El ataque no pareció provenir de una brecha directa en el código del contrato inteligente de Ostium. En cambio, los materiales de fuente validados apuntan a la manipulación de los informes de precios mediante una clave privada de oracle comprometida. Esa distinción es importante porque muestra que el riesgo no solo estaba en los contratos en cadena, sino también en la infraestructura fuera de cadena que alimentaba datos al sistema.
Los intercambios de perpetuos dependen de precios precisos. Si la fuente de precios puede ser manipulada, todo el lugar de operación se vuelve vulnerable.
La respuesta de Ostium fue suspender las operaciones mientras investigaba el incidente.
TL;DR
- Ostium suspendió el comercio tras una explotación de $18.4 millones.
- El ataque involucró una clave privada de oracle fuera de cadena comprometida.
- El incidente destaca el riesgo en la gestión de claves del oracle, más que una violación directa del contrato inteligente.
Por qué los fallos de Oracle son tan peligrosos
Los mercados de perpétuos necesitan precios confiables.
El colateral de un operador, su nivel de liquidación, su beneficio o pérdida, su exposición al financiamiento y su valor de liquidación dependen de los datos de precios. Si esos datos son incorrectos, el mercado puede ser explotado incluso si los contratos de operación principal funcionan exactamente como fueron diseñados.
Por eso, la infraestructura de oracle es una de las capas más sensibles del DeFi.
Se encuentra entre los datos del mundo real o del mercado y la ejecución en la cadena. Un protocolo puede tener contratos auditados, pero si los datos que alimentan esos contratos pueden ser manipulados, el sistema sigue siendo vulnerable.
En el caso de Ostium, el problema parece involucrar una clave de oracle fuera de cadena comprometida. Eso significa que el atacante pudo interferir con la ruta de informes confiable, en lugar de simplemente encontrar un error normal en el contrato.
Ese tipo de fallo puede ser más difícil de entender para los usuarios, ya que el problema no siempre es visible de la misma manera que una explotación de contrato.
La cadena de bloques puede registrar las transacciones, pero el punto débil puede ser la infraestructura detrás de los datos.
El contrato inteligente no fue el único riesgo
La distinción entre el riesgo de contrato inteligente y el riesgo de oracle es importante.
Los usuarios de criptomonedas a menudo preguntan si los contratos de un protocolo han sido auditados. Eso es importante, pero no suficiente. Un protocolo de trading también depende de sistemas de precios, claves administrativas, redes de keepers, puentes, bots de liquidación, interfaces de usuario y seguridad operativa.
Cualquiera de esas capas puede convertirse en un punto débil.
Si la clave privada de un oracle se ve comprometida, los atacantes pueden no necesitar romper el contrato inteligente. Pueden proporcionar al contrato información falsa y obtener beneficios a partir de la reacción del sistema.
Por eso, la seguridad de DeFi debe ser más amplia que la revisión de código.
Los protocolos necesitan gestión de claves, monitoreo, sistemas de alerta, interruptores de circuito, fuentes de respaldo y procedimientos de emergencia claros. Cuanto más rápido un lugar pueda detectar precios anormales y pausar operaciones peligrosas, más daño podrá prevenir.
La suspensión del comercio de Ostium muestra que los controles de emergencia siguen siendo esenciales.
Arbitrum DeFi enfrenta otra prueba de seguridad
Arbitrum sigue siendo uno de los ecosistemas de capa 2 de ethereum más activos para DeFi.
Esa actividad genera liquidez, operadores e innovación, pero también atrae a atacantes. Los lugares de perpetuos son especialmente atractivos porque concentran colaterales y dependen de precios en tiempo real.
Una explotación de $18.4 millones es lo suficientemente grande como para afectar al ecosistema, incluso si no amenaza a Arbitrum en sí.
El incidente no debe presentarse como un fallo de la red Arbitrum. El problema es específico de la infraestructura de oracle de Ostium. Pero para los usuarios, cada explotación suma a la pregunta más amplia sobre cuán seguros son en la práctica los entornos DeFi de capa 2.
Esa pregunta es importante a medida que más capital se mueve hacia redes más rápidas y económicas.
La escalabilidad de capa 2 reduce los costos de transacción, pero no elimina el riesgo a nivel de aplicación. Los usuarios aún deben evaluar el diseño, el modelo de seguridad y los controles operativos de cada protocolo.
¿Qué viene a continuación para Ostium?
La prioridad inmediata es la investigación, la contención y la comunicación con los usuarios.
Ostium debe explicar qué sucedió, qué sistemas se vieron afectados, si los saldos de los usuarios son recuperables, cómo se reanudará el comercio y qué controles cambiarán antes de reabrir.
Para los operadores, la pregunta más importante es si el sistema oracle ha sido reconstruido o suficientemente asegurado para evitar una repetición.
Un intercambio de trading puede sobrevivir a una explotación si la respuesta es transparente y la solución es creíble. Se vuelve mucho más difícil si los usuarios quedan sin claridad sobre dónde ocurrió el fallo o si la misma vía sigue expuesta.
El mercado en general también debería prestar atención.
El riesgo clave de Oracle no es exclusivo de un solo exchange. Cualquier protocolo que dependa de firmas fuera de la cadena, fuentes de precios o rutas de informes privilegiadas debe considerar cuidadosamente los escenarios de compromiso.
La lección es sencilla: los sistemas DeFi son tan fuertes como el componente más débil de confianza.
Los contratos de Ostium quizás no hayan sido violados directamente, pero el mercado aún sufrió una explotación importante. Por eso, la seguridad del oracle sigue siendo uno de los problemas más importantes en el comercio en cadena.
Este artículo se basa en la declaración pública de Ostium y los datos de transacciones de Arbiscan.
Este artículo fue escrito por el Equipo de Noticias y editado por Samuel Rae.
Este informe se basa en la información publicada en divulgaciones oficiales de fuentes primarias en primary source documentation.