Como se preparar hoje para as vulnerabilidades zero-day de amanhã

Como lidar com vulnerabilidades zero-day

No mundo da segurança de software, as condições podem — e muitas vezes vão — mudar de um dia para o outro. Hoje, suas aplicações e seus sistemas estão funcionando com segurança na nuvem. Amanhã, uma nova vulnerabilidade explorável vira notícia, e começa uma corrida contra o tempo para encontrar e corrigir esse componente vulnerável em todo o seu ambiente.

Vulnerabilidades zero-day — falhas de segurança recém-descobertas, muitas vezes sem outra solução além de “pare de usar por enquanto” — deixam as equipes de segurança em polvorosa como poucas coisas conseguem. Felizmente, as organizações podem tomar medidas proativas para se preparar para vulnerabilidades zero-day antes que elas apareçam (ou sejam descobertas).

Por que as vulnerabilidades zero-day representam um risco?

A maioria das aplicações atuais contém uma enorme rede de dependências e recursos externos. Uma única aplicação pode incluir dezenas de componentes de código aberto e partes de software de terceiros. Quando o público em geral descobre uma vulnerabilidade zero-day, as organizações que usam o componente vulnerável precisam localizá-lo e corrigi-lo o mais rápido possível. As organizações que não agirem a tempo podem ser vítimas de um ataque zero-day.

Quais são as consequências da exploração de uma vulnerabilidade zero-day?

A exploração bem-sucedida de uma vulnerabilidade zero-day pode ter consequências graves para as organizações, desde prejuízos financeiros até danos à reputação. Os invasores podem aproveitar essas vulnerabilidades para executar código remotamente, roubar dados confidenciais ou interromper operações comerciais críticas. Como as vulnerabilidades zero-day são desconhecidas até serem descobertas, medidas de segurança tradicionais, como firewalls e antivírus, muitas vezes não conseguem impedir a exploração. Por isso, detectar, mitigar e corrigir essas falhas rapidamente é essencial para minimizar o impacto de um ataque.

Ciclo de vida de uma vulnerabilidade zero-day

As vulnerabilidades zero-day são especialmente arriscadas porque surgem muito rápido, e seu ciclo de vida pode variar bastante, dependendo de quem as descobre. Elas podem ser desconhecidas quando você vai dormir e estar nas manchetes e nos fóruns quando acorda no dia seguinte. Veja uma possível cronologia de uma vulnerabilidade zero-day típica em uma biblioteca de código aberto (um fluxo semelhante também pode ocorrer em aplicações próprias):

• Um desenvolvedor escolhe uma biblioteca de código aberto. O código atualizado e a nova biblioteca são lançados em produção.

• Descoberta da vulnerabilidade. Nos dias, meses ou anos seguintes, pesquisadores de segurança (no melhor cenário) ou agentes mal-intencionados (no pior) encontram a vulnerabilidade. Os agentes mal-intencionados começam a explorá-la, enquanto os pesquisadores de segurança investigam como isso pode ser feito.

• Conhecimento da vulnerabilidade. Os mantenedores ficam sabendo da vulnerabilidade, mas ainda não têm uma correção.

• Divulgação da vulnerabilidade. O mantenedor da biblioteca vulnerável ou os pesquisadores de segurança que a identificaram divulgam informações sobre a vulnerabilidade aos clientes afetados ou ao público em geral.

• Correção da vulnerabilidade zero-day. O fornecedor lança soluções de correção, muitas vezes em atualizações pontuais (possivelmente mais de uma, dependendo de quantas versões foram afetadas pela vulnerabilidade). O prazo para lançar uma correção completa varia de algumas horas a alguns meses, conforme a complexidade.

• Implantação das correções pelos clientes. Por fim, cabe aos clientes afetados implantar as correções. Esse processo pode levar meses ou até anos, dependendo do tempo necessário para os usuários localizaram cada ocorrência do componente vulnerável e implantarem a correção.

• Tentativas contínuas de ataque. Mesmo muito tempo depois do lançamento de uma correção, agentes mal-intencionados continuam tentando explorar a vulnerabilidade, na esperança de encontrar algum sistema sem correção em operação. Por isso, as organizações devem sempre incluir análises de segurança regulares no processo de build e implantação.

