Autor: imToken
Un bot MEV que durante mucho tiempo ha cazado a comerciantes ordinarios en Ethereum, finalmente cayó en una trampa "hecha a medida" valorada en 7.5 millones de dólares.
El 21 de junio, el conocido bot de arbitraje de sándwich en Ethereum, Jaredfromsubway.eth, fue atacado. Los activos en la dirección, como WETH y USDC, fueron transferidos. Las pérdidas iniciales superan los 7.5 millones de dólares (aunque las cifras de pérdidas reportadas públicamente aún difieren).
Lo interesante es que este ataque no fue una filtración de clave privada ni aprovechó vulnerabilidades tradicionales de contratos inteligentes. En cambio,el atacante desplegó previamente una gran cantidad de tokens falsos, pools de liquidez y contratos auxiliares, empaquetándolos como rutas de transacción que potencialmente podrían tener espacio de arbitraje, induciendo al bot a otorgar Aprobación (Approval) ERC-20 a un contrato malicioso durante su ejecución automatizada, y finalmente transfirió "legalmente" los activos del bot MEV.
Al momento de escribir este artículo, Jaredfromsubway.eth ya ha enviado un mensaje público en la cadena al atacante, declarando: "Si devuelve 2150 ETH dentro de 48 horas, está dispuesto a pagar una recompensa del cincuenta por ciento por sombrero blanco; de lo contrario, tomará todas las medidas legales y de ejecución factibles para responsabilizarlo".
Sin embargo, que incluso un bot MEV altamente especializado impulsado por código pueda tropezar con una Aprobación, también nos lleva a reconsiderar cuán peligrosa es realmente esta acción de "Aprobación" que usamos a diario.
1. Una cacería inversa diseñada específicamente para bots MEV
Si se analiza detenidamente este incidente de ataque, se verá que no fue una vulnerabilidad activada accidentalmente, sino una cacería prolongada diseñada específicamente contra la lógica de operación de Jaredfromsubway.eth.
Jaredfromsubway.eth siempre ha sido uno de los bots de arbitraje de sándwich más conocidos en Ethereum. En términos simples, el ataque de sándwich ocurre cuando el bot detecta una transacción en cadena que está a punto de ocurrir, compra antes que el usuario para impulsar el precio al alza; luego, después de que el usuario completa la transacción a un peor precio, vende inmediatamente para obtener una diferencia de precio.
Por esta misma razón, esta estrategia requiere que el bot escanee continuamente las transacciones en cadena, juzgue oportunidades de arbitraje a una velocidad extremadamente rápida y organice rutas de transacción para llamar a diferentes tokens y contratos. Esto también significa que cuanto más rápido sea y cuantos más activos y protocolos cubra, más oportunidades podrá capturar el bot.
Pero precisamente este punto se convirtió en la brecha de este incidente.
Según el análisis posterior al hecho, el atacante no atacó directamente el contrato de fondos del bot, sino que pasó varias semanas construyendo un entorno de transacción que parecía ser rentable:
- Primer paso, desplegar una gran cantidad de tokens falsos y pools de liquidez. Estos tokens imitan en nombre, interfaz y comportamiento de transacción activos comunes como WETH, USDC, USDT, engañando al sistema de identificación automática del bot para que crea haber descubierto rutas de transacción normales;
- Segundo paso, ganarse gradualmente la confianza del bot. En las pruebas iniciales, las autorizaciones otorgadas por el bot se usaban normalmente con las transacciones. Una vez que el sistema del bot comenzó a ejecutar rutas similares repetidamente, el atacante ajustó la lógica del contrato, haciendo que algunas autorizaciones generadas por el bot ya no se consumieran en realidad ni volvieran a cero después de la transacción, dejando que estas autorizaciones permanecieran allí;
- Finalmente, el atacante invocó centralizadamente los límites de autorización aún vigentes, transfiriendo los WETH, USDC y USDT reales del contrato del bot;
En pocas palabras, todo el ataque se dirigió completamente a las características operativas del bot MEV: primero crear un entorno que se ajustara a sus reglas de juicio de rentabilidad, y luego aprovechar su mecanismo de ejecución automática de rutas de transacción para que el sistema entregue activamente el derecho a invocar activos.
Esto también explica por qué incluso un bot MEV altamente especializado pudo ser víctima.
Sabe calcular diferencias de precio, costos de Gas y el orden de las transacciones, pero no necesariamente realiza una verificación de identidad completa para cada nuevo contrato que aparece. Desde este ángulo,el problema del usuario común es "confirmar sin entender", mientras que el problema del bot automatizado es "ejecutar automáticamente sin confirmar".
Superficialmente, los dos son completamente diferentes, pero el riesgo subyacente es muy similar, porque ambos tratan la autorización como un paso ordinario antes de completar una transacción, sin darse cuenta claramente de cuán alto es el riesgo latente.
2. ¿Por qué la Aprobación siempre está subestimada?
Como es sabido, en el estándar ERC-20 de Ethereum y cadenas compatibles con EVM, Approve (Aprobación) es un diseño bastante básico.
Sin embargo, cuando los usuarios realizan transferencias directas desde su billetera, generalmente invocan 'transfer', que generalmente no involucra Approve. Solo en escenarios de contratos inteligentes como DEX, préstamos, staking o adición de liquidez, cuando un usuario necesita permitir que un contrato inteligente invoque tokens en su nombre, se involucra la Aprobación.
Por ejemplo, cuando queremos cambiar USDT por ETH en Uniswap, el contrato inteligente de Uniswap no puede tomar directamente el USDT de su billetera. Primero debe ejecutar una Approve para informar al sistema "Permito que Uniswap retire X cantidad de mi USDT de mi billetera".
Solo después de completar la autorización, el contrato con el permiso puede, a través de transferFrom, invocar el USDT del usuario dentro del límite, y los Swaps posteriores también pueden completarse.
En otras palabras, la Aprobación en sí misma no es una vulnerabilidad, sino una base importante para el funcionamiento normal de DeFi. El problema es que se parece un poco a los permisos de débito automático de Alipay/WeChat Pay:
El usuario no entrega la contraseña de su cuenta al comerciante, sino que permite que el comerciante realice débitos automáticos dentro del rango acordado. Siempre que la autorización siga vigente, los débitos posteriores no requerirán que el usuario ingrese nuevamente la contraseña o confirme cada transacción, lo que naturalmente trae algunos problemas.
Primero está el problema de la autorización infinita; la gente a menudo convierte una transacción en un permiso a largo plazo. Principalmente para reducir los costos operativos y de Gas generados por autorizaciones repetidas, muchas DApps solicitan por defecto un límite de autorización muy grande, comúnmente conocido como "autorización infinita".
El usuario originalmente solo quería usar 100 USDC para una transacción, pero permitió que el contrato utilizara todos los USDC en su dirección en el futuro. Mientras esta autorización no sea revocada, incluso si el usuario solo tenía una pequeña cantidad de activos en su billetera en ese momento, los USDC que vuelva a transferir en el futuro también podrían verse afectados.
En segundo lugar, la autorización por defecto no desaparece al abandonar la DApp. Muchos usuarios confunden "desconectar la billetera" con "revocar la autorización". En realidad, desconectar solo hace que la página web no pueda leer o solicitar temporalmente la billetera actual, pero no cambia la Aprobación ya escrita en la blockchain.
Cerrar la página web, eliminar la DApp, borrar el caché del navegador, o incluso cambiar la aplicación de billetera, no la invalidará automáticamente.
Finalmente, incluso los contratos normales pueden volverse peligrosos en el futuro. Esto se debe a que muchos riesgos de autorización no solo provienen de sitios de phishing que eran maliciosos desde el principio. Como en esta cacería, un usuario puede otorgar permiso a un protocolo que era normal en ese momento, pero posteriormente el contrato del protocolo es atacado, se filtra la clave del administrador, se reemplaza la lógica actualizable, o surgen problemas con su contrato de ruta invocado.
Para el usuario, los activos permanecen en su dirección, pero desde la perspectiva de los permisos, otro contrato siempre ha tenido la capacidad de invocar estos activos. Por lo tanto, el riesgo de Aprobación no es solo "si le otorgué autorización a un mal actor", sino también "si el objeto al que autoricé tendrá problemas en el futuro".
3. Entonces, ¿cómo gestionar el riesgo de Aprobación?
Frente al riesgo de Aprobación, el consejo más simple es "no otorgar autorización infinita".
Pero en el entorno real de uso de DeFi, rechazar completamente la autorización no es realista. Como se mencionó anteriormente, la autorización en sí misma no es una vulnerabilidad, es la forma básica en que las aplicaciones en cadena invocan activos.
Lo que realmente necesita cambiar es transformar la Aprobación de una acción de confirmación única en un mecanismo continuo de gestión de permisos.
Para el usuario común, primero necesita desarrollar algunos hábitos básicos:
- Primero, seguir el principio de "privilegios mínimos". Cuando la billetera muestre la solicitud de autorización, intente establecer el límite según las necesidades reales de esta interacción. Por ejemplo, si solo planea usar 100 USDT, otorgue un límite de autorización cercano a 100 USDT, en lugar de abrir directamente un permiso infinito;
- Segundo, distinguir entre la billetera de almacenamiento y la de interacción. Las direcciones que almacenan grandes cantidades de activos a largo plazo no deben conectarse frecuentemente a DApps desconocidas; al participar en interacciones de DeFi de alto riesgo como airdrops, mint, nuevos proyectos, se puede usar una dirección separada para limitar las pérdidas potenciales a un rango más pequeño;
- Tercero, revisar regularmente y revocar las autorizaciones que ya no son necesarias. Los usuarios pueden usar herramientas como Revoke.cash, o en imToken, ingresar a la página del token correspondiente, hacer clic en "Función del Token" en la esquina inferior izquierda, luego seleccionar "Gestión de autorizaciones", ver los objetos de autorización, tokens y límites de esa dirección, e iniciar la revocación para permisos que ya no se usen o sean de origen desconocido (lectura extendida "Guía paso a paso para usar Revoke.cash para gestión de autorizaciones");
Por supuesto, dicho todo esto, frente a los ataques de autorización que son difíciles de prevenir, depender únicamente de la conciencia de seguridad del usuario y las revisiones periódicas no es suficiente. Después de todo, a la mayoría de los usuarios les resulta difícil distinguir a quién pertenece una dirección de contrato, y también es difícil juzgar si un límite de autorización es razonable.
Como la primera línea de defensa para que los usuarios entren en Web3, las billeteras deben proporcionar defensas activas en su capacidad de producto.
Por ejemplo, imToken marca o bloquea tokens, direcciones y DApps de riesgo identificados,cuando un usuario otorga permisos de token a una cuenta externa común o transfiere directamente a una dirección de contrato, también se proporcionan advertencias de riesgo específicas, estas advertencias no pueden reemplazar el juicio del usuario, pero al menos pueden agregar un amortiguador de seguridad necesario antes de firmar realmente.
Además, en imToken, en enlaces clave como inicio de sesión en DApp, transferencias, intercambio de tokens y autorizaciones, el contenido de la firma se analiza estructuralmente y se presenta de manera legible, ayudando tanto como sea posible a los usuarios a entender qué están consintiendo antes de confirmar,asegurando que el contenido firmado por el usuario debe ser consistente con el comportamiento que ve, en lugar de comprimirse en un fragmento de datos hash difícil de identificar.
A medida que los estándares como ERC-7730 Clear Signing avancen, esta presentación legible "Lo que ves es lo que firmas (What You See Is What You Sign)" también tiene el potencial de pasar de ser una capacidad de producto individual de una billetera a convertirse gradualmente en un estándar de la industria compartido entre billeteras, DApps y contratos inteligentes.
En general, la clave privada determina quién posee la cuenta, la Aprobación determina quién más puede invocar los activos en la cuenta, no son lo mismo, pero son igualmente importantes.
Esto también significa quela seguridad de la billetera no puede detenerse en "si la clave privada se filtró", y esto requiere un esfuerzo conjunto desde los usuarios hasta las billeteras: Para los usuarios, necesitan ver claramente el objeto y el límite antes de autorizar, y limpiar los permisos que ya no son necesarios después de la interacción; para las billeteras, necesitan hacer que estos permisos originalmente ocultos en los contratos sean más visibles, más fáciles de entender y también más convenientes de limitar y revocar.
Después de todo, lo realmente peligroso puede no ser la transferencia que acaba de ocurrir, sino una autorización que ha sido olvidada durante mucho tiempo pero nunca ha expirado.
