Log4j é uma estrutura de registro desenvolvida pela Apache Software Foundation. Como o nome sugere, Log4J é um registrador. Registra informações importantes, como mensagens de erro e entradas de usuário em um programa.

Log4J é uma biblioteca de software de código aberto, um pacote de código pré-escrito que os desenvolvedores podem usar livremente. Em vez de escrever seus próprios loggers, os desenvolvedores podem conectar a biblioteca Log4J em seus aplicativos. Essa conveniência é a razão pela qual Log4J é tão difundido, embutido em produtos de grandes organizações como Microsoft e Amazon, para citar alguns.

Log4Shell—Identificador de vulnerabilidade e exposição comum (CVE), CVE-2021-44228—é uma vulnerabilidade de execução remota de código (RCE) presente em algumas versões do Log4J. A falha afeta o Apache Log4J 2, versões 2,14,1 e anteriores. Log4J 2,15 e posterior, e todas as versões do Apache Log4J 1, não são afetadas.

O Log4Shell surge de como versões mais antigas do Log4J 2 lidam com pesquisas de Java Naming e Interface de Diretório (JNDI). O JNDI é uma interface de programação de aplicativos (API) que os aplicativos Java usam para acessar recursos hospedados em servidores externos. Uma pesquisa JNDI é um comando que diz ao aplicativo para ir a um servidor e baixar um objeto específico, como um pedaço de dados ou um script. Versões mais antigas do Log4J 2 executam automaticamente qualquer código baixado dessa maneira. 

Os utilizadores podem enviar procuras JNDI para versões vulneráveis do Log4J ao incluí-las em mensagens de registo.Fazer isso é simples. Por exemplo, em versões mais antigas do Minecraft Java Edition, que utilizam o Log4J para registrar mensagens de usuário, um usuário pode digitar a pesquisa JNDI na janela de chat público.

Hackers podem usar essa funcionalidade JNDI para executar códigos maliciosos arbitrários remotamente. Primeiro, o hacker configura um servidor que usa um protocolo comum, como Lightweight Directory Access Protocol (LDAP) para evitar chamar a atenção. Em seguida, eles armazenam uma carga maliciosa nesse servidor, como um arquivo de malware. Finalmente, enviam uma consulta JNDI para um programa, dizendo-lhe para acessar o servidor LDAP do atacante, baixar a carga e executar o código.

Os pesquisadores de segurança da gigante da tecnologia Alibaba descobriram a Log4Shell em 24 de novembro de 2021. Ele recebeu imediatamente a pontuação mais alta possível do Common Vulnerability Scoring System (CVSS): 10 de 10. Alguns fatores contribuíram para essa classificação.

• Log4Shell foi uma vulnerabilidade de dia zero, o que significa que não havia um patch disponível quando foi descoberta. Os agentes de ameaça podem usar o Log4Shell enquanto o Apache está trabalhando em uma correção.
  
  
• Log4J é também uma das bibliotecas de registro mais amplamente usadas, embutida em endpoints de consumidores, aplicativos web e serviços de nuvem empresarial. De acordo com Wiz e EY, 93% de todos os ambientes de nuvem estavam em risco quando Log4Shell foi descoberto.
  
  
• As empresas nem sempre podem dizer imediatamente se são vulneráveis. O Log4J frequentemente está presente em redes como uma dependência indireta, o que significa que os ativos da empresa podem não utilizar o Log4J, mas dependem de outras aplicações e serviços que o fazem.
  
  
• Finalmente, Log4Shell é fácil de usar. Hackers não precisam de permissões especiais ou autenticação. Eles podem causar estragos digitando comandos maliciosos em formulários públicos como caixas de bate-papo e páginas de login. E como Log4J pode se comunicar com outros serviços no mesmo sistema, os hackers podem usar Log4J para passar cargas maliciosas para outras partes do sistema.

Em 9 de dezembro de 2021, um código de prova de conceito sobre como usar Log4Shell foi postado no GitHub, e hackers começaram a montar ataques. Grandes empresas e serviços como Minecraft, Twitter e Cisco foram expostos. No auge da atividade do Log4Shell, a Check Point observou mais de 100 ataques por minuto, afetando mais de 40% de todas as redes empresariais globalmente.

Os primeiros ataques espalharam malwares de botnets e criptomineração. Alguns hackers usaram a falha para iniciar ataques sem arquivos, enviando scripts maliciosos para computadores Windows e Linux para fazer com que divulguem senhas e outras informações sensíveis.

Várias gangues de ransomware apreendidas no Log4Shell. Notavelmente, hackers espalharam a tensão do ransomware Khonsari através do Minecraft. O ransomware Night Sky teve como alvo sistemas executando VMware Horizon.

Até mesmo atores estatais participaram. Hackers associados à China, Irã, Coreia do Norte e Turquia foram vistos usando a vulnerabilidade.

O Apache lançou a primeira correção (Log4J versão 2,15,0) em 10 de dezembro de 2021. No entanto, essa correção deixou outra vulnerabilidade exposta, a CVE-2021-45046, que permitiu que hackers enviassem comandos maliciosos para logs com determinadas configurações não padrão.

