Ribbon Finance, anteriormente Aevo, pierde $2.7 millones en un hackeo de DeFi

Un sofisticado ataque a Aevo-rebrand Ribbon Finance drenó $2.7 millones de su contrato antiguo y los movió a quince direcciones de billetera separadas, algunas de las cuales ya han sido consolidadas en cuentas más grandes. 

Según varios investigadores de blockchain en la plataforma social X, el ataque ocurrió solo seis días después de que la plataforma actualizara su infraestructura de oracle y los procedimientos de creación de opciones. Utilizaron un contrato inteligente para extraer cientos de tokens Ethereum y otros activos digitales.

En un hilo explicando el exploit, el analista de seguridad Web3 Liyi Zhou dijo que un contrato malicioso manipuló el stack oracle de Opyn/Ribbon abusando de los proxies de alimentación de precios, e introdujo precios de vencimiento arbitrarios para wstETH, AAVE, LINK y WBTC en el oracle compartido en una marca de tiempo de vencimiento común. 

"El atacante colocó grandes posiciones short de oToken contra el MarginPool de Ribbon Finance, que utilizó estos precios de vencimiento falsificados en su proceso de liquidación y transfirió cientos de WETH y wstETH, miles de USDC, y varios WBTC a direcciones de robo a través de transacciones redeem y redeemTo", explicó Zhou.

La actualización del precio del oracle de Ribbon Finance tenía debilidades

Seis días antes del ataque, el equipo de Ribbon Finance actualizó el pricer del oracle para soportar 18 decimales para stETH, PAXG, LINK y AAVE. Sin embargo, otros activos, incluyendo USDC, seguían con ocho decimales, y según Zhou, la discrepancia en la precisión decimal contribuyó a la vulnerabilidad que fue explotada el viernes.

Según un desarrollador pseudónimo con el nombre de usuario Weilin en X, la creación de los oTokens en sí no era ilegal porque cada token subyacente debe estar en lista blanca antes de ser utilizado como garantía o activo de strike, un procedimiento que el atacante siguió al pie de la letra.

La actividad maliciosa comenzó con la creación de productos de opciones mal estructurados, donde un producto consistía en una opción de compra de stETH con un strike de 3,800 USDC, garantizada con WETH, con fecha de vencimiento el 12 de diciembre. El atacante luego creó varios oTokens para estas opciones, que posteriormente fueron explotados para drenar el protocolo.

El ataque involucró interacciones repetidas con el contrato de administración proxy en 0x9D7b…8ae6B76. Algunas funciones, como transferOwnership y setImplementation, se utilizaron para manipular los proxies de alimentación de precios a través de llamadas delegadas. El hacker invocó una implementación para que el oracle estableciera precios de vencimiento de activos en la misma marca de tiempo para causar eventos ExpiryPriceUpdated que confirmaron las valoraciones fraudulentas.

Los precios manipulados hicieron que el sistema reconociera stETH como muy por encima del precio de strike y quemó 225 oTokens, produciendo 22.468662541163160869 WETH. En total, el hacker extrajo aproximadamente 900 ETH a través de este método.

La firma de seguridad Web3 Spectre detectó las transferencias iniciales a una dirección de billetera en 0x354ad…9a355e, pero desde allí, el dinero fue distribuido a 14 cuentas más, muchas de las cuales tenían alrededor de 100.1 ETH cada una. Algunos de los fondos robados ya han entrado en lo que Zhou denominó como "TC" o pools de consolidación de tesorería.

Constructor de protocolo de préstamo DeFi: La dApp Opyn no fue comprometida 

Según el desarrollador de Monarch DeFi Anton Cheng, la aplicación descentralizada Opyn respaldada por Coinbase no fue comprometida como se rumoreaba en las conversaciones en Crypto Twitter.

Cheng explicó que el hack de Ribbon Finance fue facilitado por un código de oracle actualizado que inadvertidamente permitió a cualquier usuario establecer precios para activos recién añadidos. Señaló que el ataque comenzó con una transacción preparatoria para "preparar el escenario" generando oTokens mal estructurados con activos de garantía y strike legítimos. Continuó diciendo que los tokens falsos permitieron al hacker elegir subyacentes bien conocidos como AAVE para evitar llamar la atención y ser marcado. 

El hacker luego configuró tres "subcuentas", cada una depositando garantía mínima para acuñar las tres opciones. Todas las subcuentas fueron marcadas como tipo 0, lo que significa que estaban totalmente garantizadas, pero la ausencia de un límite máximo de pago para cada cuenta u oToken ayudó al perpetrador a drenar activos sin restricciones.

Bajo los sistemas Gamma de Opyn, el activo subyacente debe coincidir con la garantía para las opciones de compra y el strike para las opciones de venta para mantener a los vendedores totalmente garantizados. Si un oracle es comprometido, solo los vendedores de ese producto específico deberían sufrir.

Sin embargo, en este caso, la combinación de la creación de nuevos oTokens y el oracle manipulado fue suficiente para eludir estas protecciones.

No solo leas noticias cripto. Entiéndelas. Suscríbete a nuestro boletín. Es gratis.