Aunque gran parte de 2023 fue un mercado bajista para los protocolos DeFi, el ecosistema continúa sufriendo graves hackeos debido a vulnerabilidades en los protocolos. En particular, hubo una pérdida significativa de casi $200 millones en el hackeo de Euler Finance. Mientras tanto, han surgido nuevas tendencias en los incidentes de seguridad de DeFi, como vulnerabilidades causadas por compiladores e incompatibilidades entre estándares ampliamente utilizados. Para contrarrestar estas amenazas, la comunidad ha propuesto múltiples soluciones, incluyendo monitoreo e inteligencia de amenazas. Si bien algunas de estas medidas han demostrado ser efectivas, creemos que estos esfuerzos son ad-hoc. A la comunidad aún le falta un enfoque sistemático y una guía para ayudar a proteger los protocolos DeFi.
En este blog, primero utilizaremos casos representativos para presentar las nuevas tendencias en la seguridad de los protocolos DeFi, luego ilustraremos las soluciones actuales y sus limitaciones. Finalmente, propondremos la perspectiva de BlockSec sobre cómo proteger los protocolos DeFi.
0x0. Nuevas Tendencias en la Seguridad de los Protocolos DeFi
Tendencia-I: Protocolos reconocidos han sido atacados
En 2023, algunos protocolos bien establecidos y reconocidos han sido comprometidos, incluyendo Curve, Balancer y KyberSwap. La tabla a continuación ilustra las fechas de lanzamiento de estos protocolos reconocidos y cuándo fueron atacados. Es importante señalar que las vulnerabilidades explotadas pueden haber sido introducidas en actualizaciones que ocurrieron después del lanzamiento inicial de los protocolos. Por lo tanto, las duraciones proporcionadas en la tabla son aproximadas y están destinadas a ofrecer una idea general del período de tiempo involucrado.
| Protocolo | Fecha de lanzamiento | Fecha del incidente de seguridad | Duración |
|---|---|---|---|
| kyberSwap | 2017 | Nov, 2023 | ~ 6 años |
| Curve | 2020 | Julio, 2023 | ~ 3 años |
| Balancer | 2020 | Agosto, 2023 | ~ 3 años |
Además de los anteriores, Aave V2 fue pausado de emergencia tras recibir un informe de vulnerabilidad de la comunidad en noviembre. Aunque el protocolo no fue atacado, aún generó preocupaciones de seguridad sobre protocolos reconocidos.
Estos protocolos han pasado por varias auditorías, con múltiples medidas de seguridad implementadas internamente. Las tablas a continuación enumeran los auditores de cada protocolo. Cabe señalar que un auditor puede haber realizado auditorías solo en algunos de los contratos inteligentes dentro de los protocolos. Los auditores mencionados en la tabla no corresponden necesariamente a quienes auditaron los contratos inteligentes específicos que eran vulnerables. El propósito de esta tabla es mostrar que los protocolos han invertido recursos considerables en seguridad.
| Protocolo | Auditores | Enlace |
|---|---|---|
| kyberSwap | ChainSecurity, Sherlock, Hacken | Auditorías - Documentación de KyberSwap |
| Curve | TrailOfBits, MixBytes, Quantstamp, ChainSecurity | Auditorías - Documentación de Curve |
| Balancer | OpenZeppelin, TrailOfBits, Certora, ABDK | Seguridad | Balancer |
Afortunadamente, las víctimas han sido compensadas por sus pérdidas a través de planes implementados por los respectivos protocolos. Por ejemplo, Kyber Network anunció que tiene la intención de compensar a los usuarios afectados a través del Tesoro de KyberSwap. De manera similar, la comunidad de Curve votó a favor de una propuesta para reembolsar a los LPs por sus pérdidas financieras. Estas medidas son pasos hacia la restauración de la confianza de la comunidad DeFi, aunque con un costo considerable.
Tendencia-II: Han Surgido Nuevos Tipos de Vectores de Ataque
Los vectores de ataque que involucran errores de compiladores y bibliotecas de terceros incompatibles han surgido en el espacio DeFi. Por ejemplo, la causa subyacente del incidente de seguridad de Curve fue identificada como errores en ciertas versiones de los compiladores Vyper. Además, algunos protocolos han sufrido ataques que surgieron de la incompatibilidad entre dos estándares ampliamente adoptados: ERC2771 y Multicall, cuando estos fueron implementados en populares bibliotecas de desarrollo de terceros, como thirdweb. Estos complejos desafíos técnicos subrayan la importancia de prácticas de seguridad exhaustivas y la evolución continua de las medidas de seguridad para protegerse contra vulnerabilidades nuevas e imprevistas.
Errores de Compilador
En 1983, Ken Thompson pronunció un discurso en su conferencia del Premio Turing titulada "Reflexiones sobre la Confianza en la Confianza." En este discurso, describió los pasos para modificar un compilador de C e insertar una puerta trasera en un programa, lo que puede llevar a resultados inesperados. La idea transmitida en el discurso fue bien recibida por la comunidad. Sin embargo, los casos reales de compiladores maliciosos en la práctica son raros (excepto por los conocidos incidentes de seguridad de XcodeGhost). Incluso si relajamos el modelo de seguridad de compiladores maliciosos a comportamiento del compilador benigno pero inesperado, los casos públicos que causan graves pérdidas financieras siguen siendo raros.
El incidente de seguridad de Curve causado por el error del compilador Vyper es uno de los casos públicamente conocidos que causó aproximadamente 70 millones en pérdidas (algunos de ellos han sido devueltos, y las pérdidas reales rondan los 23 millones). Las versiones 0.2.15, 0.2.16 y 0.3.0 del compilador Vyper tienen errores que inutilizan el mecanismo de protección contra reentrada. Esto significa que el atacante puede aprovechar la reentrada para realizar el hackeo, lo que no debería ocurrir si el compilador genera el bytecode correcto, ya que el desarrollador había añadido el código para evitar que ocurra la reentrada.

