---
title: "¿Qué es un ataque de reentrancy en Solidity?"
description: "Qué es, cómo funciona y cómo proteger tus smart contracts"
---

# ¿Qué es un ataque de reentrancy en Solidity?

**Un ataque de reentrancia** en [Solidity](https://www.alchemy.com/overviews/solidity) retira fondos repetidamente de un contrato inteligente y los transfiere a un contrato no autorizado hasta que los fondos se agotan. El ataque ocurre durante el ciclo de ejecución en la blockchain cuando actores maliciosos encuentran un contrato inteligente explotable. Los ataques de reentrancia han liquidado millones de dólares de [DAOs](https://www.alchemy.com/dapps/top/daos) y protocolos blockchain.

El siguiente artículo explica la mecánica de un ataque de reentrancia, dos tipos de ataques de reentrancia y las medidas preventivas que los **desarrolladores de Solidity** pueden tomar para proteger un contrato inteligente de vulnerabilidades en las blockchains de Ethereum y Solana.

## ¿Qué es un ataque de reentrancia?

Los ataques de reentrancia ocurren cuando una función de contrato inteligente cede temporalmente el control del flujo de la transacción al hacer una llamada externa a un contrato que a veces está escrito por actores desconocidos o potencialmente hostiles. Esto permite que el segundo contrato haga una llamada recursiva de vuelta a la [**función principal del contrato inteligente**](https://www.alchemy.com/overviews/solidity-functions) para drenar sus fondos.

El ciclo de ejecución de un contrato inteligente en las blockchains de Ethereum verifica el saldo, envía los fondos y luego actualiza el saldo. Mientras el contrato inteligente está en depósito, los actores maliciosos pueden [hacer otra llamada](https://www.alchemy.com/overviews/solidity-call) para retirar fondos. El ciclo se repite hasta que todos los fondos quedan efectivamente drenados.

## ¿Cómo funciona un ataque de reentrancia?

**Un ataque de reentrancia crea un proceso recursivo que transfiere fondos entre dos contratos inteligentes: el contrato vulnerable y el contrato malicioso.** Estos son los pasos de un ataque de reentrancia:

1. El actor malicioso hace una llamada al contrato vulnerable, "X," para transferir fondos al contrato malicioso, "Y."
1. El contrato X determina si el atacante tiene los fondos necesarios y luego procede a transferir los fondos al contrato Y.
1. Una vez que el contrato Y recibe los fondos, ejecuta una función de _callback_ que vuelve a llamar al contrato X antes de que se actualice el saldo.
1. Este proceso recursivo continúa hasta que todos los fondos se agotan y se transfieren.

**El siguiente diagrama ilustra el escenario de ataque:**

<ImageBlock
  src="https://media.alchemy.com/1704184186-reentrancy-attack-scenario.png"
  alt="Diagrama de un ataque de reentrancy: un contrato malicioso llama recursivamente antes de que se actualice el balance"
  width={752}
  height={481}
  caption="Escenario de ataque de reentrancy | Fuente de la imagen: CryptoMarketPool"
/>

## **¿Cuáles son los diferentes tipos de ataques de reentrancia?**

**Hay dos tipos de ataques de reentrancia: un ataque de función única y un ataque de reentrancia entre funciones.**

### **1. Ataques de reentrancia de función única**

Un ataque de reentrancia de función única ocurre cuando la función vulnerable es la misma función que el atacante intenta llamar recursivamente. Los ataques de reentrancia de función única son más simples y más fáciles de prevenir que los ataques de reentrancia entre funciones.

### **2. Ataques entre funciones**

Un ataque de reentrancia entre funciones solo es viable cuando una función vulnerable comparte estado con otra función que tiene un efecto deseable para el atacante. Los ataques entre funciones son más difíciles de detectar y más difíciles de prevenir.

### **3. Ataque entre contratos**

Un ataque de reentrancia entre contratos ocurre cuando el estado de un contrato es invocado en otro antes de que se actualice por completo. Los ataques de reentrancia entre contratos generalmente ocurren cuando varios contratos comparten manualmente la misma variable y algunos actualizan la variable compartida de forma insegura.

## **Ejemplos de ataques de reentrancia en Solidity**

Los siguientes ataques de reentrancia prominentes ilustran cómo actores maliciosos han explotado vulnerabilidades en protocolos blockchain: el hackeo de The DAO, Lendf.me, y [Cream Finance](https://www.alchemy.com/dapps/cream-finance).

### 1. Hackeo de The DAO \(2016\)

El DAO de Ethereum fue hackeado por aproximadamente $60 millones en Ether. El DAO de Ethereum fue diseñado como un fondo de inversión donde los miembros de la red podían votar directamente sobre decisiones de inversión.

El DAO recaudó aproximadamente $150 millones, pero expertos y participantes de la comunidad expresaron preocupaciones sobre la seguridad del contrato inteligente que almacenaba los fondos. Los fondos quedaron bloqueados en un contrato inteligente vulnerable a un ataque de reentrancia debido a un error de llamada recursiva en el código fuente. Antes de que el equipo de desarrollo corrigiera el problema, un hacker ejecutó un ataque y drenó el contrato.

### **2. Protocolo Lendf.me \(2020\)**

En abril de 2020, un actor malicioso robó $25 millones mediante un ataque de reentrancia al protocolo Lendf.me, un protocolo de finanzas descentralizadas para operaciones de préstamo en la red de Ethereum.

Los desarrolladores del protocolo pasaron por alto el hecho de que los tokens ERC-777 contienen una función de callback que notifica a los usuarios cuando se ha enviado o recibido dinero. Los hackers explotaron la vulnerabilidad instituyendo un contrato inteligente malicioso como destinatario y drenando el 99.5% de los fondos del protocolo Lendf.me.

### **3. Hackeo de Cream Finance \(2021\)**

En octubre de 2021, un actor malicioso robó más de $130 millones en tokens ERC-20 y tokens de liquidez \(LP\) de CREAM utilizando un ataque de reentrancia sobre la función de "préstamo flash" del protocolo. La causa raíz de la explotación fue la integración errónea de AMP en el protocolo CREAM finance.

## **Cómo prevenir un ataque de reentrancia**

**Desarrollar un marco de seguridad blockchain riguroso es fundamental para prevenir y mitigar el daño potencial de un ataque de reentrancia.** Las siguientes mejores prácticas contra la reentrancia ayudarán a los desarrolladores y a la comunidad web3 en general a proteger sus fondos: checks, effects and interactions \(CEI\), guardas de reentrancia, pull payments y límites de gas.

### **Checks, effects, and interactions \(CEI\)**

El proceso CEI es un método rudimentario para prevenir la reentrancia. Los checks se refieren a la veracidad de la condición, los effects se refieren a las modificaciones de estado que resultan de la interacción, y las interactions se refieren a las transacciones entre funciones o contratos.

Los posibles riesgos de seguridad y vacíos asociados con colocar los efectos ejecutivos antes de las interacciones son una consideración importante para los desarrolladores.

### **Guarda de reentrancia o mutex**

Una guarda de reentrancia o mutex puede crearse como una función o un [modificador de función](https://www.alchemy.com/overviews/solidity-modifier). Se coloca un bloqueo booleano alrededor de la llamada a la función que es vulnerable a la reentrancia. Esto implica que el estado inicial de "locked" es falso; sin embargo, se establece en verdadero inmediatamente antes de que comience la ejecución de la función vulnerable y luego se vuelve a establecer rápidamente en falso después de la finalización.

### **Pull payment**

Una transacción de extremo a extremo más segura se logra utilizando la metodología de pull payment. El proceso de pull payment exige el uso de un depósito en garantía intermediario para enviar fondos y evita el contacto directo con un contacto potencialmente hostil.

Al enviar fondos a través de un depósito en garantía intermediario, los fondos del contrato inteligente quedan protegidos de un ataque de reentrancia. El depósito en garantía podría estar sujeto a reentrancia si administra fondos para múltiples cuentas. El patrón CEI y la guarda de reentrancia deberían implementarse donde sea apropiado.

### **Límite de gas**

Los límites de gas no son un método óptimo para evitar un atacante, ya que los costos de gas dependen de los opcodes de Ethereum, que están sujetos a cambios. Por otro lado, el código del contrato inteligente es inmutable.

Es importante entender la diferencia entre las funciones [_send_, _transfer_ y _call_](https://www.alchemy.com/overviews/solidity-functions). _Send_ y _transfer_ son efectivamente lo mismo, pero _transfer_ revertirá si la transacción falla y _send_ no lo hará.

A diferencia de _send_ y _transfer_, la función _call_ no tiene límite de gas y reenviará su gas para ejecutar transacciones entre múltiples contratos. Lamentablemente, esto también significa que los ataques de reentrancia son posibles.

## **Aprende más sobre los ataques de reentrancia con Alchemy University**

El ciclo de ejecución de un contrato inteligente en Ethereum no es un proceso infalible. Los actores maliciosos explotan la blockchain implementando [ataques de reentrancia](https://solidity-by-example.org/hacks/re-entrancy/) para transferir y drenar fondos de contratos inteligentes vulnerables. Tomar medidas preventivas garantizará a los desarrolladores de Solidity ciclos de ejecución más seguros y la protección de sus protocolos blockchain.

Para aprender sobre las mejores prácticas de desarrollo de contratos inteligentes en Solidity, únete al [bootcamp gratuito de 7 semanas para desarrolladores de Ethereum](https://www.alchemy.com/university/courses/ethereum?a=c1cf9a376f) de Alchemy. Originalmente un curso de certificación de $3,000, el bootcamp de Alchemy University es el lugar principal para [aprender Solidity de forma gratuita](https://www.alchemy.com/overviews/learn-solidity).

Si los desarrolladores son nuevos en el desarrollo en general, el **curso intensivo de JavaScript de 3 semanas** de Alchemy es un excelente prerrequisito antes de comenzar un bootcamp de Ethereum.
