Log4Shell – Dois Meses Mais Tarde

Passados dois meses, e agora que a poeira abaixou, tanto na temporada de férias quanto na vulnerabilidade do Log4j (que viu muitos de nós trabalhando nela), faz sentido olhar para trás e fazer um balanço de como as coisas aconteceram. Quais estratégias funcionaram diante de uma das vulnerabilidades mais notáveis ​​da última década?

Se você não está por dentro de tudo o que aconteceu em relação ao Log4Shell, leia a postagem em nosso blog, escrita em tempo real durante o incidente que afetou servidores em todo o mundo e foi declarado como um dos piores em mais de 10 anos.

Um Breve Resumo do Incidente

Para começar, vamos examinar brevemente a questão em si. O Log4j é um utilitário de log Java utilizado por, praticamente, todos os produtos, ferramentas e serviços baseados em Java na Internet. Se você já viu uma página de erro em um site ou digitou incorretamente suas credenciais, é provável que tenha gerado um evento processado pelo Log4j em algum momento. A injeção de uma string especificamente criada em um evento processado pelo Log4j faria com que o Log4j consultasse uma URL externa arbitrária e a carregasse como um objeto Java. Um invasor pode usar essa vulnerabilidade (chamada Log4Shell) para forçar uma vítima a baixar, instalar e executar cargas maliciosas hospedadas externamente com relativa facilidade.

Como foi Descoberto?

No final de Novembro, pesquisadores relataram a descoberta de uma falha no Apache Log4j, ferramenta presente em uma infinidade de sistemas, que permite execução remota de código e tem nível de gravidade CVSS 10 de 10, forçando especialistas em segurança cibernética a corrigir sistemas imediatamente para impedir o uso desta vulnerabilidade por hackers. Na terça-feira, dia 14 de Dezembro, a vulnerabilidade CVE-2021-44228 foi complementada pela CVE-2021-45046, informando que a cobertura da solução inicialmente proposta para a falha no Apache Log4j 2.15.0 era incompleta em determinados ambientes fora do padrão e, no dia 18 de Dezembro, as duas foram complementadas pelo CVE-2021-45105, após a descoberta de uma brecha que possibilitaria um ataque do tipo DDoS (Distributed Denial of Service).

Apenas 12 horas após a descoberta da existência da primeira vulnerabilidade, foi divulgado que ela já havia sido “totalmente armada”, o que significa que malfeitores experientes rapidamente desenvolveram e distribuíram ferramentas para explorá-la em ataques do tipo “Zero-Day Exploit”, entre outros.

Com inúmeros invasores explorando ativamente estas vulnerabilidades, a Apache Foundation recomendou que todos os desenvolvedores e usuários do Java 8 ou posterior atualizassem suas bibliotecas para a versão 2.16.0. e que, se isso não for possível, que utilizem um dos métodos descritos na página Apache Log4j Security Vulnerabilities.

Como Evitar

Uma vez que a falha tenha sido identificada, torna-se mais fácil, para os administradores de sistemas, a organização dos passos a seguir para realizar as correções necessárias. Empresas como Microsoft já divulgaram guias de prevenção e mitigação de falhas ligadas à vulnerabilidade presente no Loj4j mas, apesar de soluções para a vulnerabilidade já terem sido divulgadas, a Apache afirma que será necessário um certo tempo para localizar o programa defeituoso e implementar as soluções em todos os sistemas afetados.

Detecção de Vulnerabilidades com o GAT Security Score

Diversas vulnerabilidades identificadas (CVEs), inclusive as que permitem ataques como o “Log4Shell”, podem ser identificadas gratuitamente utilizando o crédito do primeiro acesso ao GAT Security Score. A plataforma coleta dados disponíveis publicamente na Internet (de forma não intrusiva) para dar uma perspectiva externa da postura de Segurança da Informação nas empresas, entregando um resumo daquilo que um agente malicioso teria visão, e eventual acesso, a partir da Internet pública. Os dados são classificados em diferentes fatores de risco que, juntos, formam a base para o cálculo da pontuação de segurança. O processo é simples, automático e intuitivo:

1. Preencha o formulário com seus dados
2. Confira a mensagem que enviaremos em sua caixa de entrada e confirme o cadastro no sistema
3. Aguarde enquanto nossos algoritmos calculam o score de segurança de seu domínio
4. Verifique os apontamentos identificados no snapshot

Boa Gestão de Ativos Cibernéticos

Há algumas práticas comuns em organizações que sentiram que haviam se preparado ou respondido ao Log4Shell de forma eficaz. As organizações com sistemas de gestão de ativos abrangentes e atualizados acharam mais fácil identificar sistemas vulneráveis ​​rapidamente, avaliar o potencial “raio de explosão” de uma exploração bem-sucedida e quantificar seu risco geral. Elas também acharam mais fácil aplicar patches de emergência, quarentena ou medidas de monitoramento em hosts vulneráveis.

