Polyfill.io era um serviço de CDN que entregava, sob demanda, trechos de JavaScript para dar suporte a recursos modernos em navegadores antigos. Em fevereiro de 2024 o domínio foi vendido, e em junho os scripts servidos por ele passaram a redirecionar visitantes para páginas fraudulentas em mais de cem mil sites, que apenas mantinham a mesma tag
<script>de sempre.
Nenhum desses sites foi invadido. A tag <script> continuou apontando para o mesmo endereço de sempre. Foi o endereço que mudou de dono. É por isso que o caso incomoda tanto: o time de segurança podia ter feito tudo certo do lado de dentro e ainda assim servir código malicioso aos próprios clientes.
O caso do Banco Horizonte Digital: uma história de confiança quebrada
O Banco Horizonte Digital é um exemplo composto, não um cliente. O comportamento dele, porém, foi o que se repetiu em boa parte dos sites afetados.
O banco carregava o Polyfill.io no portal de internet banking havia anos, para manter compatibilidade com navegadores antigos. Em fevereiro, quando o domínio cdn.polyfill.io mudou de dono, nada aconteceu. O serviço continuou respondendo, os scripts continuaram carregando, o portal continuou funcionando. Meses depois, uma fração dos clientes começou a cair em páginas de phishing que copiavam a tela de login, e as credenciais digitadas ali iam para o servidor do atacante.
A detecção demorou semanas. Ninguém no banco tinha a lista do que o portal carregava de fora, então não havia onde procurar. Quando a origem apareceu, milhares de clientes já tinham passado pela página falsa, e sobrou notificar cliente, responder ao regulador e explicar publicamente o que tinha acontecido. Nenhuma dessas etapas dependeu de uma falha no código do banco.
A alta dos ataques à cadeia de suprimentos digital
O caso Polyfill.io entra num padrão maior. Os ataques à cadeia de suprimentos digital vêm subindo há anos, e a curva ainda não deu sinal de virar.
O crescimento em números
Ataques à cadeia de suprimentos aumentaram mais de 600% em 2021 na comparação com o ano anterior, conforme relatado por PaloAlto Networks. Em 2024, 75% de todas as cadeias de suprimentos de software relataram ter sofrido ataques (Resilience Forward). A previsão da Gartner era de que, até 2025, 45% das organizações no mundo teriam sofrido ataques em suas cadeias de suprimentos de software, três vezes mais que em 2021.
Tempo de detecção
40% dos ataques à cadeia de suprimentos permanecem não detectados por mais de 6 meses. Seis meses dá tempo de o código malicioso alcançar sistemas internos, de o atacante deixar um segundo acesso plantado e de os dados saírem aos poucos, sem pico de tráfego que chame atenção. Quando a conta chega, ela cobre meio ano de operação do atacante.
Ataques à cadeia de suprimentos digitais exploram a confiança entre fornecedores e consumidores, injetando código malicioso em bibliotecas amplamente utilizadas. A detecção tardia permite que o comprometimento se espalhe por milhões de sites.
Anatomia do ataque Polyfill.io
Como funcionava o Polyfill.io
O Polyfill.io era um CDN legítimo. Ele detectava o navegador do visitante e devolvia só os polyfills que aquele navegador precisava, o que economizava código e resolvia compatibilidade sem trabalho do desenvolvedor. Milhões de sites apontavam para ele. Essa base instalada é exatamente o que fez do domínio um alvo: comprar um único endereço dava acesso a todos eles de uma vez.
A aquisição maliciosa
Em fevereiro de 2024, o domínio cdn.polyfill.io foi comprado por uma entidade com intenção maliciosa. Os novos donos não mudaram nada de imediato. O serviço continuou entregando os mesmos scripts, na mesma velocidade, e quem monitorava disponibilidade não viu diferença. O código malicioso entrou depois, misturado ao código legítimo.
A entrega era seletiva. Só parte dos visitantes recebia o redirecionamento, escolhida por geolocalização, tipo de dispositivo e horário de acesso. Um scanner rodando de um datacenter em horário comercial recebia a versão limpa. Foi assim que o comprometimento atravessou meses antes de alguém publicar.
O impacto global
Mais de 100.000 sites carregavam o script, entre bancos, e-commerces, portais de governo e sistemas de saúde. Milhões de visitantes passaram por essas páginas no período, e cada um recebeu o que o cdn.polyfill.io decidiu mandar naquele momento. Olhando a página, nenhum deles tinha como saber que a origem do script havia trocado de mãos meses antes.
Técnicas de ataque utilizadas
Os scripts maliciosos vinham ofuscados e misturados ao código legítimo, o que derrubava a análise estática e a maior parte das ferramentas automatizadas. O redirecionamento só disparava para uma fração dos visitantes, filtrada por geolocalização, dispositivo e horário.
As páginas de phishing copiavam o site legítimo campo a campo. As credenciais digitadas iam para servidores dos atacantes, e cookies e armazenamento local eram manipulados para reinfectar o visitante na visita seguinte, o que fazia a limpeza parcial não resolver.
O caso Polyfill.io expõe várias falhas críticas na forma como organizações gerenciam sua superfície de ataque e dependências externas.
Falta de inventário de dependências
A falha mais comum também é a mais simples: a organização não sabe o que carrega. Biblioteca de terceiro entra no projeto sem registro, CDN externo é adicionado direto no template, versão não é fixada, e o fornecedor do serviço nunca chega a virar linha em lista nenhuma. Dá para discutir controle depois. Antes disso, ninguém protege o que não sabe que existe.
Ausência de monitoramento contínuo
Mesmo onde a dependência foi documentada uma vez, ninguém volta para olhar. Domínio crítico troca de dono e não há alerta. O script servido muda de conteúdo e ninguém compara o hash. Uma aplicação começa a falar com um domínio que nunca falou antes e o tráfego passa. Foram meses de janela aberta no caso do polyfill.io, e a janela não era técnica. Era de processo.
Confiança implícita
Serviço popular vira sinônimo de serviço seguro. CDN que existe há dez anos entra sem revisão, biblioteca com milhões de downloads entra sem revisão, e reputação passada é tratada como garantia futura. O polyfill.io tinha exatamente essa reputação em janeiro de 2024. Em fevereiro, tinha outro dono.
Tempo de resposta lento
Quando a história veio a público, parte das organizações tirou o script no mesmo dia. Outras levaram semanas, porque primeiro precisaram descobrir em quais aplicações a tag estava. Sem plano escrito, o tempo de resposta vira o tempo que se leva para achar quem sabe responder, e a comunicação com o cliente atrasa junto.
Como o Attack Surface Management previne ataques à supply chain
O Attack Surface Management (ASM) ataca essas quatro falhas na ordem em que elas aparecem: descobrir o que existe, vigiar o que muda, decidir o que importa, responder.
Uma plataforma de ASM mapeia sozinha o que a organização carrega de fora: CDNs, bibliotecas de terceiros, versões em uso e as integrações que algum time subiu sem passar por segurança. No caso do polyfill.io, esse inventário responderia em segundos à pergunta que travou todo mundo por semanas: quais dos nossos sites carregam cdn.polyfill.io?
Monitoramento de mudanças
Inventário sozinho envelhece. O ASM observa o que muda nele. Troca de titularidade em WHOIS e DNS de um domínio que a sua aplicação carrega. Hash do script servido que deixou de bater com o da semana passada. Comportamento novo em um JavaScript que antes só lia o DOM e agora abre conexão para fora. Qualquer um desses três sinais teria aparecido no caso polyfill.io, e o primeiro deles apareceu quatro meses antes de o ataque virar notícia.
Análise de comportamento de scripts
Parte das ferramentas vai além de comparar hash e executa o script em sandbox para ver o que ele faz: redirecionamento que ninguém pediu, leitura de campo de formulário, chamada para domínio fora da lista conhecida. Essa camada pega o polyfill.io comprometido mesmo se a troca de dono tivesse passado batido.
Priorização baseada em risco
Dependência não é tudo igual. Um script na página de login do internet banking e o mesmo script na página institucional têm risco técnico idêntico e impactos que não se comparam. A ordem de trabalho sai de quatro perguntas: quantos usuários passam por ali, que dado circula naquela tela, quão fácil é explorar aquilo, o que quebra se a dependência sair do ar. É o que permite a um time pequeno tratar primeiro o que dói.
Resposta rápida e coordenada
Com o inventário pronto, a resposta muda de natureza. A lista de ativos afetados sai na hora, o bloqueio da dependência comprometida pode ser aplicado por política em vez de chamado a chamado, e a comunicação com cliente e regulador sai com número em vez de estimativa. A diferença entre remediar em um dia e remediar em três semanas quase nunca está na correção. Está em saber onde aplicar.
Validação contínua de fornecedores
Avaliação de fornecedor costuma ser um questionário respondido uma vez, na contratação. O ASM troca isso por verificação que roda sozinha: reputação do domínio do terceiro em feeds de inteligência de ameaças, histórico de incidentes, certificação que venceu e ninguém renovou. Confiança reavaliada toda semana é coisa diferente de confiança assinada em 2019.
Lições aprendidas do caso Polyfill.io
Para organizações
Duas coisas mudam o resultado, e nenhuma delas é comprar ferramenta. A primeira é ter a lista do que suas aplicações carregam de fora, mantida por descoberta automática e não por planilha. A segunda é tratar essa lista como coisa viva: alguém precisa ser avisado quando um item dela muda de dono, de hash ou de comportamento.
O resto é defesa em profundidade, e aqui o específico vale mais que o princípio. Content Security Policy restritivo limita de onde o navegador aceita script. Subresource Integrity trava o hash do arquivo carregado, o que resolve para script de conteúdo fixo e não resolve para CDN que monta a resposta por navegador. Ensaie o plano de resposta em mesa uma vez por ano, porque o dia do incidente não é o dia de descobrir quem tem acesso ao DNS.
Para a indústria
Do lado da indústria, o buraco é de aviso. Quando um domínio que milhões de sites carregam muda de dono, não existe canal que avise esses sites. A transferência é uma operação comercial privada e o comprador não deve satisfação a quem depende do serviço. Enquanto isso não mudar, cada organização descobre sozinha.
O que dá para fazer hoje é mais modesto e já ajuda: publicar indicador de comprometimento cedo, mesmo com a análise pela metade, e documentar as TTPs do ataque em vez de só anunciar que houve um.
Implementando proteção contra ataques à supply chain
Passo 1: inventário completo
Levante o que entra na página vindo de fora: biblioteca JavaScript de terceiro em produção, CDN, API externa, SaaS conectado, plugin instalado. Feito à mão, esse levantamento nasce desatualizado. Precisa vir de descoberta contínua.
Passo 2: controles técnicos
O CSP diz de onde o navegador pode carregar script. Configurado de verdade, ele derruba o domínio que apareceu do nada:
Content-Security-Policy:
default-src 'self';
script-src 'self' https://trusted-cdn.com;
connect-src 'self' https://api.trusted.com;
O SRI fixa o hash do arquivo. Se o conteúdo mudar um byte, o navegador recusa carregar:
<script src="https://cdn.example.com/lib.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
crossorigin="anonymous"></script>
Passo 3: monitoramento contínuo
Compare o hash de script externo a cada execução. Alerte domínio novo sendo contatado pela aplicação. Bloqueie e registre tentativa de envio de dado de formulário para fora da lista conhecida. É pouca coisa e cobre a maior parte do que aconteceu no caso polyfill.io.
Passo 4: processos de validação
Dependência nova entra com aprovação e revisão de segurança. Dependência velha é revista em calendário, não quando dá problema. Versão sobe com teste. Dependência que ninguém usa mais sai, e essa última costuma ser a mais fácil e a mais esquecida.
Passo 5: plano de resposta
Escreva o procedimento antes: como confirmar o comprometimento, quem isola a dependência, quem fala com o cliente, quem fala com o regulador. Teste em simulado. Plano nunca ensaiado leva quase o mesmo tempo que plano nenhum.
O papel do ASM na prevenção
O caso Polyfill.io não expôs uma técnica nova. Expôs que a maior parte das organizações não sabia responder qual código de terceiro rodava nas próprias páginas. Sem essa resposta, o resto do programa de segurança opera no escuro.
O ASM entrega essa resposta e a mantém atualizada. A parte de descobrir ativos é a que aparece nas demonstrações. A parte que muda o dia a dia do time é a segunda: saber, na semana em que muda, o que mudou.
Conclusão
Com 40% dos ataques à cadeia de suprimentos passando mais de 6 meses sem detecção e 75% das organizações já tendo sofrido ataque na cadeia de suprimentos de software, planejar para o caso de ser atingido deixou de ser exercício de pessimismo. Virou previsão de calendário.
O que ainda dá para controlar é o tempo entre o comprometimento e a descoberta. Esse tempo depende de uma coisa que a maioria das empresas não tem: a lista atualizada do que suas aplicações carregam de fora, e alguém avisado quando essa lista muda. Se você não sabe montar essa lista hoje, comece por aí.
Referências
- PaloAlto Networks - Supply Chain Attacks Frequency and Severity Stats
- Resilience Forward - 75% of Software Supply Chains Exposed to Cyber Attacks
- MITRE ATT&CK Framework - Supply Chain Compromise (T1195)
- NIST Cybersecurity Framework - Supply Chain Risk Management
- OWASP Top 10 - Using Components with Known Vulnerabilities