El exploit que encontró Curve esta vez puede abrir nuevas ideas para los piratas informáticos.

Por Jaleel, BlockBeats

La industria DeFi se ha sumido en el caos luego de un incidente de explotación de vulnerabilidad. Curve Finance, un gigante en la industria DeFi, se ha convertido en el objetivo de un "ataque" serio, y múltiples grupos de monedas estables como alETH/msETH/pETH están en riesgo. Según estadísticas incompletas, el evento de explotación de la vulnerabilidad ha causado una pérdida total de 52 millones de dólares estadounidenses en los grupos de Alchemix, JPEG'd, MetronomeDAO, deBridge, Ellipsis y CRV/ETH, y la confianza de todo el mercado se ha visto seriamente afectada.

Los bloqueos de reingreso de las versiones 0.2.15, 0.2.16 y 0.3.0 de Vyper no son válidos y la interfaz de instalación del documento oficial de Vyper recomienda una versión incorrecta. Otras partes del proyecto que usan el compilador Vyper también se apresuraron a realizar un autoexamen, tratando de asegurarse de que no se conviertan en la próxima víctima. A medida que se revela gradualmente la fuente del incidente de explotación de la vulnerabilidad, el mercado se da cuenta gradualmente de que esta crisis no solo significa un incidente ordinario de explotación de piratas informáticos, sino que también revela el enorme riesgo potencial de toda la pila subyacente para toda la industria de DeFi.

En comparación con el pasado, la cantidad de incidentes de piratería en el período anterior se ha vuelto cada vez menor, lo que es inseparable de la prosperidad del mercado. Durante el verano de DeFi y el verano de NFT, se lanzaron nuevos acuerdos de miles de millones de dólares cada semana, en comparación con el mercado actual que se está reduciendo mucho. Al mismo tiempo, las oportunidades de mercado para que los piratas informáticos encuentren exploits o creen ataques a gran escala se están reduciendo gradualmente, lo que significa que los piratas informáticos necesitan puntos de entrada nuevos y sin explotar para explorar.

Los piratas informáticos que regresan a los "primeros principios" han encontrado un punto de entrada perfecto en el compilador de nivel inferior para comerse el enorme y delicioso "pastel" en el mercado DeFi. El compilador de nivel inferior se ha convertido en un hacker más "inteligente". Elección. BlockBeats entrevistó al desarrollador de contratos inteligentes Box (@BoxMrChen) y al investigador de BTX Derek (@begas_btxcap) sobre este incidente y los problemas relacionados que expuso.

¿Cómo ocurre el evento Curve?

Stani (@StaniKulechov), el fundador de Aave y Lens, expresó su opinión sobre el incidente en las redes sociales: "Este es un revés desafortunado para Curve y DeFi. Aunque DeFi es un espacio abierto que puede contribuir, debe hacerlo absolutamente bien es difícil y hay mucho en juego. En el caso de Curve, lo hicieron bien en el nivel de protocolo".

El exploit que sufrió Curve es una de las formas más antiguas y quizás la más común de ataque a los contratos inteligentes de Ethereum, el ataque de reentrada. Los ataques de reingreso permiten a un atacante llamar repetidamente a una función de un contrato inteligente sin esperar a que se complete la llamada anterior a esa función. De esta manera, pueden continuar usando la escapatoria para retirar fondos hasta que el contrato de la víctima se quede sin fondos.

Cerradura reentrante y principio CEI

Dé un ejemplo simple para ilustrar los ataques de reingreso: un banco tiene un total de 100,000 en efectivo. Pero este banco tiene una gran laguna, cada vez que las personas retiran dinero, el personal del banco no actualiza el saldo de la cuenta de inmediato, sino que espera hasta el final del día para verificar y actualizar. En ese momento, alguien descubrió esta laguna. Abrió una cuenta en el banco, primero depositó 1.000 yuanes, luego retiró 1.000 yuanes y luego sacó 1.000 yuanes después de 5 minutos. Dado que el banco no actualiza el saldo en tiempo real, el sistema pensará que su cuenta aún tiene 1000 yuanes antes de verificar y actualizar. A través de repetidas operaciones, el usuario finalmente sacó todo el efectivo de US$100.000 en el banco. No fue hasta el final del día que el banco descubrió que se había aprovechado la laguna.

La complejidad del ataque de reentrada radica en el hecho de que aprovecha la llamada mutua entre contratos y las lagunas lógicas del contrato en sí, y logra un comportamiento fraudulento al activar deliberadamente excepciones y funciones de reversión. Los atacantes pueden explotar repetidamente las lagunas lógicas del contrato para robar fondos. La solución para evitar ataques de reingreso también es muy común. Se establece de antemano un contenido de código especial específico para la protección, y dicho mecanismo de protección se utiliza para garantizar la seguridad de los fondos. Esto se denomina bloqueo de reingreso.

