El ataque a Polymarket entró por el DNS de DebugBear

Seguimiento de Un script ajeno vació carteras en Polymarket, publicada el 2 de noviembre.

DebugBear, la empresa de medición de rendimiento web cuyo script se usó para vaciar carteras en Polymarket, ya ha explicado por dónde entraron los atacantes: no por sus servidores, sino por su dominio. «Los registros de nuestro servidor DNS se vieron comprometidos a través de nuestro registrador de dominios. Actualmente no podemos recibir correos enviados a nuestro dominio», ha comunicado la compañía, según recoge SecurityWeek.

Es la pieza que faltaba en lo que contamos tras el ataque del 29 de octubre, cuando código malicioso servido desde la web de Polymarket vendió posiciones y movió fondos de usuarios con la sesión iniciada. Entonces no estaba claro cómo se había sustituido el script.

Quien controla el DNS controla el script

Si alguien cambia los registros DNS de un dominio, decide a qué servidor llegan los navegadores que piden un archivo a ese dominio. Las webs que cargaban el script de DebugBear seguían pidiéndolo a la dirección de siempre, pero podían recibir lo que el atacante quisiera. DebugBear asegura que no ha encontrado indicios de que sus sistemas internos fueran comprometidos.

La empresa añade, como conclusión preliminar, que los atacantes parecen haber ido a por la web de un cliente concreto, al que no nombra. Polymarket, por su parte, tampoco ha identificado al proveedor comprometido. DebugBear no ha explicado cómo se consiguió el acceso en el registrador y su investigación sigue abierta. Al principio, se limitó a pedir a sus clientes que retiraran el código del script.

La factura sube a 3,9 millones

Polymarket ha ampliado la compensación. A los unos 2,7 millones de dólares robados directamente de 726 carteras suma 1,19 millones para unas 5.500 carteras perjudicadas por la suspensión de la negociación o cuyas posiciones fueron vendidas o transferidas por el script. En total, 3,9 millones. En su actualización del 30 de octubre, la plataforma decía que todas las carteras afectadas salvo 37 habían recibido ya su dinero.

Según los investigadores de Hudson Rock, el código leía datos relacionados con credenciales guardados en el navegador, pero no vieron que enviara contraseñas, frases semilla ni claves privadas. Le bastaba con aprovechar los permisos de la sesión abierta para operar.

Polymarket dice que retiró al proveedor «en menos de una hora», que investiga con las fuerzas de seguridad y que publicará un análisis del incidente. No es la primera vez: en junio ya atribuyó a un proveedor externo comprometido la inyección de un script malicioso en su web, con unos 3 millones de dólares robados.

La lección se alarga: incluir código de terceros no es solo confiar en el proveedor, sino también en su registrador, en sus cuentas y en todo lo que hay detrás de su dominio.

Fuente: SecurityWeek