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

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

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

Há uma semana e meia, pesquisadores de segurança do Alibaba cloud equipe de segurança revelou um método para abusar de aplicativos com o Log4j. Log4j é usado em aplicativos para registrar eventos. Acabou sendo possível acessar aplicativos com a biblioteca de fora com instruções para executar malware. O abuso leva pouco mais do que um piscar de olhos. Acrescente a isso a ocorrência estimada da biblioteca na maioria dos ambientes corporativos e você entenderá a escala do desastre enfrentado pelo cenário global de TI.

Desenvolvedores de software como Fortinet, Cisco, IBM e dezenas de outros usam a biblioteca em seus softwares. Seus desenvolvedores trabalharam horas extras no fim de semana de 11 de dezembro para processar o primeiro patch de emergência para a vulnerabilidade e entregá-lo às organizações de usuários. Exatamente a mesma tendência era esperada 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é que 2.15 também foi considerado vulnerável.

Certas configurações da biblioteca permaneceram possíveis na versão 2.15. O uso dessas configurações perpetuou a vulnerabilidade. A versão 2.16 inviabilizou as configurações, garantindo um novo patch. Muitas vezes, para desgosto das equipes de TI já sobrecarregadas. No entanto, sempre pode ser pior, porque 2.16 também tem uma doença.

Voltar ao início

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

Resumindo, acontece que é possível rodar dezenas de versões do log4j – incluindo a 2.16 – com uma linha (string) para iniciar um loop eterno que trava a aplicação. As condições que um ambiente deve atender para ser abusado são extensas. Tão extenso que a gravidade prática do problema é contestada. O patch é oficialmente recomendado, mas nem todos estão convencidos.

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