El 9 de junio, Anthropic lanzó oficialmente la versión pública de Claude Fable 5 de Mythos. Anteriormente, Mythos destacó por su capacidad para detectar vulnerabilidades de seguridad, encontrando rápidamente fallos ocultos en el sistema, lo que generó gran atención en el ámbito de la ciberseguridad.
El reciente evento de Zcash es un ejemplo clásico de cómo la IA explota vulnerabilidades en blockchain. El investigador de seguridad Taylor Hornby utilizó el modelo Anthropic Claude Opus 4.8 para descubrir en pocas horas una vulnerabilidad de solidez en el depósito privado Orchard, que había estado oculta durante cuatro años y no había sido detectada en múltiples auditorías manuales previas; esta vulnerabilidad teóricamente permitía acuñar ZEC falsos ilimitados sin detección, provocando una caída del 40% en el precio de ZEC.
Actualmente, la IA demuestra una eficiencia asombrosa en la coincidencia de patrones de código y la filtración inicial por lotes, y su integración en los procesos de auditoría de seguridad de blockchain y contratos inteligentes se está convirtiendo en una tendencia en la industria de la seguridad Web3. Este artículo analizará las ventajas y limitaciones de la IA en la auditoría de contratos inteligentes, combinando casos reales de vulnerabilidades y el rendimiento práctico de Fable 5.
Escenarios de ventaja de la auditoría de IA
Análisis de caso: Colisión de ranuras
Un contrato utiliza simultáneamente los siguientes dos componentes:
1. Mapeo personalizado de recompensas (para registrar las recompensas que el usuario puede reclamar)
2. ReentrancyGuard de la biblioteca Solady (para prevenir ataques de reentrada)
Y se produjo un conflicto en la disposición del almacenamiento de ambos componentes.
En Solady, ReentrancyGuard optimiza el gas al máximo utilizando ranuras de almacenamiento fijas y de número bajo (generalmente obtenidas mediante un cálculo específico que produce una ranura cercana a un constante). La lógica típica del modificador nonReentrant es:
// Una versión simplificada modifier nonReentrant() { // al entrar, escribir la ranura de protección como 0xff...ff (Valor centinela) assembly { if eq(sload(REENTRANCY_GUARD_SLOT), 2) { revert(...) } // 2 representa bloqueado sstore(REENTRANCY_GUARD_SLOT, 2) // bloqueado } _; // recuperar cuando finaliza la función assembly { sstore(REENTRANCY_GUARD_SLOT, 1) }}
Mapeo de recompensas personalizado:
mapping(address => uint256) public rewards;
Debido a las reglas de disposición de almacenamiento de Solidity (el primer slot de un mapping es calculado según su posición de declaración), el primer slot del mapping de recompensas coincide exactamente con el slot de protección fijo de ReentrancyGuard.
Proceso de ataque (pasos detallados):
1. El atacante llama a la función getReward()
2. Se activó el modificador nonReentrant, escribiendo el slot de protección con 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (todos 1)
3. El código del contrato luego lee rewards[ dirección del atacante ], pero debido a una colisión de ranuras, en realidad lee el valor extremadamente grande 0xff...ff del slot guard.
4. El contrato considera que "hay una recompensa enorme", por lo que transfiere este ETH al atacante y intenta limpiar rewards[atacante] (pero vuelve a escribir en la misma ranura de protección).
5. Debido a que el modifier restaura el slot al finalizar la función, el atacante puede volver a llamar a getReward() y repetir el proceso.
6. El atacante llama repetidamente 200 veces, extrayendo con éxito una cantidad fija de ETH en cada llamada hasta que se agota el ETH disponible en el contrato.
Es importante tener en cuenta que esto no es un "ataque de reentrada" en el sentido tradicional, sino que el mecanismo de protección de ReentrancyGuard fue invertido y explotado debido a una colisión de almacenamiento, convirtiéndose en una vulnerabilidad que permite reclamar recompensas ilimitadas. Durante las auditorías manuales, rara vez se analiza línea por línea la disposición de almacenamiento de bibliotecas de terceros, mientras que la IA puede completar instantáneamente la comparación de versiones de la biblioteca y el mapeo preciso de los slots de almacenamiento, detectando directamente este tipo de vulnerabilidades de "colisión oculta".
Escenarios desfavorables de auditoría de IA
Fable 5 destaca en la detección de vulnerabilidades en contratos únicos, sintaxis de código puro y almacenamiento subyacente, pero presenta limitaciones evidentes frente a semánticas de combinación entre protocolos y ataques de combinación de múltiples contratos. Utilizamos la versión más reciente y pública de Fable 5 para volver a probar los contratos relacionados con el ataque a Curve LlamaLend sDOLA, lo que confirmó este problema.
La presente auditoría abarca la lista de contratos: crvUSD Controller.vy, sDOLA.sol, ERC4626.sol, entre otros. Sin embargo, Fable 5 no identificó el riesgo central correspondiente a este ataque:
Este evento es una vulnerabilidad típica de combinación entre protocolos; el código del contrato individual no tiene problemas de sintaxis ni lógica, pero el atacante aprovechó la interacción entre múltiples protocolos para construir una cadena de ataque:
1. Utilizando herramientas de préstamos relámpago, manipular el precio del pool de Curve, reduciendo intencionadamente el precio de los activos de sDOLA (cuotas del depósito ERC-4626);
2. Se activó el umbral de liquidación para numerosas posiciones de préstamo garantizadas con sDOLA;
3. Los atacantes ejecutan operaciones de liquidación en masa para obtener beneficios.
Estas vulnerabilidades se basan en combinaciones multi-protocolo DeFi y ponen a prueba la capacidad de análisis integral de los expertos en IA/auditoría sobre el negocio general y los modelos económicos de los protocolos; actualmente, la auditoría por IA aún presenta deficiencias en la semántica de combinaciones entre protocolos.
Conclusión
A través de pruebas con casos reales, se puede ver que Fable 5 es capaz de identificar eficazmente vulnerabilidades ocultas que los auditores humanos suelen pasar por alto en escenarios estandarizados y detallados, como conflictos en ranuras de almacenamiento, vulnerabilidades en patrones de código, defectos lógicos en contratos individuales y filtrado inicial por lotes de código. Sin embargo, al manejar semántica de combinación entre protocolos, modelos económicos DeFi, ataques coordinados entre múltiples contratos y vulnerabilidades en lógica de negocio compleja, tiene dificultades para comprender la esencia empresarial del ecosistema en cadena y descubrir rutas de ataques combinados; esta parte sigue requiriendo el análisis liderado por auditores de seguridad profesionales.
En el trabajo diario de auditoría, Beosin ha establecido un proceso de auditoría maduro que combina IA con expertos en seguridad, lo que no solo mejora significativamente la eficiencia de la auditoría, sino que también permite identificar mejor riesgos potenciales en detalles y vulnerabilidades en lógicas de negocio complejas, haciendo que el trabajo de auditoría sea más eficiente, completo y profundo.