Algumas ferramentas de varredura da superfície de vulnerabilidade, tal como o GAT Security Score, foram capazes de alertar analistas e administradores de rede antes que o estrago fosse feito. Enquanto milhares de requisições rodavam pela Internet em busca de servidores com a vulnerabilidade exposta, poucas ferramentas eram capazes de detectá-la em tempo hábil e informar os gestores de que uma atualização deveria ser executada o quanto antes.

Compreender a Cadeia de Fornecimento de Software

Com um bom entendimento de suas bibliotecas, dependências e cadeia de fornecimento de software, as organizações podem identificar rapidamente códigos de terceiros vulneráveis ao Log4Shell. Essa visibilidade aprimorada em sua base de código permitiu que relatassem a vulnerabilidade para mantenedores de código e parceiros.

Log Centralizado

No caso do Log4Shell, o log centralizado é, reconhecidamente, uma faca de dois gumes. Por um lado, ter logs de eventos enviados para fora do host fornece uma medida de garantia de que um invasor astuto não poderia remover os sinais indicadores de uma exploração bem-sucedida antes que um analista do SOC. Por outro lado, o registro centralizado, inevitavelmente, fornece uma superfície de ataque mais ampla para ataques baseados em registro, tais como o Log4Shell.

No geral, porém, ter um local central para armazenar e visualizar os logs de todos os dispositivos potencialmente afetados melhorou, significativamente, a velocidade e a facilidade de resposta a incidentes, fazendo com que o aumento da superfície de ataque valesse o risco.

Inteligência Sólida sobre Ameaças

As tentativas de explorar o Log4Shell foram (inicialmente, ao menos) facilmente detectáveis ​​por automações e analistas. A capacidade de adquirir e distribuir rapidamente indicadores de comprometimento (IOCs) foi vital nos dias após o anúncio da vulnerabilidade. À medida em que os invasores se tornaram mais sofisticados, implantando vários métodos de ofuscação de código, o compartilhamento rápido de novos IOCs tornou-se ainda mais crítico. As organizações que promoveram e mantiveram a inteligência de ameaças se destacaram em relação à velocidade de reação e eficácia, frente às outras organizações afetadas.

Pesquisar e Alertar

O registro centralizado e a boa inteligência contra ameaças não seriam nada sem as ferramentas e o treinamento corretos para aproveitá-los. As organizações que implantaram soluções EDR/NDR/SIEM, juntamente com uma equipe bem treinada no console, estavam bem posicionadas para detectar e automatizar a detecção das tentativas de explorar o Log4Shell.

Filtragem de Rede

Apesar dos efeitos de longo alcance do Log4Shell, a mitigação da vulnerabilidade foi surpreendentemente fácil e acessível para aqueles preparados adequadamente. A técnica mais simples para garantir que um invasor não consiga explorar a vulnerabilidade foi bloquear o tráfego HTTPS ou LDAP que deixa a rede.

Bloquear a solicitação de saída não resolve a causa raiz do problema, mas impede que invasores instalem cargas maliciosas em hosts vulneráveis. A filtragem de rede de saída, quando configurada corretamente, tem o bônus de registrar a exploração, ajudando a orientar os analistas de SOC na resposta de incidentes nos sistemas afetados.

Políticas Restritivas de DNS

O contato com hosts externos mal-intencionados é um pré-requisito para um ataque Log4Shell bem-sucedido. Ao restringir a resolução de nomes de rede a recursos exclusivamente internos, as organizações podem bloquear algumas (mas não todas) tentativas de baixar cargas maliciosas.

Este é um método rápido, barato e surpreendentemente eficaz de tornar as coisas mais difíceis para os invasores. Mesmo assim, esta técnica defensiva pode ser subvertida pelo invasor utilizando endereços IP ou hospedando o objeto Java malicioso em recursos internos já comprometidos.

Conclusão

O Log4Shell foi um excelente (embora aterrorizante) estudo de caso no valor da “defesa em profundidade”. A sobreposição de várias estratégias de detecção e mitigação menos que perfeitas em toda a rede totalizou um todo maior que a soma de suas partes.

As organizações que gastaram tempo e esforço para entender sua infraestrutura antecipadamente, por meio do gerenciamento de ativos e registro centralizado, estavam melhor posicionadas para reagir de forma rápida e abrangente a uma vulnerabilidade nova e nunca vista.

A capacidade de adquirir e distribuir rapidamente indicadores de comprometimento dentro da organização, com pares externos à organização e, em alguns casos, até concorrentes, foi vital para permitir uma resposta global rápida e abrangente.

Nem todo problema requer uma nova solução. A boa “observação” combinada com algumas mudanças diretas nos sistemas existentes, como firewalls externos e servidores de nomes, muitas vezes deram às equipes de SOCs a cobertura necessária para corrigir os sistemas de forma calma e metódica (ao invés de passar noites em pânico, arrancando os cabelos).

O Log4Shell afetou todos nós até certo ponto, mas as organizações que tiveram seus ativos organizados antes que a vulnerabilidade fosse anunciada puderam mitigá-la de forma rápida, abrangente e metódica.