Wallet Safe de Ethereum pierde $7.73 millones en rsETH por un módulo malicioso y un hook de Uniswap v4
Puntos clave
- •Una wallet Safe de Ethereum perdió aproximadamente $7.73 millones en rsETH en dos transacciones identificadas por el monitoreo de seguridad el 15 de septiembre.
- •El atacante utilizó un multicall público de keeper para invocar un módulo de liquidez personalizado de Uniswap v4 en la Safe y dirigir los activos a un pool construido con un hook controlado por el atacante.
- •El hook malicioso convirtió la garantía aEthrsETH de la wallet, que representa rsETH depositado en Aave, en rsETH transferible antes de la extracción de los fondos.
- •Una operación de MEV etiquetada como MEV Frontrunner Yoink adelantó la transacción del ataque y capturó gran parte del valor extraído, dejando a la Safe únicamente con un NFT de posición de liquidez.
- •Los contratos centrales de multisig de Safe, las claves de los firmantes, Aave, Kelp DAO y el contrato del token rsETH no fueron comprometidos. El incidente es independiente del exploit de Kelp DAO de aproximadamente $292 millones ocurrido en abril y del ataque de SquidRouterModule de mayo, que drenó 86 cuentas Safe.

Un usuario de Ethereum perdió aproximadamente $7.73 millones en rsETH después de que un atacante explotara una ruta de ejecución de módulos de Safe para redirigir activos a través de un pool de liquidez de Uniswap v4 controlado por el atacante.
La dirección Safe afectada (0x40e93a52f6af9fcd3b476aedadd7feabd9f7aba8) fue atacada a primeras horas del 15 de septiembre. El monitoreo de seguridad identificó dos transacciones responsables de la pérdida. La evidencia disponible apunta al módulo personalizado de la wallet y su interacción con un hook malicioso, en lugar de una vulnerabilidad en los contratos centrales de smart accounts de Safe.
El módulo personalizado dirigió los activos a un pool malicioso
El ataque utilizó un multicall público de keeper para invocar un módulo Uni V4 LP Safe personalizado conectado a la cuenta. La ejecución dirigió la liquidez a un pool de Uniswap v4 creado con un hook controlado por el atacante, lo que permitió que la lógica maliciosa de enrutamiento accediera a los activos involucrados en la posición.
Luego, el hook convirtió la posición aEthrsETH de la víctima en rsETH transferible. aEthrsETH representa rsETH depositado en Aave, por lo que el atacante primero tuvo que sacar la posición de su forma de receipt token de Aave antes de extraer el rsETH subyacente.
La arquitectura de módulos de Safe permite que extensiones autorizadas ejecuten transacciones de forma independiente del flujo normal de múltiples firmas. Los módulos pueden automatizar operaciones DeFi complejas, pero Safe advierte que son críticos para la seguridad porque un módulo malicioso o vulnerable habilitado puede ejecutar transacciones arbitrarias desde una cuenta. La documentación de Safe sobre módulos está disponible aquí.
Debido a que el multicall público de keeper podía invocar el módulo personalizado de la cuenta, el límite de seguridad relevante se extendía más allá del flujo de los firmantes de Safe hacia la autorización y la lógica de transacciones del módulo. En cuentas similares habilitadas para DeFi, revisar únicamente el contrato de Safe no describiría por completo la superficie de ejecución activa de la cuenta.
El ataque no comprometió los contratos centrales de multisig de Safe, las claves de los firmantes ni Ethereum. La ruta de falla identificada involucró el módulo personalizado de la cuenta y un hook de Uniswap v4 controlado por el atacante. Una separación similar surgió en mayo, cuando un exploit de SquidRouterModule drenó 86 cuentas Safe en Ethereum y Base, mientras los contratos subyacentes de Safe quedaron fuera de la ruta de falla identificada.
Un bot de MEV capturó la extracción
La transacción del ataque fue interceptada dentro del bloque por una operación de MEV asociada con la dirección que Etherscan etiqueta como MEV Frontrunner Yoink.
El bot adelantó la extracción original y capturó la ruta de transacción rentable antes de que el atacante pudiera completarla tal como la había enviado. La víctima aún perdió el rsETH porque la ejecución maliciosa subyacente tuvo éxito, mientras que el orden de las transacciones cambió qué dirección externa capturó finalmente gran parte del valor extraído.
La Safe quedó únicamente con un NFT de posición de liquidez del pool malicioso, en lugar de la posición respaldada por rsETH que tenía antes de las transacciones.
El rsETH vuelve a estar bajo el foco de seguridad
rsETH es el token de restaking líquido de Kelp DAO y continúa integrado en los mercados de préstamos y liquidez de Ethereum. Su uso dentro de Aave creó la garantía aEthrsETH involucrada en el drenaje de la wallet.
El token de Kelp también sufrió una importante interrupción de seguridad a principios de este año. Un exploit de Kelp DAO ocurrido en abril liberó aproximadamente $292 millones en rsETH desde la infraestructura cross-chain y creó una exposición significativa posterior en los mercados de préstamos DeFi.
La pérdida del 15 de septiembre es un evento separado. La evidencia actual se concentra en la ejecución del módulo de la Safe individual, el hook de Uniswap v4 controlado por el atacante y la conversión resultante de la posición de rsETH de la wallet respaldada por Aave. No se ha establecido un compromiso más amplio de Safe, Aave, Kelp DAO ni del contrato del token rsETH.
Fuente: Crypto Adventure.