El 21 de febrero de 2025, el mundo de las criptomonedas fue testigo de uno de los mayores robos cripto hasta la fecha. Unos hackers sustrajeron 1.500 millones de dólares de Bybit, uno de los principales exchanges de criptomonedas. Para lograrlo, recurrieron a la ingeniería social, lo que demuestra que la seguridad en su conjunto va mucho más allá de las contraseñas y los cortafuegos.
Las investigaciones de varias empresas de seguridad y un Anuncio de Servicio Público oficial del FBI apuntan a que este hackeo está vinculado al Grupo Lazarus, una organización cibercriminal norcoreana conocida por robar grandes sumas de dinero para financiar las actividades de su país (por ejemplo, el robo al Banco de Bangladesh). El FBI denomina esta operación norcoreana concreta "TraderTraitor."
Qué ocurrió
Bybit utiliza una cartera multifirma para proteger sus fondos. Una cartera multisig funciona como una caja fuerte que necesita varias llaves de distintos empleados para abrirse. Ninguna persona por sí sola puede mover el dinero y las monedas.
Sin embargo, los hackers no accedieron directamente a la caja fuerte. En su lugar, alteraron la interfaz de usuario (el front end) que los empleados utilizan para aprobar transacciones, engañando a los titulares de las llaves para que firmaran transacciones falsas sin darse cuenta.
Cómo ocurrió
1) Ataque al front end (lado del cliente)
Los atacantes inyectaron JavaScript malicioso en la interfaz web que los empleados de Bybit utilizan habitualmente para aprobar transacciones. Este código malicioso estaba oculto de tal forma que todo parecía normal en pantalla, pero en segundo plano modificaba detalles importantes.
La mayoría de las empresas se centran exclusivamente en la seguridad del backend o en las carteras hardware. Pero si el front end está comprometido, puede alterar silenciosamente las transacciones antes de que el usuario haga clic en "Aprobar". Por eso creamos cside: para que los sitios web puedan monitorizar las dependencias en el navegador de sus usuarios y evitar ataques como este.
Los hackers utilizaron correos de phishing y mensajes falsos para convencer a los empleados de que las transferencias eran rutinarias.
2) El truco de delegatecall + proxy
Aunque Bybit usaba una "caja fuerte" multisig, el JavaScript malicioso cambió el tipo de transacción de una "llamada" normal a algo denominado "delegatecall".
- Delegatecall permitió a los hackers ejecutar su propio código como si formara parte del contrato de la caja fuerte.
- Lo utilizaron para cambiar la dirección del "master copy" de la caja fuerte—un elemento clave del funcionamiento de este tipo de cartera—y apuntarla al contrato de los atacantes.
- Con ese cambio en vigor, los atacantes pudieron ejecutar funciones especiales de "barrido" que vaciaron la caja fuerte de 1.500 millones de dólares.
Análisis técnico detallado
Basado en el análisis de @S1r1u5_ en X.
A continuación se detallan paso a paso los aspectos técnicos de cómo fue comprometida la Safe{Wallet}:
- JavaScript malicioso inyectado
- Los atacantes añadieron código malicioso en app.safe.global/_next/static/chunks/pages/_app-4f0dcee809cce622.js. En esencia, uno de los desarrolladores comprometidos lo desplegó en producción.
- Objetivo: executeTransaction()
- El JS malicioso solo se activaba si reconocía una lista predefinida de firmantes (en este caso, los propietarios de la multisig de Bybit).
- Cambio a delegatecall
- En lugar de una llamada normal, el código malicioso cambió la operación a 1, que corresponde a delegatecall. Esto delegó la ejecución a un contrato del atacante.
- Modificación del almacenamiento de la Safe
- Mediante delegatecall, el contrato del hacker reescribió efectivamente el slot de almacenamiento masterCopy de la cartera Safe.
- El nuevo master copy vacía los fondos
- El nuevo contrato malicioso de "master copy" contenía las funciones sweepETH() y sweepERC20(), lo que permitió al atacante drenar 1.500 millones de dólares en criptomonedas.
Esta cadena de eventos permitió al atacante eludir todas las protecciones multifirma habituales, ya que en la interfaz de la cartera aparecía como una transacción válida.
En resumen:
- Los ataques al front end están subestimados. La gente suele centrarse en los servidores backend, pero un simple cambio en el código del sitio web puede engañar a los usuarios para que firmen cualquier cosa.
- Error humano. La ingeniería social se aprovecha de que las personas actúan con prisa o confían en el contenido de los correos electrónicos. Un mensaje falso cuidadosamente elaborado puede engañar incluso al personal mejor formado.
- Delegatecall + patrones proxy. Muchas carteras cripto y protocolos DeFi utilizan contratos "proxy" por su flexibilidad. Desafortunadamente, si un atacante redirige el puntero hacia su propio código, puede tomar el control total.
- Interfaces engañosas. La interfaz mostraba todo como "legítimo", por lo que los firmantes no tenían forma de saber que estaban aprobando transacciones maliciosas.
- Sistemas complejos. Incluso con múltiples capas de seguridad, un único fallo en la concienciación del usuario o en la integridad del front end puede hacer que todo se derrumbe.
Por qué los ataques al lado del cliente son difíciles de investigar
Cuando los hackers actúan a través de código del lado del cliente (el JavaScript y el HTML que se ejecutan en el navegador web), recopilar evidencias forenses después del ataque puede ser especialmente complicado:
- Datos efímeros:
- Las sesiones del navegador son de corta duración, y los registros de exactamente qué archivos JavaScript se cargaron —y cómo cambiaron— pueden estar incompletos o directamente no existir. A diferencia de los registros del lado del servidor, los registros del front end no suelen almacenarse de forma persistente.
- Despliegues y actualizaciones rápidas:
- Las aplicaciones web modernas actualizan o redesplegan código con frecuencia. Cuando un atacante inyecta scripts maliciosos, puede revertirlos con la misma rapidez, dejando solo una breve ventana de tiempo para capturar evidencias.
- Registros de servidor limitados:
- Aunque el lado del servidor sea seguro, la acción real ocurre en el navegador del usuario. Los registros estándar del servidor pueden mostrar que se sirvió un archivo, pero no necesariamente qué cambios se realizaron en ese archivo ni cómo se comportó una vez ejecutado.
- Falta de transparencia en el control de versiones:
- Algunos equipos no mantienen un registro público de cada build del front end. Si el cambio malicioso se introdujo a través de un pipeline de compilación comprometido, los equipos forenses necesitan historiales de versiones detallados, que pueden estar mal rastreados o ser fácilmente manipulables.
- Dependencia de terceros:
- El código del lado del cliente frecuentemente carga desde bibliotecas externas o CDNs. Si el script malicioso se inyectó a través de un servicio de terceros, los equipos forenses deben coordinarse con proveedores externos que pueden no conservar registros detallados o ser lentos a la hora de cooperar.
Para los investigadores forenses, todo esto significa que reconstruir un ataque al lado del cliente puede implicar ensamblar fragmentos de cachés del navegador, registros de la consola de desarrollador, historiales de despliegue y los datos de versionado disponibles en el pipeline de compilación. Es posible hacerlo, pero resulta significativamente más difícil que investigar un compromiso tradicional del lado del servidor, donde normalmente se dispone de registros más claros y acceso directo al sistema comprometido.
Cómo cside podría haber ayudado
cside es una solución que analiza los scripts del lado del cliente de primera parte y actúa como proxy del JavaScript de terceros antes de que se ejecute en tu sitio. Además, almacenamos los scripts hasta un año, ofreciendo capacidad forense completa donde hoy existe un punto ciego. Si Bybit hubiera utilizado cside, cualquier modificación inesperada o maliciosa en la interfaz de la cartera Safe podría haber sido detectada y bloqueada, lo que potencialmente habría impedido todo este ataque.
Referencias: https://x.com/lookonchain/status/1892965762186522975 https://x.com/lookonchain/status/1892971811807387877 https://x.com/lookonchain/status/1893223657838633177
