Reentrancy Attack (Ataque de Reentrada)
⚡ Definición Rápida
Un reentrancy attack (ataque de reentrancia) ocurre cuando un smart contract permite que un atacante vuelva a entrar a una función antes de que se actualice el estado, repitiendo retiros o acciones y drenando fondos.
Términos relacionados: smart contract • audit • exploit • flash loan attack • liquidity pool
El exploit que cambió Ethereum para siempre
El ataque de reentrada no es solo una vulnerabilidad técnica; es un hito histórico en la seguridad cripto que llevó a la bifurcación (hard fork) de Ethereum y a la pérdida de decenas de millones. Imagina un cajero automático que, antes de actualizar tu saldo después de entregarte el dinero, te permite insertar la misma tarjeta y pedir otra vez… y otra, y otra, hasta vaciarlo.
Eso es un ataque de reentrada. Su peligro radica en su elegancia y poder destructivo: con unas pocas líneas de código en un contrato mal diseñado, un atacante puede secuestrar la lógica del contrato y convertir una simple llamada en un bucle de saqueo. Es la vulnerabilidad por excelencia que enseñó al ecosistema que en el mundo de los smart contracts, el orden de las operaciones (cómputos vs. actualizaciones) es una cuestión de vida o muerte para los fondos.
📖 Definición Técnica
Un Reentrancy Attack (Ataque de Reentrada) es una vulnerabilidad crítica en contratos inteligentes donde una función maliciosa externa realiza una llamada recursiva repetida a la función de un contrato vulnerable antes de que su estado interno se actualice. Esto permite al atacante retirar fondos repetidamente en un solo bloque de transacción, drenando en muchos casos la totalidad de los activos del contrato.
⚙️ Mecánica del ataque: Cómo se drena un contrato en segundos
El núcleo del exploit es la violación del patrón Checks-Effects-Interactions. Un contrato vulnerable realiza una interacción externa (enviar fondos) antes de hacer el efecto (actualizar el saldo interno).
| Paso | Contrato Vulnerable (Mal Diseñado) | Contrato Atacante (Malicioso) | Resultado del Estado |
|---|---|---|---|
| 1. Llamada Inicial | El usuario/atacante llama a withdraw(100). | El contrato atacante llama normalmente a la función de retiro. | Saldo del atacante en el contrato: 100 (aún no actualizado). |
| 2. Interacción Externa (ERROR) | El contrato ENVÍA los 100 ETH al llamante antes de actualizar saldos.msg.sender.call{value: 100}("") | Al recibir los ETH, su función receive() o fallback() se ejecuta AUTOMÁTICAMENTE. | El atacante ya tiene 100 ETH, pero el contrato vulnerable aún cree que le debe 100. |
| 3. Reentrada (El Ataque) | Mientras procesa el pago, está «en pausa». | La función receive() del atacante LLAMA DE NUEVO a withdraw(100) del contrato vulnerable. | El contrato vulnerable verifica: «¿Saldo ≥ 100?» → SÍ (porque aún no lo restó). |
| 4. Repetición y Drenaje | Vuelve al paso 2: envía OTROS 100 ETH… y así sucesivamente. | Este bucle se repite hasta que: a) se acaba el gas, b) el contrato víctima se queda sin fondos, o c) se alcanza el límite de profundidad de llamada. | El saldo interno del atacante sigue siendo 100 para el contrato vulnerable, permitiendo retiros infinitos en un loop. |
| 5. Actualización Tardía | Finalmente, tras todas las llamadas, actualiza: balances[msg.sender] -= 100. | El atacante ya se ha llevado todo el ether. | La actualización es irrelevante: el contrato está vacío. El atacante ha ganado. |
La clave es que la llamada externa (.call) cede el control al receptor, dándole la oportunidad de ejecutar código arbitrario (y malicioso) antes de que el contrato original complete su lógica.
🔀 Tipos de Ataques de Reentrada
No todos los ataques de reentrada son iguales. Su sofisticación varía:
1. Reentrancy de Función Única (Single-Function)
El atacante vuelve a llamar a la misma función que está explotando (como en el ejemplo de `withdraw`). Es el más común y sencillo.
2. Reentrancia Cruzada (Cross-Function)
El atacante aprovecha que dos funciones comparten un estado. Al llamar a la Función A, durante su ejecución, llama a la Función B que también modifica el mismo estado (ej: el saldo), creando inconsistencias que puede explotar.
3. Reentrancia Basada en Delegatecall
Más sofisticado. Explota contratos que usan `delegatecall` para ejecutar código desde otra dirección (como en proxies actualizables), pudiendo manipular el almacenamiento del contrato llamante.
Recurso externo recomendado: Para una comprensión técnica profunda y ejemplos de código, el informe «ConsenSys Diligence: Stop using Solidity’s transfer()» explica no solo el ataque, sino también mejores prácticas para evitarlo.
💥 Casos históricos y el impacto en el ecosistema
- The DAO Hack (2016): El ataque de reentrada más famoso y costoso. Drenó 3.6 millones de ETH (valorados entonces en ~$50 millones) del contrato de The DAO. Este evento obligó a un hard fork de Ethereum, creando Ethereum (ETH) y Ethereum Classic (ETC). Es la prueba definitiva de que un bug de contrato puede tener consecuencias a nivel de blockchain.
- Lendf.Me Hack (2020): Un protocolo DeFi de préstamos perdió $25 millones debido a un ataque de reentrada cruzada que explotó un token ERC-777 (que tiene «hooks» que notifican al emisor/receptor, facilitando la reentrada).
- Cream Finance Hack (2021): Pérdida de $130 millones en un ataque de reentrada flash loan (préstamo flash) combinado, donde el atacante usó un préstamo instantáneo para manipular los precios de un activo y explotar una función de préstamo.
- SurpriseBNB (2022): Un ataque de reentrada en la blockchain de BNB Chain (BSC) que robó $570,000, demostrando que la vulnerabilidad no es exclusiva de Ethereum.
🛡️ Prevención y Mitigación: Código seguro desde el día uno
La defensa contra la reentrada es un pilar del desarrollo seguro de smart contracts.
1. Patrón Checks-Effects-Interactions (CEI)
La regla de oro. Primero, verifica todas las condiciones y requisitos (Checks). Después, actualiza todos los estados y saldos internos (Effects). Por último, interactúa con otros contratos o envíes ETH (Interactions). Esto asegura que el estado sea consistente antes de cualquier llamada externa.
2. Mutex (Bloqueo de Reentrada)
Usar una variable de estado booleana (ej: `bool private locked;`) que actúe como un cerrojo. Antes de ejecutar la función sensible, verificas que `locked` sea `false`, la estableces en `true`, ejecutas la lógica, y finalmente la vuelves a `false`. Esto bloquea cualquier llamada recursiva.
3. Usar Transferencias Seguras
En lugar de `address.call{value: x}(«»)` (bajo nivel y propicia reentrada), usar `address.transfer(x)` o `address.send(x)` que limitan el gas enviado (2300 unidades), suficiente para registrar un evento pero no para ejecutar un contrato complejo y reentrar. Sin embargo, esta práctica también tiene matices en contextos modernos.
4. Herramientas de Análisis y Auditoría
Usar analizadores estáticos como Slither o MythX que detectan automáticamente patrones de reentrada. Contar siempre con auditorías de seguridad por parte de firmas especializadas antes de desplegar un contrato con fondos. Aprende los conceptos básicos en cómo auditar un token.
5. Librerías Probadas en Batalla
Usar contratos de bibliotecas como OpenZeppelin Contracts, que implementan utilidades como `ReentrancyGuard`, un modificador listo para usar que implementa un mutex de forma segura y estandarizada.
La seguridad integral es un proceso, no un punto final.
🔍 Cómo identificar un contrato vulnerable (Como usuario)
Como usuario que interactúa con dApps, tu capacidad de auditar código es limitada, pero puedes tomar precauciones:
- Verifica las Auditorías: ¿El proyecto ha sido auditado por firmas de renombre (ConsenSys Diligence, Trail of Bits, PeckShield)? Los informes suelen ser públicos.
- Revisa el Código Fuente (si es abierto): En Etherscan, verifica si el contrato tiene código verificado. Busca términos como «nonReentrant» (modificador de OpenZeppelin) o lógica clara de CEI.
- Historial del Equipo: ¿Tiene el equipo desarrolladores con experiencia reconocida en seguridad de smart contracts?
- Usa Herramientas de Monitoreo: Para transacciones grandes, considera usar una billetera hardware y revísalas en Etherscan antes de firmar.
- Diversifica el Riesgo: Nunca deposites una parte desproporcionada de tu capital en un solo contrato o protocolo nuevo y no auditado.
🚀 El futuro: Evolución de las defensas y los ataques
La batalla entre atacantes y defensores continúa:
- Lenguajes más Seguros: Lenguajes como Vyper (más simple) o Fe (en desarrollo) buscan eliminar por diseño clases enteras de vulnerabilidades, incluyendo la reentrada, mediante restricciones explícitas.
- Verificación Formal: El uso de herramientas matemáticas para probar formalmente que un contrato es inmune a la reentrada (y otras vulnerabilidades) ganará adopción en proyectos de alto valor.
- Inteligencia Artificial para Auditoría: Los modelos de IA empezarán a ser capaces de analizar código Solidity de forma más efectiva, detectando patrones de vulnerabilidad complejos o variantes nuevas.
- Seguros On-Chain (DeFi Insurance): Protocolos como Nexus Mutual ofrecen cobertura contra exploits de smart contracts. Su adopción crecerá como una capa de mitigación de riesgo financiero.
- Ataques más Sutiles: Los atacantes buscarán combinaciones más complejas (reentrada + lógica de precios + flash loans) para explotar interacciones entre múltiples contratos.
🎯 Conclusión: La lección más cara de la programación de contratos
El ataque de reentrada es un recordatorio brutal de que en la blockchain, el código es ley, y un error microscópico puede tener un coste macroscópico. No es una vulnerabilidad teórica; es una que ha dado forma a la historia de Ethereum y ha destruido cientos de millones de dólares. Su persistencia demuestra lo difícil que es escribir software perfecto que maneje valor en un entorno hostil y sin permisos.
Sin embargo, también es la vulnerabilidad mejor entendida y más fácil de prevenir si se siguen prácticas de codificación seguras establecidas. Patrones como Checks-Effects-Interactions y herramientas como el ReentrancyGuard de OpenZeppelin han convertido la prevención en una rutina para los desarrolladores serios. Para los usuarios, la lección es clara: la confianza debe ser verificada, no otorgada. Interactuar con una dApp implica confiar en la competencia de sus desarrolladores y la rigurosidad de sus auditorías. En un mundo donde tu cartera puede ser drenada en una sola transacción, la educación sobre estos riesgos no es opcional; es el cimiento de tu propia soberanía y seguridad financiera.
❓ Preguntas Frecuentes sobre Reentrancy Attack
📚 ¿Quieres profundizar?
Refuerza tus conocimientos sobre seguridad y tecnología blockchain:
⚠️ Guía Completa de Seguridad Crypto – La base para proteger tus activos.
🔍 Cómo Auditar un Token Cripto – Técnicas para evaluar la seguridad de un proyecto.
🏛️ ¿Qué es DeFi? – El ecosistema donde estas vulnerabilidades son más críticas.
💼 Tutorial de MetaMask – Para interactuar con contratos de forma segura.
🚀 ¿Empezando en Crypto?
La seguridad es lo primero. Si estás comenzando, construye una base sólida con nuestra guía completa gratuita para principiantes.
📋 ¿Por qué confiar en esta definición? Cada término de la Cryptopedia sigue una metodología de verificación con fuentes primarias, whitepapers y legislación oficial. Conoce nuestro proceso →
⚠️ Disclaimer: Este artículo es informativo y educativo. NO constituye asesoramiento de seguridad, desarrollo o inversión. La interacción con contratos inteligentes conlleva riesgos extremos. Siempre realiza tu propia investigación (DYOR), consulta a auditores profesionales para proyectos serios y nunca inviertas más de lo que estés dispuesto a perder.
📅 Actualizado: Marzo 2026
📖 Categoría: Seguridad y Riesgos / Auditoría y Smart Contracts