El exchange Bybit fue hackeado alrededor de las 14:00 PM UTC el 21 de febrero de 2025, con pérdidas que se aproximan a los 1.500 millones de dólares – el incidente de seguridad más grande en la historia de las criptomonedas hasta la fecha. A diferencia de brechas de seguridad anteriores, este robo no fue causado por problemas con permisos de contratos inteligentes, sino por una actualización maliciosa de la billetera multifirma Safe utilizada por Bybit. El atacante engañó a múltiples operadores de la billetera Safe para que firmaran una transacción de actualización de billetera, logrando así tomar el control de la billetera Safe. Una vez en control, el atacante drenó los fondos.
Descubrimos que este ataque fue una operación meticulosamente planificada dirigida contra Bybit, habiendo el atacante desplegado y probado el contrato de ataque en la cadena dos días antes de lanzar el asalto final. En esta entrada de blog, comenzaremos con una introducción a la billetera Safe, analizaremos todo el proceso del ataque y, finalmente, ofreceremos algunas recomendaciones de seguridad.
Qué es una Billetera Multifirma Safe
Una Billetera Multifirma Safe es un tipo de billetera de contrato inteligente cuya característica principal es el uso de múltiples claves para autorizar transacciones. Esta billetera requiere que múltiples usuarios (generalmente titulares de claves predesignados) firmen una transacción antes de que se pueda ejecutar una transferencia u otra operación, mejorando así la seguridad y previniendo un punto único de fallo o el compromiso de una sola clave.
Cuando se crea la billetera, se configuran múltiples claves (generalmente usando un modelo "n-de-m"), lo que significa que entre los múltiples titulares de claves, se requiere un cierto número de firmas para que una transacción sea ejecutada. Por ejemplo, una billetera multifirma "3-de-5" significa que de cinco titulares de claves, se necesitan al menos tres firmas para que la transacción sea válida.
Aunque existen métodos para construir transacciones sin depender del sitio web oficial de Safe, desde una perspectiva de experiencia de usuario, la mayoría de los usuarios opta por construir y firmar transacciones a través del sitio web de Safe. Normalmente, los usuarios visitan https://app.safe.global para construir transacciones. Al usar una billetera Safe para construir y firmar una transacción, los usuarios primero simulan la transacción para comprender su resultado potencial una vez en la cadena, y para verificar si se alinea con sus expectativas. Solo si el resultado es el esperado, el operador procederá a completar el proceso de firma.
A continuación se muestra una captura de pantalla de la interfaz de construcción de transacciones en la billetera Safe. Dado que el sitio web de Safe actualmente no está disponible temporalmente, la siguiente captura de pantalla proviene de internet (fuente: https://milkroad.com/reviews/safe-wallet/).
En la práctica, al usar una billetera Safe, existen los siguientes riesgos de seguridad:
-
Cadena de seguridad larga: Los usuarios deben confiar en el sitio web oficial de Safe, la aplicación y los servicios de backend, así como en su propio ordenador y navegador, y finalmente en la billetera utilizada para firmar (ya sea una extensión de navegador o una billetera de hardware). Si alguno de estos componentes es comprometido por un atacante, el operador podría recibir información incorrecta (por ejemplo, podría estar firmando una transacción de actualización mientras la interfaz muestra una transacción de transferencia normal).
-
Falta de análisis de transacciones en billeteras de hardware: Las billeteras de hardware generalmente carecen de la capacidad de analizar transacciones Safe. Esto significa que si los usuarios son engañados por la interfaz de Safe, no tienen medios para realizar una verificación cruzada durante la firma final, lo que lleva a lo que se conoce como "firma a ciegas".
Proceso del Ataque
Antes de lanzar el ataque final, el atacante ya había desplegado y probado el contrato de ataque en la cadena. Múltiples direcciones diferentes estuvieron involucradas en todo el proceso del ataque.
Paso 1: Obtención de Fondos
El atacante primero necesitaba adquirir los fondos iniciales para el ataque. Normalmente, los atacantes obtienen fondos a través de plataformas de mezcla (por ejemplo, Tornado Cash) para ocultar sus rastros. Sin embargo, en este caso, los fondos del atacante provenían de Binance. Creemos que esto podría ser el método del atacante para ocultar su identidad, ya que los fondos y direcciones de los servicios de mezcla generalmente son monitoreados de cerca por las empresas de seguridad, mientras que los fondos provenientes de exchanges son monitoreados con menos rigor. Además, aunque los fondos provenían de un exchange, es posible que la cuenta del exchange no haya pasado por KYC, o que su información KYC haya sido falsificada.
Paso 2: Despliegue y Prueba del Contrato
Antes de lanzar el ataque real, el atacante realizó una serie de pruebas. Estas pruebas incluyeron desplegar una billetera Safe, desplegar el contrato de ataque, y usar la billetera Safe autodesplegada para realizar una operación de actualización, así como extraer fondos de la billetera Safe actualizada. Además, durante las pruebas, el atacante solo experimentó con un rango limitado de activos – activos que coincidían con los de la billetera que finalmente fue drenada en Bybit. Esto indica que el atacante apuntó específicamente a la billetera Safe de Bybit.
El atacante creó una billetera Safe con fines de prueba; una de las direcciones de la billetera Safe de prueba fue:
0x509b1eDa8e9FFed34287ccE11f6dE70BFf5fEF55
El atacante probó la actualización del contrato Safe. Podemos ver la información relevante a través del Phalcon Explorer en el siguiente enlace:
Después de probar la actualización, el atacante procedió a probar el proceso de retiro. Extrajeron directamente activos stEth del contrato Safe actualizado en la dirección:
0x509b1eda8e9ffed34287cce11f6de70bff5fef55
Paso 3: Engañar a los Usuarios para que Construyan y Firmen la Transacción de Actualización
Después de completar las pruebas, el atacante necesitaba engañar a los usuarios para que construyeran y firmaran la transacción de actualización del contrato Safe. Dado que las pruebas se realizaron dos días antes, el engaño probablemente ocurrió dentro de los dos días siguientes a las pruebas. Aún no se ha confirmado públicamente si esto se logró atacando los servidores de Safe o los ordenadores de los operadores de la billetera.
Paso 4: Lanzamiento del Ataque
Una vez que el atacante obtuvo un número suficiente de firmas, envió la transacción en la cadena y ejecutó con éxito la actualización del contrato. Tras la actualización, el atacante extrajo los fondos. Descubrimos que la transacción de actualización maliciosa era idéntica a la transacción de prueba anterior.
Lecciones e Perspectivas
De hecho, ataques similares ocurrieron dos veces el año pasado – incluyendo los robos de Radiant y del exchange indio WazirX (con pérdidas superiores a 200 millones de dólares) – ambos resultantes de transacciones maliciosas firmadas con billeteras Safe. La diferencia en este incidente es que la transacción firmada esta vez fue una transacción de actualización de contrato. Por lo tanto, aprender lecciones de estos incidentes de seguridad y prevenir futuros ataques sigue siendo un desafío que los exchanges y equipos de proyectos que poseen grandes cantidades de activos digitales deben abordar. Esto puede lograrse mejorando las operaciones diarias, la gestión de procesos internos, los protocolos de seguridad para operaciones sensibles y la configuración de descentralización para reducir el riesgo de ser atacado.
En segundo lugar, la cuestión de cómo las billeteras pueden participar mejor en el proceso de seguridad durante la firma de transacciones sigue sin resolverse. Actualmente, especialmente las billeteras de hardware generalmente carecen de la capacidad de analizar transacciones complejas. Además, dado que las billeteras de hardware no se conectan directamente a internet, cómo realizar simulaciones de transacciones (y presentar los resultados a los usuarios de manera fácilmente comprensible) para evitar la firma a ciegas sigue siendo un desafío.
Adicionalmente, es necesario implementar múltiples medidas de seguridad, como emplear plataformas de monitoreo de seguridad como BlockSec Phalcon para monitorear las billeteras Safe, asegurando que cualquier comportamiento anormal sea detectado y atendido de manera oportuna. De hecho, Phalcon ya tiene la capacidad de monitorear billeteras Safe, y continuaremos actualizando nuestros productos para que dicho monitoreo pueda configurarse automáticamente en el futuro, ayudando a los usuarios a evitar riesgos al usar Safe para gestionar grandes cantidades de activos. Aunque este incidente fue causado por el uso de una billetera Safe, no hay necesidad de temer a "Safe"; sigue siendo el estándar de facto para las billeteras multifirma, con la seguridad de su contrato habiendo sido probada con el tiempo.
Finalmente, debemos enfatizar que la defensa de seguridad nunca es un campo de batalla para avances en un solo punto, ni existe una bala de plata que funcione de una vez y para siempre. Al mismo tiempo que se garantiza la seguridad operativa y empresarial, los participantes de la industria pueden usar BlockSec Phalcon como la última línea de defensa para proteger sus activos.