Solidity establece un "principio CEI" (Comprobar interacciones de efectos) para la programación de contratos inteligentes, que puede proteger bien las funciones de los ataques de reingreso. Los contenidos de los principios de la CEI incluyen:

1. El orden de invocación de los componentes de función debe ser: primero, inspección, segundo, impacto en variables de estado y último, interacción con entidades externas.

2. Antes de interactuar con entidades externas, todas las variables de estado deben actualizarse. Esto se llama "contabilidad optimista", donde los efectos se escriben antes de que ocurra la interacción.

3. Se deben realizar verificaciones al comienzo de la función para asegurarse de que la entidad que llama tiene permiso para llamar a la función.

4. Las variables de estado deben actualizarse antes de cualquier llamada externa para evitar ataques de reingreso.

5. Incluso las entidades externas de confianza deben seguir el patrón CEI porque pueden transferir el flujo de control a terceros maliciosos.

Según la documentación, los principios de CEI ayudan a limitar la superficie de ataque de un contrato, en particular, a prevenir ataques de reingreso. Los principios de CEI se pueden aplicar fácilmente, principalmente en el orden de los códigos de función, sin cambiar ninguna lógica. El conocido exploit de The DAO, que condujo a la bifurcación de Ethereum, también ignoró el "principio CEI", y el atacante logró un ataque de reentrada, causando consecuencias devastadoras.

Pero el grupo de Curve que fue atacado no siguió este principio CEI porque Curve usó el compilador Vyper. Como la vulnerabilidad del código Vyper del compilador, el bloqueo de reingreso falla, lo que hace que el ataque de reingreso del hacker se realice con éxito.

La mayoría de la gente conoce Solidity, pero Solidity no es el único lenguaje para crear contratos inteligentes. Una alternativa popular a Solidity es Vyper. Aunque Vyper no es tan poderoso y popular como Solidity, es ideal para desarrolladores familiarizados con Python, porque Vyper puede traducir código similar a Python al lenguaje de programación de contratos inteligentes Ethereum.

Según la información de github, el desarrollador que contribuye primero al código base de github de Vyper también es el desarrollador de Curve. No es difícil explicar por qué Curve usa Vyper en lugar de Solidity.

![Los piratas regresan a los "primeros principios", la crisis de Curve no es un ataque común] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-c30cf03f91-dd1a6f-1c6801)

¿Por qué falla el bloqueo de reentrada de Vyper?

Entonces, en este ataque, ¿cuál es el problema con Vyper? ¿Por qué falla el bloqueo de reingreso? ¿Es porque no hay pruebas? BlockBeats entrevistó al desarrollador de contratos inteligentes Box 826.eth (@BoxMrChen), según él, el bloqueo de reentrada de Vyper ha sido probado con casos de uso. Pero la razón de la falla es que el caso de prueba está orientado a resultados, es decir, el caso de prueba también es incorrecto.

En resumen, la principal razón por la que falla el bloqueo de reentrada de Vyper es que la persona que escribió el caso de prueba lo hizo en función del resultado, sin pensar en por qué la ranura saltaría 1 inexplicablemente.

![Los piratas regresan a los "primeros principios", la crisis de Curve no es un ataque común] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-0527942e35-dd1a6f-1c6801)

En los siguientes párrafos del código Vyper compartido por Box, se puede ver claramente el problema. Cuando el nombre del bloqueo aparece por segunda vez, el número de almacenamiento_slot se sobrescribirá, es decir, en ret, el espacio para la primera adquisición del bloqueo es 0, pero después de que una función usa el bloqueo nuevamente, el Se añade una ranura para la cerradura. Después de la compilación, se usa la ranura incorrecta, lo que provoca que el bloqueo de reentrada no surta efecto.

![Los piratas regresan a los "primeros principios", la crisis de Curve no es un ataque común] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-87ec9b545c-dd1a6f-1c6801)

El izquierdo es el código atacado, y el derecho es el código reparado

"Se esperan resultados de prueba incorrectos y, por supuesto, no se pueden verificar errores. Para dar un ejemplo simple, ahora estamos haciendo un problema de cálculo, 1+ 1 = 2, pero la respuesta estándar dada es incorrecta, diciendo 1+ 1 = 3 Y esto El compañero de clase que estaba haciendo la pregunta dio la respuesta incorrecta y respondió 1+ 1 = 3, pero era la misma que la respuesta estándar dada de antemano, por lo que el programa naturalmente no tenía forma de determinar que el resultado de la prueba era mal", dijo Box en una entrevista con BlockBeats.

Colgando por dos años "Espada de Damocles"

