Análisis técnico del robo de aproximadamente 11.3 millones de dólares en UXLINK
El atacante, mediante una serie de operaciones que incluyeron la llamada a la función execTransaction del contrato Gnosis Safe Proxy y al contrato MultiSend, fue eliminando gradualmente a los demás propietarios, hasta finalmente tomar el control del contrato y acuñar de manera maliciosa tokens 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:
Descargo de responsabilidad: El contenido de este artículo refleja únicamente la opinión del autor y no representa en modo alguno a la plataforma. Este artículo no se pretende servir de referencia para tomar decisiones de inversión.
También te puede gustar
Todas las miradas puestas en Washington, ¿la próxima semana el “supermiércoles de los bancos centrales” traerá una ola de subas de tasas del G7?
En medio de una creciente inflación, conflictos geopolíticos y el precio del petróleo superando los 100 dólares, los bancos centrales del G7 se preparan para una semana clave de decisiones sobre tasas de interés. Impulsada por una inflación núcleo superior a lo esperado, se estima que la Reserva Federal realice su primer aumento de tasas en tres años; el Banco de Japón podría elevar su tasa al 1,25%, marcando un máximo de 30 años; la postura hawkish de los bancos centrales de Reino Unido, la Unión Europea y Canadá también se fortalece, iniciando así un importante giro hacia el endurecimiento colectivo de la política monetaria global.
¿La Reserva Federal continuará subiendo las tasas de interés? ¿Se repetirá el ciclo de endurecimiento de finales de los años 80?
El informe de Citibank señala que el entorno macroeconómico actual es muy similar al ciclo de restricción de 1988-1989, cuando la economía mantuvo su resiliencia y la presión inflacionaria fue acumulándose gradualmente; posteriormente, la actividad económica se desaceleró y las políticas se volvieron más flexibles. En ese ciclo de restricción, la Reserva Federal aumentó las tasas de interés en 16 ocasiones consecutivas.
¡Enemigos mortales se unen rara vez! Musk y Aaltman apoyan el llamado de Dario Amodei a “ralentizar globalmente la IA”
Anthropic Amodei hizo un llamado a "ralentizar la IA a nivel global", y sorprendentemente tanto Musk como Altman salieron públicamente a respaldar la propuesta. Los tres gigantes acordaron unánimemente abrir a terceros la evaluación de tecnologías al nivel de sus empleados y coordinar una desaceleración del desarrollo; Altman incluso anunció directamente que OpenAI no saldrá a la bolsa este año. La renuncia indignada de un investigador y una serie de incidentes con IAs descontroladas que "escaparon", encendieron el pánico que hacía tiempo se venía acumulando en la industria.
Precios de las criptos
Más
