Análisis técnico del robo de aproximadamente 11.3 millones de dólares en UXLINK

Título original: «Análisis técnico del robo de aproximadamente 11.3 millones de dólares en UXLINK»
Fuente original: ExVul Security

Descripción del evento

El 23 de septiembre, la clave privada de la billetera multifirma del proyecto UXLINK fue filtrada, lo que resultó en el robo de criptomonedas por un valor aproximado de 11.3 millones de dólares, las cuales ya han sido dispersadas y transferidas a varios exchanges centralizados (CEX) y descentralizados (DEX). Inmediatamente después del ataque, investigamos y analizamos el incidente junto a UXLINK y monitoreamos el flujo de los fondos. UXLINK contactó de urgencia a los principales exchanges solicitando el congelamiento de los fondos sospechosos, y ya ha presentado denuncias ante la policía y organismos pertinentes para buscar apoyo legal y la recuperación de los activos. La mayoría de los fondos del hacker ya han sido marcados y congelados por los principales exchanges, minimizando así el riesgo de que la comunidad enfrente mayores pérdidas. El equipo del proyecto se comprometió a mantener la transparencia con la comunidad, y ExVul continuará analizando y siguiendo el desarrollo del caso.

()

Últimos avances

Durante el movimiento de los fondos del hacker, el dinero que ingresó a los exchanges fue congelado. A través de un rastreo preliminar en la blockchain, se descubrió que el hacker que robó los activos de UXLINK aparentemente fue víctima de un ataque de phishing por parte de Inferno
Drainer. Tras la verificación, se confirmó que aproximadamente 542 millones de tokens $UXLINK obtenidos ilegalmente fueron robados mediante una técnica de «phishing de autorización».

Análisis del ataque

1. Anteriormente, debido a operaciones maliciosas del Owner multifirma o a la filtración de la clave privada, una dirección maliciosa fue añadida como miembro multifirma y el umbral de firmas (threshold) del contrato fue restablecido a 1, es decir, solo se necesitaba la firma de una cuenta para ejecutar operaciones en el contrato. El hacker configuró una nueva dirección de Owner: 0x2EF43c1D0c88C071d242B6c2D0430e1751607B87.

()

2. El atacante primero llamó a la función execTransaction del contrato Gnosis Safe Proxy. Esta función se convirtió en la puerta de entrada para eliminar miembros multifirma de forma maliciosa, y todas las operaciones maliciosas posteriores se ejecutaron internamente en esta transacción.

()

3. Al llamar a execTransaction, el atacante especificó en el parámetro data una operación maliciosa: llamar mediante delegatecall al contrato de implementación Safe: Multi Send Call
Only 1.3.0.

()

4. En la función multiSend de Safe: Multi Send Call Only 1.3.0, el flujo de ejecución retorna al contrato Gnosis Safe Proxy para ejecutar removeOwner. El proceso específico es: el atacante, mediante un delegatecall al contrato proxy, llama al contrato de implementación MultiSend, haciendo que multiSend se ejecute en el contexto del contrato proxy; luego, multiSend, según los parámetros construidos por el atacante, llama de vuelta al contrato Gnosis Safe Proxy mediante call y activa la función removeOwner, eliminando así la dirección Owner existente.

()

5. La clave para que la llamada sea exitosa es cumplir la condición msg.sender== address(this). En la función removeOwner, para evitar llamadas externas directas, el contrato establece una verificación de autorización, cuya lógica interna generalmente requiere que el llamador sea el propio contrato (msg.sender == address(this)). Por lo tanto, solo cuando el flujo interno del contrato se llama a sí mismo, removeOwner puede ejecutarse correctamente.

6. El hacker, mediante la técnica mencionada, eliminó uno a uno a los otros Owners de la multifirma, destruyendo el mecanismo multifirma y finalmente tomando el control del contrato.

7. De este modo, el atacante, repitiendo continuamente los pasos anteriores, provocó la falla total del mecanismo de seguridad multifirma original. En este punto, solo la firma del Owner malicioso era suficiente para pasar la verificación multifirma y así obtener el control total del contrato.

()

Resumen

Debido a operaciones maliciosas del Owner multifirma o a la filtración de la clave privada, el atacante añadió una dirección maliciosa como miembro multifirma y estableció el umbral de firmas (threshold) de Gnosis Safe Proxy en 1, lo que provocó la falla total del diseño de seguridad multifirma original. A partir de entonces, un solo Owner malicioso podía pasar la verificación multifirma. El atacante procedió a eliminar gradualmente a los otros Owners del contrato, logrando finalmente el control total del contrato y transfiriendo los activos, además de acuñar maliciosamente tokens $UXLINK en la blockchain.

Este ataque resalta el papel clave de la gestión multifirma en la seguridad blockchain. Aunque el proyecto utilizó el mecanismo multifirma Safe y configuró varias cuentas multifirma, los defectos en la gestión hicieron que el diseño multifirma fuera inútil. El equipo de ExVul recomienda que los proyectos busquen la máxima descentralización en la gestión multifirma, por ejemplo, permitiendo que diferentes miembros custodien las claves privadas y adoptando métodos diversificados de almacenamiento de claves, para asegurar que el mecanismo multifirma brinde la protección de seguridad esperada.

Apéndice

A continuación, las direcciones sospechosas de hackers rastreadas en la blockchain por el equipo de ExVul: