Este artículo fue compilado y organizado por BlockWeeks
La plataforma Ostium fue explotada por atacantes, robando aproximadamente 24 millones de dólares en USDC, involucrando ocho transacciones. Los atacantes, al poseer simultáneamente las claves de firma de los oráculos autorizados y el rol de PriceUpKeep, presentaron informes de precios firmados correctamente con fechas futuras, y abrieron y cerraron repetidamente pares de trading, creando así ganancias falsas sin tener realmente exposición al mercado.
El ataque ocurrió en ocho transacciones, cada una transfiriendo fondos a la misma billetera 0x321Df1…8bfD9, donde la mayor transferencia individual fue una operación de apertura-cierre cíclica ejecutada en un lote atómico. Ostium opera en Arbitrum, permitiendo a los usuarios operar derivados en forma de contratos a plazo que rastrean el precio de los activos subyacentes, pero sin entrega del activo subyacente ni fecha de vencimiento fija.
El problema se origina en cómo el sistema de oráculos de Ostium autoriza los datos de precios. Los validadores reciben informes de precios, derivan la identidad del firmante a partir de la firma y verifican si el firmante está en la lista autorizada. Solo verifican la identidad del firmante, no la precisión del precio en sí. Los atacantes, al poseer simultáneamente las claves de firma de los oráculos autorizados y el rol registrado de PriceUpKeep (responsable de cumplir con las órdenes pendientes), utilizaron esta combinación para presentar informes de precios firmados correctamente con fechas futuras, y luego abrieron y cerraron repetidamente pares de trading que se cubrían entre sí. Esto les permitió generar ganancias comerciales desde la perspectiva del sistema, sin tener realmente exposición al mercado.
El incidente de Ostium es uno de los múltiples exploits importantes a nivel de aplicación este año, incluidos los casos de Drift y KelpDAO con rsETH. Un tema común es que los contratos inteligentes y su lógica siguen siendo sólidos; los atacantes se dirigen principalmente a la infraestructura operativa y la confianza humana: en el caso de Ostium, credenciales de firmante comprometidas; en el caso de Drift, una toma de control administrativa pre-firmada mediante ingeniería social; y en el caso de KelpDAO, infraestructura RPC envenenada.
Después de estos exploits de alto perfil, algunos han pedido salvaguardas a nivel de aplicación para los fondos de los usuarios, como limitar los retiros, para disuadir el comportamiento malicioso y limitar las pérdidas cuando ocurren exploits. Tales sugerencias deben ser resistidas.
Limitar los retiros introduce un riesgo directo de censura a nivel de aplicación. Una vez que un protocolo puede retrasar o limitar unilateralmente los depósitos o retiros de los usuarios, el concepto de autocustodia en esa capa de aplicación ya no es absoluto, sino condicional. En tal caso, quien decide la disponibilidad y el uso de los fondos es la aplicación, no el usuario. Esta práctica también difumina la línea entre atacantes y usuarios comunes, porque las salvaguardas diseñadas para detener a los atacantes inevitablemente se aplican a todos los usuarios de la aplicación.
El riesgo de "efecto pendiente resbaladiza" agrava aún más este problema. Una vez que un protocolo tiene la capacidad técnica de limitar o congelar depósitos/retiros, esta capacidad se convierte en un precedente. Los reguladores pueden citar esto como evidencia de que estas aplicaciones ya tienen las herramientas para cumplir con órdenes de congelación, puertas KYC u otros requisitos, y por lo tanto también deberían ser obligadas a hacerlo. Las salvaguardas construidas para detener ataques podrían convertirse en un gancho que arrastre a los protocolos hacia obligaciones que de otro modo no podrían asumir.
Además, los participantes inocentes del mercado también se verían incentivados a eludir la fricción causada por estas medidas. Por ejemplo, los usuarios restringidos que buscan formas de salir de su exposición económica generalmente significan la aparición de un objeto de reclamo negociable para llenar el vacío (como tokens de recibo, IOUs, envolturas alternativas de criptomonedas). Este reclamo en sí mismo se convierte en una nueva dependencia con su propio perfil de riesgo: a nivel de mercado (anclajes que pueden romperse, descuentos que se amplían durante el pánico) y a nivel técnico (nuevos contratos, nuevos oráculos, nuevas entidades explotables independientes de la aplicación). Las salvaguardas destinadas a contener un punto único de falla terminan exacerbando la vulnerabilidad que pretenden prevenir.
Este tipo de contenido no implica que los protocolos no deban fortalecer lo que realmente falla (por ejemplo, la gestión de claves de firma, la redundancia de validadores). Pero la forma de reparar las debilidades en la infraestructura operativa y la confianza humana es fortalecer esos aspectos, no agregar control arbitrario sobre los fondos de los usuarios, lo que socava la propuesta de valor central de lo que se protege.
