El ETH Router Exploit 1 & 2, Premature Trading, arreglos y respuesta de la red, así como la respuesta de 5 puntas.
THORChain sufrió dos exploits consecutivos en su enrutador ETH. El primero tomó todo el ETH del sistema a través de un contrato de ataque que se encontraba frente al enrutador, y el segundo tomó todos los ERC20 económicamente significativos a través de un contrato de ataque que se encontraba detrás del enrutador.
En ambos casos, los exploits pudieron engañar al Bifrost para que informara sobre la recepción de activos que no había recibido. La causa raíz fue una interfaz Bifrost que no tuvo en cuenta completamente los grados de manipulación que pueden ocurrir en eventos de contratos inteligentes.
No se vieron afectadas otras cadenas o activos.
El equipo y la comunidad de THORChain han puesto en marcha un plan de cinco pasos para abordar, solucionar y recuperar. Se detallan a continuación.
La tesorería de THORChain cubrirá todas las pérdidas de los LP. Los nodos no se ven afectados.
El atacante implementó un contrato que se encontraba frente al enrutador, que podía llamar a la función deposit () del enrutador. La capacidad de encapsular el enrutador se puso a disposición recientemente para respaldar el desarrollo del ecosistema. El alcance total de esto no se evaluó a fondo en ese momento.
El contrato de ataque simplemente desvió el valor del mensaje hacia ellos mismos, llamando con un valor de 0 al enrutador. El Bifrost leyó el valor de mensaje en lugar del evento de depósito emitido. Esto es necesario para admitir actualizaciones de enrutadores, pero no debería haber sido para eventos de depósito.
La solución fue hacer cumplir que para una acción de depósito, solo se lee el evento de depósito.
Billetera del atacante: 0x3a196410a0f5facd08fd7880a4b8551cd085c031
Dirección del contrato: 0x4a33862042d004d3fc45e284e1aafa05b48e3c9c
Dirección del tornado: 0x4b713980d60b4994e0aa298a66805ec0d35ebc5a
Un informe completo está disponible aquí:
https://thearchitect.notion.site/THORChain-Incident-07-15-7d205f91924e44a5b6499b6df5f6c210
Impacto – $ 8 millones
El atacante depositó ETH falso en el contrato muchas veces, cambiando a otros ERC20, aumentando artificialmente sus precios y pagando grandes cantidades de tarifas. Luego, finalmente pudieron desviar el ETH al forzar un reembolso (utilizando un memorando deliberadamente malo).
En total, desviaron ~ 4200 ETH del sistema y provocaron un gran aumento en los volúmenes de arbitraje.
La red fue detenida rápidamente por nodos para limitar el impacto. Alrededor de 700 ETH se retuvieron en salidas pendientes. Luego se lanzó una actualización posterior para purgar estos límites y guardar el 700 ETH. El sistema pensó que tenía 13,000 ETH, pero solo tenía 700 ETH, por lo que la actualización también contenía una migración de la tienda para corregir el saldo. Esta migración de la tienda haría que el precio de ETH en el sistema pasara de $ 350 (13k ETH) a alrededor de $ 7000 (700 ETH), para reflejar los saldos reales del grupo.
El plan era completar la actualización y permitir que el arbitraje vendiera el ETH de $ 7k a $ 2k (precio real), por lo que el informe para los administradores fue habilitar el comercio después de la actualización.
El proceso de actualización no se desarrolló adecuadamente. Las instrucciones de actualización deberían haber sido reiniciar thord, actualizar y luego cerrar inmediatamente el servicio Bifrost. Esto se debe a que hay una ventana de tiempo estrecha desde el 67% actualizado hasta el 100% actualizado donde la lógica anterior aún se aplica, pero la red está operativa. Idealmente, debería haber existido un mimir para detener la firma mediante programación.
Retiros LP
Una vez que el 67% se actualizó, la red se reinició y comenzó a procesar txIns. Lo que no se planeó fue que los LP de ETH comenzaron a retirarse asimétricamente a ETH aprovechando el hecho de que estaban recibiendo un reclamo sobre 13k ETH, cuando solo había 700 ETH.
La respuesta correcta a esto fue pedirle a los Nodos que apagaran sus Bifrosts para detener las retiradas (el sistema se estaba volviendo insolvente rápidamente), O que dispusieran de un mimir para detener las retiradas. Esta configuración mimir no se había creado debido a la filosofía del sistema de no bloquear nunca los retiros.
En el calor del momento, el administrador de mimir en servicio infirió incorrectamente que la respuesta era permitir que el comercio corrija el precio de ETH para detener el abuso de los LP de ETH. Esto fue según el resumen, pero fue prematuro, ya que el precio de ETH aún no se había actualizado desde la migración de la tienda. El resultado final fue que la reactivación del comercio hizo que los agentes de arbitraje compraran ETH barato, en lugar de vender ETH caro. Al comprar el ETH barato, se tomó el ETH restante en el sistema y la red se declaró insolvente.
Se pidió nuevamente a los nodos que se detuvieran.
Las soluciones a los problemas anteriores se implementaron y se enviaron a la red. La solución también incluía la capacidad de detener una cadena completa y detener programáticamente los retiros. La solución también contenía lógica para desviar las transacciones arb al tesoro ya que el sistema era insolvente y no podía cumplirlas. Esto requería que los Bifrost estuvieran en línea para reiniciarse.
Lo que se desconocía en ese momento era que había otra vulnerabilidad crítica en el enrutador ETH. El atacante creó un enrutador falso, luego un evento de depósito emitido cuando el atacante envió ETH. El atacante pasa returnVaultAssets () con una pequeña cantidad de ETH, pero el enrutador se define como una bóveda Asgard. En el enrutador Thorchain, envió ETH al falso Asgard. Esto crea un evento de depósito falso con una nota maliciosa. El Bifrost intercepta como un depósito normal y reembolsa a un atacante debido a una mala definición de la nota.
Dirección del contrato
Transacción 1
Transacción 2
Transacción 3
Transacción 4
Transacción 5
Transacción 6
Última transacción de un atacante
Enrutador: 0xc145990e84155416144c532e31f89b840ca8c2ce
Bóveda: 0xf56cba49337a624e94042e325ad6bc864436e370
Contrato de ataque: 0x700196e226283671a3de6704ebcdb37a76658805
Cartera de ataque (generada a partir de Tornado Cash):0x8c1944fac705ef172f21f905b5523ae260f76d62
Impacto (~ $ 8M USD)
966,62 ALCX20.866.664,53 XRUNE1,672,794.010 USDC56,104 SUSHI6,91 YFI990.137,46 USDT
Los problemas anteriores tienen soluciones simples, pero la verdadera pregunta es por qué, no realmente cómo.
No es realista que THORChain alguna vez esté libre de ataques, por lo que se necesita un pensamiento general, comenzando desde el código hasta la red en vivo. ¿Por qué hubo vulnerabilidades críticas en el código durante tanto tiempo, por qué fueron abusados por los sombreros negros antes que los sombreros blancos, por qué THORChain pudo enviar tanto TVL tan rápidamente, por qué el sistema no reaccionó más rápido.
Se pueden resumir de la siguiente manera.
Problema 1: el código ETH Bifrost no fue auditado
La máquina de estado THORChain y el código BNB Bifrost fueron auditados como parte de Single Chain Chaosnet, pero la máquina de estado MCCN actualizada y sus nuevos Bifrosts MCCN no lo fueron. Se programaron con TrailOfBits, que desafortunadamente no había comenzado en el momento del primer Exploit.
Reparar: Detener y auditar. Tanto Trail of Bits como Halborn Security están en marcha con dos auditorías simultáneas.
Problema 2: No había un programa oficial de recompensas.
Como parte de Single Chain Chaosnet, se lanzó un programa de recompensas, pero no se actualizó como parte de MCCN. Esto se pasó por alto. Por lo tanto, no hubo incentivos y campañas claros para que los hacks blancos se incorporen y encuentren vulnerabilidades.
Reparar: Encargue un programa de recompensas con Immunify.
Problema 3: no hay un "equipo rojo" en curso
THORChain es un intercambio de adentro hacia afuera. Los intercambios tienen equipos de seguridad activos, incluso con motores de intercambio patentados bloqueados. THORChain necesita un equipo rojo que funcione de forma continua las 24 horas del día, los 7 días de la semana para cada nuevo RP, así como para monitorear activamente la red.
Reparar: Encargue un Equipo Rojo con Halborn Security.
Problema 4: THORChain no tiene monitoreo de seguridad activo
La naturaleza autónoma y descentralizada de THORChain fue su propia espada en la que murió. Felizmente ejecutó transacciones de ataque y no había nada que nadie pudiera hacer. La única respuesta fue que todos los nodos apagaran sus máquinas.
Arreglos:
Comprobador de solvencia automático para detenerse tan pronto como se detecte una solvencia (proactiva y reactivamente) Tiempo de espera del operador del nodo: cualquier nodo puede llamar para interrumpir el tiempo de espera de la red durante 25 minutos si sospecha algo. Esto le da a cada uno de los 36 operadores de nodo la capacidad de agotar el tiempo de espera de un ataque cuando lo observan. Regulación de salida: la cola txOut se regula para retrasar artificialmente la liquidación de transacciones cuando hay picos repentinos.
Problema 5: No hay seguro de protocolo
Si bien la tesorería puede cubrir las insolvencias, la tesorería no existirá para siempre. La solución es asegurar todos los TVL que no sean de RUNE con un proveedor de seguros DeFi, utilizando garantías e ingresos de las propias reservas del sistema.
Reparar: Involúcrese con los protocolos de seguros DeFi para intentar asegurar todo el protocolo.
La red tiene que lidiar con una insolvencia de ~ $ 16 millones. El plan es:
1/3 ($ 5,3 millones) se contribuirá directamente de los activos de tesorería. 1/3 ($ 5,3 millones) se prestará de Iron Bank utilizando la garantía RUNE y se pagará más tarde. de nuevo en línea para operar.
Para financiar (2) y cubrir parcialmente (1), se encargará un gran evento de recaudación de fondos públicos después de que la red esté operativa, en las cercanías de $ 10 millones a $ 20 millones. Esto se planificará y ejecutará en el dominio público cuando llegue el momento.
Las correcciones anteriores deben estar implementadas antes, tardarán de 2 a 3 meses en configurarse por completo.
Sin embargo, la red se puede poner en línea en etapas una vez que se revisa minuciosamente el código suficiente y el programa de recompensas ha solicitado suficientes errores importantes (si los hay). Los cronogramas guiados son:
Reinicio de la red (enviar RUNE, Bond, recibir recompensas en bloque) – principios de agosto Cadena BNB en línea – Agosto Cadenas UTXO en línea – Septiembre Cadena ETH en línea – Octubre
La descripción general se detalla ampliamente aquí:
Gráfico de gantt:
Suponiendo que todas las correcciones estén implementadas, la red se vuelva a comprar en línea y sea solvente, y pueda lograr estabilidad, se espera que la línea de tiempo para Mainnet sea EoY 2021 o principios de 2022.
Mainnet es simplemente la definición de que la red es estable y segura.