Aviso de 680 millones de dólares: la mayoría de los ataques DeFi quedan fuera del alcance de las auditorías

Autor: Liam 'Akiba' Wright, cryptoslate

Compilación: Chopper, Foresight News

En el ámbito de las finanzas descentralizadas, «auditado» suele considerarse un respaldo de seguridad para todo el proyecto. Pero en realidad, las auditorías normalmente solo cubren un momento específico, un código, componentes y versiones determinados. Cualquier cosa que se añada, elimine o manipule fuera de ese alcance puede tener un resultado de auditoría completamente distinto.

Un nuevo artículo preprint ofrece cifras concretas sobre esta brecha. Investigadores de la empresa de seguridad ack3 y de la Universidad Técnica Checa en Praga analizaron 135 incidentes de seguridad reportados en el primer semestre de 2025, con pérdidas de hasta 939,86 millones de dólares. Descubrieron que 68 de esos incidentes tenían registros de auditoría pública identificables antes del ataque.

En esa muestra de 68 incidentes, los investigadores clasificaron 46 rutas de ataque como completamente fuera del alcance de cualquier auditoría verificable; 20 incidentes estaban al menos parcialmente cubiertos por una auditoría; y los 2 restantes no pudieron determinarse. Los incidentes fuera del alcance representaron el 67,6 % del total, pero sus pérdidas correspondieron al 94,4 % del total reportado.

Esta proporción sorprendente no es una evaluación de la eficacia de las auditorías ni una prueba de que las limitaciones del alcance causen pérdidas. Solo representa la distribución de pérdidas en la muestra seleccionada de incidentes de seguridad públicos. Dos incidentes extraordinarios influyeron enormemente en los datos: si se excluyen la pérdida de 292 millones de dólares de Kelp DAO y la de 285 millones de Drift Protocol, en la misma muestra auditada, la proporción de pérdidas por ataques fuera del alcance baja al 72,1 %.

Aun con esas limitaciones, el estudio revela un problema básico de confianza en la seguridad: un proyecto afirma haber sido auditado, pero los usuarios no pueden saber si el sistema que realmente funciona, los flujos de fondos y los controles asociados han sido revisados.

El verdadero significado de los datos

La investigación de ack3 cubre del 1 de enero al 29 de junio de 2025, con 122 ataques confirmados y 13 sospechosos. De toda la muestra, 35 incidentes no tenían registros de auditoría y 32 tenían historial de auditoría desconocido; ambos grupos no se incluyen en las estadísticas de los 68 incidentes mencionados.

En la muestra de 68 incidentes, las pérdidas fuera del alcance ascendieron a 680,97 millones de dólares, sobre un total de 721,24 millones, lo que da el 94,4 %. Al excluir Kelp DAO y Drift Protocol, las pérdidas fuera del alcance fueron de 103,97 millones, sobre un total de 144,24 millones, es decir, el 72,1 %. El archivo json del conjunto de datos permite reproducir el número de incidentes clasificados y los montos de pérdidas.

La etiqueta «dentro/fuera del alcance de auditoría» es un juicio de los investigadores basado en evidencia pública. El equipo consultó los archivos del proyecto y de las firmas auditoras, encontró los informes de auditoría previos al ataque y comparó la ruta final del ataque con el código auditado, las versiones y las exclusiones de la auditoría. El estudio es un preprint de 6 páginas, elaborado junto con los publicadores del conjunto de datos, y dos de sus autores pertenecen a la firma de auditoría de seguridad ack3.

El estudio carece de un grupo de control sin ataques y no calcula el tiempo de exposición al riesgo de cada sistema. Por tanto, no puede demostrar que los protocolos auditados sean en general más seguros, ni estimar la probabilidad de incidentes, ni confirmar que «fuera del alcance de auditoría» sea la causa directa de cada pérdida. Es posible que falten auditorías no públicas e incidentes privados, y los datos de pérdidas reportados no son totalmente comparables.

Por ello, el estudio solo puede llegar a conclusiones limitadas: los registros de auditoría y la cobertura de auditoría son dos indicadores independientes. Un contrato inteligente auditado no garantiza que las actualizaciones del contrato, las claves privilegiadas, el frontend, los repetidores, los oráculos, los servicios en la nube o los procesos de respuesta de emergencia tengan el mismo nivel de seguridad.

Dos incidentes ocurridos en agosto confirman esta distinción desde ángulos distintos. El caso de ICON Network muestra de forma directa cómo dos fragmentos de código auditados fallan en el límite entre dos puntos de verificación; mientras que el incidente de seguridad de aelf en agosto es otro caso: la evidencia de auditoría existente aún no permite asignar la ruta de ejecución del ataque al alcance de una auditoría previa.

ICON Network: una muestra de fallo en el límite de la revisión

En el ataque de repetición a ICON Network del 27 de agosto, dos módulos de la cadena de retiro interpretaron de forma distinta el mismo mensaje.

Según el informe retrospectivo de la Fundación ICON: el contrato de migración se basaba en los bits altos del número de secuencia del mensaje de retiro para determinar si el mensaje era único; pero la firma criptográfica solo cubría los 256 bits bajos del número de secuencia. El atacante modificó los bits altos no incluidos en la verificación de firma y, en unos 20 minutos, presentó repetidamente 1492 mensajes de retiro con firmas legítimas, de los cuales 1490 llamadas se ejecutaron con éxito.

