Autor: Artela Blog chino, medio # Resumen

Los ataques de reingreso siguen siendo un desafío. Los métodos de defensa existentes se centran principalmente en el nivel del código fuente del protocolo, que solo surten efecto antes de que el contrato entre en el estado de tiempo de ejecución.

La "protección en tiempo de ejecución" es un complemento importante de la seguridad DeFi. Su objetivo es "proteger los resultados de la ejecución" y garantizar que la ejecución del protocolo sea coherente con su diseño esperado.

El diseño de EVM no admite la "protección en tiempo de ejecución", porque el contrato inteligente no puede acceder a la información de contexto completa del estado del tiempo de ejecución.

Artela explora un paradigma de capa de ejecución EVM+Extension, mejora la capa de ejecución para eliminar los ataques de reingreso

Artela implementa extensiones de "protección en tiempo de ejecución" en cadena a través de la programación de aspectos

Mostramos paso a paso cómo prevenir ataques de reentrada en el contrato de Curve a través de Aspect

Por qué los ataques de reingreso siguen siendo un desafío a pesar de los controles de riesgo existentes

Aunque los ataques de reingreso son un problema bien conocido y se han implementado muchos controles de riesgo, los incidentes de seguridad que involucran este tipo de ataques han seguido ocurriendo durante los últimos dos años:

Ataque financiero de Curve (julio de 2023): $ 60 millones Curve sufrió un ataque de reingreso debido a una falla de compilación en su lenguaje de programación de contrato Vyper.

Ataque al protocolo de origen (noviembre de 2022): el proyecto de moneda estable de $ 7 millones Origin Dollar (OUSD) sufrió un ataque de reingreso.

Ataque del protocolo Siren (septiembre de 2021): $ 3,5 millones, el grupo AMM sufre un ataque de reingreso.

Ataque Cream Finance (agosto de 2021): 18,8 millones de dólares, los atacantes explotaron una vulnerabilidad de reingreso para obtener préstamos secundarios.

En la actualidad, el enfoque de la prevención de ataques de reingreso está en el nivel del código fuente de los contratos inteligentes. Las medidas incluyen la integración de ReentrancyGuard de OpenZeppelin y la realización de auditorías de seguridad en los códigos lógicos del contrato para evitar riesgos de seguridad predefinidos.

Este enfoque, conocido como solución de "caja blanca", tiene como objetivo evitar vulnerabilidades en el nivel del código fuente para minimizar los errores lógicos. Sin embargo, su principal desafío es la incapacidad para defenderse de peligros ocultos desconocidos.

"Traducir" un contrato del código fuente al tiempo de ejecución real es un proceso desafiante. Cada paso puede traer problemas imprevistos para los desarrolladores, y es posible que el código fuente del contrato en sí mismo no cubra completamente todas las situaciones potenciales. En el caso de Curve, incluso si el código fuente del protocolo es correcto, aún puede haber discrepancias entre la ejecución final y el diseño previsto del protocolo debido a problemas del compilador.

No es suficiente confiar en la seguridad del protocolo a nivel de código fuente y compilación. Incluso si el código fuente parece estar impecable, las vulnerabilidades aún pueden aparecer inesperadamente debido a problemas del compilador.

Necesitamos protección en tiempo de ejecución

A diferencia de las medidas de control de riesgos existentes que se concentran en el nivel del código fuente del protocolo y entran en vigencia antes de la ejecución, la protección en tiempo de ejecución implica que los desarrolladores de protocolos escriban reglas y operaciones de protección en tiempo de ejecución para manejar circunstancias imprevistas en el tiempo de ejecución. Esto facilita la evaluación en tiempo real y la respuesta a los resultados de ejecución en tiempo de ejecución.

La protección en tiempo de ejecución es fundamental para mejorar la seguridad de DeFi y es una adición importante a las medidas de seguridad existentes. Al proteger el protocolo en forma de "caja negra", mejora la seguridad al garantizar que el resultado operativo final sea coherente con el diseño previsto del protocolo, sin interferir directamente con la ejecución del código del contrato.

