Introducción
En los últimos tres años, hemos observado varios incidentes de seguridad en el ecosistema DeFi. Para defenderse de las amenazas, la comunidad ha adoptado métodos centrados en el código, como la auditoría estática de código, herramientas de análisis de contratos inteligentes o el fuzzing dinámico. Aunque han demostrado ser efectivos, sostenemos que el enfoque centrado en el código no puede resolver por sí solo los problemas de seguridad y proteger los activos de los usuarios del proyecto. Por ejemplo, existen varios casos en los que contratos vulnerables han sido auditados por múltiples empresas de auditoría de código de reconocido prestigio.
Creemos que, además de los enfoques existentes centrados en el código, debería existir una solución de prevención de amenazas más proactiva para defenderse de ellas. Deliberamos internamente sobre esta idea a finales de 2021 y desarrollamos un sistema llamado IronDome a principios de 2022. Desde entonces, hemos desplegado el sistema internamente en BlockSec. En 2022, IronDome bloqueó con éxito múltiples ataques y salvó más de 5 millones de USD en activos de usuarios, incluido el caso que evitó el exploit a Saddle Finance en abril de 2022 y rescató 3,8 millones de USD.
En este blog, detallaremos la arquitectura del sistema IronDome y sus casos de éxito. También analizaremos las limitaciones de nuestro sistema y las perspectivas sobre la dirección futura de la prevención de amenazas.
Arquitectura General del Sistema
La idea básica de IronDome es escuchar el pool de transacciones pendientes de Ethereum, detectar la transacción de ataque a través de nuestro sistema de pre-ejecución de transacciones Mopsus, y bloquear el ataque sintetizando automáticamente una transacción de rescate que transfiere los activos vulnerables a nuestra cuenta segura, adelantándose a la transacción de ataque mediante FlashBot. La siguiente figura muestra la arquitectura.
Monitoreo del Mempool
IronDome escucha las transacciones pendientes en el pool de memoria a través de nuestro cliente Geth personalizado. El punto crítico es que nuestro sistema debe escuchar las transacciones con prontitud y captar el mayor número posible de transacciones.
Detección de Ataques
Cada transacción pendiente se enviará al módulo de detección de ataques. Dado que estas transacciones aún no están en la cadena, aprovecharemos nuestro motor de pre-ejecución de transacciones Mopsus para pre-ejecutarlas y detectar las transacciones de ataque (maliciosas) basándonos en los estados en tiempo de ejecución y los resultados de la transacción.
Síntesis de la Transacción de Rescate
Para la transacción de ataque, IronDome sintetizará automáticamente una transacción de rescate y sus contratos auxiliares. La transacción de rescate seguirá un método similar al de la transacción de ataque para "explotar" el contrato vulnerable, pero transferirá el beneficio a nuestra cuenta segura (una cuenta multi-firma) en lugar de a la cuenta controlada por el atacante. Por ejemplo, podemos desplegar automáticamente contratos auxiliares similares a los contratos de ataque, pero reemplazando la dirección de transferencia de tokens por nuestra cuenta segura. Por supuesto, para algunas transacciones de ataque es necesario utilizar enfoques más complejos.
Para la transacción de rescate, necesitamos que llegue a la cadena antes que la transacción de ataque. En el sistema actual, utilizamos FlashBot para este propósito. En primer lugar, debemos asegurarnos de que nadie más pueda escuchar nuestra transacción de rescate. En segundo lugar, podemos adoptar ciertas estrategias para colocar nuestra transacción de rescate en la cima del bloque.
Casos de Éxito Representativos
Desplegamos IronDome a principios de 2022. El sistema ha detectado y bloqueado con éxito múltiples ataques. Esta tabla resume algunos de los casos de éxito.
La siguiente línea de tiempo muestra cómo nuestro sistema rescató 3,8 millones de USD para Saddle Finance a finales de abril de 2022. En particular, nuestro sistema completó todo el proceso de detección de la transacción de ataque y síntesis automática de la transacción de rescate en menos de un segundo. Devolvimos todos los fondos rescatados a Saddle Finance. Haz clic en el enlace para ver la transacción del hack original y nuestra transacción de rescate a continuación.
- Transacción del hack original: https://etherscan.io/tx/0xd9bc83688e8eddde39bd9073c363665b1419d475dd4498e81b52cce41d7c76b3
- Nuestra transacción de rescate: https://etherscan.io/tx/0x9549c0cb48ec5a5a2c4703cbbbbea5638028b2d8c8adc103220ef1c7fe5e99a3
Consideraciones Éticas
Nos tomamos muy en serio la ética de seguridad en nuestro sistema. Aunque nuestro sistema está "explotando" el contrato vulnerable para rescatar los activos de los usuarios, creemos que esta acción no presenta un problema ético.
- En primer lugar, nuestro sistema no está explotando activamente el contrato vulnerable. Solo reacciona cuando detecta una transacción de ataque pendiente y sintetiza automáticamente una similar (para bloquear la transacción de ataque). Nunca crea la transacción de ataque en primera instancia.
- En segundo lugar, nos comunicamos activamente con el protocolo afectado y devolvemos los fondos rescatados.
Limitaciones
Aunque IronDome ha demostrado su eficacia, el sistema todavía tiene algunas limitaciones. A continuación, ilustraremos estas limitaciones y discutiremos las direcciones futuras en la prevención proactiva de amenazas.
- En primer lugar, nuestro sistema escucha las transacciones pendientes en el mempool. Si el atacante utiliza algún servicio de transacción privada, como FlashBot, la transacción de ataque no estará en el mempool y, por tanto, no podrá ser detectada. Para resolver este problema, pedimos colaboración con el proveedor de servicios de transacciones privadas para detectar y bloquear la transacción de ataque (adoptando una forma similar a la de nuestro sistema para detectar la transacción maliciosa). Además, incluso si nuestro sistema no puede bloquear la transacción de ataque en la herramienta de pendientes, aún puede detectar la transacción de ataque en la cadena y enviar una transacción de rescate para prevenir futuras transacciones de ataque. Cabe destacar que, en muchos casos, existe más de una transacción de ataque.
- En segundo lugar, la seguridad es una carrera armamentista. Hemos visto casos en los que los atacantes elevan el listón para la síntesis de la transacción de rescate. Por ejemplo, pueden dividir una transacción de ataque en múltiples transacciones y ofuscar la dirección de beneficios. Aunque estos problemas pueden resolverse, creemos que la carrera armamentista no se detendrá. Estamos trabajando en soluciones para resolver estos problemas.
- En tercer lugar, cómo hacer que la transacción de rescate llegue a la cadena antes que la transacción de ataque sigue siendo una pregunta abierta. Aunque algunas estrategias de puja pueden mejorar las posibilidades de que nuestra transacción de rescate sea incluida en el bloque, no podemos garantizarlo al 100%.
Referencias y Lectura Adicional
[1] Cómo hacer que los ataques a la BlockChain sean "bloqueables" | por BlockSec
[2] The Block: El DEX de stablecoins Saddle Finance hackeado por 10 millones de dólares
[3] Post-Mortem del Exploit de Lend — HomeCoin (mirror.xyz)
[5] FSWAP en Twitter: "Los detalles del ataque al progreso de liquidez de FSWAP" / Twitter
[6] https://forta.org/blog/blocksec-and-forta-work-to-secure-web3-beyond-audits/
[7] https://forta.org/blog/the-future-of-threat-prevention-in-web3/