A Apache lançou um segundo patch (Log4J versão 2.16.0) em 14 de dezembro de 2021. Ele também tinha uma falha—CVE-2021-45105—que permitia que hackers iniciassem ataques de denial-of-service (DoS).

A terceira correção, Log4J versão 2,17, corrigiu a falha da DoS, mas deixou uma vulnerabilidade final (CVE-2021-44832), que permitiu que hackers aproveitassem o controle de um componente Log4J chamado "aplicador" para executar o código remoto. Apache abordou isso com umm quarta e última correção, Log4J versão 2,17,1. 

Embora o Log4J 2.17.1 tenha fechado o Log4Shell e todas as suas vulnerabilidades relacionadas no lado da Apache, ameaças cibernéticas ainda usam a falha. Até maio de 2023, o Log4Shell permaneceu uma das vulnerabilidades mais comumente usadas.

Log4Shell persiste por vários motivos.

Um dos principais problemas é que o Log4J está profundamente enraizado nas cadeias de suprimento de software de muitas empresas. Hoje, muitos aplicativos são desenvolvidos montando bibliotecas de software de código aberto preexistentes. Esse processo é conveniente, mas também significa que as organizações têm visibilidade limitada sobre todos os componentes que compõem seus aplicativos. Versões antigas do Log4J podem ser facilmente esquecidas.

Quando uma versão vulnerável do Log4J é corrigida, ela nem sempre permanece corrigida. Em novembro de 2022, a Tenable relatou que 29% dos ativos ainda vulneráveis ao Log4Shell eram "recorrências". Eles foram corrigidos no passado, mas a falha reapareceu. Esse cenário acontece porque quando as pessoas constroem ou atualizam aplicativos, às vezes usam acidentalmente bibliotecas de software que ainda contêm versões não corrigidas do Log4J.

Finalmente, os hackers desenvolveram uma maneira astuta de cobrir seus rastros. De acordo com a CISA, alguns hackers usam o Log4Shell para invadir uma rede e, em seguida, corrigem o ativo. A empresa acha que é seguro, mas os hackers já estão dentro.

As versões mais recentes do Log4J são gratuitas do Log4Shell. Especialistas em segurança cibernética sugerem que as equipes de segurança priorizem a verificação de que todas as instâncias do Log4J em seus sistemas estejam atualizadas.

A atualização do Log4J pode ser um processo lento, pois muitas vezes as empresas precisam se aprofundar em seus ativos para encontrá-lo. Enquanto isso, as equipes de segurança podem usar ferramentas contínuas de verificação de vulnerabilidades e detecção de ameaças, como gerenciamento de superfície de ataque (ASM) e plataformas de detecção e resposta de endpoint (EDR) para monitorar ativos voltados para a Internet. Os especialistas recomendam que as equipes de resposta a incidentes investiguem minuciosamente qualquer indício de atividade do Log4Shell.

Depois que o Log4Shell ficou público, muitos firewalls, sistemas de detecção de intrusão (IDSs) e sistemas de prevenção de intrusão (IPSs) adicionaram regras para detectar a exploração do Log4Shell. Essas ferramentas podem ajudar as equipes de segurança a detectar e bloquear o tráfego de servidores controlados por invasores. 

• 18 de julho de 2013: o Apache lança Log4J 2,0-beta9, a primeira versão para suportar o plug-in JNDI. Embora a vulnerabilidade não seja descoberta até anos depois, Log4Shell está presente a partir deste momento.

• 24 de novembro de 2021: os pesquisadores de segurança da Alibaba descobrem o Log4Shell e relatam ao Apache. O Apache começa a trabalhar em uma correção, mas não libera um aviso de segurança pública.

• 9 de dezembro de 2021: pesquisadores de segurança da Alibaba encontram evidências de que Log4Shell está sendo discutido na natureza, e o código de prova de exploração do conceito é publicado no GitHub.

• 10 de dezembro de 2021: o Apache emite a primeira correção, e os desenvolvedores do Minecraft descobrem Log4Shell no Minecraft Java Edition. A comunidade de segurança cibernética percebe rapidamente a gravidade da situação, e as organizações começam a se esforçar para bloquear seus sistemas.

• 11 de dezembro de 2021: A Cloudflare encontra evidências de que os agentes de ameaças começaram a explorar o Log4Shell mais cedo do que se pensava — já em 1º de dezembro.

• 14 de dezembro de 2021: o CVE-2021-45046 foi descoberto e o Apache lança uma correção para resolvê-lo.

• 17 de dezembro de 2021: o CVE-2021-45105 foi descoberto e o Apache lança uma correção para resolvê-lo.

• 28 de dezembro de 2021: CVE-2021-44832 é descoberto e o Apache lança uma correção final. Do Log4J versão 2.17.1 em diante, o Log4Shell foi totalmente corrigido.

• 4 de janeiro de 2022: A Comissão Federal de Comércio dos EUA (FTC) anuncia que pretende processar qualquer empresa que exponha dados de consumidores a hackers por não ter corrigido a vulnerabilidade Log4Shell.

• 2023 de maio: o ponto de verificação descobre que o Log4Shell ainda é a segunda vulnerabilidade mais explorada.