A Fundação Apache lançou ontem mais uma atualização do utilitário Log4J-2: foi a versão 2.16, substituindo a anterior. Na versão 2.15, apenas um aspecto da funcionalidade de recuperação de mensagem do JNDI foi desabilitada por padrão. Agora, na correção 2.16, é desativado todo o suporte JNDI por padrão, e removendo completamente o tratamento de consulta de mensagem. JNDI é uma API usada pelo Log4j para recuperar objetos de servidores remotos para uso em registros de log. Portanto, na versão 2.16.0 o JNDI está desabilitado.
A Java Naming and Directory Interface (JNDI) é um conjunto de APIs Java organizadas como um serviço de diretório que permite que clientes Java abram e visualizem dados e objetos por nome. Como qualquer outra API Java, como um conjunto de interfaces, JNDI é independente da implementação subjacente. Além disso, ele fornece uma implementação de interface do provedor de serviços (SPI) que permite que os serviços de diretório sejam emparelhados com uma estrutura.
O lançamento da segunda atualização foi necessário porque a versão 2.15 ainda pode ser explorada em certas configurações não originais. Este problema recebeu seu próprio identificador, que é o CVE-2021-45046.
A Fundação Apache reconheceu que o JNDI “tem sérios problemas de segurança”, então foi tomada a decisão de desativá-lo por padrão: “CVE-2021-44228 nos mostrou que JNDI tem sérios problemas de segurança. Embora tenhamos eliminado o que sabíamos, foi decidido desabilitá-lo completamente por padrão para maior segurança do usuário, especialmente porque a maioria das pessoas quase não o usa ”, disse a Apache.
Veja isso
Updates de segurança tiram do ar serviços federais
Hackers varrem 40% das redes em busca de Log4J
Com o JNDI habilitado, os invasores podem forçar o utilitário Log4j a extrair o código Java de um servidor sob seu controle e executá-lo, comprometendo o dispositivo. Para fazer isso, os invasores devem inserir um texto especialmente criado, por exemplo, no nome de uma conta de aplicativo ou em uma consulta de pesquisa em um site. Quando conectado pelo Log4j, isso acionará a execução remota de código.
Sean Gallagher, pesquisador sênior de Ameaças da Sophos, diz que “com exceção de cryptomining, ‘há uma calmaria antes da tempestade’ em termos de atividades maliciosas. Ao nosso ver, a probabilidade é de que os invasores provavelmente tenham o máximo de acesso possível a tudo o que puderem agora, com o objetivo de monetizar e/ou capitalizar mais tarde. A prioridade imediata para os defensores é reduzir a exposição, corrigindo e mitigando todas as possíveis falhas da infraestrutura, além de investigar sistemas expostos e potencialmente comprometidos. Essa vulnerabilidade pode estar em qualquer lugar”.
A publicação da versão 2.16 foi feita junto com um alerta da Mitre Corp, dizendo; “Foi descoberto que a correção para resolver o CVE-2021-44228 no Apache Log4j 2.15.0 estava incompleta em certas configurações não-padrão. Isso pode permitir que os invasores tenham controle sobre os dados de entrada do Thread Context Map (MDC) quando a configuração de registro usar um layout de padrão não padrão com uma Pesquisa de contexto (por exemplo, $$ {ctx: loginId}) ou um padrão de Thread Context Map ( % X,% mdc ou% MDC) para criar dados de entrada maliciosos usando um padrão de pesquisa JNDI resultando em um ataque de negação de serviço (DOS). Log4j 2.15.0 faz uma tentativa de melhor esforço para restringir pesquisas JNDI LDAP para localhost por padrão. O Log4j 2.16.0 corrige esse problema removendo o suporte para padrões de consulta de mensagens e desabilitando a funcionalidade JNDI por padrão.“
Com agências de notícias internacionais
