Resumen: cronología de la inyección en la interfaz de Safe Wallet en Bybit
- La interfaz de firma falló: El multisig no falló en Bybit. Falló la interfaz de firma. Los atacantes reescribieron lo que veía el firmante en el navegador, de modo que cinco aprobadores dieron el visto bueno a un delegatecall que apuntaba al código del atacante.
- Un año de historial de scripts: El script malicioso solo se activaba para una lista predefinida de firmantes y movió 1.500 millones de dólares después de que el delegatecall sustituyera el master copy. cside guarda cada script de terceros hasta un año para que puedas ver la build exacta inyectada a posteriori.
- Monitoriza el JavaScript de tesorería: Si tu interfaz de tesorería carga cualquier JavaScript de terceros, monitorízalo en tiempo de ejecución hoy mismo. Si no lo hace, asume igualmente que el proveedor que suministra la interfaz de la cartera sí lo hace, porque Safe lo hacía.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
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, un exchange de criptomonedas importante. 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 empresas de seguridad y un Anuncio de Servicio Público oficial del FBI afirman 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 es 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 donde los empleados de Bybit aprueban habitualmente las 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 siquiera 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 del delegatecall + proxy
Aunque Bybit usaba una "caja fuerte" multisig, el JavaScript malicioso cambió el tipo de transacción de una "call" 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, una parte 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 "sweep" que vaciaron la caja fuerte de 1.500 millones de dólares.
Análisis técnico detallado
Basándose en el análisis de @S1r1u5_ en X, aquí tienes un desglose paso a paso de cómo se comprometió la Safe{Wallet}:
- JavaScript malicioso inyectado: los atacantes añadieron código malicioso en app.safe.global/_next/static/chunks/pages/_app-4f0dcee809cce622.js después de que uno de los desarrolladores comprometidos lo desplegara en producción.
- executeTransaction() como objetivo: 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 call normal, el código malicioso cambió la operación a 1, que corresponde a delegatecall, delegando la ejecución a un contrato del atacante.
- Modificación del almacenamiento de la Safe: mediante el uso de delegatecall, el contrato del hacker reescribió 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.
Por qué los ataques del 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 tu 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 a menudo no se almacenan de forma persistente.
- Despliegues y actualizaciones rápidas: las aplicaciones web modernas actualizan o redespliegan 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, y estos 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 tienen que 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 del 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 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 tienes un punto ciego. Si Bybit hubiera utilizado cside, cualquier modificación inesperada o maliciosa en la interfaz de la cartera Safe podría haberse detectado y bloqueado, 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
