Prompt to Pwn: Automated Exploit Generation for Smart Contracts

Resumen Técnico: Prompt to Pwn

1. El Problema

Los contratos inteligentes son fundamentales para las finanzas digitales, pero su inmutabilidad una vez desplegados convierte cualquier fallo en una vulnerabilidad permanente y explotable indefinidamente. Aunque existen herramientas de detección de vulnerabilidades (como Slither o Mythril) y trabajos recientes que utilizan Grandes Modelos de Lenguaje (LLMs) para detectar fallos, existe una brecha crítica: la Generación Automatizada de Explotos (AEG, por sus siglas en inglés).

La detección y la generación de explotos son tareas distintas. Mientras que la detección localiza debilidades, la AEG debe sintetizar artefactos ejecutables (código de ataque) y validarlos bajo ejecución real. El riesgo es que los LLMs, al ser accesibles vía API, podrían ser utilizados por atacantes novatos ("script kiddies") para lanzar ataques reales contra el ecosistema. Sin embargo, la capacidad de los LLMs para realizar esta tarea de extremo a extremo no había sido estudiada sistemáticamente hasta este trabajo.

2. Metodología: El Framework ReX

Para abordar esta brecha, los autores presentan ReX, un marco de trabajo basado en la ejecución que conecta la síntesis de explotos mediante LLMs con la pila de pruebas Foundry (un entorno de desarrollo y prueba para Solidity en Rust).

Flujo de trabajo de ReX:

1. Preprocesamiento: Limpieza de contratos vulnerables (eliminación de comentarios y ruido) para centrar al LLM en la lógica central.
2. Generación de Scripts: El LLM genera dos scripts en Foundry:
   • Un contrato de explotación diseñado para activar la ruta de código vulnerable.
   • Un contrato de prueba que valida si el exploit tiene éxito bajo condiciones específicas.
3. Optimización Opcional: Corrección automática de errores comunes (ej. checksums de direcciones Ethereum EIP-55, conversiones payable faltantes).
4. Compilación y Pruebas: Los scripts se integran en un proyecto Foundry, se compilan y se ejecutan (forge test).
5. Bucle de Retroalimentación Iterativa: Si la compilación o las pruebas fallan, los mensajes de error se devuelven al LLM para que corrija y regenere el código. Este ciclo se repite hasta encontrar un exploit válido o agotar los intentos.

Validación:
En lugar de depender de reglas manuales por contrato, ReX utiliza invariantes de seguridad a nivel de clase (ej. cambios de estado no autorizados, violaciones aritméticas, revertimientos inesperados) verificadas automáticamente por Foundry.

Conjuntos de Datos:

• SmartBugs-Curated: Un benchmark clásico de contratos vulnerables para pruebas controladas.
• Web3-AEG: Un nuevo dataset curado con 38+ casos reales de incidentes de alto impacto (2021-2025), incluyendo contratos explotados en la cadena de bloques y sus pruebas de concepto (PoC) escritas por expertos. Es el primer dataset de este tipo para evaluación reproducible en escenarios reales.

Modelos Evaluados:
Se probaron cinco LLMs de vanguardia: GPT-4.1, Gemini 2.5 Pro, Claude Opus 4, DeepSeek-R1 y Qwen3-Plus.

3. Contribuciones Clave

1. Primer Estudio Empírico Sistemático: Es la primera investigación que evalúa sistemáticamente la capacidad de AEG de los LLMs para contratos inteligentes bajo un pipeline unificado de benchmark y validación.
2. Framework ReX: Implementación de un pipeline automatizado de extremo a extremo que integra síntesis de LLM, compilación, ejecución y verificación determinista.
3. Dataset Web3-AEG: Creación y publicación de un dataset público con PoCs de expertos para incidentes reales, permitiendo evaluar la utilidad práctica y la capacidad de generalización de los generadores de exploits.
4. Análisis de Factores de Éxito: Identificación de qué determina el éxito o fallo en la generación de exploits (capacidad del modelo vs. complejidad del código).

