El supuesto hacker de Bitget no roba claves privadas, sino que falsifica solicitudes de transferencia
Esta vez, el robo en Bitget no es lo más importante quizá no sea el número de 350 millones de dólares, sino que el hacker ni siquiera necesitaba obtener la clave privada para transferir el dinero.
Según la divulgación más reciente de Bitget, el atacante accedió al sistema de backend clave de la infraestructura de la billetera, falsificó los datos de las transacciones y luego, aprovechando el proceso de autorización existente de la bolsa, inició la transferencia. Es decir, el problema no es “que se haya robado la clave privada”, sino que el sistema tomó una solicitud de transferencia falsa como si fuera una solicitud real.
La diferencia entre estas dos formas de ataque es enorme.
Si se filtró la clave privada, significa que el atacante obtuvo directamente el control de los activos; y esta vez parece más bien que el atacante logró engañar al “sistema de aprobación”, haciendo que el mecanismo de firma normal completara la transferencia para el hacker.
Actualmente Bitget ha divulgado que los afectados son algunos monederos calientes y monederos templados; los monederos fríos no se vieron afectados, y los monederos autohosted independientes de Bitget Wallet tampoco. Bitget estimó inicialmente la pérdida en aproximadamente 351,6 millones de dólares, y luego, tras el seguimiento on-chain, volvió a contabilizar los activos involucrados en alrededor de 387,5 millones de dólares; el aumento proviene principalmente de activos de Zcash y TRON que no se habían incluido previamente, y no de nuevas transferencias no autorizadas.
La advertencia más importante para la industria de CEX es que el verdadero lugar peligroso no necesariamente es la clave privada, sino el sistema “instrucciones de transacción—control de riesgos—aprobación—firma” que está antes de la clave privada.
Si el sistema de backend puede ser controlado por el atacante, entonces aunque la clave privada en sí no se haya filtrado, el atacante aún podría falsificar parámetros de la transacción y hacer que el sistema de firma emita “legalmente” una transacción no autorizada.
Por lo tanto, en adelante, al evaluar la seguridad de un exchange, quizá no baste con mirar “si tiene monedero frío” y “si la clave privada está fuera de línea”; también hay que ver si la generación de transacciones, la gestión de permisos, el mecanismo de aprobación, la detección de anomalías y el control de riesgos por capas pueden validarse entre sí de forma independiente.
Actualmente Bitget ya ha suspendido los retiros y ha iniciado una investigación; instituciones de seguridad como Mandiant y SlowMist participan en el rastreo. Bitget también afirma que su fondo de protección de usuarios de más de 464 millones de dólares cubre esta pérdida.
Por supuesto, el caso sigue en investigación: por ahora no se puede sacar conclusiones demasiado pronto sobre qué punto de entrada utilizó el atacante para entrar en el sistema de backend.
Pero este incidente al menos demuestra una cosa:
La vulnerabilidad más peligrosa de un exchange quizá no sea “que roben la llave”, sino que el propio sistema le haya abierto la puerta al hacker.
Para Bitget, esto fue un incidente de seguridad; para toda la industria de CEX, también fue una prueba de tensión para su arquitectura de seguridad.
Después de este incidente, ¿crees que al evaluar la seguridad de un exchange los usuarios todavía solo deberían mirar “reservas + monedero frío”?