-
El fallo permitía a un único validador operar sin confirmaciones y vaciar pools de liquidez.
-
El bug fue encontrados semanas previas al hackeo de USD 10 millones que sufrió THORChain.
La firma de seguridad V12 Security reveló que a finales de abril pasado encontró una vulnerabilidad crítica en el protocolo de intercambios (swaps) THORChain que permitía a un solo operador de nodo validador robar fondos de los pools de liquidez del protocolo. El hallazgo, aunque no implicó la misma falla, ocurrió semanas antes del hackeo de USD 10 millones sufrido por la plataforma el 15 de mayo.
THORChain habría aplicado el parche en silencio, sin comunicación pública, y notificó a la firma que su programa de recompensas por reporte de vulnerabilidades (conocido como bug bounty) estaba «permanentemente retirado», según explicaron investigadores de V12 Security este 1 de junio.
ZachXBT, el investigador on chain que había alertado sobre el hackeo de mayo, reaccionó con una crítica directa al protocolo: «Uno esperaría que después de todos los exploits que tuvieron, la seguridad se tomara más en serio. Sin embargo, THORChain sigue bajando el listón».
THORChain lleva dos semanas con la red detenida a raíz del hackeo del 15 de mayo, que involucró una vulnerabilidad distinta a la reportada por V12 Security. El fallo, como lo explicó CriptoNoticias, ocurrió a nivel del GG20 TSS, el esquema criptográfico que permite a los nodos del protocolo firmar transacciones en conjunto.
Desde THORChain comunicaron el 27 de mayo que la versión de software necesaria para reanudar operaciones (la v3.19.0) debe completar pruebas antes de llegar a la red principal, sin fecha confirmada.
¿Cómo funcionaba el fallo y qué podía perder un usuario?
THORChain opera con activos de distintas redes (bitcoin, ether, entre otros) que los usuarios depositan para hacer intercambios. Antes de ejecutar un swap, el protocolo espera que la transacción origen alcance un número mínimo de confirmaciones en su cadena: para bitcoin, por ejemplo, 10 bloques. Ese requisito existe para garantizar que el depósito sea irreversible antes de liberar los fondos del lado de THORChain.
El fallo reportado por V12 Security permitía eludir ese requisito. Cada validador de THORChain firma criptográficamente su observación de una transacción externa (una firma de atestación que certifica que el depósito fue visto), pero esa firma solo cubre los datos básicos de la transacción, como los montos y las direcciones. Los campos que registran si la transacción alcanzó las confirmaciones necesarias quedaban fuera de la firma y podían ser modificados libremente.
¿Cómo se ejecutaba el ataque?
Según el informe de V12 Security, en THORChain los validadores se turnan para proponer bloques con una rotación predecible y determinista.
En el contexto de la vulnerabilidad encontrada por los investigadores, un validador malicioso podría, cuando le tocara el turno, tomar las observaciones firmadas por otros nodos honestos sobre una transacción aún no confirmada, alterar los campos de finalidad para indicar que la transacción ya estaba completa e inyectarla en el bloque.
De acuerdo con el mismo informe, la etapa de validación del bloque no verificaría esa finalidad, ya que solo comprobaría que las transacciones pudieran leerse correctamente. Las firmas de los validadores honestos seguirían siendo válidas porque los campos alterados nunca estuvieron cubiertos por ellas.
El resultado, según V12 Security, sería que THORChain ejecutaría el intercambio de inmediato y liberaría los fondos del pool hacia el atacante, antes de que el depósito original hubiera alcanzado las confirmaciones requeridas. El atacante podría entonces revertir ese depósito y quedarse con ambos lados del intercambio.
V12 Security demostró el ataque en un entorno de prueba controlado con cuatro validadores activos. En esa prueba de concepto (una demostración técnica que verifica que la vulnerabilidad es real y explotable) una transacción de Bitcoin con una sola confirmación, cuando se requerían diez, fue procesada como si estuviera completa. El pool simulado perdió el equivalente a más de 82.000 millones de unidades de RUNE (token nativo de THORChain).
El ataque, aseguran desde V12 Security, requería controlar un único nodo validador activo, sin necesidad de acceder a claves de otros validadores ni ocupar una posición especial en la red.
Un historial de reportes sin pago
La firma de seguridad QED Audit informó a THORChain en enero pasado de dos vulnerabilidades en el protocolo mientras el programa de bug bounty aún estaba activo: una que habría permitido el robo de activos por más de USD 40 millones y otra que habría permitido vaciar todos los bonos de RUNE de los validadores, según explicaron.
De acuerdo con QED Audit, ambos fallos fueron corregidos antes de la versión 3.15.0, publicada el 29 de enero, pero la firma tampoco recibió el pago de recompensa. «No vamos a abogar por la divulgación abierta porque creemos que la divulgación responsable debe mantenerse separada de las disputas por compensación», señaló la firma, que igualmente publicó los detalles técnicos de los fallos.
THORChain no emitió ningún comunicado público sobre estas vulnerabilidades ni sobre la eliminación de su programa de bug bounty. El comunicado del 27 de mayo informó que la librería criptográfica central del protocolo, tss-lib, fue temporalmente puesta en código cerrado para que el equipo de seguridad interno THORSec complete una auditoría sin exponer el trabajo de remediación en curso.
Luego de haber sufrido el exploit a mediados de mayo que le implicó una pérdida de USD 10 millones, el protocolo de intercambios promete una reapertura «segura y estable» sin fecha confirmada.