Este ataque de repetición liberó 119,866 millones de ICX y 531 600 bnUSD. Al publicarse el informe, ICON confirmó una pérdida neta de aproximadamente 150,2 ETH más 31 204 USDC. La fundación afirmó que se recuperaron 531 600 bnUSD y 1,366 millones de SODA, y que los depósitos de los usuarios, los saldos de cuentas y las posiciones no se vieron afectados.

ICON indicó que este contrato de migración ya había pasado una auditoría externa y que se aplicaron las recomendaciones, incluidas modificaciones relacionadas en la misma zona del módulo; la lógica de retransmisión correspondiente también recibió una revisión especializada por separado. La lista de auditorías de la documentación de desarrollo de Sodax incluye 8 informes que cubren distintos componentes, entre ellos el informe de auditoría del repetidor de Sodax de noviembre de 2025.

Pero el informe retrospectivo señala que la discrepancia exacta entre la lógica de verificación de unicidad y el valor de verificación de firma no estaba dentro de los hallazgos de dichas auditorías. Una simple etiqueta de proyecto «auditado» no permite al usuario saber si los criterios de «unicidad del mensaje» en ambos extremos de la cadena de retiro son coherentes.

La línea de tiempo de respuesta también expone otro tipo de problema de límites. La primera alerta automatizada de ICON se activó a las 02:08 UTC, unos 7 minutos después del inicio del ataque. El personal inició la investigación alrededor de las 03:40, pausó el contrato afectado a las 03:53 y detuvo toda la red a las 06:18:54.

Entre la primera alerta y la respuesta de emergencia completa hubo un intervalo de unos 90 minutos. ICON lo atribuye al ajuste del mecanismo de alertas: esa regla había generado muchas falsas alarmas en fallos anteriores de conectividad de red, por lo que no se notificaba con alta prioridad al personal de guardia. La fundación planea implementar mecanismos de apagado automático, reducir el umbral de fusible y realizar una revisión especializada sobre unicidad de mensajes y protección contra repeticiones.

Este tipo de mecanismos de control de riesgos no sustituye a la auditoría, pero responde a otra pregunta clave: cuando fallan las medidas preventivas, ¿puede el sistema detectar y aislar rápidamente el riesgo?

aelf: la garantía de seguridad necesita actualización continua

El incidente de seguridad de aelf en agosto confirma lo anterior desde otro ángulo. La información pública describe una intrusión en tiempo de ejecución y una recuperación controlada, pero la evidencia existente no basta para determinar si la ruta del ataque estaba dentro del alcance de una auditoría previa específica.

El anuncio oficial del proyecto indica que existía un contrato inteligente no autorizado capaz de inyectar ensamblados .NET codificados e instrucciones en la cadena de ejecución del nodo mediante parámetros de transacción.

El informe preliminar atribuye el incidente a deficiencias en la validación de reflexión en tiempo de ejecución y carga dinámica, junto con un aislamiento insuficiente entre el entorno de ejecución de contratos y los nodos sensibles y recursos de infraestructura. aelf identificó 155 transacciones relacionadas y 5 ensamblados de carga independientes, con capacidades para ejecutar comandos del host, intentar comunicaciones externas, acceder a claves del nodo y realizar reconocimiento de infraestructura.

Tener capacidad no equivale a confirmar que todas las cargas se ejecutaron con éxito, ni que el atacante obtuvo todas las credenciales objetivo o que se filtraron datos sensibles. aelf declaró que rotó las claves de firma y las credenciales de infraestructura según los estándares de posible exposición.

Hasta el 11 de septiembre, esa conclusión seguía siendo provisional. El blog oficial de aelf no publicó ninguna actualización específica sobre este incidente después del 26 de agosto. El anuncio del 26 de agosto prometía publicar actualizaciones y un informe final posteriormente.

La documentación técnica de seguridad de aelf indica que su blockchain y el contrato del token ELF pasaron varias rondas de auditoría sin que se encontraran problemas de seguridad. Pero las páginas públicas actuales no permiten relacionar la ruta de ejecución del ataque de agosto con ningún informe de auditoría previo. Por tanto, calificar el incidente como negligencia de auditoría o como fallo fuera del alcance carece de evidencia suficiente.

Esta incertidumbre en sí misma es significativa. Un informe de auditoría con sello de tiempo se va desvinculando gradualmente del código actual del sistema, de las bibliotecas dependientes y del estado operativo real. Los usuarios necesitan un registro de seguridad versionado que refleje esa diferencia.

Ese registro de seguridad debería indicar: el repositorio auditado y la versión del commit de código, las direcciones de los contratos desplegados, los componentes excluidos, los roles privilegiados y las bibliotecas dependientes; además, registrar las actualizaciones de contratos posteriores a la auditoría, la custodia y rotación de claves, la política de aislamiento en tiempo de ejecución, los mecanismos de alerta y fusible, y el estado de recuperación de activos con sello de tiempo, distinguiendo pérdidas confirmadas, activos congelados y exposiciones de riesgo no resueltas.

Esto no niega el valor de la auditoría, sino que busca que la publicidad de la auditoría coincida con el trabajo real realizado y se relacione con el sistema que está actualmente en funcionamiento.

Una insignia de auditoría no puede responder si los componentes auditados, el sistema desplegado y los mecanismos de respuesta a fallos siguen dentro del mismo perímetro de seguridad.