En el primer incidente de ataque de reentrada registrado en la historia, los atacantes de WETH Attack son exactamente los hackers blancos que intencionalmente crean ataques para que los desarrolladores presten atención a los ataques de reentrada, con el propósito de hacer que más proyectos sean inmunes a la posibilidad de ataques de reentrada. En el contexto de los contratos inteligentes, los desarrolladores deben usar diferentes mecanismos de activación, como llamar a una función de cambio de estado para lograr la protección. Esto requiere que los desarrolladores consideren completamente los posibles escenarios de ataque al diseñar contratos y tomen las precauciones adecuadas.

Para obtener una comprensión profunda del editor de Vyper, BlockBeats entrevistó al investigador de BTX Derek (@begas_btxcap), quien dijo que para los desarrolladores familiarizados con Python, Vyper es una opción más ideal que Solidity, con una interfaz de usuario más cómoda. y un aprendizaje más rápido. Pero aparentemente, algunas versiones del código del editor Vyper no han sido auditadas por un tercero confiable. Incluso algunos trabajos de auditoría pueden ser realizados por los propios desarrolladores. "Este tipo de cosas no sucederán en la industria de TI tradicional, porque después de que salga un nuevo lenguaje, habrá innumerables empresas de auditoría buscando sus lagunas".

Sin mencionar, permitir que un error exista abiertamente durante dos años.

Fubuloubu, colaborador de Vyper, también dijo: El compilador no está tan revisado ni auditado como todos piensan. La mayoría de los compiladores tienen cambios significativos y frecuentes, lo que hace que la auditoría sea una desventaja. Incluso con una auditoría completa de la base de código, se volverá obsoleto a medida que se agreguen más versiones después de eso. Auditar el compilador no es una buena idea, porque tiene más sentido auditar el producto final (es decir, el código EVM sin procesar) producido por el usuario final que usa la herramienta.

Todo esto apunta a un último problema: la motivación. Dicho esto, nadie tiene incentivos para encontrar errores críticos en los compiladores, especialmente en las versiones anteriores. fubuloubu previamente hizo una propuesta que ayudaría a mejorar Vyper al agregar un programa de recompensas copatrocinado por los usuarios, pero no se llevó a cabo.

Los piratas informáticos están volviendo a los "primeros principios"

Este es otro ejemplo vivo de prácticas de desarrollo seguras para contratos para desarrolladores de protocolos y proyectos. Pero lo más importante, el incidente de Curve nos dio a todos una advertencia de que la seguridad del compilador subyacente ha sido seriamente ignorada, y los piratas informáticos que regresaron a los "primeros principios" encontraron uno perfecto en el compilador inferior.

Posteriormente, Stani (@StaniKulechov), el fundador de Aave y Lens, también publicó un largo artículo en las redes sociales para expresar sus sentimientos: El ataque a Curve significa que el riesgo de DeFi siempre ha involucrado a toda la pila subyacente, el lenguaje de programación, EVM. , etc. Esto nos advierte que seamos más cautelosos y sensibles, especialmente cuando utilicemos EVM personalizados y cadenas de aplicaciones en el futuro.

![Los piratas regresan a los "primeros principios", la crisis de Curve no es un ataque común] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-3324fcfbcd-dd1a6f-1c6801)

Ataques desde un nivel inferior

Para las vulnerabilidades del compilador, es difícil averiguarlo solo auditando la lógica del código fuente del contrato. Solo investigar las diferencias entre versiones y versiones también es un gran proyecto. Es necesario combinar versiones específicas del compilador con patrones de código específicos para determinar si los contratos inteligentes se ven afectados por las vulnerabilidades del compilador.

"Actualmente, solo dos compiladores son los mejores, la base de código de Vyper es más pequeña, más fácil de leer y tiene menos cambios para analizar su historial, que es probablemente la razón por la que los piratas informáticos comienzan aquí, la base de código de Solidity es un poco más grande", incluso sospecha Fubuloubu que afirma- Los piratas informáticos respaldados pueden estar involucrados en este ataque de Curve: "Tomará semanas o meses encontrar la vulnerabilidad y, considerando los recursos invertidos, puede ser llevado a cabo por un pequeño grupo o equipo".

Como el lenguaje de compilación más utilizado en la industria del cifrado, la seguridad de Solidity está aún más preocupada por los usuarios.Después de todo, si el compilador de Solidity tiene el problema de falla de bloqueo de reingreso esta vez, entonces la historia de toda la industria DeFi puede haber para ser reescrito.

Según las alertas de seguridad emitidas regularmente por el equipo de desarrollo de Solidity, ha habido vulnerabilidades de seguridad en muchas versiones diferentes del compilador de Solidity.

El error de compilación más reciente registrado fue el 26 de junio, cuando se investigaba un informe de seguridad relacionado con el uso de abi.error. El antiguo generador de código no evaluaba expresiones complejas como asignaciones, llamadas a funciones o condiciones a cuyo .selector se accedía. Esto provoca efectos secundarios de dichas expresiones que no se ejecutan, por lo que los contratos compilados con la canalización anterior pueden comportarse incorrectamente.

