El 21 de junio, uno de los bots MEV más activos en la red de Ethereum, Jaredfromsubway.eth, sufrió un ataque de "jaula de miel" (honeypot attack) cuidadosamente diseñado, perdiendo más de 7,5 millones de dólares en activos criptográficos. A continuación, el equipo de seguridad de Beosin presenta el análisis del ataque y el rastreo del flujo de los fondos robados.
Análisis del proceso de ataque
Ataque a la familia de contratos
- Contrato coordinador (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52): responsable de registrar si el bloque actual está en estado armed y llamar cíclicamente a los contratos secundarios en la fase final para extraer fondos. - Contrato disparador (0x4de8c729a064ff6087cc84a4152969349e4feb98): responsable de establecer el estado falso del par de intercambio dentro del mismo bloque, haciendo que la ruta de arbitraje parezca ejecutable. - Contratos secundarios / contratos de tokens falsos: se disfrazan como tokens ERC-20 normales para obtener autorizaciones reales. - Contrato Hub: responsable de pagar pequeños rendimientos reales para hacer que los bots MEV consideren la operación rentable. - Par Ring V2: par de intercambio falsificado de Uniswap v2. - Contratos de tokens intermedios falsos: utilizados para construir rutas de arbitraje de múltiples saltos, como fCAP, fUSDC.
El punto clave del ataque: engañar para obtener autorización
Al analizar las transacciones en la cadena, el atacante creó múltiples conjuntos de transacciones engañosas:
- Gran USDC: el robot generó aproximadamente 36.997120 USDC, pero dejó 20 USDC autorizados. - Gran USDT: el robot generó aproximadamente 37.053440 USDT, pero dejó 20 USDT autorizados. - Gran WETH: el robot generó aproximadamente 0.0179 WETH, pero dejó 16 WETH autorizados. - Las operaciones pequeñas funcionaron normalmente, con las autorizaciones consumidas dentro de la misma transacción para reducir sospechas.
En operaciones de pequeño tamaño, después de que el robot autorice el monto de tokens reales, el contrato secundario transfiere inmediatamente los tokens reales, agotando la autorización y pareciendo completamente normal.
En las transacciones de gran volumen, el contrato secundario no llama a transferFrom para transferir los tokens reales, sino que directamente acuña tokens falsos mediante transacciones falsificadas. El robot cree que ha completado los pasos previos normales del intercambio, pero la autorización de los tokens reales sigue siendo mantenida.
Este es el núcleo del ataque: las transacciones pequeñas consumen normalmente la autorización, mientras que las transacciones grandes la conservan.
Proceso de ataque
Como ejemplo de una operación de ataque contra USDC:
(1) El atacante llama al coordinador para establecer el bloque actual como armed. (2) El atacante llama al disparador para actualizar el estado de múltiples pares falsificados Ring V2. (3) El MEV Bot detecta una oportunidad de arbitraje y ejecuta la transacción.
El flujo interno aproximado del bot MEV es el siguiente:
(1) El contrato MEV Bot autorizó un monto elevado de USDC a un contrato secundario. (2) El contrato MEV Bot llamó a la función wrapTo/wrap del contrato secundario. (3) Debido a que el estado actual del contrato secundario está en modo armed, no consume USDC real, sino que acuña tokens falsos para el par, manteniendo la autorización de USDC. (4) El contrato MEV Bot continúa llamando al swap del par falsificado. (5) El segundo par de intercambio envía los tokens al MEV Bot. (6) El contrato hub paga al MEV Bot una pequeña ganancia en USDC real.
ejemplo de aprobación
hash de la transacción: 0x0121e07a916c06eea3e7daf11893f3f0b95b9e1684124545ae14c32aee6029bb
Resultado visto por el MEV Bot: una operación de arbitraje exitosa que generó ganancias reales en USDC. Sin embargo, la autorización de USDC fue retenida por el subcontrato. Este proceso se repite por separado para USDC, USDT y WETH, generando finalmente una gran cantidad de autorizaciones.
La hash de la transacción atacada es:
0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65
El atacante llama al bucle de drenaje del contrato coordinador, donde los datos de llamada contienen 66 direcciones de contratos secundarios y la dirección del contrato MEV Bot. Si el contrato MEV Bot previamente otorgó autorización de límite a los contratos secundarios, estos pueden transferir directamente los tokens reales correspondientes al atacante.
Resultado final:
- Se agotaron los 20 permisos de gran tamaño de USDC - Se agotaron los 16 permisos de gran tamaño de WETH - Aún existe un permiso parcial de USDT, pero el saldo de USDT es insuficiente
Análisis de flujo de fondos
Tras el éxito del ataque, la dirección del atacante (0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0) recibió $2.87M USDC, $2.04M USDT y 1,474 WETH. Posteriormente, el atacante intercambió las stablecoins por ETH y las transfirió a las siguientes 4 direcciones:
- 0xe3Da36E4bd1a5738fa5D6Ef4F0e4dF40bDeB5f17 (aprox. 1.000 ETH) - 0x74Dc5b93586D248D5Aec64b3586736FF0A0D0e65 (1.001 ETH) - 0xd8C125efCBc99408eC8723E9BBd81d1E8D39D845 (1.001 ETH) - 0x71d4416A7A85e08a5Fe7227Ca3B44Fc639e94e97 (1.423 ETH)
其中 0xe3Da3 ha transferido 1,000 ETH a Tornado Cash, y no se han realizado transferencias adicionales de ETH desde los otros tres direcciones. El flujo de fondos se muestra a continuación:
Conclusión
Este ataque demuestra un método altamente sofisticado: el atacante no ataca directamente el código del contrato, sino que, basándose en la lógica de negocio del MEV Bot, crea escenarios de arbitraje específicos para inducir al MEV Bot a otorgar autorizaciones que parecen legítimas, finalmente transfiriendo sus activos. Para los bots de arbitraje y los MEV Bot, no basta con depender únicamente de la estimación de ganancias simuladas para evaluar la seguridad de una ruta; especialmente cuando la ruta de arbitraje incluye contratos desconocidos, tokens falsificados o wrappers personalizados, se debe actuar con cautela y considerar la posibilidad de realizar una verificación obligatoria de los cambios en los allowances tras la transacción.