Desafíos de implementar la protección en tiempo de ejecución

Desafortunadamente, el diseño de EVM no admite la protección en tiempo de ejecución en la cadena porque los contratos inteligentes no tienen acceso al contexto de tiempo de ejecución completo.

¿Cómo superar este desafío? Creemos que los siguientes requisitos previos son necesarios:

Un módulo dedicado que brinda acceso a toda la información a través de contratos inteligentes, incluido todo el contexto de la transacción.

La autorización necesaria se obtiene del contrato inteligente, lo que otorga al módulo el derecho de revertir transacciones según sea necesario.

Asegúrese de que la funcionalidad del módulo surta efecto después de que se ejecute el contrato inteligente y antes de que se envíe el estado.

EVM actualmente enfrenta limitaciones para abordar los desafíos anteriores y no puede adaptarse a más innovaciones. Bajo el paradigma de blockchain modular, la capa de ejecución necesita explorar el avance de ir más allá de EVM.

La idea de Artela es EVM + extensión nativa, mediante la creación de la capa de extensión nativa WASM de EVM para lograr ir más allá de EVM.

Introducción a la programación de aspectos

Lanzamos Aspect Programming, un marco de programación para la cadena de bloques de Artela que admite el escalado nativo en la cadena de bloques.

Aspect es un módulo de extensión nativo programable, que se utiliza para integrar dinámicamente funciones personalizadas en la cadena de bloques en tiempo de ejecución, como complemento modular de los contratos inteligentes y mejorar la funcionalidad en la cadena.

La característica de Aspect es que puede acceder a la API de nivel de sistema de la capa base de la cadena de bloques y agregar lógica de extensión en cada punto de unión del ciclo de vida de la transacción. Los contratos inteligentes pueden vincular aspectos específicos para activar funciones extendidas. Cuando una transacción invoca un contrato inteligente, la transacción también es procesada por el aspecto asociado con el contrato.

Cómo la programación de aspectos implementa la protección en tiempo de ejecución

Aspect puede registrar el estado de ejecución de cada llamada de función y evitar el reingreso durante la ejecución de la función de devolución de llamada. Cuando se produce una llamada de reentrada durante la ejecución de la función de devolución de llamada, Aspect detecta y revierte la transacción de inmediato, lo que evita que los atacantes aprovechen las vulnerabilidades de reentrada. Con este enfoque, Aspect elimina efectivamente los ataques de reingreso, lo que garantiza la seguridad y la estabilidad de los contratos inteligentes.

Aspect implementa propiedades clave para la protección en tiempo de ejecución:

Se puede activar después de la ejecución del contrato inteligente y antes del envío del estado: los módulos de aspecto se pueden configurar para activarse después de la ejecución del contrato inteligente pero antes del envío del estado.

Acceso completo al contexto de la transacción: Aspect puede acceder al contexto completo de la transacción, incluida toda la información de la transacción (métodos, parámetros, etc.), la pila de llamadas (todas las llamadas de contratos internos durante la ejecución), los cambios de contexto de estado y todos los eventos desencadenados por transacciones.

Capacidad de llamada al sistema: Aspect puede realizar llamadas al sistema e iniciar el seguimiento de transacciones cuando sea necesario.

Vinculación y autorización con contratos inteligentes: los contratos inteligentes se pueden vincular a Aspect y otorgar permiso a Aspect para participar en el procesamiento de transacciones.

Implementar Aspecto para la protección de reentrada

En este capítulo, discutimos cómo implementar la protección de tiempo de ejecución de Aspect en la cadena.

Se puede implementar un aspecto real de "Intención de protección del contrato" en el punto de unión de "preContractCall" y "postContractCall" para evitar ataques de reingreso.

preContractCall: Activado antes de la ejecución de la llamada de contrato cruzado

