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.

O Log4J é uma biblioteca de software de código aberto, que consiste em um pacote de código pré-escrito que os desenvolvedores podem utilizar gratuitamente.Em vez de escrever seus próprios loggers, os desenvolvedores podem conectar a biblioteca Log4J em seus aplicativos. É por essa facilidade que o Log4J está tão amplamente utilizado, incorporado a produtos de grandes organizações como Microsoft e Amazon, para citar apenas algumas.

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.

Os hackers podem usar essa funcionalidade JNDI para executar códigos maliciosos e arbitrários remotamente. Primeiro, o hacker configura um servidor usando um protocolo comum, como o Lightweight Directory Access Protocol (LDAP), para evitar chamar a atenção. Em seguida, eles armazenam uma carga útil maliciosa nesse servidor, como um arquivo de malware. Por fim, eles enviam uma pesquisa JNDI para um programa, informando-o para acessar o servidor LDAP do invasor, baixar a carga útil 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 era uma vulnerabilidade de dia zero, o que significa que nenhuma correção estava disponível quando foi descoberto. Os atores de ameaças podem explorar o Log4Shell enquanto o Apache estava trabalhando em uma correção.
  
  
• O Log4J também é uma das bibliotecas de registro mais usadas, incorporada em endpoints do consumidor, aplicações web e serviços de nuvem empresarial.De acordo com a Wiz e a EY, 93% de todos os ambientes de nuvem estavam em risco (link externo ao site ibm.com) quando o 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, o Log4Shell é muito fácil de explorar. Os hackers não precisam de permissões ou autenticação especiais. Eles podem causar estragos digitando comandos maliciosos em formulários públicos, como caixas de chat e páginas de login. E como o Log4J pode se comunicar com outros serviços no mesmo sistema, os hackers podem usar o Log4J para enviar cargas úteis para outras partes do sistema.

Em 9 de dezembro de 2021, código de prova de conceito sobre como explorar o Log4Shell foi postado no GitHub, e hackers estavam realizando ataques.Grandes empresas e serviços como Minecraft, Twitter e Cisco foram expostos. No pico da atividade Log4Shell, o Check Point observou mais de 100 ataques a cada minuto, afetando mais de 40% de todas as redes de negócios em todo o mundo (link externo ao site ibm.com).

Os primeiros ataques espalharam malwares de botnets e criptomineração. Alguns hackers exploraram a vulnerabilidade para realizar ataques sem arquivo, enviando scripts maliciosos para computadores com Windows e Linux para extrair senhas e outras informações confidenciais.

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 estado-nação se juntaram. Hackers associados à China, Irã, Coreia do Norte e Turkiye foram vistos explorando 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.

O Apache lançou uma segunda correção (Log4J versão 2,16,0) em 14 de dezembro de 2021. Ele também teve uma falha (CVE-2021-45105), o que permitiu que hackers iniciassem ataques de negação de serviço (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. 

Apesar do Log4J 2.17.1 ter resolvido o Log4Shell e todas as suas vulnerabilidades relacionadas no âmbito da Apache, as ameaças cibernéticas ainda estão usando a falha.Recentemente, em maio de 2023, o Log4Shell permaneceu uma das vulnerabilidades mais comumente exploradas (link reside fora do ibm.com).

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.Atualmente, muitos aplicativos são desenvolvidos através da montagem de bibliotecas de software de código aberto preexistentes. Esse processo é conveniente, mas também significa que as organizações têm visibilidade limitada de todos os componentes que compõem seus aplicativos.É fácil perder versões antigas do Log4J.

Quando uma versão vulnerável do Log4J é corrigida, nem sempre permanece corrigida. Em novembro de 2022, a Tenable informou (link externo ao site ibm.com) que 29% dos ativos ainda vulneráveis ao Log4Shell eram “recorrências”. Eles foram apanhados no passado, mas a falha reapareceu. Esse cenário acontece porque, quando as pessoas criam ou atualizam aplicativos, às vezes usam acidentalmente bibliotecas de software que ainda contêm versões sem correções do Log4J.

Por fim, os hackers desenvolveram uma maneira inteligente de cobrir seus rastros. De acordo com a CISA (link externo ao site ibm.com), 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) (link externo ao site ibm.com) anuncia que pretende perseguir todas as empresas que exponham dados de consumidores a hackers porque não conseguiram abordar a Log4Shell.

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