Exploits zero-day: porque é que o teu browser é vulnerável

O que é realmente um zero-day

Imagina uma casa cuja porta das traseiras já não tem puxador. O dono não faz ideia. O serralheiro do bairro também não. Quem reparar primeiro no puxador em falta pode entrar e sair à vontade, noite após noite, sem que ninguém dê por nada, até que outra pessoa tropece por acaso na mesma porta. Um zero-day é exatamente essa porta. O «zero» refere-se ao número de dias que o fabricante teve para corrigir a falha: a vulnerabilidade é explorada antes mesmo de ser reconhecida.

Todos os grandes browsers têm o seu quinhão. O Chrome corrigiu dez zero-days só em 2024, o Firefox quatro, o Safari sete. O ritmo está a acelerar, não a abrandar, porque a superfície de ataque não para de crescer. Cada nova API (WebGL, WebAssembly, WebRTC, service workers) acrescenta complexidade e abre novas classes de bugs em que investigadores e atacantes podem mexer.

O que distingue os zero-days das vulnerabilidades comuns é precisamente o tipo de poder que entregam. Um atacante com um na mão pode chegar a qualquer pessoa, em qualquer sítio, sem ferramentas nem telemetria que a vítima possa razoavelmente detetar. Basta levar-te até uma página, e uma página prepara-se sem dificuldade.

O ciclo de vida de um zero-day

Todo o zero-day segue uma sequência previsível. Cada fase diz-te onde as tuas defesas funcionam e onde falham.

1. 1

   Descoberta

   Um investigador ou um atacante dá com o bug. As descobertas éticas são reportadas ao fabricante. O resto fica debaixo do tapete. Alguns zero-days ficam a dormir durante meses antes do primeiro uso real.
2. 2

   Armamento

   O exploit é construído. Raramente se trata de um único bug. A maior parte dos ataques modernos encadeia uma falha do renderer, um sandbox escape e uma escalada ao nível do kernel. Os atores estatais acumulam cadeias completas e guardam-nas para alvos de alto valor.
3. 3

   Exploração no terreno

   O exploit chega via anúncios maliciosos, sites comprometidos ou links de spear-phishing. Detetá-lo é difícil porque nada na entrega parece fora do comum e o antivírus não tem assinatura para fazer correspondência.
4. 4

   Patch e divulgação

   Assim que o abuso é detetado, o fabricante atira uma correção de urgência. Um advisory pede a toda a gente que atualize de imediato. A maioria dos utilizadores não atualiza durante dias ou semanas, e as empresas costumam demorar ainda mais.
5. 5

   Reutilização em exploit kits

   Os exploit kits de prateleira agarram na vulnerabilidade já corrigida e atiram-se à longa cauda de sistemas por atualizar durante meses. Os atacantes reembalam a cadeia para outros browsers ou combinam-na com bugs novos, esticando-lhe a vida útil.

Os utilizadores ficam expostos durante as fases dois e três, e bem dentro da fase quatro. Mesmo depois de instalares o patch, outros dispositivos da tua rede podem continuar atrás. O contenimento tem de estar a funcionar antes de o patch chegar, não depois.

As tuas janelas de exposição

Manter os browsers atualizados parece simples. Na prática, as empresas fazem malabarismos com dependências, revisões de compliance e janelas de deployment agendadas. Os utilizadores comuns despacham os avisos de atualização no meio das reuniões. O resultado é um conjunto de buracos previsíveis com os quais os atacantes contam à partida.

Antes do patch (de horas a semanas). O exploit está ativo e não há correção. Todos os browsers da internet estão vulneráveis. Os fabricantes ficam muitas vezes em silêncio enquanto investigam, o que dá mão livre aos atacantes sobre toda a base de utilizadores exposta.

Corrigido, mas não aplicado (7 a 30 dias). As equipas de IT testam compatibilidade, agendam rollouts e desenrascam reboots. Entretanto, os atacantes fazem engenharia inversa ao patch e montam exploit kits em massa. Assim que a correção se torna pública, a corrida acelera de forma drástica.

Cauda longa (sem prazo). Quiosques partilhados, sistemas legacy e máquinas pessoais ficam presos em versões antigas durante meses ou anos. Os atacantes continuam a explorá-los muito depois de os títulos dos jornais terem caído.

Atualizações em pausa. Por vezes, as equipas congelam as atualizações por causa de bugs, problemas de compatibilidade ou janelas de change freeze de fim de trimestre. O próprio congelamento torna-se um alvo. Estes buracos existem mesmo em ambientes bem geridos, e é precisamente por isso que o isolamento importa: os utilizadores continuam a trabalhar enquanto os patches são testados, porque o código não fiável nunca chega à máquina local.

Zero-days em números

Alguns números ajudam a perceber a escala. São dados reais da indústria publicados nos últimos dois anos.