Tx del Ataque: 0x2e7dc8b2fb7e25fd00ed9565dcc0ad4546363171d5e00f196d48103983ae477c
Incompatibilidad de Estándares Comunes
La componibilidad de DeFi permite que diferentes contratos inteligentes y estándares se conecten y creen aplicaciones poderosas. Sin embargo, esto genera posibles problemas de compatibilidad. Por ejemplo, combinar estándares populares puede introducir nuevas vulnerabilidades de seguridad cuando cada contrato inteligente funciona sin problemas por sí solo.
Un ejemplo de tal problema de incompatibilidad involucra los estándares ERC-2771 y Multicall. ERC-2771 define una interfaz para recibir metatransacciones a través de un reenviador de confianza, mientras que Multicall es un mecanismo para agrupar múltiples llamadas a funciones dentro de una sola transacción. El problema surge cuando una llamada reenviada desde un reenviador de confianza recupera la dirección de llamada real desde los calldata, que puede ser manipulada por un atacante. Aunque cada estándar funciona perfectamente de forma aislada, su uso combinado puede interrumpir ciertas suposiciones y llevar a problemas imprevistos. Para más detalles, consulte la publicación del blog de OpenZeppelin.
Tenga en cuenta que tanto los estándares ERC-2771 como Multicall están implementados en populares bibliotecas de desarrollo como OpenZeppelin y thirdweb. Los desarrolladores suelen depositar su confianza en estas conocidas bases de código y pueden excluirlas de las auditorías de código. Esta práctica puede introducir nuevas brechas de seguridad, incluso si los protocolos en sí mismos no son intrínsecamente vulnerables.
Tendencia-III: Las Vulnerabilidades Antiguas Tienen Nuevos Impactos en la Seguridad
La pérdida de precisión se refiere a la reducción en la precisión y exactitud durante los cálculos, generalmente causada por un resultado que tiene menos decimales de los esperados. Si bien los analizadores estáticos pueden detectar fácilmente problemas de pérdida de precisión, su mera existencia no indica necesariamente una vulnerabilidad de seguridad. Solo se considera una vulnerabilidad si la pérdida de precisión podría llevar a consecuencias graves. Sin embargo, evaluar el impacto de la pérdida de precisión suele ser difícil, ya que requiere una comprensión profunda de la semántica del protocolo y el contexto específico del código.
Varios ataques han apuntado a protocolos que son bifurcaciones de otros protocolos líderes, como Compound v2 y Aave v2, que pueden ser susceptibles a problemas de precisión conocidos. Específicamente, los incidentes que involucran a Hundred Finance y Channels Finance—que son bifurcaciones de Compound v2—surgieron de mercados inicializados incorrectamente, así como de problemas relacionados con la pérdida de precisión. Estos problemas permitieron a los atacantes canjear colateral con un número reducido de tokens debido a errores de redondeo hacia abajo.
Tx del Ataque: 0x3f7de75566289224c5e95a35ee8717ddd6928500227a05c1d83838844c60491d
0x1. Soluciones Actuales
Es cierto que los protocolos DeFi reconocidos han invertido sustancialmente en medidas de seguridad y han pasado por múltiples rondas de auditorías de seguridad. No obstante, considerando las grandes cantidades de activos de usuarios que gestionan estos protocolos, está completamente justificado subrayar la naturaleza crítica de la seguridad de los protocolos. Más allá de la auditoría de código, existen soluciones adicionales propuestas como el monitoreo de amenazas. Analicemos el estado actual de estas soluciones y sus limitaciones.
Auditoría de Código
La auditoría de código, tal como se define aquí, es un proceso crítico en la evaluación de seguridad de los protocolos DeFi, que generalmente se realiza antes de que un protocolo entre en funcionamiento. Incorpora una variedad de técnicas, incluyendo revisión manual de código, análisis estático, pruebas de fuzzing dinámico y verificación formal. Además, este proceso puede llevarse a cabo en una (o pocas) empresas de auditoría o mediante un método impulsado por la comunidad. Sin embargo, existen limitaciones en la auditoría de código que deben reconocerse.
-
En primer lugar, la auditoría de código ocurre principalmente antes de que el protocolo sea desplegado. Una vez que el protocolo está en funcionamiento, el proceso de auditoría generalmente concluye, y la seguridad continua no puede ser evaluada de forma continua por la auditoría de código inicial. Esto significa que cualquier vulnerabilidad o problema que surja después del lanzamiento puede no ser detectado por la auditoría de código inicial.
-
En segundo lugar, la auditoría de código a menudo tiene dificultades para identificar vulnerabilidades sutiles que requieren interacciones complejas y estados específicos para ser explotadas. La componibilidad de los protocolos DeFi, si bien es una característica que promueve la flexibilidad y la integración, expande significativamente el espacio del programa y presenta desafíos graves para los revisores humanos y los analizadores estáticos, que tienen dificultades para explorar toda la gama de estados del programa. Aunque las pruebas de fuzzing dinámico pueden ser beneficiosas, están limitadas por las dependencias de transacciones y estados. La ausencia de oráculos de fuzzing conscientes de los protocolos DeFi, que puedan detectar fallos, es una brecha significativa en el campo que sigue siendo una pregunta de investigación abierta tanto en la industria como en la academia.
-
En tercer lugar, hay escasez de auditores de código calificados, lo que no puede resolverse rápidamente debido al limitado grupo de talentos. La auditoría de código es una tarea interdisciplinaria que requiere conocimientos de ciberseguridad, finanzas y matemáticas. Solo un número selecto de universidades ofrecen actualmente educación en este campo especializado, lo que lleva a altos costos para auditorías de código de calidad y largos tiempos de espera para los servicios. Como resultado, los protocolos pueden entrar en funcionamiento sin una auditoría de código para mantener sus plazos comerciales.
-
En cuarto lugar, evaluar la calidad de una auditoría de código es un desafío para los usuarios. Si bien los usuarios son los más interesados en la seguridad del protocolo, ya que depositan sus activos en él, la mayoría carece de la capacidad para evaluar la exhaustividad de una auditoría de código. Esto puede llevar a auditorías realizadas meramente por apariencias, lo que en última instancia puede comprometer la seguridad tanto del protocolo como de los activos de los usuarios.
En conclusión, si bien la auditoría de código es una herramienta valiosa para asegurar los protocolos, sus limitaciones inherentes significan que no puede ser la única solución de seguridad.
Monitoreo de Amenazas
La idea básica del monitoreo de amenazas es supervisar y detectar las sospechosas. Esto mejora la seguridad, pero necesita abordar las siguientes preocupaciones para ser efectivo.
-
En primer lugar, la precisión de los sistemas de monitoreo de amenazas es crucial. Deben lograr un equilibrio minimizando tanto los falsos positivos como los falsos negativos. Una alta tasa de falsos positivos puede generar alertas falsas, donde los usuarios o los equipos de seguridad se vuelven insensibles a las advertencias, potencialmente pasando por alto amenazas reales.
-
En segundo lugar, el estado actual de los sistemas de monitoreo de amenazas a menudo requiere confirmación manual para actuar ante la detección de transacciones sospechosas. Esto se debe en gran medida al problema mencionado anteriormente de las altas tasas de falsos positivos. La naturaleza reactiva de las intervenciones manuales es problemática porque, en el entorno de ritmo rápido de la cadena de bloques y los protocolos DeFi, los ataques pueden agotar los recursos rápidamente, a menudo antes de que puedan implementarse respuestas manuales. Por lo tanto, el valor de un sistema de monitoreo de amenazas se reduce significativamente si no puede proporcionar acciones automáticas oportunas para prevenir o mitigar los ataques.
-
Además, el monitoreo de amenazas debe ser persistente y capaz de adaptarse a las nuevas amenazas a medida que surjan.
0x2. La Perspectiva de BlockSec
Creemos que la seguridad del protocolo necesita múltiples defensas en diferentes etapas del ciclo de vida de un protocolo, incluyendo auditoría de código de alta calidad, pruebas de seguridad antes del lanzamiento, detección y bloqueo de ataques, y respuesta a incidentes de seguridad después del lanzamiento. También queremos destacar algunas perspectivas que han sido ignoradas en la comunidad.
-
Primero, creemos que se necesitan pruebas de seguridad exhaustivas para cualquier pequeña actualización de código o configuración. Dichas pruebas deben realizarse en los estados reales del protocolo en lugar de los estados ficticios de los datos de usuario. Como se discutió anteriormente, los estados del protocolo son cruciales para localizar vulnerabilidades en protocolos complicados.
-
Segundo, se necesita un sistema de respuesta automático a los ataques, en lugar de intervención manual. Esto requiere un sistema de detección de ataques preciso y rápido, con muy bajos falsos positivos y casi cero falsos negativos. Por ejemplo, se pueden salvar los activos de millones de usuarios si se implementa una respuesta automática.
-
Tercero, se debe establecer un procedimiento adecuado de respuesta a incidentes de seguridad, y se necesitan socios de seguridad que puedan proporcionar servicios de seguridad integrales. Por ejemplo, cuando ocurre un exploit, el socio puede asistir en el proceso de creación de una sala de guerra, recomendar acciones a tomar, ayudar a revisar y auditar parches de seguridad, rastrear flujos de fondos, etc. El artículo de yearn finance es un buen recurso sobre cómo manejar exploits.
Servicio de Seguridad de Pila Completa Proporcionado por BlockSec
Basándose en las perspectivas anteriores, BlockSec proporciona servicios de seguridad de pila completa a los protocolos.
- Servicios de auditoría de código de alta calidad. BlockSec proporciona servicios de auditoría de código diligentes a los protocolos DeFi. Aprovechando la herramienta de análisis estático, el fuzzing dinámico y el marco de pruebas diferenciales respaldado por investigación académica creativa, nuestras auditorías de código cubren tanto los protocolos como el motor de ejecución EVM subyacente. Además, la herramienta de análisis estático HookScan fue apoyada por Uniswap Lab para detectar las vulnerabilidades en los hooks de Uniswap V4.
- Phalcon: Sistema de Detección y Bloqueo de Ataques. Con técnicas probadas en batalla para bloquear más de 20 ataques y rescatar alrededor de 14 millones de USD, BlockSec Phalcon puede ayudar al protocolo a monitorear activamente contratos y transacciones de ataque (incluso antes de que el hacker lance las transacciones de ataque). Con un motor de detección de ataques con casi un 99,99% de precisión más políticas personalizadas por el usuario, BlockSec Phalcon equilibra los falsos positivos y negativos, habilitando el mecanismo de defensa automático.
- Respuesta a Incidentes de Seguridad. BlockSec es siempre el proveedor de seguridad más rápido (si no el primero) que puede identificar las causas raíz de los ataques y las vulnerabilidades en los hackeos de DeFi. Podemos ayudar a los protocolos a revisar los parches de seguridad (Telcoin), proporcionar el rescate de fondos en blanco [por ejemplo, AnySwap, TransitSwap, Paraspace, Loot], rastrear el flujo de fondos del hackeo e identificar la identidad del atacante de Hopeland.
0x3. Conclusión
En 2023, encontramos que hay nuevas tendencias en la seguridad de los protocolos DeFi, y muchos protocolos reconocidos han sido atacados. Sabemos que garantizar la seguridad de los protocolos en términos técnicos es un desafío complejo y continuo. Simplemente adoptar auditorías de código o sistemas de monitoreo ya no es suficiente. Necesitamos una solución de pila completa que combine estos elementos y funcione a lo largo de todo el ciclo de vida de un protocolo.
En conclusión, el enfoque holístico de BlockSec hacia la seguridad de los protocolos DeFi, que combina técnicas de auditoría de vanguardia, herramientas automáticas de defensa contra ataques y gestión de incidentes receptiva, lo posiciona como un socio líder para los protocolos que buscan fortalecer sus medidas de seguridad y proteger los activos de los usuarios frente a las amenazas en evolución en el espacio DeFi en 2024.



