Un script de monitorización secuestrado vacía unos 2,7 M$ de traders de Polymarket

El 29 de octubre, un pequeño fragmento de JavaScript que el mercado de predicciones Polymarket cargaba para medir la velocidad de sus páginas fue sustituido discretamente por una versión maliciosa. Durante aproximadamente una hora, ese script utilizó las sesiones ya iniciadas de los traders para entregar sus posiciones y fondos a una billetera controlada por los atacantes. Polymarket afirma que está reembolsando cerca de 2,7 millones de dólares a 726 billeteras afectadas.

Qué ocurrió

El script pertenecía a DebugBear, un servicio de monitorización de usuarios reales (RUM) que mide la rapidez con la que cargan las páginas para los visitantes. Cada cliente de DebugBear inserta su propia copia del script, y la que se sustituyó fue la de Polymarket.

DebugBear indica que sus registros DNS fueron comprometidos a través de su registrador de dominios. Con el DNS bajo su control, los atacantes hicieron que la dirección desde la que Polymarket descargaba el script apuntara a otro servidor, que entregaba el archivo malicioso en lugar del legítimo, alojado normalmente en la nube. Los primeros hallazgos de DebugBear apuntan a que solo se atacó el sitio de un cliente y, por ahora, no ha visto indicios de intrusión en sus propios sistemas; la investigación sigue abierta.

Cómo se llevaron el dinero

El código malicioso no intentó robar contraseñas, frases semilla ni claves privadas. En su lugar, aprovechó el acceso que el trader ya tenía en una pestaña de Polymarket abierta y con sesión iniciada:

• leyó datos de la cuenta guardados en el navegador, incluidas las claves API de trading;
• localizó la lógica de colocación de órdenes y el firmante que aprueba las transacciones de la cuenta;
• en las cuentas que inician sesión con una billetera cripto, transfirió las posiciones directamente a la billetera de los atacantes;
• en las cuentas que inician sesión por correo electrónico, vendió las posiciones a precios cada vez peores y sacó el dinero.

En ambos casos, el código pidió al firmante de la cuenta que firmara las solicitudes y las envió al relayer de Polymarket. No está demostrado que todas las víctimas firmaran a ciegas —algunos proveedores de billeteras podrían haber mostrado un aviso o aplicado sus propias reglas—, pero el resultado demuestra el poder que tiene el código que se ejecuta dentro de una página de confianza.

Los registros on-chain muestran que la billetera atacante recibió fondos aproximadamente entre las 17:10 y las 18:02 UTC, acumulando unos 28,6 millones de tokens POL (unos 2,64 millones de dólares en ese momento) además de posiciones de trading. Entre las 18:28 y las 18:38 UTC, los POL se movieron a otras tres direcciones.

La respuesta de Polymarket

Polymarket publicó su primera actualización sobre actividad no autorizada en billeteras a las 17:38 UTC y pasó su plataforma a modo de solo cancelación a las 18:05 UTC, pausando las acciones del relayer. La empresa asegura que retiró el script en menos de una hora, purgó las cachés, restableció todas las sesiones activas, mantuvo el trading en pausa hasta que el sitio quedó limpio y remitió el caso a las autoridades.

A 30 de octubre, 689 de las 726 billeteras afectadas habían sido reembolsadas por completo, y las 37 restantes se pagan a medida que se verifican. Polymarket también compensa a unas 5.500 billeteras —unos 1,19 millones de dólares— que perdieron dinero durante la pausa o a las que se les quitaron posiciones, con lo que el total devuelto asciende a unos 3,9 millones de dólares. Los traders no necesitan presentar ninguna reclamación. DebugBear ha pedido a sus clientes de RUM que eliminen su código incrustado, y Polymarket señala que los scripts de terceros solo volverán con controles más estrictos: una Content Security Policy más restrictiva, versiones fijadas y sandboxing.

Por qué importa

Es un caso de manual de ataque a la cadena de suministro web. El código de Polymarket nunca fue vulnerado: el punto débil fue el registrador de dominios de un proveedor, a dos pasos de distancia. Cualquier script cargado desde otro dominio se ejecuta con todos los privilegios de la página y, en una página donde los usuarios operan o firman transacciones, eso equivale a poder actuar en su nombre.

También deja en evidencia los límites de las defensas habituales. Una CSP que simplemente permite un CDN de confianza no sirve de nada si el DNS de ese CDN —o el archivo que entrega— cambia sin que lo sepas.

Qué hacer

Para los responsables de sitios web:

1. Inventaria todos los scripts de terceros que cargan tus páginas y elimina lo que no sea imprescindible en las páginas donde los usuarios inician sesión, operan, pagan o firman.
2. Fija versiones y verifica. Cuando un archivo pueda versionarse, sírvelo con hashes de Subresource Integrity (SRI) para que el navegador lo rechace si cambia su contenido, o alójalo tú mismo.
3. Endurece la CSP más allá de las listas de dominios permitidos y aísla las etiquetas de analítica y monitorización en iframes con sandbox, lejos de los flujos sensibles.
4. Limita lo que el código de la página puede pedir al firmante. Revisa qué acciones puede desencadenar el código del cliente y exige una confirmación explícita y comprensible para las operaciones que mueven dinero.
5. Vigila también la infraestructura de tus proveedores. Los cambios inesperados de DNS o de alojamiento en los dominios desde los que cargas código son una señal de alerta temprana.

Para traders y usuarios: rechaza cualquier solicitud de firma que no esperabas y revisa la actividad de tu billetera y tu cuenta tras cualquier aviso de incidente de una plataforma que utilices.

La mayoría de las organizaciones no tiene una lista precisa de los dominios y scripts externos de los que dependen sus propios sitios. Nuestro servicio de Attack Surface Management mapea de forma continua esas dependencias —incluidos los orígenes de scripts de terceros y el DNS que hay detrás— y alerta de los cambios inesperados, para que un script sustituido o un dominio de proveedor secuestrado se detecte antes de llegar a tus usuarios.