postContractCall: activado después de la ejecución de la llamada de contrato cruzado

Para la protección de reingreso, nuestro objetivo es evitar el reingreso del contrato hasta que se complete la llamada. Con Aspect, podemos lograr esto agregando una lógica específica en puntos de corte en el ciclo de vida de la transacción.

En el punto de corte "preContractCall", Aspect supervisa la pila de llamadas del contrato. Si hay llamadas duplicadas en la pila de llamadas (lo que significa un reingreso inesperado en nuestra llamada bloqueada), el aspecto revertirá la llamada.

Implemente el contrato Curve y evite los ataques de reingreso

Escribimos un contrato simulado de Curve y forjamos un ataque de reingreso para reproducir este proceso de una manera más comprensible. El código del contrato es el siguiente:

Se puede ver que tanto add_liquidity como remove_liquidity del contrato anterior están protegidos por el mismo bloqueo de bloqueo de reingreso, lo que significa que si la protección de reingreso funciona normalmente, no se puede volver a ingresar a la función protegida cambiando el bloqueo (por ejemplo, en remove _liquidity llama a add_liquidity).

Compile el contrato anterior con el compilador vyper 0.2.15, 0.2.16 o 0.3.0 (estas versiones tienen problemas conocidos de protección de reingreso).

Luego implementamos el contrato de víctima anterior y lo atacamos con el siguiente contrato:

Para simular un ataque real, el método de ataque de este contrato intenta volver a ingresar add_liquidity desde el método remove_liquidity a través de su función de respaldo. Si realmente ocurre una reentrada, se puede observar en el recibo que se registra un evento AddLiquidity antes que el evento RemoveLiquidity.

Ahora usemos Aspect para proteger el contrato bajo ataque. Antes de hacer lo siguiente, complete los siguientes pasos:

1. Implementar aspecto

2. Vincular el contrato de la víctima con Aspect

Si no está familiarizado con las operaciones de Aspect, primero puede consultar nuestra guía para desarrolladores.

Habiendo hecho lo anterior, ahora intentemos llamar al método de ataque nuevamente para verificar si la operación será exitosa.

En la imagen en movimiento (puede ver el enlace original al final del artículo), podemos ver que la transacción de reingreso se ha revertido, lo que significa que nuestro Aspect protege con éxito el contrato de la víctima de los ataques de reingreso.

en conclusión

El reciente ataque a Curve demuestra una vez más que ningún protocolo es 100 % completamente seguro. No basta con centrarse en la seguridad en los niveles de origen y compilación del protocolo. Incluso si el código fuente parece estar impecable, las vulnerabilidades aún pueden aparecer inesperadamente debido a problemas del compilador.

Para mejorar la seguridad de DeFi, la protección del tiempo de ejecución se vuelve fundamental. Al proteger el protocolo en forma de "caja negra", asegurando que la ejecución del protocolo sea consistente con su diseño previsto, puede prevenir de manera efectiva los ataques de reingreso en el tiempo de ejecución.

Bifurcamos el contrato de Curve y simulamos completamente su reciente ataque de reingreso, y reproducimos todo el proceso de una manera más comprensible. Utilizando la programación de aspectos como un nuevo enfoque para la protección en tiempo de ejecución en cadena, mostramos paso a paso cómo proteger los contratos de las víctimas con aspectos. Nuestro objetivo es ayudar a eliminar los ataques de reingreso que pueden sufrir los protocolos DeFi como Curve, mejorando así la seguridad en todo el espacio DeFi.

Con Aspect Programming, los desarrolladores no solo pueden lograr protección en tiempo de ejecución en cadena en el espacio de seguridad, sino también habilitar casos de uso innovadores sin precedentes, como intentos, JIT y automatización en cadena. Además, este marco general basado en Cosmos SDK no solo admitirá la cadena de bloques de Artela, sino que también admitirá otras cadenas de bloques para crear extensiones nativas basadas en sus propias capas de ejecución.