A distância entre «patch disponível» e «patch instalado» é onde se concentra a maior parte dos estragos. O Verizon Data Breach Investigations Report mostra que, em mais de metade dos casos, os atacantes exploram as vulnerabilidades publicadas no espaço de um dia após o lançamento, enquanto a maior parte das empresas precisa de duas semanas inteiras para distribuir as atualizações em condições. É uma corrida impossível de ganhar se a tua única defesa for o patching.

Incidentes recentes que moldaram o guião

É tentador tratar os zero-days como raios isolados. A realidade é mais um ruído de fundo constante. Bastam alguns exemplos recentes para ver o padrão.

Chrome CVE-2023-2033. Um bug de type-confusion no V8, explorado através de redes de publicidade maliciosa. A payload chegava a uma remote code execution sem qualquer interação do utilizador. A Google confirmou a exploração ativa dias antes de haver patch disponível.

Firefox CVE-2024-29902. Usada numa campanha de spear-phishing de duas semanas contra ONG. A cadeia escapava da sandbox do browser e deixava spyware persistente em endpoints Windows antes mesmo de alguém reportar o incidente.

Safari WebKit CVE-2024-43817. Dirigida a utilizadores de iOS através de links no iMessage. A payload instalava software de vigilância sem qualquer ação do utilizador. A Apple lançou uma correção de emergência e os atacantes passaram meses a cair sobre dispositivos macOS por atualizar.

Chrome CVE-2025-1023. Escondida em portais fraudulentos de apoio ao cliente que pediam aos utilizadores para clicar em «Iniciar assistência remota». As empresas levaram cinco dias a distribuir o patch. Essa janela bastou para comprometer vários alvos de elevado valor nas áreas financeira e da saúde.

O fio condutor salta à vista assim que olhas com atenção: entrega pelo browser, armamento rápido e uma comunidade defensora sempre um passo atrás. Para uma visão mais ampla sobre como as sessões são sequestradas assim que o exploit entra, lê o nosso guia de proteção contra session hijacking.

Porque é que aplicar patches não chega

Mesmo um patching impecável deixa buracos. Os browsers modernos dependem de extensões, bibliotecas do sistema, configurações do utilizador e componentes ao nível do sistema operativo. Qualquer elo fraco mantém a porta aberta.

Extensões. Uma extensão comprometida ou maliciosa contorna por completo os patches do browser, injetando scripts em todas as páginas. O incidente QuickTranslate de 2025 afetou quatro milhões de utilizadores que tinham o browser em dia.

Políticas mal configuradas. As empresas que desativam o site isolation ou o split tunneling para apps legacy abrem brechas. Os zero-days exploram muitas vezes o atalho de configuração em vez de um bug no próprio browser.

Escalada de privilégios. Os exploits de browser encadeiam-se com frequência com bugs ao nível do sistema operativo. Um browser com o patch aplicado perde na mesma quando o kernel ou o driver gráfico por baixo são vulneráveis, e esse é o estado por defeito da maior parte dos desktops.

Atraso humano. Os patches obrigam a reboots, os utilizadores adiam para não perder trabalho e os atacantes ajustam as campanhas precisamente a esse momento. O isolamento não substitui o patching. Ganha tempo. Quando a sessão de browser vive num container cloud descartável, uma vulnerabilidade sem patch rebenta lá dentro e evapora quando a sessão acaba. Podes distribuir as atualizações a um ritmo saudável em vez de reagir em pânico.

O que te defende a sério

Cada equipa acha-se protegida só por ter os controlos do costume. Vamos ver como é que as defesas habituais se comportam mesmo contra um zero-day a sério.

O isolamento na cloud é a única linha que aguenta no dia zero. Todas as outras dependem de saber o que procurar e, por definição, isso não é possível com um zero-day. Um browser remoto descartável não precisa de assinatura nem de patch: o exploit corre dentro de um ambiente que vais deitar fora em minutos.

O padrão prático é simples. A navegação de alto risco (triagem de phishing, onboarding de fornecedores, threat research, revisão de faturas duvidosas) passa por uma sessão isolada que se autodestrói depois do uso. A navegação de rotina fica em local, por trás das camadas habituais de patching e filtros de reputação. Isolamento e patching não são alternativas, são os dois lados da mesma postura.

Conter o desconhecido primeiro, aplicar patches depois

Os zero-days não vão desaparecer. O ritmo sobe ano após ano e o canal de entrega fica cada vez mais afinado. Qualquer equipa que trate o patching como defesa principal aposta tudo em que os fabricantes sejam mais rápidos do que os atacantes, e essa aposta anda a perder há uma década.

A jogada estratégica é inverter a ordem. Conter primeiro, aplicar patches depois. Manda o tráfego arriscado por uma sessão que possas apagar, deixa os patches sair a um ritmo saudável, e os zero-days deixam de ser ameaças existenciais. Passam a ser incidentes: pequenos, contidos e resolvidos sem acordar ninguém às 3 da manhã.