4. Resultados Principales

• Capacidad de AEG: Los LLMs de vanguardia pueden generar PoCs funcionales para una subconjunto no trivial de vulnerabilidades, especialmente en contratos individuales.
  • Gemini 2.5 Pro obtuvo el mejor rendimiento general (67.3% de éxito en el benchmark), seguido por GPT-4.1 y Claude Opus 4.
  • Los modelos más pequeños (DeepSeek-R1, Qwen3-Plus) tuvieron tasas de éxito significativamente más bajas.
• Limitaciones en Ataques Cruzados: Los LLMs luchan considerablemente con ataques entre múltiples contratos (cross-contract). Mientras que los expertos humanos pueden encadenar exploits que involucran inconsistencias de estado entre varios contratos y protocolos DeFi complejos, los LLMs tienden a limitarse a la lógica local de un solo contrato.
• Factores que Influyen en el Éxito (RQ2):
  • Capacidad del Modelo: Es el factor determinante principal. La capacidad general de codificación del LLM predice su éxito en la generación de exploits.
  • Tipo de Vulnerabilidad: Los errores con patrones fijos y estructuras simples (ej. desbordamientos aritméticos) son los más fáciles de explotar. Las vulnerabilidades que requieren razonamiento sobre el estado global o el orden de transacciones (ej. front-running, control de acceso complejo) son más difíciles.
  • Estructura del Código: La complejidad estructural (tamaño del código, profundidad de anidamiento) tiene una correlación débil con la dificultad de explotación. Los LLMs no se ven obstaculizados significativamente por la complejidad superficial del código.
  • Ingeniería de Prompts: Las mejoras en los prompts (formato, roles) ofrecen beneficios marginales. El bucle de retroalimentación iterativa (reparación automática) es mucho más efectivo, duplicando las tasas de éxito en muchos casos.
• Costos: La generación automatizada es costosa en términos de tokens y tiempo, pero factible. Gemini 2.5 Pro resultó ser más eficiente en costos que GPT-4.1.

5. Significado y Defensas

Implicaciones de Seguridad:
El estudio demuestra que los LLMs pueden ser utilizados por atacantes para automatizar la creación de exploits, reduciendo la barrera de entrada para ataques contra contratos inteligentes. Sin embargo, la brecha entre un "PoC técnicamente válido" y un "ataque económico rentable" sigue siendo grande, especialmente en escenarios complejos de múltiples contratos.

Estrategias de Defensa (Hardening):
Los autores proponen técnicas de endurecimiento específicas para dificultar el análisis de los LLMs, aunque advierten que no reemplazan la corrección del fallo subyacente:

1. Externalización de Lógica: Dividir la lógica en múltiples contratos (ej. separar proxies de lógica) obliga al LLM a razonar a través de fronteras de contrato, donde su rendimiento cae drásticamente.
2. Complejidad Estructural: El uso de herencia profunda, interfaces abstractas y dispatch polimórfico confunde la trazabilidad semántica de los LLMs más que la ofuscación superficial.
3. Vulnerabilidades de Cebo (Decoys): Introducir patrones sintácticos que parecen vulnerables pero no lo son puede engañar a los LLMs, aumentando sus tasas de fallo.
4. Sintaxis de Borde: El uso de características de bajo nivel de Solidity (ej. inline assembly, Yul) degrada la capacidad del modelo para sintetizar exploits válidos.

Conclusión:
La investigación revela que, aunque los LLMs actuales son herramientas poderosas para la generación de exploits en escenarios controlados y de un solo contrato, aún carecen del razonamiento causal profundo y la comprensión del estado global necesarios para replicar los ataques complejos de múltiples contratos que ejecutan los expertos humanos. La defensa efectiva requiere combinar correcciones de seguridad tradicionales con estrategias de "fricción asimétrica" diseñadas para explotar las limitaciones de razonamiento de los LLMs.