Você deve estar se perguntando: Mais uma versão do Log4j? Pois é caro(a) padawan (ou Jedi), esta já é a terceira versão disponibilizada em menos de duas semanas para corrigir as vulnerabilidades encontradas (que não foram corrigidas corretamente nas versões anteriores do Log4j lançadas).

Vamos situar você neste emaranhado de informações. Gostaria de apresentar uma linha do tempo para as versões do Log4j lançadas para corrigir as vulnerabilidades que foram descobertas.

VersãoCVEVulnerabilidadeQual a proteção?Deficiência
2.15.0CVE-2021-44228 Execução remota de código (RCE) e vazamento de dados (exfiltration)Restringe as pesquisas via JNDI e desabilita o suporte para padrões de consulta (Message Lookup Substitution).Falta de controle nos dados de entrada ocasiona negação de serviço (DoS). A proteção não funciona em determinadas configurações.
2.16.0CVE-2021-45046Negação de serviçoDesabilita a funcionalidade JNDI por padrão e remove o suporte para padrões de consulta.A proteção não funciona em determinadas configurações.
2.17.0CVE-2021-45105Negação de serviço (DoS)Protege contra a recursividade de dados de entrada, impedindo assim a ocorrência da negação de serviço (DoS)Nenhuma até o momento
Tabela com o resumo das correções lançadas para o Log4j

Veja agora os detalhes:

1 ) Log4j 2.15 (CVE-2021-44228)

A primeira vulnerabilidade, catalogada na CVE-2021-44228 foi manchete na semana passada, conforme também noticiamos, após o pesquisador de segurança chinês p0rz9 ter divulgado uma prova de conceito (PoC) para explorá-la. É uma vulnerabilidade crítica de execução remota de código (RCE), um 0-day que afeta a biblioteca de registros Java Apache Log4j.

Após a divulgação da prova de conceito, pesquisadores da Microsoft relataram que cibercriminosos patrocinados pelo governo chinês, pelo Irã, a Coreia do Norte e a Turquia têm tirado proveito da vulnerabilidade Log4Shell em suas campanhas. Entre os grupos que exploram a vulnerabilidade podemos citar o Hafnium, ligado à China e o Phosphorus, ligado ao Irã. O primeiro está usando a falha para atacar a infraestrutura de virtualização e o último para implantar ransomware.

A Apache Software Foundation (ASF), entidade que mantêm o Log4j, lançou rapidamente uma correção (a versão 2.15.0), mas que acabou corrigindo parcialmente a vulnerabilidade em certas configurações não-padrão. Um atacante com controle sobre os dados de entrada Thread Context Map (MDC), quando a configuração de registro (log) usa um padrão (pattern) de layout não-padrão com uma pesquisa de contexto (por exemplo, $${ctx:loginId}) ou um padrão Thread Context Map (%X, %mdc, ou %MDC), poderá entrar com dados maliciosos usando um padrão de pesquisa JNDI que aciona uma condição de negação de serviço (DoS).

2) Log4j 2.16 (CVE-2021-45046)

Ambos os problemas foram resolvidos com o lançamento da versão 2.16.0 do Log4j, que corrigiu a vulnerabilidade ao remover o suporte para os padrões de pesquisa de mensagens e desativando a funcionalidade JNDI por padrão.

Seguindo os passos da CVE-2021-44228, uma segunda CVE para o Log4j foi registrada, a CVE-2021-45046. As regras que lançamos anteriormente para a CVE-2021-44228 fornecem o mesmo nível de proteção para a nova CVE”, afirma a Cloudflare. “Esta vulnerabilidade está sendo explorada ativamente e qualquer pessoa que use o Log4j deve atualizar para a versão 2.16.0 o mais rápido possível, mesmo que você já tenha atualizado para 2.15.0. A versão mais recente pode ser encontrada na página de download do Log4j”.

3) Log4j 2.17 (CVE-2021-45105)

