O mês de dezembro foi bastante conturbado para o cenário de segurança da informação. E essa “muvuca” tem nome: Log4j. Como falamos, o Log4j é apenas o sistema de gerenciamento de logs para aplicações web em Java mais usado no mundo.

No dia 28 de dezembro de 2021, a Apache Software Foundation (ASF), entidade que mantêm o Log4j, lançou a versão 2.17.1 para corrigir uma vulnerabilidade de execução remota de código (RCE), descoberta recentemente na versão 2.17.0, e catalogada na CVE-2021-44832.

Até então, a 2.17.0 era tida como a versão mais recente e considerada também a mais segura, mas parece que não é mais isso.

Já é a 5ª CVE em menos de um mês

A 5ª vulnerabilidade, uma falha de RCE, foi descoberta na versão 2.17.0. Rapidamente um patch foi aplicado na versão mais recente, a 2.17.1.

A vulnerabilidade possui uma pontuação CVSS de 6,6, considerada como moderada e é decorrente da falta de controles adicionais no acesso via JNDI no Log4j. “O JDBC Appender deve usar o JndiManager ao acessar o JNDI. Este acesso deve ser controlado por meio de uma propriedade do sistema”, afirma o site BleepingComputer.

Log4j 2.17.1 está na área para corrigir nova vulnerabilidade
Obrigado a ele, nosso software não foi afetado e está seguro. Falhou para atualizar o Log4j 1.2 para uma versão recente“. | Créditos da imagem: https://devs.lol/meme/failed-to-upgrade-log4j-259?ref=similar

Relacionado ao CVE-2021-44832, um invasor com permissão para modificar o arquivo de configuração de registro (de logs) poderá criar uma configuração maliciosa por meio do JDBC Appender usando uma fonte de dados referenciando uma URI de JNDI para poder executar código malicioso remotamente”.

Log4j 2.17.1 está na área para corrigir nova vulnerabilidade
Não é possível ser pego pelo Log4Shell se você não logar” (ou seja, não gere log em seu sistema, logo não será afetado pela vulnerabilidade Log4Shel / Isso é brincadeira hein?) | Créditos da imagem: https://twitter.com/ShadowM82/status/1469904590573228033

Um pesquisador de segurança da Checkmarx, Yaniv Nizry, foi responsável por relatar a vulnerabilidade à ASF:

Tweet do especialista de segurança, Yaniv Nizry

Já o especialista Kevin Beaumont rotulou este alerta como outra “divulgação falha do Log4j em curso”, durante as vésperas de feriados.

Nizry publicou este post informando maiores detalhes sobre a vulnerabilidade. Veja no vídeo abaixo uma prova de conceito (PoC) executada por Nizry:

Foi precipitado?

No momento do tweet de Nizty, o site BleepingComputer não havia encontrado nenhum comunicado oficial indicando a presença de uma falha de RCE no Log4j 2.17.0.

O tweet em si não possuía detalhes sobres a vulnerabilidade ou como ela poderia ser explorada, mas isso, em minutos, levou um grupo de profissionais de segurança e internautas a começar a investigar a divulgação feita por Nizry.

Divulgar vulnerabilidades de forma prematura pode atrair a curiosidade de “agentes de ameaça” (é qualquer pessoa que represente uma ameaça). Estes agentes podem executar atividades maliciosas de varredura e exploração, como ficou evidente no vazamento da exploração do Log4Shell em 9 de dezembro de 2021.

Marc Rogers, VP de Cybersecurity da Okta, revelou pela primeira vez o número da CVE (CVE-2021-44832) e que a exploração da vulnerabilidade depende de uma configuração não-padrão do Log4j, quando esta configuração está sendo carregada de um servidor remoto:

Até agora, as vulnerabilidades foram exploradas por todos os tipos de agentes de ameaças, desde hackers patrocinados por algum governo a grupos de ransomware e outros, com o objetivo de injetar mineradores do Monero em sistemas vulneráveis.

Por exemplo, o grupo de ransomware Conti, foi visto mirando servidores VMWare vCenter vulneráveis. Enquanto que, outros invasores estiveram hackeando a plataforma de criptografia vietnamita, ONUS, via vulnerabilidade Log4Shell, onde exigiram um pagamento de 5 milhões de dólares.

E a correção?

Pois bem, os usuários que utilizam o Log4j em suas aplicações, precisam atualizar imediatamente para a versão 2.17.1 (ambientes que usam o Java 8). As versões com backport para o Log4j 2.12.4 (Java 7) e 2.3.2 (Java 6) contendo a correção também deverão ser lançadas em breve.

Confira links para ficar mais informado(a) sobre o que tem rolado com o Log4j:

https://www.canalhacker.com.br/2021/12/13/log4shell-a-vulnerabilidade-que-coloca-em-risco-aplicacoes-web-java/

https://www.canalhacker.com.br/2021/12/18/log4shell-antigo-ransomware-e-usado-em-ataques-ao-log4j/

https://www.canalhacker.com.br/2021/12/18/log4j-2-17-mais-uma-versao-foi-lancada-para-corrigir-as-vulnerabilidades/

Referência:

https://www.bleepingcomputer.com/news/security/log4j-2171-out-now-fixes-new-remote-code-execution-bug/

Download da última versão do Log4j:

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

Créditos da imagem usada na capa do post:

https://bgr.com/tech/you-cant-do-anything-to-stop-the-log4j-zero-day-attacks-yourself/

O que achou?

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