Desarrollo 001 de Contratos Inteligentes Seguros: Revisión del Patrón de Interacciones de Efectos

Este artículo es una traducción de Sergio Mazariego, hecha por Héctor Botero. Puedes encontrar el artículo original aquí.
Sería genial escucharte en nuestro Discord, puedes contarnos tus ideas, comentarios, sugerencias y dejarnos saber lo que necesitas.
Si prefieres puedes escribirnos a @web3dev_es en Twitter.

Tabla de Contenidos

• Introducción
• ¿Qué son las Revisiones de Patrones de Interacción de Efectos?
• ¿Por qué los ataques de reentrada son posibles cuando no se siguen las Revisiones de Patrones de Interacciones de Efectos?
• Ejemplo de Ataque de Reentrada que no sigue el Patrón de Interacción de Efectos
• Cómo aplicar los Patrones de Interacción de Efectos
• Conclusiones
• Referencias

Introducción

En este artículo, discutiremos la Revisión de Patrón de Interacción de Efectos (Checks Effects Interacions, CEI), el cual es un concepto crucial en el desarrollo de un contrato inteligente y, siguiendo este patrón, los desarrolladores pueden mejorar la seguridad de sus contratos inteligentes significativamente y, cuando falta un patrón, puede que introduzca el famoso vector de ataque de reentrada.

Si quieres conectarte conmigo, sígueme en twitter @s3rgiomazari3go, mis DMs siempre están abiertos para ayudarte.

¿Qué son las Revisiones de Patrones de Interacción de Efectos?

Las Revisiones de Patrones de Interacción de Efectos es un concepto fundamental en el desarrollo de contratos inteligentes que apunta a mejorar la seguridad, asegurándose que las llamadas externas sean hechas sólo después que todos los estados de cambio hayan sucedido, esta es una práctica que todos los desarrolladores deben tener en cuenta mientras construyen contratos inteligentes más seguros en la blockchain, particularmente usando el lenguaje de programación de solidity para las blockchain compatibles con el EVM.

Las Revisiones de Patrones de Interacción de Efectos requieren que cualquier modificación de estado en una función deba ocurrir antes que una llamada externa sea hecha. En esencia, esto quiere decir que antes de hacer una llamada externa, la función debe realizar todos los estados de cambios necesarios como: actualizar los datos del contrato (por ejemplo, el balance de un usuario), revisar los valores de entrada para la validación, etc.

Una violación de la Revisión de Patrón de Interacción de Efectos puede llevar a consecuencias nefastas, abajo te doy un ejemplo si quieres saber más sobre las consecuencias de no seguir esta práctica.

¿Por qué los ataques de reentrada son posibles cuando no se siguen las Revisiones de Patrones de Interacciones de Efectos?

Cuando una llamada externa se realiza, el control es transferido a otro contrato o a un tercero, lo cual puede llevar a que el estado que no haya cambiado aún, ejecute un código maligno que pueda comprometer la seguridad del contrato y esto puede llevar al escenario de reentrada, donde un actor maligno puede, repetidamente, reentrar la función del contrato y alterar el flujo esperado.

Otra Definición de Reentrada por BlockSec

En un contrato inteligente, la reentrada puede ocurrir cuando una función ejecuta una llamada externa a otro contrato, el cual invoca aún más la función original (u otras funciones) antes que la invocación original regrese. Si la llamada externa es controlada por una entidad sin confianza (por ejemplo, un contrato maligno) puede llevar a resultados inesperados. Esto es porque, en algunas funciones, el resultado depende del estado del contrato. El estado de contrato será actualizado luego de la llamada externa. Sin embargo, la invocación de la función de reentrada usará el estado antiguo en vez del actualizado.

**Ejemplo de Ataque de Reentrada que no sigue la Revisión de Patrón de Interacción de Efectos

**###

Código del Ethernaut challenge no está usando la Revisión de Patrón de Interacción de Efectos, introduciendo un vector de ataque de reentrada:

Código Vulnerable

El ataque de reentrada consistirá en los siguientes pasos:

1. La víctima deposita 0.001 ETH en el contrato vulnerable.

2. El atacante llama a la función de ataque en el AttackerContract, esta función primero deposita 0.01 ETH a la bóveda usando la función de donación, esto es hecho para tener un balance en la bóveda que pueda ser retirado desde el AttackerContract

3. El atacante luego llama a la función de retirada de la bóveda, intentando retirar estos 0.01 ETH y, ya que el atacante tiene un balance en la bóveda, la retirada es exitosa.

4. La bóveda transfiere 0.01 ETH desde el balance del atacante al AttackerContract

5. El AttackerContract recibe 0.01 ETH en su función de recibir, el cual es desencadenado por la transferencia y en este punto, el balance del atacante en la bóveda sigue sin ser alterado.

6. Desde la función de recibir, el atacante invoca de nuevo la función de retirada de la bóveda, intentando retirar 0.01 ETH y, ya que el balance del atacante en la bóveda no ha sido actualizado aún, la retirada es exitosa.

7. La bóveda adicionalmente transfiere 0.001 ETH (el balance restante) al AttackerContract, el cual ha ejecutado exitosamente un ataque de reentrada, llamando repetidas veces a la función de retirada, drenando el contrato.

AttackerContract

Mira el código de AttackerContract aquí:

Prueba que explota el código vulnerable de arriba:

1. Balance inicial del contrato vulnerable = 0.001 ETH.

1. Desplegando el AttackerContract, pasando el argumento como la dirección del contrato vulnerable.

1. El balance de AttackerContract antes del ataque:

1. El atacante inicial la función de ataque desde AttackerContract (deposita 0.01 ETH desde el EOA del atacante y, además, retira los mismos 0.01 ETH).

1. El atacante obtiene el balance del AttackerContract usando la función getBalance, y ahora tiene el 0.01 ether que envió más el 0.001 ETH que estaba en el contrato antes del ataque.

1. El contrato vulnerable, ahora, ha sido drenado de sus fondos.

Cómo aplicar las Revisiones de Patrones de Interacción de Efectos

Para implementar las Revisiones de Patrones de Interacciones de Efectos, los desarrolladores deben seguir los siguientes tres pasos:

1. Revisión: La función debe validar todos los parámetros de entrada para asegurar que sean válidos.

2. Efectos: Todos los estados de cambios deben ocurrir, incluyendo la actualización de los datos del contrato.

3. Interacción: Finalmente, cualquier llamada externa debe realizarse.

Conclusiones

Las Revisiones de Patrones de Efectos de Interacciones (Checks Effects Interaccions, CEI) es la mejor práctica de seguridad crítica para el desarrollo de contratos inteligentes, siguiendo el patrón del CEI, los desarrolladores pueden, significativamente, mejorar la seguridad de sus contratos inteligentes, asegurándose que las llamadas externas sean sólo hechas luego que todos los cambios de estados hayan sucedido, esto puede ayudar a prevenir los ataques de reentrada, ya que son una de las vulnerabilidades de seguridad más comunes en los contratos inteligentes.

El patrón CEI es relativamente simple de implementar y hay un gran número de recursos disponibles para ayudar a los desarrolladores a aprender más sobre esto. Aliento a los desarrolladores, que están construyendo contratos inteligentes, a adoptar los patrones CEI como parte de las prácticas de seguridad.

¡Gracias por leerme!

Referencias

Revisión de Efectos de Interacción por Fravoll

Contratos Inteligentes: Patrones de Seguridad

Ataques de Reentrada en Contratos Inteligentes - GeeksForGeeks