Incidente de Seguridad en Abracadabra
El protocolo DeFi Abracadabra ha sufrido una pérdida de $1.8 millones tras ser atacado por un individuo que explotó un simple error lógico en su función de lote. Según analistas de Hacken, el atacante logró blanquear los fondos a través de Tornado Cash.
Detalles del Ataque
A principios de octubre, Abracadabra, un protocolo de préstamos DeFi que permite a los usuarios pedir prestado su stablecoin MIM utilizando tokens depositados como colateral, volvió a ser víctima de un ataque, esta vez perdiendo aproximadamente $1.8 millones. El atacante utilizó un error lógico en la función de lote del protocolo para solicitar préstamos sin aportar colateral, replicando un ataque que había ocurrido días antes en un proyecto bifurcado, según un informe de la firma de seguridad blockchain Hacken compartido con crypto.news.
Abracadabra se lanzó como una plataforma que permite a los usuarios utilizar tokens generadores de intereses como colateral para pedir prestado un token vinculado al dólar estadounidense, conocido como Magic Internet Money (MIM). El sistema se basa en dos componentes: las Calderas, que gestionan las reglas de préstamo, y la DegenBox, la bóveda compartida que almacena los tokens. En resumen, los usuarios depositan colateral en una Caldera, mientras que la DegenBox lleva un registro de las transacciones detrás de escena.
El Error Lógico
El problema surgió cuando una bandera de seguridad, que debería forzar una verificación final para asegurar que un prestatario realmente tenía colateral, se desactivó dentro de una única transacción. Según el informe de Hacken, el atacante
«explotó un error lógico en la función cook de Abracadabra, donde podían pedir prestados tokens MIM y luego restablecer inmediatamente la bandera de validación que debía verificar si tenían suficiente colateral»
. Esto permitió que se realizara un préstamo único sin colateral a través de múltiples Calderas.
Para entender cómo ocurrió, es importante mencionar que Abracadabra utiliza una función agrupada llamada cook, que permite a los usuarios realizar varias acciones en una sola transacción, como depositar colateral y pedir prestado con un solo clic. Una de estas acciones, el paso de «pedir prestado», establece una bandera llamada needsSolvencyCheck en verdadero, lo que significa que al final de la transacción se debe verificar la solvencia del prestatario. Sin embargo, otra acción que se puede ejecutar dentro del mismo lote llama a la función _additionalCookAction(…). Hacken señala que esta función fue declarada como «virtual» y nunca fue implementada, lo que provocó que devolviera un objeto vacío donde todo estaba configurado como falso, incluida la bandera needsSolvencyCheck. Como resultado, el atacante pudo solicitar el préstamo, luego llamó a la acción predeterminada que restableció la bandera, y al final, el protocolo nunca verificó la solvencia del prestatario.
Consecuencias del Ataque
Los analistas indican que el atacante golpeó seis Calderas simultáneamente, obteniendo aproximadamente 1.79 millones de MIM y cambiándolos por ETH. Los atacantes aprovecharon la vulnerabilidad y drenaron sistemáticamente cada una de las seis Calderas utilizando la misma técnica con una llamada de función cook dedicada. Después de realizar el intercambio, el atacante enrutó los fondos a través de Tornado Cash, un protocolo de mezcla de criptomonedas, enviando gradualmente 10 ETH cada uno durante el día siguiente.
Reacciones y Lecciones Aprendidas
Este no es el primer incidente en el que el código CauldronV4 de Abracadabra se ha visto involucrado en problemas. Otros incidentes a principios de este año utilizaron diferentes casos extremos dentro de la misma familia de contratos. Lo interesante es la rápida reacción del despliegue bifurcado. Según el informe, una bifurcación llamada Synnax pausó o eliminó de la lista blanca su maestro CauldronV4 en su propia DegenBox días antes del drenaje de Abracadabra, lo que sugiere que el equipo de bifurcación activó el freno de emergencia al detectar el mismo patrón de vulnerabilidad, indicando que el riesgo era visible para los equipos que observaban el código, aunque no se había solucionado.