Pode haver muitas etapas intermediárias e, dependendo de as equipes envolvidas seguirem ou não as práticas recomendadas de divulgação de vulnerabilidades, o impacto de uma determinada falha pode mudar bastante.

6 dicas para planejar e se preparar para vulnerabilidades zero-day

Vulnerabilidades zero-day surgem com frequência e deixam milhares de organizações sem saber como agir todos os anos. Em 2022, o Google registrou 41 vulnerabilidades zero-day em exploração. Portanto, não é uma questão de se, mas de quando sua organização vai enfrentar uma vulnerabilidade zero-day.

Como essas vulnerabilidades surgem com frequência, as organizações precisam se preparar proativamente. Em períodos sem emergências, as empresas podem tomar algumas medidas para estar prontas para agir e resolver ameaças zero-day quando uma emergência acontecer. Essas medidas incluem:

1. Adote uma mentalidade de segurança em primeiro lugar durante o desenvolvimento.

Uma mentalidade de segurança em primeiro lugar significa que os desenvolvedores corrigem as vulnerabilidades assim que elas surgem ao longo de todo o SDLC. Corrigir problemas de segurança assim que aparecem é muito mais eficiente do que esperar dias ou semanas para resolver uma longa lista de problemas que avançaram pelas etapas do desenvolvimento.

Uma mentalidade de segurança em primeiro lugar também permite que a equipe de segurança colabore melhor com os desenvolvedores, em vez de frustrá-los. Essa colaboração leva a uma cultura DevSecOps mais sólida. Quando as equipes de desenvolvimento e segurança já estão acostumadas a trabalhar juntas, conseguem resolver problemas com mais eficiência quando surge uma vulnerabilidade zero-day.

2. Estruture um processo de segurança sólido.

Processos de segurança de aplicações sólidos e que antecipam as verificações ao longo do desenvolvimento se concentram em encontrar e corrigir vulnerabilidades durante todo o SDLC, em vez de esperar o fim de cada grande etapa para fazer os testes. Por exemplo, algumas organizações realizam testes estáticos de segurança de aplicações (SAST) no código próprio sempre que um desenvolvedor cria uma solicitação de pull request.

Esses processos também incluem localizar todas as dependências de terceiros com a análise de composição de software (SCA) e manter um registro detalhado delas em uma lista de materiais de software (SBOM). Como os processos de desenvolvimento atuais são muito dinâmicos, muitas organizações usam ferramentas de automação para acompanhar continuamente suas dependências em tempo real.

Quando uma organização já adota processos de segurança sólidos no dia a dia, fica muito mais fácil localizar projetos que usam recursos de terceiros comprometidos por falhas zero-day e corrigi-los rapidamente.

3. Faça avaliações e auditorias de segurança regularmente.

Também é essencial que as organizações realizem avaliações e auditorias de segurança regularmente. Embora os detalhes dessas avaliações variem conforme o setor e outras necessidades da empresa, elas costumam incluir alguma forma destas cinco etapas:

• Determinar as possíveis ameaças

• Identificar dados confidenciais no ambiente

• Mapear a superfície de ataque

• Avaliar os pontos problemáticos dos processos

• Criar um roteiro para aprimorar o processo

Ao realizar essas etapas regularmente, uma organização pode garantir que seu programa de segurança esteja em ótima forma. As avaliações também ajudam a organização a manter um conhecimento aprofundado de sua postura de segurança atual. Esse conhecimento e essa preparação facilitam muito a prevenção da exploração de uma vulnerabilidade zero-day.

4. Promova a conscientização dos funcionários.

A conscientização dos funcionários também ajuda a prevenir vulnerabilidades zero-day. Um programa de treinamento eficaz ensina práticas de codificação segura aos desenvolvedores de forma interativa e envolvente. Uma das melhores maneiras de capacitar as equipes de desenvolvimento é oferecer orientações de correção junto com a análise de vulnerabilidades. Por exemplo, algumas ferramentas explicam por que cada vulnerabilidade representa um risco e como corrigi-la.

