Apache desativa recurso do Log4j na versão 2.16

15/12/2021 mindsecblog Notícias 5

Apache desativa recurso do Log4j na versão 2.16. Agora JNDI de biblioteca de registro de código aberto desativado inteiramente por padrão.

Na semana passada, a versão 2.15 da biblioteca de registro de código aberto amplamente usada Log4j foi lançada para resolver uma falha de segurança crítica, apelidada de Log4Shell, que poderia ser usada de forma trivial por malfeitores para sequestrar servidores e aplicativos pela Internet.

A versão 2.15 fechou o buraco ( CVE-2021-44228 ) ao desabilitar por padrão a funcionalidade principalmente explorável da biblioteca Java: pesquisas de mensagem JNDI. Agora a versão 2.16 foi lançada e desabilita todo o suporte JNDI por padrão, e remove a manipulação de pesquisa de mensagem inteiramente para uma boa medida, esperançosamente, finalmente evitando exploração posterior.

Isso é necessário porque a versão 2.15 ainda pode ser explorada em certas configurações não padrão, e esse descuido de severidade moderada ganhou sua própria ID de bug: CVE-2021-45046 .

Crucialmente, esse movimento é uma defesa em profundidade: o Apache reconheceu que o JNDI “tem problemas de segurança significativos”, então ele é apenas desativado por padrão com uma nova versão. A versão 2.15 foi provavelmente suficiente para protegê-lo de ataques, a versão 2.16 torna isso certo.

Em suas últimas notas de lançamento do Log4j 2.x, a Apache Foundation disse: “Lidar com CVE-2021-44228 mostrou que o JNDI tem problemas de segurança significativos. Embora tenhamos atenuado o que sabemos, seria mais seguro para os usuários completamente desative-o por padrão, especialmente porque a grande maioria provavelmente não o usará. “

Portanto, a versão 2.16.0 foi enviada com JNDI, o Java Naming and Directory Interface, desativado. JNDI é a API que foi descoberta de forma explosiva para ser explorada no Log4j na semana passada. É compatível com Log4j para que os objetos possam ser buscados em servidores remotos para usar nas entradas de log.

Com o JNDI habilitado, o Log4j pode ser induzido a buscar o código Java de um servidor controlado pelo invasor e executá-lo cegamente, comprometendo o dispositivo. Para conseguir isso, o invasor precisaria alimentar algum texto especialmente criado em, digamos, um nome de usuário de conta de aplicativo ou consulta de pesquisa de site, que, quando registrado pelo Log4j, acionaria a execução remota de código.

De acordo com a equipe Apache:

A partir da versão 2.16.0, o recurso de pesquisa de mensagens foi completamente removido. As pesquisas na configuração ainda funcionam.
Além disso, o Log4j agora desabilita o acesso ao JNDI por padrão. As pesquisas JNDI na configuração agora precisam ser ativadas explicitamente. Além disso, Log4j agora limita os protocolos por padrão apenas para java, ldap e ldaps e limita os protocolos ldap para acessar apenas objetos primitivos Java. Hosts diferentes do host local precisam ser explicitamente permitidos.

Isso basicamente significa que se você deseja usar pesquisas JNDI, é necessário retirar os dispositivos de segurança de sua pilha de software.

Jeff Dileo, do NCC Group, comentou em uma postagem de blog : “Na realidade, o material JNDI é lamentavelmente mais um recurso ‘corporativo’ do que um que os desenvolvedores poderiam inserir aleatoriamente se deixados por conta própria. O Enterprise Java tem tudo a ver com antipadrões que invocam código de formas indiretas até o ponto de ofuscação, e suportando formas cada vez mais dinâmicas de integrar protocolos estranhos como RMI para carregar e invocar código remoto dinamicamente de maneiras estranhas. “

Essencialmente, se você estiver usando (ou implantando) Log4j 2.x versões 2.14 ou abaixo, atualize para 2.16, e se você já estiver no 2.15, considere o 2.16 para sua tranquilidade: o código JNDI não é conhecido por ser terrivelmente seguro .