Fuente original: Beosin
El 9 de junio, Anthropic lanzó oficialmente la versión pública Claude Fable 5 de Mythos. Anteriormente, Mythos demostró una capacidad destacada en la búsqueda de vulnerabilidades de seguridad, pudiendo descubrir rápidamente fallos ocultos dentro de los sistemas, lo que generó gran atención en el campo de la ciberseguridad.
El reciente incidente de Zcash es un ejemplo típico de la IA descubriendo vulnerabilidades en blockchain. El investigador de seguridad Taylor Hornby, utilizando el modelo Anthropic Claude Opus 4.8, descubrió en apenas unas horas una vulnerabilidad de solidez (soundness) en el pool de privacidad Orchard que había permanecido latente durante cuatro años y que no fue detectada en múltiples auditorías manuales previas. Esta vulnerabilidad permitía teóricamente acuñar ZEC falsos ilimitados sin ser detectados, lo que provocó una caída del precio del ZEC de casi el 40%.
Actualmente, la IA muestra una eficiencia asombrosa en la coincidencia de patrones de código, el cribado inicial por lotes y otras áreas. Integrar la IA en los flujos 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 desventajas de la IA en la auditoría de contratos inteligentes, combinando casos reales de vulnerabilidades y el rendimiento medido de Fable 5.
Escenarios de Ventaja de la Auditoría con IA
Caso de Estudio: Colisión de Slots de Almacenamiento
Un contrato utilizaba simultáneamente los siguientes dos componentes:
1. Un 'mapping' de recompensas personalizado (para registrar las recompensas reclamables por los usuarios).
2. La biblioteca Solady ReentrancyGuard (para prevenir ataques de reentrada).
El diseño de almacenamiento de ambos componentes entró en conflicto.
Para una optimización extrema del gas, el ReentrancyGuard de Solady utiliza un 'slot' de almacenamiento fijo y de número bajo (normalmente obtenido mediante un cálculo específico que resulta en un valor cercano a una constante). La lógica típica del modificador 'nonReentrant' es:
// Una versión simplificada
modifier nonReentrant() {
// al entrar, escribe el slot de guardia como 0xff...ff (Valor Centinela)
assembly {
if eq(sload(REENTRANCY_GUARD_SLOT), 2) { revert(...) } // 2 representa bloqueado
sstore(REENTRANCY_GUARD_SLOT, 2) // bloqueado
}
_;
// restaura cuando la función finaliza
assembly { sstore(REENTRANCY_GUARD_SLOT, 1) }
}
El 'mapping' de recompensas personalizado:
mapping(address => uint256) public rewards;
Debido a las reglas de diseño de almacenamiento de Solidity (el primer slot de un 'mapping' se calcula a partir de su posición de declaración), el primer slot del 'mapping' 'rewards' coincidía exactamente con el slot fijo de protección de ReentrancyGuard.
Flujo del ataque (pasos detallados):
1. El atacante llama a la función getReward().
2. Se activa el modificador nonReentrant, que escribe en el slot de guardia 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (todos 1s).
3. El código del contrato luego lee rewards[dirección_del_atacante]. Pero debido a la colisión de slots, lo que realmente lee es el enorme valor 0xff...ff almacenado en el slot de guardia.
4. El contrato interpreta que "hay una recompensa enorme", por lo que transfiere esa cantidad de ETH al atacante, e intenta poner rewards[atacante] a cero (pero escribe de nuevo en el mismo slot de guardia).
5. Dado que el modificador restaurará el slot al finalizar la función, cuando el atacante vuelva a llamar a getReward(), el proceso se repite.
6. El atacante llama cíclicamente 200 veces, extrayendo con éxito una cantidad fija de ETH cada vez, hasta agotar el ETH extraíble del contrato.
Es importante señalar que esto no es un "ataque de reentrada" (reentrancy attack) tradicional, sino que el propio mecanismo de protección de ReentrancyGuard fue aprovechado en sentido contrario por la colisión de almacenamiento, convirtiéndose en una vulnerabilidad de reclamación infinita. Durante una auditoría manual, rara vez se profundizaría línea por línea en el diseño de almacenamiento de bibliotecas de terceros, mientras que la IA puede completar instantáneamente la comparación de versiones de bibliotecas + el mapeo preciso de slots de almacenamiento, detectando directamente este tipo de vulnerabilidades de "colisión oculta".
Escenarios de Desventaja de la Auditoría con IA
Fable 5 mostró un rendimiento excelente en la detección de vulnerabilidades en contratos individuales, puramente de sintaxis de código, o de bajo nivel relacionadas con almacenamiento. Sin embargo, aún presenta limitaciones evidentes al enfrentarse a semánticas combinadas entre protocolos o ataques que involucran múltiples contratos. Utilizamos la última versión pública de Fable 5 para reevaluar los contratos relacionados con el incidente de ataque a Curve LlamaLend sDOLA, y los resultados confirman este problema.
Lista de contratos involucrados en esta auditoría: crvUSD Controller.vy, sDOLA.sol, ERC4626.sol, entre otros. Fable 5 no logró identificar el riesgo central correspondiente a este ataque:
Este evento pertenece a una vulnerabilidad combinada típica entre protocolos. La sintaxis y lógica del código de un contrato individual no presentaban problemas, pero el atacante aprovechó la interacción de múltiples protocolos para construir una cadena de ataque:
1. Utilizando herramientas de préstamo flash (flashloan), manipuló el precio del pool de liquidez de Curve, bajando maliciosamente el precio del activo sDOLA (participaciones del vault ERC-4626).
2. Numerosas posiciones de préstamo con sDOLA como colateral alcanzaron el umbral de liquidación.
3. El atacante ejecutó operaciones de liquidación en masa, obteniendo ganancias.
Este tipo de vulnerabilidades se forman a partir de la combinación de múltiples protocolos DeFi y ponen a prueba la capacidad de análisis integral del modelo de negocio general y el modelo económico de los protocolos, tanto por parte de la IA como de los auditores expertos. Actualmente, la auditoría con IA aún presenta deficiencias en la semántica combinada entre protocolos.
Conclusión
Mediante pruebas con casos reales se puede observar que Fable 5, en escenarios estandarizados y detallados como conflictos de slots de almacenamiento, vulnerabilidades de patrones de código, defectos de lógica en contratos individuales y cribado inicial por lotes de código, puede descubrir eficazmente vulnerabilidades ocultas que las auditorías manuales suelen pasar por alto. Sin embargo, al tratar con semánticas combinadas entre protocolos, modelos económicos DeFi, ataques que involucran múltiples contratos o vulnerabilidades de lógica de negocio compleja, le resulta difícil comprender la esencia del negocio del ecosistema on-chain y descubrir rutas de ataque combinadas. Esta parte aún requiere un análisis dirigido por auditores de seguridad profesionales.
En el trabajo diario de auditoría, Beosin ha establecido un proceso de auditoría maduro que combina IA + expertos en auditoría de seguridad. Esto no solo mejora significativamente la eficiencia de la auditoría, sino que también permite una mejor identificación de riesgos detallados potenciales y vulnerabilidades de lógica de negocio complejas, haciendo el trabajo de auditoría más eficiente, integral y profundo.
