El 21 de febrero de 2025, Bybit perdió aproximadamente $1.5 mil millones después de que un atacante comprometiera la máquina de un desarrollador de Safe{Wallet} mediante ingeniería social. El atacante inyectó JavaScript malicioso en el bucket AWS S3 de Safe{Wallet}, apuntando específicamente a las transacciones de Bybit. El código inyectado alteró el contenido de las transacciones durante el proceso de firma: la interfaz de Safe{Wallet} mostraba una transacción legítima, mientras que el payload real enviado a los dispositivos Ledger de los firmantes actualizaba el contrato Safe de Bybit a una implementación maliciosa, otorgándole al atacante control total. Una vez firmado y ejecutado, el atacante drenó todos los activos del contrato. Un análisis técnico detallado está disponible en nuestro informe anterior [1].
Antecedentes
Safe{Wallet} (también conocido como GnosisSafe) es una infraestructura de billetera multifirma que utiliza un modelo n-de-m: ejecutar una transacción requiere al menos n firmas de m firmantes en total.
Cada billetera Safe se despliega como un contrato proxy. Dos variables de almacenamiento son fundamentales en este incidente:
masterCopy(slot 0): la dirección del contrato de implementación. Este contrato contiene toda la lógica de ejecución, incluyendo la verificación de firmas y los mecanismos de actualización. El proxy delega todas las llamadas amasterCopymediantedelegatecall.threshold(slot 4): el número mínimo de firmas (n) requeridas. Para el Safe de Bybit, este valor era 3.
Debido a que el proxy usa delegatecall, cualquier función llamada en masterCopy se ejecuta en el contexto de almacenamiento del proxy. Esto significa que un objetivo de delegatecall puede sobrescribir directamente masterCopy en el slot 0, reemplazando toda la implementación en una sola transacción.
Análisis de Vulnerabilidades
La ruta de ataque atravesó tres capas del sistema, cada una de las cuales presentaba una condición estructural que el atacante aprovechó:
Modelo de servicio del frontend. El JavaScript del frontend de Safe{Wallet} se servía desde un bucket AWS S3. En esta arquitectura, cualquier persona con acceso de escritura al bucket puede modificar el código que construye las transacciones para los firmantes. Los mecanismos de verificación de integridad, como los hashes de integridad de subrecursos (SRI) o la firma de código, pueden mitigar este riesgo, pero aún no son una práctica estándar en la mayoría de los frontends de dApps. El atacante obtuvo acceso de escritura a través de la máquina del desarrollador comprometida y modificó silenciosamente el JavaScript servido.
Brecha entre la visualización en la interfaz y el payload de firma. El JavaScript inyectado mostraba una transacción de apariencia legítima en la interfaz de Safe{Wallet} mientras enviaba un payload diferente a las billeteras hardware Ledger. Los detalles de la transacción mostrados en la pantalla del Ledger habrían diferido de los de la interfaz, pero interpretar datos de transacciones en bruto en la pantalla de una billetera hardware no es sencillo, especialmente para operaciones multifirma complejas. Esta brecha permitió al atacante recopilar tres firmas válidas para el payload malicioso.
Modelo de actualización del proxy. Como se describe en los Antecedentes, delegatecall ejecuta el código del objetivo en el contexto de almacenamiento del proxy. La arquitectura del proxy Safe enruta todas las llamadas a través de un único puntero masterCopy en el slot 0. Sobrescribir este puntero redirige el proxy a una implementación completamente diferente, incluida su lógica de verificación de firmas, en una sola transacción. El modelo n-de-m rige quién puede iniciar una transacción, pero una vez que una transacción es aprobada y ejecutada, puede alterar la implementación en sí misma. Si la nueva implementación elimina la verificación de firmas, la protección multifirma desaparece efectivamente para todas las transacciones posteriores.
Análisis del Ataque
El ataque se desarrolló en tres pasos: Inyección de Código Malicioso, Reemplazo de Implementación y Robo de Activos.
Paso 1: Inyección de Código Malicioso
El atacante comprometió la máquina de un desarrollador de Safe{Wallet} e inyectó JavaScript malicioso en el bucket AWS S3 que servía el frontend. El código inyectado apuntaba específicamente a las transacciones provenientes de la dirección Safe de Bybit. Según el CEO de Bybit, Ben Zhou [2], la interfaz de Safe{Wallet} mostraba una transacción legítima, mientras que se enviaba un payload diferente a los dispositivos Ledger de los firmantes. Los firmantes aprobaron la transacción tal como se presentó en la interfaz, otorgando al atacante tres firmas válidas para el payload malicioso.
Paso 2: Reemplazo de Implementación
El atacante envió la transacción maliciosa con las tres firmas recopiladas. El proxy Safe delegó la llamada a masterCopy, cuya función execTransaction() validó las firmas y luego ejecutó el payload de la transacción: un delegatecall al contrato del atacante (0x962214...5c7242). Debido a que este delegatecall se ejecuta en el contexto de almacenamiento del proxy, la función transfer() del atacante sobrescribió el valor de masterCopy en el slot 0 con una dirección de implementación maliciosa (0xbDd077...9516). A partir de ese momento, todas las llamadas al contrato Safe fueron delegadas al código del atacante.
Paso 3: Robo de Activos
Con masterCopy apuntando ahora a la implementación del atacante, el requisito de multifirma ya no aplicaba. El atacante llamó directamente a SweepERC20() y SweepETH() en el contrato Safe. Estas funciones, definidas en el contrato de implementación del atacante, transfirieron todos los activos almacenados sin ninguna verificación de firmas. Se ejecutaron cinco transacciones de drenaje, con pérdidas totales de aproximadamente $1.5 mil millones.
Contratos y Transacciones Relacionados
Resumen
Este incidente demostró cómo el compromiso de una infraestructura fuera de la cadena puede derivar en pérdidas catastróficas dentro de la cadena. El atacante encadenó una brecha Web2, una manipulación del frontend y una actualización del proxy en una única ruta de ataque que eludió la protección multifirma sin explotar ninguna vulnerabilidad en la cadena.
Lecciones clave:
- La integridad del frontend merece la misma atención que la seguridad en la cadena. La cadena de ataque comenzó en la capa de servicio del frontend. A medida que las dApps median cada vez más transacciones de alto valor, proteger el código del frontend con verificación de integridad (SRI, firma de código, compilaciones reproducibles) y monitorear cambios no autorizados se convierte en un requisito básico.
- La verificación en billeteras hardware sigue siendo difícil en la práctica. Las billeteras hardware pueden mostrar el payload de firma real, pero interpretar datos complejos de transacciones multifirma en una pantalla pequeña es un conocido desafío de usabilidad. Mejorar la legibilidad de los resúmenes de transacciones en el dispositivo es un problema abierto para el ecosistema de billeteras.
- Los mecanismos de actualización de proxy son objetivos de alto impacto. La arquitectura del proxy Safe enruta toda la lógica a través de un único puntero actualizable. Cualquier mecanismo que permita el reemplazo de la implementación en un solo paso concentra el riesgo. Añadir un timelock, un paso de confirmación secundario o un guardián independiente para las actualizaciones puede reducir el impacto de una única transacción comprometida.
Referencias
Acerca de BlockSec
BlockSec es un proveedor integral de seguridad blockchain y cumplimiento cripto. Desarrollamos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluyendo contratos inteligentes, blockchain y billeteras), interceptar ataques en tiempo real, analizar incidentes, rastrear fondos ilícitos y cumplir con las obligaciones AML/CFT, a lo largo de todo el ciclo de vida de protocolos y plataformas.
BlockSec ha publicado múltiples artículos de seguridad blockchain en conferencias de prestigio, reportado varios ataques de día cero en aplicaciones DeFi, bloqueado múltiples hackeos para rescatar más de 20 millones de dólares y asegurado miles de millones en criptomonedas.
-
Sitio web oficial: https://blocksec.com/
-
Cuenta oficial de Twitter: https://twitter.com/BlockSecTeam
