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 con UXLINK y monitoreamos el flujo de fondos. UXLINK contactó de emergencia 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 han sido marcados y congelados por los principales exchanges, minimizando así el riesgo adicional para la comunidad. El equipo del proyecto se ha comprometido a mantener la transparencia con la comunidad, y ExVul continuará analizando y dando seguimiento al desarrollo del incidente.

（）

Últimos avances

Durante el proceso de transferencia de los fondos del hacker, los activos que ingresaron a los exchanges han sido congelados. A través de un rastreo preliminar en la cadena, se descubrió que el hacker que robó los activos de UXLINK fue aparentemente 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, lo que significa que solo se requería la firma de una cuenta para ejecutar operaciones en el contrato. El hacker estableció una nueva dirección 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 manera 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: invocar mediante delegatecall el 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 regresa al contrato Gnosis Safe Proxy para ejecutar removeOwner. El proceso específico es: el atacante, mediante 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 radica en cumplir la condición msg.sender== address(this). En la función removeOwner, para evitar llamadas directas externas, el contrato establece una verificación authorized, 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 exitosamente.

6. El hacker, utilizando el método descrito anteriormente, eliminó uno por uno a los demás Owners del multifirma, destruyendo el mecanismo multifirma y finalmente tomando el control del contrato.

7. Hasta este punto, el atacante, repitiendo continuamente los pasos anteriores, hizo que el mecanismo de seguridad multifirma original quedara completamente inservible. En este momento, solo se requería la firma de un único Owner malicioso 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) del Gnosis Safe Proxy en 1, haciendo que el diseño de seguridad multifirma original quedara completamente inservible. Posteriormente, un único Owner malicioso podía pasar la verificación multifirma. El atacante procedió a eliminar gradualmente a los demás Owners del contrato, logrando finalmente el control total del contrato y transfiriendo los activos, además de acuñar maliciosamente tokens $UXLINK en la cadena.

Este incidente resalta el papel clave de la gestión multifirma en la seguridad blockchain. Aunque el proyecto adoptó el mecanismo multifirma Safe y configuró varias cuentas multifirma, las deficiencias en la gestión hicieron que el diseño multifirma fuera inútil. El equipo de ExVul recomienda que los proyectos busquen la descentralización en la gestión multifirma, por ejemplo, permitiendo que diferentes miembros custodien las claves privadas y adoptando diversas formas de almacenamiento de claves, para asegurar que el mecanismo multifirma brinde realmente la protección de seguridad esperada.

Apéndice

A continuación se muestran las direcciones sospechosas de hackers rastreadas en la cadena por el equipo de ExVul: