A vulnerabilidade Log4j, ou “Log4Shell”, é considerada um dos defeitos de software mais catastróficos já registrados. A Apache corrigiu a falha em dezembro de 2021, mas ela ainda é uma preocupação para as equipes de segurança. De fato, ainda está entre as vulnerabilidades de segurança mais exploradas.
O Log4Shell persiste porque o pacote de software Apache Log4J 2 que ela afeta é uma das bibliotecas de registro mais usadas do mundo. Encontrar e corrigir todas as instâncias do Log4Shell deve levar uma década, de acordo com o US Department of Homeland Security.
Enquanto isso, as equipes de segurança podem tomar algumas medidas para acelerar a mitigação e remediação do Log4Shell em suas redes.
Junte-se aos líderes de segurança que confiam no boletim informativo Think para receber notícias selecionadas sobre IA, cibersegurança, dados e automação. Aprenda rápido com tutoriais e explicações de especialistas, entregues diretamente em sua caixa de entrada. Consulte a Declaração de privacidade da IBM.
Antes de nos aprofundarmos em como detectar e corrigir o Log4Shell, é importante entender a natureza da vulnerabilidade.
O Log4j é um logger de código aberto (mantido pela Apache Software Foundation) que registra informações e eventos em um programa. O Log4j não é um software independente, mas um pacote de código que os desenvolvedores podem conectar a seus próprios aplicativos Java. O framework Apache Log4j é usado em alguns dos maiores serviços da web, desde infraestruturas de rede, como Amazon Web Services (AWS) e soluções Cisco até aplicativos populares, como Twitter e Minecraft.
Algumas versões do Log4j (especificamente, Log4j 2.17.0 e inferior) sofrem de vulnerabilidades graves. A mais perigosa delas é o Log4Shell (CVE-2021-44228; classificação CVSS: 10), uma vulnerabilidade de dia zero de execução remota de código (RCE) encontrada no Log4j versões 2.14.1 e anteriores.
O Log4Shell é um resultado de como as versões vulneráveis do Log4j lidam com o Java Naming and Directory Interface (JNDI), uma API que os aplicativos Java usam para acessar recursos hospedados em servidores externos. Os agentes de ameaças podem assumir o controle quase total de sistemas vulneráveis enviando comandos maliciosos de pesquisa JNDI por meio do Log4j. Esses comandos enganam o aplicativo em executar código arbitrário que pode fazer quase qualquer coisa: roubar dados, instalar ransomware, colocar dispositivos offline e muito mais.
Um ataque cibernético típico do Log4Shell funciona assim:
Enquanto o Apache trabalhava para corrigir o Log4Shell, os pesquisadores de segurança identificaram um punhado de falhas relacionadas em algumas versões do Log4j. Elas incluem:
Encontrar todas as instâncias vulneráveis do Log4j em uma rede pode ser difícil. O Log4j aparece em cerca de milhões de aplicativos, o que significa que as equipes de segurança têm muitos ativos para inspecionar.
Além disso, o Log4j está frequentemente presente como uma dependência indireta. Isso significa que ele não está diretamente contido no código-fonte de um ativo, mas aparece como uma dependência de um pacote de software ou integração da qual o ativo depende. O Google relata que as instâncias do Log4j mais vulneráveis são mais de um nível de profundidade na cadeia de dependências, e algumas são de até nove níveis de profundidade.
Dito isso, as equipes de segurança podem detectar vulnerabilidades do Log4j com as táticas e ferramentas certas.
Todas as versões do Log4j 2, da 2.0-beta9 à 2.17, são vulneráveis ao Log4Shell ou a uma falha relacionada. Em outras palavras, as equipes de segurança devem encontrar e lidar com qualquer versão do Log4j inferior à 2.17.1.
O Log4Shell e suas falhas relacionadas estão presentes apenas nos arquivos "Log4j-core", que fornecem a funcionalidade central do Log4j. As falhas não estão presentes nos arquivos "Log4j-api", que controlam a interface entre aplicativos e loggers do Log4j.
O Log4j pode aparecer em ativos que a empresa controla, ativos de terceiros que a empresa utiliza (por exemplo, serviços de nuvem) e ativos usados por provedores de serviços com acesso à rede da empresa. Embora haja maior probabilidade de o Log4j aparecer em aplicativos baseados em Java, ele também pode estar presente em aplicativos não Java por meio de dependências e integrações.
Dentro de aplicativos Java, bibliotecas como o Log4j são frequentemente empacotadas em arquivos Java Archive ou "arquivos JAR." Arquivos JAR podem conter outros arquivos JAR, que por sua vez podem conter seus próprios arquivos JAR e assim por diante. Para encontrar todas as versões vulneráveis do Log4j, as equipes de segurança devem inspecionar todos os níveis de arquivos JAR, não apenas os arquivos de nível superior.
Os especialistas recomendam o uso de uma combinação de técnicas para encontrar vulnerabilidades do Log4j.
Pesquisas manuais. As equipes de segurança podem procurar manualmente por falhas do Log4j. Elas podem usar ferramentas de desenvolvimento como o Apache Maven para gerar árvores de dependência que mapeiam todas as dependências em um aplicativo, ou podem usar inteligência de ameaças externa para identificar os ativos afetados. Por exemplo, a Cybersecurity and Infrastructure Security Agency (CISA) compilou uma lista de softwares que sofrem com o Log4Shell. A lista está disponível no GitHub .
Nos sistemas operacionais Linux, Microsoft Windows e macOS, as equipes de segurança podem procurar diretórios de arquivos por instâncias do Log4j usando a interface de linha de comando.
Ferramentas de verificação de vulnerabilidades. Após a descoberta do Log4Shell, algumas organizações lançaram ferramentas gratuitas projetadas para encontrar vulnerabilidades do Log4j. Como exemplos, temoso Log4j-sniffer do Palantir o o scanner do CERT Coordination Center, entre muitos outros.
Embora scanners especializados ainda estejam disponíveis, muitas soluções de segurança padrão, como scanners de vulnerabilidade, plataformas de gerenciamento de superfície de ataque (ASM) e soluções de detecção e resposta de endpoint (EDR) agora podem detectar vulnerabilidades Log4j.
Como o Log4Shell pode se esconder profundamente em cadeias de dependência, as equipes de segurança podem complementar varreduras automatizadas com métodos mais práticos, como testes de penetração.
Caça a ameaças. De acordo com a CISA, sabe-se que os invasores usam o Log4Shell para invadir uma rede e, em seguida, corrigir o ativo que comprometeram para cobrir seus rastros. Por esse motivo, é recomendável que as equipes de segurança assumam que uma violação já ocorreu e procurem ativamente sinais de invasão do Log4Shell.
Ferramentas de cibersegurança, como soluções de gerenciamento de eventos e informações de segurança(SIEM) e plataformas de detecção e resposta estendidas (XDR) , podem ajudar a detectar atividades anormais associadas ao Log4Shell, como entradas de registro estranhas ou padrões de tráfego suspeitos. As equipes de segurança devem lançar procedimentos completos de resposta a incidentes e investigação para qualquer possível indício do Log4Shell, dada a seriedade das consequências de um ataque.
As equipes de segurança têm algumas opções ao lidar com as vulnerabilidades Log4j.
Para a remediação completa do Log4Shell e falhas relacionadas, as organizações devem atualizar todas as instâncias do Log4j em suas redes para a versão mais recente (ou pelo menos para a versão 2.17.1). As versões mais recentes do Log4j removem as funções que os invasores podem explorar e removem a compatibilidade com protocolos comumente abusados, como o LDAP.
Não há uma correção única para todo o sistema disponível, e a atualização do Java em si não lida com o problema. As equipes de segurança devem atualizar todas as instâncias do Log4j em todos os ativos afetados.
Os pesquisadores de segurança concordam que a aplicação de patches é a solução ideal. Se a correção não for viável, as organizações podem usar outras etapas de mitigação para minimizar as chances de um ataque.
Desativar a pesquisa de mensagens em aplicativos vulneráveis. Os invasores usam uma funcionalidade do Log4j chamada “substituições de pesquisa de mensagens” para enviar comandos maliciosos para aplicativos vulneráveis. As equipes de segurança podem desativar manualmente essa função alterando a propriedade do sistema “Log4j2.formatMsgNoLookups” para "true" ou definindo o valor da variável de ambiente "LOG4J_FORMAT_MSG_NO_LOOKUPS" como "true".
Embora a remoção da função de substituição de pesquisa de mensagens dificulte o ataque dos invasores, ela não é infalível. Agentes maliciosos ainda podem usar a CVE-2021-45046 para enviar pesquisas JNDI mal-intencionadas para aplicativos com configurações não padrão.
Remoção da classe JNDIlookup de aplicativos vulneráveis. No Log4j, a classe JNDIlookup controla como o logger lida com as pesquisas JNDI. Se essa classe for removida do diretório de classes do Log4j, as pesquisas JNDI não poderão mais ser executadas.
O Apache observa que o seguinte comando pode ser utilizado para remover a classe JNDIlookup de aplicativos vulneráveis:
zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class
Embora esse método seja mais eficaz do que a desativação das pesquisas de mensagens, ele não impede que os invasores montem outras tentativas de invasão, como os ataques de denial-of-service por meio de pesquisas recursivas.
Bloqueio de possível tráfego de ataque do Log4Shell. As equipes de segurança podem usar firewalls de aplicações da web (WAFs), sistemas de detecção e prevenção de intrusões (IDPS), EDRs e outras ferramentas de cibersegurança para interceptar o tráfego de e para servidores controlados por invasores, bloqueando protocolos comumente usados, como LDAP ou RMI. As equipes de segurança também podem lidar com os endereços IP associados a ataques ou strings que os invasores costumam usar em solicitações maliciosas, como "jndi", "ldap" e "rmi".
No entanto, os invasores podem contornar essas defesas usando novos protocolos e endereços IP ou ofuscando strings maliciosas.
Quarentena de ativos afetados. Se tudo mais falhar, as equipes de segurança podem colocar os ativos afetados em quarentena enquanto esperam por um patch. Uma maneira de fazer isso é colocar ativos vulneráveis em um segmento de rede isolado que não pode ser acessado diretamente da internet. Um WAF pode ser colocado em torno deste segmento de rede para proteção extra.
Uma das coisas complicadas sobre remediar o Log4Shell é que ele nem sempre permanece corrigido. Em novembro de 2022, a Tenable relatou que 29% dos ativos ainda vulneráveis ao Log4Shell eram "recorrências", o que significa que eles foram corrigidos, mas a falha reapareceu. As recorrências acontecem quando os desenvolvedores usam acidentalmente bibliotecas de software que contêm versões não corrigidas do Log4j para criar ou atualizar aplicativos.
Embora os desenvolvedores possam examinar os frameworks que usam mais de perto, é fácil perder versões vulneráveis do Log4j quando elas estão vários níveis profundos em arquivos JAR.
A implementação de programas formais de gerenciamento de vulnerabilidades e gerenciamento de patches pode oferecer às equipes de segurança uma maneira mais eficaz de monitorar os ativos em busca do retorno das vulnerabilidades do Log4j. A verificação regular de vulnerabilidades e os testes de penetração podem ajudar a detectar rapidamente novas vulnerabilidades, Log4Shell ou outros. O gerenciamento de patches garante que novas vulnerabilidades sejam fechadas assim que os fornecedores lançam as correções.