Script de monitorização sequestrado desvia cerca de 2,7 M$ de traders da Polymarket

A 29 de outubro, um pequeno excerto de JavaScript que o mercado de previsões Polymarket carregava para medir a velocidade das suas páginas foi discretamente substituído por uma versão maliciosa. Durante cerca de uma hora, esse script usou as sessões já iniciadas dos traders para entregar as suas posições e fundos a uma carteira controlada pelos atacantes. A Polymarket afirma que está a reembolsar cerca de 2,7 milhões de dólares a 726 carteiras afetadas.

O que aconteceu

O script pertencia à DebugBear, um serviço de monitorização de utilizadores reais (RUM) que mede a rapidez com que as páginas carregam para quem as visita. Cada cliente da DebugBear incorpora a sua própria cópia do script — e a cópia substituída foi a da Polymarket.

A DebugBear indica que os seus registos DNS foram comprometidos através do seu registador de domínios. Com o DNS sob o seu controlo, os atacantes fizeram com que o endereço de onde o site da Polymarket descarregava o script apontasse para outro servidor, que entregava o ficheiro malicioso em vez do legítimo, normalmente alojado na nuvem. As primeiras conclusões da DebugBear indicam que apenas o site de um cliente foi visado e, até agora, a empresa não encontrou sinais de intrusão nos seus próprios sistemas; a investigação continua.

Como o dinheiro foi levado

O código malicioso não tentou roubar palavras-passe, frases-semente ou chaves privadas. Em vez disso, aproveitou o acesso que o trader já tinha num separador da Polymarket aberto e com sessão iniciada:

• leu dados da conta guardados no navegador, incluindo as chaves de API de negociação;
• localizou a lógica de colocação de ordens e o assinante que aprova as transações da conta;
• nas contas que iniciam sessão com uma carteira cripto, transferiu as posições diretamente para a carteira dos atacantes;
• nas contas que iniciam sessão por e-mail, vendeu as posições a preços cada vez piores e retirou o dinheiro.

Em ambos os casos, o código pediu ao assinante da conta que assinasse os pedidos e enviou-os para o relayer da Polymarket. Não está provado que todas as vítimas tenham assinado às cegas — alguns fornecedores de carteiras podem ter mostrado um aviso ou aplicado as suas próprias regras —, mas o resultado mostra o poder que tem o código executado dentro de uma página de confiança.

Os registos on-chain mostram que a carteira dos atacantes recebeu fundos aproximadamente entre as 17:10 e as 18:02 UTC, acumulando cerca de 28,6 milhões de tokens POL (cerca de 2,64 milhões de dólares na altura), além de posições de negociação. Entre as 18:28 e as 18:38 UTC, os POL foram transferidos para outros três endereços.

A resposta da Polymarket

A Polymarket publicou a primeira atualização sobre atividade não autorizada em carteiras às 17:38 UTC e colocou a plataforma em modo apenas de cancelamento às 18:05 UTC, suspendendo as ações do relayer. A empresa afirma que removeu o script em menos de uma hora, limpou as caches, reiniciou todas as sessões ativas, manteve a negociação suspensa até o site estar limpo e participou o caso às autoridades.

Até 30 de outubro, 689 das 726 carteiras afetadas tinham sido totalmente reembolsadas, e as restantes 37 estão a ser pagas à medida que são verificadas. A Polymarket está também a compensar cerca de 5500 carteiras — aproximadamente 1,19 milhões de dólares — que perderam dinheiro durante a pausa ou a quem foram retiradas posições, elevando o total devolvido para cerca de 3,9 milhões de dólares. Os traders não precisam de apresentar qualquer pedido. A DebugBear pediu aos clientes do RUM que removessem o seu código incorporado, e a Polymarket diz que os scripts de terceiros só regressarão com controlos mais rigorosos: uma Content Security Policy mais restritiva, versões fixadas e sandboxing.

Porque é que isto importa

É um exemplo clássico de ataque à cadeia de fornecimento web. O código da Polymarket nunca foi comprometido — o ponto fraco foi o registador de domínios de um fornecedor, a dois passos de distância. Qualquer script carregado a partir de outro domínio corre com todos os privilégios da página e, numa página onde os utilizadores negociam ou assinam transações, isso significa poder agir em nome deles.

O caso evidencia também os limites das defesas habituais. Uma CSP que se limita a permitir um CDN de confiança de nada serve se o DNS desse CDN — ou o ficheiro que entrega — mudar sem que dê por isso.

O que fazer

Para os responsáveis por sites:

1. Faça o inventário de todos os scripts de terceiros carregados pelas suas páginas e remova tudo o que não seja estritamente necessário nas páginas onde os utilizadores iniciam sessão, negociam, pagam ou assinam.
2. Fixe versões e verifique. Quando um ficheiro puder ser versionado, sirva-o com hashes de Subresource Integrity (SRI), para que o navegador o rejeite se o conteúdo mudar — ou aloje-o internamente.
3. Reforce a CSP para além das listas de domínios permitidos e isole as etiquetas de análise e monitorização em iframes com sandbox, longe dos fluxos sensíveis.
4. Limite o que o código da página pode pedir ao assinante. Reveja que ações o código do lado do cliente pode desencadear e exija uma confirmação explícita e legível para as operações que movimentam dinheiro.
5. Vigie também a infraestrutura dos seus fornecedores. Alterações inesperadas de DNS ou de alojamento nos domínios de onde carrega código são um sinal de alerta precoce.

Para traders e utilizadores: rejeite qualquer pedido de assinatura que não esperava e verifique a atividade da carteira e da conta após qualquer aviso de incidente de uma plataforma que utilize.

A maioria das organizações não tem uma lista exata dos domínios e scripts externos de que dependem os seus próprios sites. O nosso serviço de Attack Surface Management mapeia continuamente essas dependências — incluindo as origens de scripts de terceiros e o DNS por trás delas — e assinala alterações inesperadas, para que um script substituído ou um domínio de fornecedor sequestrado seja detetado antes de chegar aos seus utilizadores.