Transit Swap - REKT
Trabajando el fin de semana como siempre...
Las notificaciones del domingo por la mañana de un protocolo cross-chain perdiendo millones.
Como en los viejos tiempos.
Transit Swap ha perdido $21M por una vulnerabilidad que permitió a un unknown attacker vaciar las wallets de los usuarios que habían aprobado los swap contracts del protocolo.
Pero, por desgracia para el hacker, se perdieron más de $1M en el tránsito... no todos los MEV bots han caído 0xbad esta semana.
El team detuvo los contratos afectados antes de anunciar el incidente en Twitter.
Luego vino una update que a través de " los esfuerzos conjuntos de @SlowMist_Team , @Bitrace_Team, el equipo de seguridad de @peckshield " , se había descubierto información clave sobre el hacker, incluida su "IP, dirección de correo electrónico y direcciones asociadas on-chain".
A medida que el anonimato del attacker comenzó a desvanecerse, parece que lo tuvieron que pensar mejor. Hasta el momento, se ha devuelto más del 70% de los fondos.
Encontrar una vulnerabilidad en un unverified contract; un diligent decompiler, o alguno que actúa con información privilegiada?
Aunque la vulnerabilidad estaba en el código del proyecto, este ataque se dirigía directamente a los usuarios a través de una vulnerabilidad en el uso de la función transferFrom(). Todos los tokens approved para trading en Transit Swap podían ser transferidos directamente desde las wallets de los usuarios a la dirección del exploiter desconocido.
La primera tx de ataque se produjo justo después de las 18:30 UTC, y el ataque duró aproximadamente media hora antes de cambiar los tokens robados a ETH y BNB.
Dirección del exploiter en ETH y BSC: 0x75f2aba6a44580d7be2c4e42885d4a1917bffd46
Contrato vulnerado (revoke approvals tanto en ETH como en BSC): 0xed1afc8c4604958c2f38a3408fa63b32e737c428
Crédito: Supremacy Inc. , SlowMist
Los smart contracts del proyecto no están verificados. Sin embargo, pueden ser decompiled a partir del bytecode publicado:
Después de entender la ruta de ataque del hacker, intentamos averiguar la causa de la vulnerabilidad, pero los smart contracts del proyecto son contratos de closed-source. Así que lo descompilamos y finalmente encontramos la causa raíz de este ataque: una transferencia controlable desde external call.
Como se trata de código descompilado, es un poco oscuro para que los lectores lo entiendan. Podemos entender que varg0 es la dirección del token, varg1, varg2 y varg3 son los parámetros from, to y amount de la función transferFrom.
0x23b872dd en la figura es la signature de la función transferFrom() de la función. Por lo tanto, la función claimTokens llama a la función transferFrom de una dirección, y la dirección y los parámetros de la función son controlables.
Para una explicación más detallada, vea el análisis de SlowMist.
Peckshield también proporcionó un resumen visual de las actividades del attacker.
Los fondos devueltos se consolidaron en la misma dirección (0xD989f7B4320c6e69ceA3d914444c19AB67D3a35E) en ETH y BSC , que tiene un total de ~$16,5M en las dos chains.
Fondos robados:
3180 ETH ($4.2M), devuelto .
1500 ETH vinculado a Binance ($2M), devuelto .
50k BNB ($14M), $10.4M devueltos .
En el momento de escribir este artículo, la dirección del BSC del exploiter todavía tiene más de $3,5M en BNB robados y anteriormente envió 2500 BNB ($715k) a Tornado Cash.
La rápida respuesta y la cooperación entre múltiples equipos de seguridad hicieron que este incidente tuviera un final más feliz que la mayoría.
Pero un protocolo que utiliza contratos vivos y no verificados nunca tiene buena pinta en DeFi, donde el open-source es el la base del juego.
Ocultar el código del contrato hace que DYOR sea casi imposible e impide el trabajo de los whitehats para detectar vulnerabilidades antes de que sean explotadas.
El closed source también genera sospechas en el mundo del blockchain, donde los exploits, rug-pulls y las "compromised keys" suelen olvidarse en cuestión de semanas.
¿Podría ser este el caso de una persona que usa información privilegiada contra sus usuarios, antes de devolver la mayor parte de los fondos y esperar que todo desaparezca?
Lo de siempre.
REKT sirve como plataforma pública para autores anónimos, nos deslindamos de la responsabilidad por las opiniones y contenidos alojados en REKT.
dona (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C
aviso legal:
REKT no es responsable ni culpable de ninguna manera por cualquier Contenido publicado en nuestro Sitio Web o en conexión con nuestros Servicios, sin importar si fueron publicados o causados por Autores ANÓN de nuestro Sitio Web, o por REKT. Aunque determinamos reglas para la conducta y publicaciones de los Autores ANÓN, no controlamos y no somos responsables por cualquier contenido ofensivo, inapropiado, obsceno, ilegal o de cualquier forma objetable, que se pudiera encontrar en nuestro Sitio Web o Servicios. REKT no es responsable por la conducta, en línea o fuera de línea, de cualquier usuario de nuestro Sitio Web o Servicios.
te podría gustar...
Tapioca DAO - Rekt
Otro día, otro robo de clave privada, otro protocolo rekt. Tapioca DAO en Arbitrum sufre una pérdida de aproximadamente $4.4 millones debido al compromiso de una clave privada. Se han recuperado algunos fondos, aunque el alcance total del daño aún está por verse.
Radiant Capital - Rekt II
Radiant Capital sufre un recorte de $53 millones. ¿Pensabas que los multi-sigs eran seguros? Piénsalo otra vez. La "robusta" configuración 3/11 de Radiant se desplomó como un castillo de naipes. Exploited dos veces en 2024, el futuro de Radiant parece tan brillante como un agujero negro.
Sobreviviendo al Peligro Digital
¿Crees que has dominado el campo minado cripto? Piensa de nuevo. Sobreviviendo al Peligro Digital - La guía rekt para convertir la paranoia en una forma de arte. Es hora de mejorar tus habilidades de supervivencia en cripto.