Vulnerabilidade zero-day: o que é e como responder

Vulnerabilidade, exploit e ataque zero-day

Os três termos são muitas vezes usados indistintamente, mas descrevem coisas diferentes:

Vulnerabilidade zero-day: a própria falha, desconhecida do fornecedor ou sem correção.
Exploit zero-day: o código ou a técnica que tira partido da falha.
Ataque zero-day: o exploit usado contra alvos reais.

Quando o fornecedor distribui uma correção, a falha deixa de ser um zero-day e passa a ser uma vulnerabilidade conhecida, muitas vezes chamada n-day. Isso dá início a uma segunda corrida: os atacantes estudam o patch e procuram sistemas que não o aplicaram, pelo que uma vulnerabilidade conhecida sem patch pode causar tantos danos como o zero-day original.

Zero-days nas suas dependências

A maior parte do código de uma aplicação moderna vem de pacotes open source, e a maioria destes são dependências transitivas: trazidas por outros pacotes, em vez de escolhidas pela sua equipa. Um zero-day em qualquer uma delas é um zero-day no seu produto.

O Log4Shell (CVE-2021-44228) é o exemplo mais conhecido. Divulgado em dezembro de 2021, permitia a um atacante que controlasse uma mensagem registada executar código arbitrário através do Apache Log4j 2, e obteve a pontuação CVSS máxima de 10.0. Para a maioria das equipas, a parte difícil não foi a correção. Foi a pergunta anterior: quais das nossas aplicações contêm log4j-core, e em que versões? O Log4j era normalmente uma dependência de uma dependência, e muitas equipas passaram dias a descobri-lo.

Os zero-days na cadeia de abastecimento nem sempre são bugs. Em março de 2024, Andres Freund encontrou uma backdoor nas versões 5.6.0 e 5.6.1 do xz (CVE-2024-3094) depois de reparar que os logins SSH estavam a usar demasiada CPU. As versões maliciosas de pacotes, um tipo comum de ataque à cadeia de abastecimento, funcionam da mesma forma: as primeiras equipas a instalar uma versão infetada, como as atingidas pelo worm npm Shai-Hulud, enfrentam um ataque que nenhum aviso de segurança ou scanner ainda conhece.

Como responder quando um zero-day atinge uma dependência

Descubra onde está. Enumere todas as aplicações, imagens e versões que contêm o componente afetado, incluindo como dependência transitiva. Isto exige uma SBOM exata de cada build. Um lockfile não apanha dependências obtidas fora do gestor de pacotes, como código descarregado por scripts de instalação ou as camadas do sistema operativo de uma imagem de contentor.
Apure o período de exposição. Que builds distribuíram a versão vulnerável, e desde quando? Isso indica-lhe o que investigar e o que reportar.
Contenha-o. Aplique a correção ou uma solução alternativa quando existir e impeça que novos builds distribuam a versão vulnerável assim que esta tiver uma CVE. Consulte remediação de CVE.
Verifique se houve exploração. Procure sinais de que a falha foi usada contra si durante o período de exposição e faça a rotação de todos os segredos a que possa ter chegado.

Estamos afetados? explica em detalhe os dois primeiros passos.

É possível defender-se de um zero-day que ninguém conhece?

Não com patches nem com scanners, porque ambos dependem de a falha ser conhecida. O que funciona antes da divulgação é limitar o que um atacante pode fazer com uma falha que encontre:

Privilégio mínimo. Dê a cada sistema e a cada job de CI apenas os acessos e segredos de que precisa.
Controlo de egress. Bloqueie as ligações de saída para hosts de que um sistema não precisa, para que um exploit em execução não consiga enviar dados ao atacante. Num build de CI, este é um dos poucos controlos que funcionam mesmo que seja a primeira vítima de um novo pacote malicioso. Consulte políticas de egress para GitHub Actions.
Defesa em profundidade. Sobreponha controlos para que uma falha não abra tudo.
Registos que possa pesquisar mais tarde. Quando o zero-day é divulgado, a rapidez da sua resposta depende de saber o que construiu e distribuiu.

Como o CRACI ajuda

O CRACI executa os seus jobs de GitHub Actions em runners próprios e regista cada build à medida que acontece:

As SBOM registadas durante o build enumeram os pacotes que cada job realmente obteve, incluindo as dependências ocultas que as ferramentas baseadas em lockfiles não apanham, para que possa responder a "onde está?" a partir do que foi realmente construído. Consulte SBOM durante o build.
O histórico de builds mostra todos os builds anteriores e a respetiva SBOM, e que builds continham uma dependência vulnerável, direta ou transitiva, para que saiba durante que período esteve afetado.
Os policy gates podem bloquear um build que contenha uma CVE específica, para que um novo build não volte a distribuir a versão vulnerável.
Uma política de egress de negação por predefinição bloqueia as ligações a hosts de que o build não precisa, mesmo durante um ataque que ninguém viu antes.

Vulnerabilidades zero-day: perguntas frequentes

O que é uma vulnerabilidade zero-day?

Uma falha de segurança que os atacantes conhecem, ou já estão a explorar, antes de o fornecedor ou o responsável pela manutenção ter lançado uma correção. O nome conta os dias que os defensores tiveram para a corrigir: zero.

Qual é a diferença entre vulnerabilidade, exploit e ataque zero-day?

A vulnerabilidade é a falha. O exploit é o código ou a técnica que tira partido dela. O ataque é o exploit usado contra alvos reais.

Quando é que um zero-day deixa de ser um zero-day?

Quando existe uma correção disponível. A partir daí é uma vulnerabilidade conhecida, por vezes chamada n-day, e o risco passa para os sistemas que ainda não aplicaram a correção.

Um scanner consegue detetar um zero-day?

Não por consulta. Os scanners de vulnerabilidades comparam componentes com avisos de segurança publicados, e um zero-day ainda não tem nenhum. O que um scanner ou uma SBOM lhe dá é o inventário a pesquisar no momento em que o aviso surge.

Como descubro se um zero-day afeta o meu software?

Pesquise o componente e as versões afetados num inventário exato do que cada build e versão contém, incluindo dependências transitivas. Depois, apure que versões o distribuíram e desde quando, para conhecer o período de exposição.