TL;DR: análise do risco oculto do Polyfill
- Pior que um redirect: Toda a gente encolheu os ombros porque o payload visível era um redirecionamento para sites de apostas e adultos, mas o Polyfill gerava código por pedido, pelo que uma variante de formjacking ou roubo de credenciais direcionada a visitantes específicos nunca apareceria numa varredura pública.
- Uma venda adormecida: O domínio foi vendido por uma quantia que muda uma vida cerca de seis semanas antes de os redirecionamentos começarem, e a cside monitoriza o que os scripts realmente carregam e fazem no navegador, em vez de confiar numa revisão única da origem do código ou numa verificação de reputação.
- A confiança única arma-o: Se a revisão do fornecedor for uma aprovação única, a confiança concedida transforma-se numa chave de execução permanente, pelo que é preciso monitorizar o comportamento em tempo de execução em cada sessão ou aceitar que a próxima venda de domínio pode armar o script da noite para o dia.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
Quando nós e outros órgãos de comunicação reportámos o ataque ao Polyfill, as reações foram surpreendentemente brandas. Isto pode dever-se ao resultado visível: um simples redirecionamento para sites obscuros. (Para a cronologia completa, consulte a nossa linha do tempo completa do Polyfill.io.)
Mas, como detalhámos no nosso post-mortem, as consequências potenciais são muito mais graves:
"Aqui, o agente malicioso optou por apenas redirecionar utilizadores para sites de conteúdo adulto e de apostas, mas algo muito pior poderia ter acontecido. Escutar as teclas digitadas numa pequena percentagem de sessões com base na geolocalização e na hora do dia, injetar malware, minerar criptomoeda ou reescrever botões em sites para redirecionar para portais de pagamento falsificados.
De um simples redirecionamento à captura de dados de cartões de crédito, os ataques de JavaScript do lado do cliente podem fazer tudo isto. O ataque ao Polyfill poderia ter tido um impacto muito mais negativo; de certa forma, tivemos sorte. Que isto sirva de aviso: temos de monitorizar os nossos scripts do lado do cliente."
O facto é que muito provavelmente aconteceu muito mais do que isso.
Novo dado sobre a transferência do domínio
O domínio que hospedava o script foi vendido a uma empresa de operação chinesa chamada Funnull. Cerca de seis semanas depois, os redirecionamentos começaram e o incidente foi reconhecido como um ataque. A empresa de segurança Sansec publicou a sua análise forense do payload de redirecionamento. (O CVE-2024-38526 relacionado foi atribuído ao pdoc, a ferramenta de documentação Python que carregava o polyfill.io, e não ao incidente como um todo.)
Recentemente, uma fonte não identificada revelou que o domínio polyfill[.]io — no centro do ataque — foi vendido por uma "quantia que muda uma vida".
O script Polyfill foi originalmente criado por Andrew Betts e Jake Champion. Andrew Betts publicou um tweet (entretanto apagado) a reconhecer a venda e a admitir que não teve qualquer influência sobre ela.
Outro utilizador do X, John Schulz, descobriu um anúncio, entretanto removido, da Funnull que identificava Jake Champion como o indivíduo que lhes transferiu o domínio:
Took me a bit to find it, but here's the announcement pic.twitter.com/9sdSboOu7l
— John Schulz (@JFSIII) February 24, 2024
Um tweet entretanto apagado de Jake Champion confirma que foi ele próprio quem transferiu o domínio para a Funnull.
Possíveis cenários catastróficos
O ataque foi exposto porque os utilizadores foram redirecionados para sites de conteúdo adulto e de apostas. No entanto, se o domínio foi vendido por uma "quantia que muda uma vida", parece improvável que tenha sido usado apenas para uma exploração tão básica.
Durante semanas, este ataque afetou meio milhão de sites, incluindo Intuit, The Guardian, Hulu e The Verge.
Eis alguns cenários catastróficos potenciais que poderiam ter sido executados ao assumir o controlo de um único ficheiro JavaScript de terceiros.
Ataque DDoS
Os atacantes podem recolher endereços IP de visitantes em meio milhão de sites e usar as suas máquinas para enviar pedidos a qualquer alvo, criando um dos maiores ataques DDoS de sempre. Isto pode paralisar grandes instituições, tanto privadas como governamentais, durante horas.
Ataque ao Workday
Os atacantes podem enganar funcionários para que partilhem as suas credenciais do Workday, obtendo acesso não autorizado a sistemas internos, ou simplesmente exfiltrar o seu token de sessão. Isto pode resultar em:
- Manipulação da folha de pagamentos
- Roubo de registos de funcionários
- Acesso a dados sensíveis de RH
- … e muito mais
Reescrever qualquer conteúdo numa página web
Em sites de notícias infetados, os atacantes podem reescrever o conteúdo para:
- Provocar reações ou pânico
- Manipular a opinião pública
- Alterar narrativas sobre temas controversos
- … e muito mais
Captura de PII e dados de cartões de crédito
Os ataques do lado do cliente recolhem frequentemente Informações de Identificação Pessoal (PII) e dados de pagamento. Com mais de meio milhão de sites afetados, muitos deles com formulários de checkout, os atacantes podem roubar dados de pagamento em massa.
Infetar outros sites
Um site infetado pode alojar scripts maliciosos, permitindo que o ataque se propague. Esta tática dificulta os esforços de deteção e contenção. Esta técnica é comummente usada em violações do lado do cliente, como se viu no caso do Schrwaa[.].com (link seguro para um artigo).
Minerar criptomoeda no navegador
O cryptojacking — forçar os navegadores dos utilizadores a minerar criptomoeda — é uma tática bem documentada. Se executado em meio milhão de sites de elevado tráfego, os atacantes podem lucrar imensamente com milhões de visitantes diários. Leia sobre os ataques ao BrowseAloud e ao Copay event-stream para ver exemplos recentes.
Um cenário e
Estes cenários não são isolados: podem ocorrer em simultâneo. Os redirecionamentos já aconteceram, mas os outros cenários também podem ter estado ativos.
Sem monitorização do lado do cliente, é impossível saber.
Para sermos precisos quanto à prova: o único payload que os investigadores captaram e descodificaram foi o redirecionamento. Uma desofuscação independente da SecureLayer7 não encontrou prova captada de recolha de credenciais, registo de teclas digitadas ou exfiltração de PII, e a divulgação forense da Sansec documentou o mesmo comportamento de apenas redirecionamento. Os cenários acima são, portanto, capacidade, não eventos confirmados, mas, como o script era reconstruído a cada pedido, uma variante de roubo de dados direcionada nunca apareceria numa varredura pública. Redirecionamento: comprovado. Roubo silencioso e direcionado: plausível por conceção, nunca captado.
Esta incerteza é a razão pela qual criámos a cside. Embora não consigamos ver todos os ataques a nível global, monitorizamos os scripts de terceiros no seu site para detetar e prevenir que ataques como este prejudiquem os seus utilizadores.
Esperemos que o redirecionamento tenha sido o pior de tudo. Mas o facto de algo muito pior poder ter acontecido já é razão suficiente para agir. Em 2025, a OFAC sancionou a Funnull pela operação mais ampla por trás deste domínio, um lembrete de que quem a geria não eram amadores. Proteja o seu site em segundos, gratuitamente, registando-se hoje.