Mas as más notícias não terminaram, porque os pesquisadores da empresa de segurança Praetorian alertaram sobre uma terceira vulnerabilidade de segurança, decorrente do Log4j 2.15.0, que havia sido lançado para corrigir a vulnerabilidade inicial do Log4Shell.

Esta terceira vulnerabilidade pode ser explorada por invasores para realizar o vazamento de dados (exfiltration) confidenciais em certas circunstâncias.

No entanto, em nossa pesquisa, demonstramos que a versão 2.15.0 ainda pode permitir o vazamento de dados em certas circunstâncias. Passamos os detalhes técnicos do problema para a Apache Foundation, mas nesse meio tempo, recomendamos fortemente que os clientes atualizem para a versão 2.16.0 o mais rápido possível”, recomenda o post publicado pela Praetorian.

A Apache Software Foundation (ASF) foi forçada a lançar uma terceira versão em uma semana (versão 2.17.0) para corrigir uma vulnerabilidade de negação de serviço (DoS) de gravidade Alta no Log4j 2.16.0, criando assim mais uma CVE, a CVE-2021-45105.

A CVE-2021-45046, da versão 2.16.0 inicialmente tinha sido classificada como gravidade Baixa (pontuação 3,7), mas na sexta-feira foi “promovida” para gravidade crítica (9,0) pela Apache Software Foundation porque os especialistas encontraram uma nova maneira de burlar a segunda correção (2.16.0), lançado pela entidade.

A vulnerabilidade registrada na CVE-2021-45105 recebeu uma pontuação CVSS de 7,5 (Alta), decorrente de uma vulnerabilidade de negação de serviço que impacta o Log4j 2.16.0. Os especialistas apontaram que, mesmo que as pesquisas JNDI fossem desabilitadas na versão 2.16.0, as pesquisas autorreferenciais continuavam a ser uma possibilidade em certas circunstâncias.

As versões 2.0-alpha1 até a 2.16.0 (excluindo a 2.12.3) não protegem contra a recursão sem controle de pesquisas autorreferenciais. Isso permite que um invasor com controle sobre os dados do Thread Context Map cause uma negação de serviço (DoS) quando determinada string criada é interpretada. Este problema foi corrigido no Log4j 2.17.0 e 2.12.3”, diz o comunicado publicado pela ASF.

A Apache Software Foundation (ASF) corrigiu a falha registrada na CVE-2021-45105 com o lançamento do log4j versão 2.17.0 (para Java 8).

Conclusão

É um assunto complicado pessoal. Sinto uma enorme insegurança, pois muitas empresas usam o Log4j em suas aplicações web Java e os mantenedores que acabam deixando algo assim tão grave sem correção durante anos?? WTF?

Olha a data das versões do Log4j citadas neste e em outros posts e quanto tempo as empresas têm ficado vulneráveis:

Versões do Log4j citadas, quando foram lançadas e quanto tempo as empresas estão vulneráveis

Clique neste link para conferir a data de lançamento das versões antigas do Log4j.

De qualquer forma, recomendamos que as empresas atualizem suas bibliotecas Log4j para a versão 2.17.0. Além disso, acompanhem os boletins de segurança dos fabricantes de suas soluções ou de qualquer empresa que forneça alguma aplicação via SaaS (Software como serviço) para saber se eles também estão tomando alguma ação corretiva.

Aguarde as cenas para os próximos capítulos.

Referências:

https://securityaffairs.co/wordpress/125760/hacking/log4j-third-flaw.html

Página de download das últimas versões do Log4j:

https://logging.apache.org/log4j/2.x/download.html

Para se informar melhor sobre a(s) vulnerabilidade(s) no Log4j:

Log4Shell: A vulnerabilidade que coloca em risco aplicações web Java

Log4Shell: Antigo ransomware é usado em ataques ao Log4j [!!!]

Link para conferir a data de lançamento das versões antigas do Log4j:

https://archive.apache.org/dist/logging/log4j/

Créditos da imagem de fundo usada na capa do post:

https://www.tln.nl/thema-cybersecurity/

O que achou?

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