log4j 2.16 vulnerável a ataques DoS, patch urgente 2.17 recomendado

O impacto da vulnerabilidade infame na biblioteca Java Log4j se arrasta. Embora o maior problema tenha sido resolvido com um patch urgente 2.16, esta versão também parece ser suscetível a abusos. Pesquisadores de segurança encontraram uma entrada para negação de serviço (DoS) ataques. log4j 2.17 foi publicado para fechar a entrada.

Apache, desenvolvedor da biblioteca Java, aconselha as organizações a aplicar o patch de emergência. Esse conselho se aplica pela terceira vez desde que a biblioteca foi considerada vulnerável.

Uma semana e meia atrás, pesquisadores de segurança da equipe de segurança em nuvem da Alibaba revelaram um método para abusar de aplicativos com Log4j. Log4j é usado em aplicativos para registrar eventos. Acabou sendo possível acessar aplicativos com a biblioteca de fora com instruções para a execução de malware. O abuso leva pouco mais que um estalo. Adicione a isso a ocorrência estimada da biblioteca na maioria dos ambientes corporativos e você entenderá a escala do desastre que enfrenta o cenário global de TI.

Desenvolvedores de software como Fortinet, Cisco, A IBM e dezenas de outros usam a biblioteca em seu software. Seus desenvolvedores trabalharam horas extras no fim de semana de dezembro 11 para processar o primeiro patch de emergência para a vulnerabilidade e entregá-lo às organizações de usuários. Exatamente o mesmo desvio era esperado das equipes de TI dessas organizações. Centenas de milhares de tentativas de ataque ocorreram em todo o mundo. Todos tiveram que mudar para 2.15 o mais rápido possível - até 2.15 também foi considerado vulnerável.

Certas configurações da biblioteca permaneceram possíveis na versão 2.15. Usar essas configurações perpetuou a vulnerabilidade. Versão 2.16 tornou as configurações impossíveis, garantindo um novo patch. Muitas vezes, para desgosto das equipes de TI já sobrecarregadas. Contudo, sempre pode ser pior, Porque 2.16 também tem uma doença.

Voltar ao início

A enorme atenção global para o problema levou a uma investigação mundial massiva. Apache, desenvolvedor da biblioteca, parece que não consegue recuperar o fôlego por dois dias sem que uma empresa de segurança aponte um novo, problema urgente.

Resumidamente, Acontece que é possível executar dezenas de versões do log4j - incluindo 2.16 - com uma linha (corda) para iniciar um loop eterno que trava o aplicativo. As condições que um ambiente deve atender para ser abusado são extensas. Tão extenso que a seriedade prática do problema é contestada. O patch é oficialmente recomendado, mas nem todo mundo está convencido.

Novamente, nem todas as instâncias do Log4j são vulneráveis, mas apenas casos em que a biblioteca está sendo executada em configurações personalizadas. Um invasor em potencial também precisa de uma visão detalhada de como funciona o Log4j. Um contraste com a inicial, vulnerabilidade facilmente acessível.