Mais de 30% dos aplicativos Log4J usam uma versão exposta da biblioteca
11 de Dezembro de 2023

Cerca de 38% dos aplicativos que usam Apache Log4j incorporam uma versão vulnerável da biblioteca, incluindo o Log4Shell, um erro crítico identificado como CVE-2021-44228 , com classificação de gravidade máxima no sistema CVSS (Common Vulnerability Scoring System), apesar dos patches estarem disponíveis há mais de dois anos.

O Log4Shell é uma falha do tipo code execution (RCE) não autenticada que permite ao invasor assumir controle total sobre sistemas baseados no Log4j 2.0-beta9 até 2.15.0.

A falha foi descoberta no zero-day e começou a ser ativamente explorada em 10 de dezembro de 2021, seu impacto generalizado, facilidade de exploração e enormes implicações de segurança serviram como um convite aberto aos operadores de ameaças.

Isso resultou em uma ampla campanha para notificar os mantenedores de projetos e administradores de sistemas afetados, mas apesar da infinidade de aviso, muitas organizações ainda continuam usando versões vulneráveis muito tempo depois dos patches estarem disponíveis.

Dois anos depois que a vulnerabilidade foi divulgada e os patches foram liberados, ainda há muitos alvos vulneráveis ao Log4Shell.

Um relatório da empresa de segurança de aplicativos Veracode, baseado em dados coletados entre 15 de agosto e 15 de novembro deste ano, destaca que problemas antigos podem persistir por longos períodos.

A Veracode compilou dados por 90 dias de 3.866 organizações que usam 38.278 aplicativos que dependem do Log4j com versões entre 1.1 e 3.0.0-alpha1.

Desses aplicativos, 2,8% utilizam as variantes Log4J 2.0-beta9 a 2.15.0, que são diretamente vulneráveis ao Log4Shell.

Outros 3,8% usam o Log4j 2.17.0 que, embora não seja vulnerável ao Log4Shell, é suscetível ao CVE-2021-44832, uma falha de execução remota de código que foi corrigida na versão 2.17.1.

Finalmente, 32% estão usando a versão 1.2.x do Log4j, que terminou o suporte em agosto de 2015.

Essas versões são vulneráveis a várias vulnerabilidades sérias publicadas até 2022, incluindo CVE-2022-23307, CVE-2022-23305 e CVE-2022-23302.

Ao todo, a Veracode descobriu que cerca de 38% dos aplicativos dentro de sua visibilidade estão usando uma versão insegura do Log4j.

O uso contínuo de versões desatualizadas da biblioteca indica um problema persistente, que a empresa atribui aos desenvolvedores que querem evitar complicações desnecessárias.

De acordo com as descobertas da Veracode, 79% dos desenvolvedores optam por nunca atualizar as bibliotecas de terceiros após sua inclusão inicial em sua base de código para evitar a quebra de funcionalidade.

Isso acontece mesmo diante do fato que 65% das atualizações de biblioteca de código aberto contêm pequenas modificações e correções que provavelmente não causarão problemas de funcionalidade.

Além disso, o estudo mostrou que 50% dos projetos demoram mais de 65 dias para resolver falhas de alta gravidade, cerca de 13,7 vezes mais do que o normal para consertar metade do que está na lista de pendências de um diretor de segurança quando faltam profissionais e mais de sete meses para lidar com 50% disso quando falta informação.

Infelizmente, os dados da Veracode indicam que o Log4Shell não foi o alerta que muitos na indústria de segurança esperavam que ser.

Em vez disso, o Log4j por si só continua a ser uma fonte de risco em um em cada três casos e pode muito facilmente ser uma das várias maneiras que os invasores podem aproveitar para comprometer um alvo específico.

A recomendação para as empresas é examir seu ambiente, encontrar textos de onde as bibliotecas de código aberto estejam sendo usadas e então desenvolver um plano de atualização de emergência para todas elas.

Publicidade

Hardware Hacking

Aprenda a criar dispositivos incríveis com o especialista Júlio Della Flora. Tenha acesso a aulas prática que te ensinarão o que há de mais moderno em gadgets de hacking e pentest. Se prepare para o mercado de pentest físico e de sistemas embarcados através da certificação SYH2. Saiba mais...