Ataque de reentrada: Por qué los Contratos inteligentes siguen siendo drenados ( y cómo detenerlo )

La versión rápida: La reentrada es como un hacker llamándote de vuelta mientras todavía estás transfiriendo dinero a ellos; drenan tu billetera antes de que la transacción siquiera termine.

Aquí está la dura verdad: Más de $100M se ha perdido debido a exploits de reentrada. ¿El más famoso? El hackeo de DAO (2016) robó $50M en ETH al explotar esta vulnerabilidad exacta.

Cómo Funciona el Ataque (Usando Lógica de Código Real)

Imagina que el ContratoA tiene 10 ETH y el ContratoB tiene un saldo de 1 ETH almacenado dentro de él.

Cuando ContractB llama a withdrawAll(), esto es lo que debería suceder:

1. Ver saldo > 0 ✓
2. Enviar ETH de vuelta ✓
3. Actualizar saldo a 0 ✓

Pero aquí es donde se rompe: El atacante explota el orden de operaciones.

El Flujo de Explotación:

• El atacante llama a attack() → que llama a withdrawAll() en ContractA
• ContractA envía 1 ETH y activa la función de fallback del atacante()
• Antes de que el saldo se actualice a 0, fallback() llama inmediatamente a withdrawAll() de nuevo.
• ContractA verifica: “¿Es el saldo > 0?” SÍ (¡porque aún no se ha actualizado!)
• Envía otro 1 ETH → activa fallback() nuevamente
• Este bucle continúa hasta que ContractA esté completamente drenado.

Perspectiva clave: La actualización de saldo ocurre DESPUÉS de la transferencia de ETH. Esa es la ventana de vulnerabilidad.

Tres Estrategias de Defensa

1. El modificador nonReentrant (Protección de función única)

Bloquee la función mientras se está ejecutando. No se permite la reentrada: solidity modificador nonReentrant { require(!locked, “No reentrancy”); bloqueado = true; _; locked = false; }

Simple, pero solo protege una función a la vez.

2. Patrón de Cheques-Efectos-Interacciones (Protección Multi-Función)

Este es el cambio de juego:

• Verificaciones: Verificar condiciones (balance > 0)
• Efectos: Actualizar estado (balance = 0) ← Mover esto ANTES de enviar ETH
• Interacciones: Enviar ETH

Pedido incorrecto:

require(balance > 0); → enviar ETH → balance = 0; // ¡Demasiado tarde!

Orden correcto:

require(balance > 0); → balance = 0; // Actualizar PRIMERO → enviar ETH // Luego interactuar

Ahora, incluso si fallback() vuelve a entrar, el saldo ya es 0. El ataque falla.

3. GlobalReentrancyGuard (Protección entre contratos)

Para sistemas complejos con múltiples contratos interactuantes, utiliza un contrato guardián centralizado que rastree el estado de bloqueo en todos los contratos. Cuando el ContratoA llama al ContratoB, el guardián lo registra; si el ContratoB intenta volver a llamar al sistema antes de regresar, el guardián lo bloquea.

Por qué esto es importante

La reentrancia no es solo un problema de Solidity, es un problema de diseño. Cada vez que envías ETH o llamas a funciones externas, estás entregando el control a un código no confiable. La función de retorno del atacante se ejecuta en el contexto de TU contrato.

Los datos: Chainalysis encontró que ~60% de los exploits de alto valor en 2023-2024 involucraron reentrancia o patrones similares. Proyectos destacados como Yearn, Curve y Balancer todos tuvieron sustos de reentrancia.

Conclusión: Usa Checks-Effects-Interactions por defecto. Añade nonReentrant donde sea necesario. Para sistemas de múltiples contratos, implementa GlobalReentrancyGuard. Los $100M+ perdidos podrían haberse salvado con estos patrones básicos.

Sigue a @TheBlockChainer para más profundidades en seguridad de Web3.