O programador abriu um link que tinha aparecido num canal de Discord onde os colegas falavam de uma nova ferramenta de build. Não carregou em nada, não escreveu nada, não descarregou nada. A página não renderizava como devia, apareceu qualquer coisa sobre uma font desatualizada. Cinco minutos depois, o portátil assinalava atividade de processos invulgar. Nas poucas centenas de milissegundos de renderização, a página já tinha explorado um bug de memória no renderer de WebGL.
Os drive-by downloads são a categoria de ataque mais discreta do browser. Não exigem qualquer interação. A vítima abre a página e o exploit já está a correr. O que no início dos anos 2000 passava por controlos ActiveX explora hoje bugs em motores JavaScript, em WebGL, em WebAssembly e nos codecs de media. Os browsers modernos são mais robustos, mas a superfície de ataque cresceu bastante.
Porque não é preciso nenhum clique
O browser não é um simples renderer de páginas. É um runtime completo: cada página carregada pode executar JavaScript, enviar gráficos para a tua GPU, descodificar streams de vídeo e correr binários de WebAssembly localmente. Tudo isso arranca automaticamente assim que o HTML chega ao parser.
Um drive-by download mete-se exatamente nessa pipeline. Um bug no motor JavaScript que deixa um índice de array sair dos seus limites, uma race condition numa API Canvas, uma frame de vídeo malformada que dispara um overflow de memória: são todos pontos de entrada. O browser corre o código do exploit porque faz parte do conteúdo da página, não porque tenhas autorizado seja o que for.
A sandbox do browser apanha muitíssimas tentativas. Os verdadeiramente perigosos são os exploits encadeados: um bug do motor JavaScript dá acesso arbitrário à memória, um segundo bug sai da sandbox, um terceiro eleva privilégios para nível de sistema. Estas cadeias saem caras aos atacantes, mas acabam por aparecer em campanhas em grande escala.
Onde batem os exploits modernos
JIT de JavaScript. Motores modernos como o V8 e o SpiderMonkey compilam em tempo de execução as funções mais usadas em código máquina. Bugs no compilador JIT produzem código errado que o browser corre com privilégios totais. A maior parte dos bugs de browser explorados nos últimos anos sai desta camada.
WebGL e WebGPU. Os shaders chegam à tua GPU sem filtragem. Os drivers gráficos arrastam um longo historial de bugs, e os exploits de WebGL são uma via comprovada para sair da sandbox do browser.
Descodificação de media. Os codecs de vídeo e áudio processam espaços de entrada enormes em C ou C++. Uma corrupção de memória num codec traduz-se muitas vezes em execução de código direta. O famoso exploit BLASTPASS de 2023 contra o iMessage atacava um parser de imagens, mas a mesma classe de problemas existe no browser.
WebAssembly e Web Workers. Threads paralelas com modelo de memória próprio são práticas e também mais uma superfície onde acabam por ser explorados bugs de memória.
Como a página chega ao teu ecrã
As páginas drive-by não surgem do nada, são distribuídas. Os três canais dominantes são o malvertising, os watering hole attacks e os sites legítimos comprometidos.
O malvertising é o canal mais barato. A página preparada vive dentro do iframe de um banner publicitário e atinge qualquer pessoa que carregue a página anfitriã. Mais sobre o tema em Malvertising: When the Ad Is the Attack. Os watering hole attacks são mais dirigidos: o atacante compromete um site que sabe ser visitado com frequência pelo público-alvo (um meio do setor, uma documentação para programadores, um fórum da comunidade) e implanta ali o exploit.
A terceira variante são os sites legítimos diretamente comprometidos. Um plugin de WordPress pirateado, uma conta de CDN roubada ou um build hook manipulado chegam para injetar scripts num site de confiança. Para os visitantes, não há forma de notar a diferença.
A janela entre o patch e o rollout
O Chrome, o Firefox e o Safari corrigem falhas críticas em poucos dias. Mas os updates só chegam até ti quando o browser os transfere e reinicia. Em desktop costuma demorar 24 horas, em Android às vezes semanas, e em ambientes enterprise geridos pode estender-se até um mês, consoante a janela de rollout.
Os atacantes conhecem esta janela ao pormenor. Esperam pelo dia da disclosure, fazem o diff ao patch para isolar a verdadeira alteração e montam um exploit em poucas horas. Durante um período curto mas muito lucrativo, o público fica vulnerável de forma assumida. Mesmo num ambiente bem gerido, ficas exposto durante essas horas.
Os updates automáticos ajudam, mas não chega. Um browser que não reinicia há cinco dias continua a correr a build antiga, ainda que o patch tenha sido transferido há muito.
Conter, não evitar
Não consegues evitar os drive-by downloads de forma fiável e continuar a usar a web. A ideia de que os sites de confiança são seguros não se aguenta, porque as redes de publicidade, os supply chain attacks e os zero-days atingem até os mais fiáveis. O foco muda de evitar para conter.
Uma sessão de browser isolada continua a levar o exploit a sério, mas faz com que caia num ambiente que não é o teu sistema operativo. O payload aterra num container que é descartado quando acabas. O teu portátil fica limpo. Junta a isto uma cadência rápida de updates no browser do dia a dia e a ideia de que os links desconhecidos não têm de abrir na máquina de produção, e o teu risco real cai bastante. Mais contexto sobre o ciclo zero-day em Zero-Day Exploits.
Pronto para teres um desktop completo em qualquer dispositivo?
Experimenta o Browser.lol grátis e sente a produtividade de um PC a partir do telemóvel.
Abrir o meu navegador desktopSem instalações • Funciona em qualquer dispositivo
