Log4j nova versão 2.17.1 do Apache corrige nova falha de RCE

Log4j nova versão 2.17.1 do Apache corrige nova falha de RCE (execução remota de código) recentemente divulgada e rastreada como CVE-2021-44832

Outro patch do Log4j foi lançado pela Apache Foundation, a organização sem fins lucrativos que oferece suporte aos projetos de software de código aberto da Apache. Seu Log4j versão 2.17.1 corrige uma execução remota de código recentemente divulgada, ou RCE, vulnerabilidade, rastreada como CVE-2021-44832 .

A última falha é a quinta divulgada em menos de um mês – quatro em torno do Log4j e outra detectada na estrutura “logback“. Todos têm como alvo a falha de execução remota de código arbitrário e facilmente explorável no utilitário de registro baseado em Java – que, dizem os especialistas, está presente em milhões de dispositivos em todo o mundo [ou mais]. A divulgação da falha, relatada pela primeira vez em 9 de dezembro, imediatamente enviou equipes de segurança para identificar dispositivos e sistemas vulneráveis, com patches subsequentes de administradores sem fins lucrativos lançados semirregularmente depois disso.

O novo CVE – que carrega um Sistema de Pontuação de Vulnerabilidade Comum, ou CVSS, pontuação de 6,6, ou “moderado” – pode ser explorado em um ataque RCE, permitindo que agentes mal-intencionados elaborem uma “configuração usando um JDBC Appender com uma fonte de dados referenciando um JNDI [Java Naming and Directory] URI. ” De acordo com o diretório CVE da MITER Corporation , 44832 é suficientemente abordado pela oferta mais recente do Apache, 2.17.1.

Comunidade de segurança

Yaniv Nizry , pesquisador da empresa de testes de segurança de aplicativos Checkmarx, supostamente tweetou pela primeira vez sobre a vulnerabilidade na terça-feira.

Em uma postagem de blog de acompanhamento , Nizry escreve: “A complexidade desta vulnerabilidade é maior do que o CVE-2021-44228 original, pois requer que o invasor tenha controle sobre a configuração (como a vulnerabilidade ‘logback’ CVE-2021-42550 ).

(Fonte: Apache)

No entanto, alguns especialistas em segurança criticaram a divulgação online da empresa, sugerindo que a exploração foi revelada prematuramente – e antes de um alerta oficial ou comunicado ser emitido.

O pesquisador de segurança Kevin Beaumont , atualmente chefe do centro de operações de segurança do Grupo Arcádia, tuitou sobre o último CVE Log4j: “2021 não estaria completo sem outra divulgação Log4j fracassada em movimento durante o período de férias novamente. (Felizmente, se for este, quase não há risco no mundo real).Beaumont diz que um invasor só pode aproveitar essa vulnerabilidade se já puder “modificar o arquivo de configuração Log4j“.

Beaumont acrescenta no tópico: “Para ser absolutamente claro, isso não é problema para 99,999% das situações – se alguém está modificando a instalação do Tomcat, eles já possuem sua caixa. Isso foi discutido há quase dez anos.”

Na verdade, em uma postagem separada , Beaumont avisa: “Não surte com o último Log4j CVE.

E Casey Ellis, CTO e fundador da plataforma de vulnerabilidade Bugcrowd, também desafiou o método de divulgação empregado pelo pesquisador da Checkmarx ao descrever a nova falha.

Além disso, Ellis diz: “É bastante seguro esperar mais desses tipos de anúncios de vulnerabilidade nas próximas semanas.” O CTO Bugcrowd acrescenta que atualizar para a versão mais recente do Apache, ou mitigar sempre que possível, imediatamente, continua sendo crucial e ajudará as equipes de segurança a se manterem atualizadas no Log4j. Isso ocorre em meio a relatórios de varredura ativa de sistemas vulneráveis ​​e relatórios de agentes de ameaças sofisticados e ameaças persistentes avançadas, movendo-se para a falha de registro.

Quinto CVE Log4j em menos de um mês

A exploração em massa da vulnerabilidade Log4Shell original (CVE-2021-44228) por atores de ameaças começou por volta de 9 de dezembro, quando uma exploração PoC  para ela apareceu no GitHub.

Devido ao amplo uso do Log4j na maioria dos aplicativos Java, o Log4Shell logo se tornou um  pesadelo para empresas e governos em  todo o mundo.

Embora o risco crítico representado pelo exploit Log4Shell original seja primordial, variantes mais suaves da vulnerabilidade surgiram nas versões Log4j, incluindo 2.15 e 2.16 – que anteriormente se acreditava estar totalmente corrigidas.

BleepingComputer relatou  quatro CVEs diferentes impactando Log4j e um descoberto na estrutura de ‘logback‘. Após a descoberta de uma falha de DoS na versão 2.16, o conselho mudou rapidamente para a  atualização para a versão 2.17.0 , considerada a mais segura de todas.

Mas agora uma quinta vulnerabilidade – uma falha de RCE, rastreada como CVE-2021-44832, foi descoberta no 2.17.0, com um patch aplicado ao lançamento mais recente 2.17.1 que foi lançado.

Classificada como ‘Moderada‘ em gravidade e atribuída uma pontuação de 6,6 na escala CVSS, a vulnerabilidade decorre da falta de controles adicionais no acesso JDNI no log4j.

