Como as vulnerabilidades de segurança mais antigas continuam a representar uma ameaça

Falhas de segurança que datam de mais de 10 anos ainda existem e ainda representam o risco de serem exploradas livremente, diz Rezilion.

A correção de vulnerabilidades de segurança deve ser um processo direto. Um fornecedor emite um patch para uma falha conhecida e todas as organizações afetadas aplicam esse patch. Mas, o que parece simples na teoria não necessariamente funciona assim na realidade. Um relatório divulgado na segunda-feira, 8 de agosto, pela empresa de segurança Rezilion analisa como as vulnerabilidades mais antigas corrigidas pelo fornecedor ainda representam riscos para as organizações.

O cenário de ameaças abrange uma década de vulnerabilidades conhecidas

Para seu relatório Vintage Vulnerabilities Are Still In Style, a Rezilion examinou o Catálogo de Vulnerabilidades Exploradas Conhecidas mantido pela CISA (Agência de Segurança Cibernética e Infraestrutura) (Figura A). Entre as 790 falhas de segurança da lista, mais de 400 são anteriores a 2020. Cerca de 104 são de 2019, 70 de 2018 e 73 de 2017. Cerca de 17 remontam a 2010.

Figura A

As vulnerabilidades descobertas de 2010 a 2020 afetam mais de 4,5 milhões de sistemas e dispositivos voltados para a Internet.

O gerenciamento ineficaz de patches para vulnerabilidades antigas deixa as empresas abertas a ataques

Embora as correções estejam disponíveis para essas “vulnerabilidades vintage” há anos, muitas delas permanecem sem correção por clientes e organizações. Como tal, eles ainda podem ser explorados livremente, criando um risco para software e dispositivos que não foram atualizados. Na verdade, a Rezilion detectou tentativas ativas de varredura e exploração para a maioria dessas falhas de segurança nos últimos 30 dias.

CONSULTE: Política de segurança de dispositivos móveis (TechRepublic )

Esse problema está no ciclo de vida de uma vulnerabilidade de segurança. No início, uma falha de segurança que existe em um produto é potencialmente explorável, pois ainda não existe um patch, embora ninguém possa estar ciente disso. Se os criminosos cibernéticos souberem da falha, ela será classificada como uma vulnerabilidade de dia zero. Depois que o fornecedor emite e implanta um patch, a vulnerabilidade ainda pode ser explorada, mas apenas em ambientes onde o patch ainda não foi aplicado.

No entanto, as equipes de TI e segurança precisam estar cientes dos patches disponíveis de um fornecedor, determinar quais patches priorizar e implementar um sistema para testar e instalar esses patches. Sem um método de gerenciamento de patches organizado e eficaz, todo esse processo pode tropeçar facilmente em qualquer ponto. Criminosos cibernéticos experientes percebem tudo isso, e é por isso que continuam explorando falhas que foram corrigidas há muito tempo pelo fornecedor.

Vulnerabilidades vintage comumente exploradas

Aqui estão apenas algumas das muitas falhas de segurança antigas descobertas pela Rezilion:

CVE-2012-1823

PHP CGI Remote Code Execution é uma vulnerabilidade de validação que permite que invasores remotos executem código colocando opções de linha de comando em uma string de consulta PHP. Conhecida por ser explorada na natureza, essa falha existe há 10 anos.

CVE-2014-0160

A vulnerabilidade de vazamento de informações confidenciais do OpenSSL da memória do processo (HeartBleed) afeta a extensão Heartbeat para o TLS (Transport Layer Security). No OpenSSL 1.0.1 a 1.0.1f, esse bug pode vazar conteúdo de memória do servidor para o cliente e vice-versa, permitindo que qualquer pessoa na Internet leia esse conteúdo usando versões vulneráveis ​​do software OpenSSL. Explorado na natureza, este foi tornado público em abril de 2014.

CVE-2015-1635

A vulnerabilidade de execução remota de código do Microsoft HTTP.sys é uma falha no módulo de processamento do protocolo HTTP (HTTP.sys) no Microsoft Internet Information Service (IIS) que pode permitir que um invasor execute código remotamente enviando uma solicitação HTTP especial para um sistema Windows vulnerável . Explorado na natureza, esse bug está ativo há mais de sete anos.

CVE-2018-13379

Fortinet FortiOS e FortiProxy é uma falha no portal da web FortiProxy SSL VPN que pode permitir que um invasor remoto baixe arquivos do sistema FortiProxy por meio de solicitações especiais de recursos HTTP. Explorada na natureza, essa vulnerabilidade existe há mais de quatro anos.

CVE-2018-7600

A vulnerabilidade de execução remota de código do Drupal (Drupalgeddon2) é uma falha de execução remota de código que afeta várias versões diferentes do Drupal. Esse bug pode ser usado por um invasor para forçar um servidor executando o Drupal a executar código malicioso que pode comprometer a instalação. Explorado na natureza, este está ativo há mais de quatro anos.

Dicas para gerenciar patches de vulnerabilidade de segurança

Para ajudar as organizações a gerenciar melhor a correção de vulnerabilidades de segurança, a Rezilion oferece vários conselhos.

Esteja ciente das superfícies de ataque

Certifique-se de poder ver sua superfície de ataque existente por meio dos CVEs associados e de identificar os ativos vulneráveis ​​em seu ambiente que exigem correção. Para isso, você deve ter uma Lista de Materiais de Software (SBOM), que é um inventário de todos os componentes de código aberto e de terceiros nos aplicativos que você usa.

Faça backup do gerenciamento de patches com os processos de e corretos

Para dar e a uma estratégia eficaz de gerenciamento de patches, determinados processos devem estar em vigor, incluindo controle de alterações, testes e garantia de qualidade, todos os quais podem ser responsáveis ​​por possíveis problemas de compatibilidade.

Certifique-se de que os esforços de gerenciamento de vulnerabilidades e patches possam ser dimensionados

Depois que um processo de gerenciamento de patches estiver em vigor, você precisará expandi-lo facilmente. Isso significa dimensionar os esforços de correção à medida que mais vulnerabilidades são descobertas.

Priorize as vulnerabilidades mais críticas

Dado o grande número de falhas de segurança descobertas, você não pode corrigir todas elas. Em vez disso, concentre-se nos patches mais importantes. A priorização por métricas como CVSS por si só pode não ser suficiente. Em vez disso, busque uma abordagem baseada em risco por meio da qual você identifique e priorize vulnerabilidades de alto risco em vez de bugs menores. Para fazer isso, examine quais falhas estão sendo exploradas em estado selvagem consultando o Catálogo de Vulnerabilidades Exploradas Conhecidas da CISA ou outras fontes de inteligência de ameaças. Em seguida, determine quais vulnerabilidades existem em seu ambiente.

Monitore e avalie continuamente a estratégia de gerenciamento de patches

Monitore seu ambiente para garantir que as vulnerabilidades permaneçam corrigidas e os patches permaneçam em vigor. Em alguns casos, a Rezilion encontrou instâncias em que o código vulnerável que já foi corrigido foi adicionado de volta aos ambientes de produção por processos de CI/CD (integração contínua e implantação contínua).