También podemos ver un archivo en el repositorio Github de Solidity que enumera algunos errores conocidos relacionados con la seguridad en el compilador de Solidity. La lista se remonta a la versión 0.3.0, los errores que existían solo antes de esta versión no se enumeran. Aquí hay otro archivo bugs_by_version.json. Este archivo se puede usar para consultar qué errores afectan a una versión particular del compilador.

Afortunadamente, es precisamente debido a la amplia aplicación del lenguaje Solidity y la asistencia de la Fundación Ethereum que muchos problemas existentes han sido señalados por proyectos y protocolos durante el proceso de implementación. Por lo tanto, Solidity ha completado la modificación y mejora unos pasos más rápido que Vyper.Desde esta perspectiva, esta es una de las razones por las que Solidity es más estandarizado y seguro.

Para ayudar a los desarrolladores de Solidity a probar mejor y evitar que suceda lo mismo. El cofundador de UnitasProtocol, SunSec (@ 1 nf 0 s 3 cpt), publicó una guía de prueba de seguridad de DeFiVulnLabs Solidity después del ataque de Curve, que admite 47 tipos de vulnerabilidades, incluidas descripciones de vulnerabilidades, escenarios, defensas, códigos de vulnerabilidad y medidas de mitigación y cómo probar .

¿Cómo evitar los ataques de bajo nivel tanto como sea posible?

En este incidente de Curve, Box cree que la iluminación para todos los desarrolladores es: no intenten seguir la tendencia tecnológica y elijan soluciones inmaduras; no aprueben su propio código sin escribir casos de prueba (varias versiones de Vyper que tienen problemas incluso el los casos de prueba son incorrectos); nunca apruebe su propio código usted mismo; algunas fortunas pueden tardar años en descubrirse; la no actualización es arrogancia hacia usted mismo y desprecio por los demás.

Por lo general, los desarrolladores no piensan en ningún peligro aquí y eligen una versión para compilar a su antojo, lo que puede ignorar los riesgos provocados por las diferencias entre versiones. Incluso las actualizaciones de versiones menores pueden introducir cambios importantes, lo que es especialmente importante cuando se desarrollan aplicaciones descentralizadas.

Las advertencias para los desarrolladores de este evento de Curve son: use una versión más nueva del lenguaje del compilador. Es importante mantener actualizados el código base, las aplicaciones y el sistema operativo, y crear sus propias defensas de seguridad en todos los aspectos. En general, hay menos problemas de seguridad conocidos que las versiones anteriores, aunque las versiones más nuevas pueden presentar nuevos problemas de seguridad. Por supuesto, también debemos prestar atención a la comunidad y a los anuncios de actualización de la versión oficial a tiempo. Comprenda los cambios que trae cada versión y actualice su propia base de código y entorno operativo según sea necesario. Seguir estos pasos puede reducir en gran medida los incidentes de seguridad causados por errores del compilador.

Además, casos de prueba unitaria para completar el código. La mayoría de los errores a nivel del compilador darán lugar a resultados de ejecución de código inconsistentes, que son difíciles de encontrar solo a través de la revisión del código, pero pueden quedar expuestos en las pruebas. Mejorar la cobertura del código puede ayudar a evitar tales problemas. Y trate de evitar el uso de funciones de lenguaje complejas, como el ensamblaje en línea y la codificación y decodificación de matrices multidimensionales, a menos que haya una necesidad clara. Históricamente, la mayoría de las vulnerabilidades del lenguaje Solidity se han relacionado con estas funciones avanzadas. Los desarrolladores deben evitar el uso de funciones de lenguaje experimental con el fin de presumir sin una necesidad específica.

Para la capa de protocolo y el personal de seguridad, los posibles riesgos de la versión del compilador no se pueden ignorar al realizar auditorías de código. Es previsible que los piratas informáticos hayan abierto nuevas ideas y, en el futuro, habrá cada vez más incidentes de explotación de vulnerabilidades de nivel inferior. Al mismo tiempo, como infraestructura subyacente, es necesario auditar la pila subyacente, el lenguaje de programación, EVM, etc. En el futuro, el mercado de las empresas de auditoría será cada vez más grande, y el mercado de las recompensas de los invitados blancos también será cada vez más grande. El equipo de Vyper también planea comenzar a revisar el programa de recompensas por errores después de que el asunto se resuelva oficialmente.

Por supuesto, no necesitamos entrar demasiado en pánico por los riesgos de la infraestructura subyacente. En la actualidad, la mayoría de los errores del compilador solo se activan en patrones de código específicos, y el impacto real debe evaluarse de acuerdo con la situación del proyecto. La actualización periódica de la versión del compilador y las pruebas unitarias adecuadas pueden ayudar a prevenir riesgos.