JDBC Appender deve usar JndiManager ao acessar JNDI. O acesso JNDI deve ser controlado por meio de uma propriedade do sistema“, afirma a descrição do problema vista por BleepingComputer.

Relacionado ao CVE-2021-44832 onde um invasor com permissão para modificar o arquivo de configuração de registro pode construir uma configuração maliciosa usando um JDBC Appender com uma fonte de dados referenciando um URI JNDI que pode executar código remoto.

Yaniv Nizry, pesquisador de segurança da Checkmarx,   reivindicou o crédito por relatar a vulnerabilidade ao Apache:

O tweet de Nizry explodiu rapidamente no tráfego, atraindo comentários e memes de especialistas em segurança e ‘vítimas‘ do cansaço contínuo dos patches do log4j.

Espero que seja uma piada, espero que sim … # log4j“, tuitou um usuário em resposta.

Já passamos MUITO do ponto em que a única coisa responsável a fazer é colocar uma placa gigante de néon piscando que diz ‘LOG4J NÃO PODE SER CONSERTADO, NÃO USE PARA NADA.‘” Provocou outro.

O especialista em segurança Kevin Beaumont rotulou  a instância como outra “divulgação falhada do Log4j em movimento” durante os feriados.

Microsoft lança painel Log4j

A gigante da tecnologia Microsoft também tentou se manter atualizada sobre todas as coisas do Log4j, tendo lançado um novo painel em seu portal 365 Defender, que a empresa diz que pode ajudar os clientes a identificar arquivos, software e dispositivos que podem ser afetados pelo Log4j. O painel também fornece orientação sobre o gerenciamento de ameaças e outras tarefas associadas à mitigação das ameaças generalizadas do CVE-2021-44228.

O painel inclui um “resumo de vulnerabilidade” com detalhes de exposição, incluindo o número de rastreamento CVE apropriado, pontuação CVSS e outras informações, e detecta onde dispositivos e software foram expostos.

Os resultados da varredura podem levar algum tempo para atingir a cobertura total, e o número de dispositivos descobertos pode ser baixo no início, mas aumentará conforme a varredura atinge mais dispositivos”, afirma o blog de segurança da Microsoft.

Os novos recursos, lançados na segunda-feira, estão disponíveis agora para Windows e uma versão com suporte para macOS está em desenvolvimento.

CISA

Na semana passada, a Agência de Segurança Cibernética e de Infraestrutura dos EUA, o FBI e a Agência de Segurança Nacional, junto com vários parceiros internacionais de aplicação da lei, emitiram um comunicado conjunto sobre as vulnerabilidades conhecidas na biblioteca de software Apache Log4j, pedindo “qualquer organização que use produtos com Log4j para mitigar e corrigir imediatamente

O comunicado seguiu a diretiva de emergência da CISA, emitida em 17 de dezembro, substituindo o prazo anterior de 24 de dezembro para corrigir o Log4j e, em vez disso, dizendo às agências e departamentos federais para corrigir ou mitigar imediatamente 

Comentando sobre o alerta conjunto das agências, o Diretor da CISA Jen Easterly disse: “Imploramos a todas as entidades que protejam suas redes. A CISA está trabalhando lado a lado com nossos parceiros interagências, setor privado e internacionais para compreender os graves riscos associados às vulnerabilidades do Log4j e fornecer informações acionáveis ​​para todas as organizações para implementar prontamente as mitigações apropriadas. Essas vulnerabilidades são as mais graves que já vi em minha carreira e é fundamental que trabalhemos juntos para manter nossas redes seguras.

A CISA criou uma página da Web Log4j dedicada com detalhes técnicos, orientação de mitigação e outros recursos. Ele também criou um repositório GitHub criado pela comunidade de dispositivos e serviços afetados.

Check Point, Alibaba

Em outro lugar, pesquisadores da empresa de segurança israelense Check Point também disseram recentemente que impediram cerca de 4,3 milhões de tentativas de aproveitar as vulnerabilidades – com 46% dessas tentativas feitas por “grupos mal-intencionados conhecidos“. A empresa disse que mais de 48% das redes corporativas foram exploradas pelo Log4j.

A Check Point também disse no início deste mês que um conhecido grupo de hackers iraniano, Charming Kitten, também conhecido como APT35, está por trás de tentativas de explorar a falha do Apache – particularmente contra alvos israelenses, incluindo seu governo e empresas.

A explosiva vulnerabilidade Log4j foi relatada originalmente à Apache Software Foundation dos Estados Unidos em 24 de novembro, mas os reguladores chineses estão suspendendo uma parceria de compartilhamento de informações com a Alibaba Cloud Computing, que foi creditada por revelar a vulnerabilidade, devido ao seu suposto fracasso em relatar e resolver a falha prontamente com o governo chinês, de acordo com um relatório recente da Reuters.

Fonte: BankInfo Security & BleepingComputer

 

Veja também:

Sobre mindsecblog 2571 Artigos
Blog patrocinado por MindSec Segurança e Tecnologia da Informação Ltda.

2 Trackbacks / Pingbacks

  1. Microsoft reedita Bug do Milênio na virada para 2022
  2. Wireshark 3.6.1 - O que há de novo!

Deixe sua opinião!