A capacitação prática em segurança ajuda os desenvolvedores a entender melhor o próprio código e seus possíveis riscos de segurança, tornando-os mais eficientes na resolução de vulnerabilidades zero-day quando elas surgem.

5. Crie seu próprio plano de ação.

Não espere a próxima vulnerabilidade zero-day para documentar seus processos. Crie planos de ação e listas de verificação para lidar com a próxima vulnerabilidade, incluindo quem envolver, como avaliar o impacto, quais inventários avaliar e como comunicar as descobertas e o impacto internamente (e externamente, se for o caso). Talvez o mais importante seja garantir que todos saibam onde encontrar esses planos. Antes da próxima vulnerabilidade crítica, comece a adotar ferramentas para acompanhar o código-fonte e o inventário de contêineres, assim você estará mais preparado.

6. Mantenha-se por dentro das últimas informações sobre segurança.

Sua organização também precisa escolher uma fonte para se manter atualizada sobre novas vulnerabilidades zero-day. Quando uma vulnerabilidade zero-day vira notícia, o tempo é precioso. Por isso, suas equipes devem se preparar para entender rapidamente onde concentrar os esforços de correção.

Com o apoio da Snyk Vulnerability Database (VulnDB), a Snyk fornece informações detalhadas sobre todas as vulnerabilidades em andamento e explica como resolvê-las — muitas vezes, com um clique. Quanto antes sua equipe tiver as informações certas para corrigir uma vulnerabilidade, mais rápido poderá mitigá-la ou aplicar uma correção.

Além disso, você pode acessar diretamente a VulnDB para conferir as vulnerabilidades em alta mais recentes:

Ataques zero-day recentes

Ao pensar em explorações zero-day recentes, o primeiro exemplo significativo que vem à mente é o Log4Shell: uma vulnerabilidade de execução remota de código no Log4j que afetava aplicações Java e recebeu uma classificação CVSS de 10 (a pontuação máxima possível). Essa vulnerabilidade afetou a maioria das grandes empresas, pois muitas usavam o Log4j em seus ambientes, frequentemente por meio de dependências indiretas.

Veja alguns outros exemplos recentes:

• CVE-2023-44487: vulnerabilidade zero-day de alta gravidade relacionada ao ataque de redefinição rápida do HTTP/2.

• CVE-2023-38545: estouro de buffer baseado em heap de alta gravidade no cURL.

• CVE-2023-4863: vulnerabilidade crítica que permite que agentes mal-intencionados explorem o Google Chrome com imagens WebP criadas com conteúdo malicioso.

• CVE-2022-3602 e CVE-2022-3786: duas vulnerabilidades de alta gravidade no OpenSSL relacionadas a estouro de buffer.

• CVE-2022-42889: vulnerabilidade de alta gravidade que permitia a execução de código arbitrário no Apache Commons Text.

• Spring4Shell: vulnerabilidade crítica de execução remota de código em Java no Spring Framework.

Todas as vulnerabilidades de alta ou crítica gravidade da lista acima, entre outras, surgiram em um período de 24 meses, mostrando a frequência com que falhas importantes vêm à tona. Em outras palavras, as equipes de segurança não podem ignorar esse problema.

Ferramentas AppSec da Snky para encontrar e corrigir vulnerabilidades zero-day

Com as ferramentas certas, as equipes conseguem responder às vulnerabilidades zero-day de forma colaborativa e eficiente. Soluções de segurança de aplicações como Snyk Code, Snyk Open Source e Snyk Container ajudam as equipes de desenvolvimento e segurança a encontrar e corrigir vulnerabilidades zero-day assim que elas são descobertas, enquanto o Snyk Insights ajuda sua organização a identificar e priorizar os principais riscos.

Além disso, nossa inteligência de segurança de ponta se mantém atualizada sobre as vulnerabilidades zero-day e outras ameaças mais recentes e usa essas informações para potencializar nossas soluções.

Saiba mais sobre nossas soluções AppSec que priorizam os desenvolvedores para corrigir problemas de segurança durante todo o SDLC e evitar ser vítima da próxima vulnerabilidade zero-day.