Cerca de 38% dos aplicativos que usam o Apache Log4j integram uma versão vulnerável da biblioteca, incluindo o Log4Shell, uma falha crítica identificada como CVE-2021-44228, com classificação de gravidade máxima no sistema de pontuação comum de vulnerabilidades (CVSS), apesar de os patches estarem disponíveis há mais de dois anos.
O Log4Shell é uma falha de execução remota de código (RCE) não autenticada que permite ao invasor assumir o controle total sobre sistemas baseados no Log4j 2.0-beta9 e até 2.15.0.
A falha foi descoberta como um dia zero explorado ativamente em 10 de dezembro de 2021 e seu impacto generalizado, facilidade de exploração e enormes implicações de segurança atuaram como um convite aberto aos operadores de ameaças. Isso levou a uma extensa campanha para notificar os mantenedores de projetos e administradores de sistema afetados, mas apesar de inúmeros avisos, um número significativo de organizações contina a usar versões vulneráveis muito após os patches terem se tornado disponíveis.
Dois anos depois que a vulnerabilidade foi divulgada e as correções foram lançadas, há muitos alvos ainda vulneráveis ao Log4Shell. Um relatório da empresa de segurança de aplicativos Veracode, com base 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 reuniu 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% usam 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.
Por fim, 32% estão usando a versão 1.2.x do Log4j, que chegou ao fim do suporte em agosto de 2015. Essas versões são vulneráveis a várias vulnerabilidades graves publicadas até 2022, incluindo CVE-2022-23307, CVE-2022-23305 e CVE-2022-23302. No total, a Veracode descobriu que cerca de 38% dos aplicativos dentro de sua visibilidade usam uma versão insegura do Log4j.
O uso contínuo de versões desatualizadas da biblioteca indica um problema contínuo, que a empresa atribui aos desenvolvedores que desejam evitar complicações desnecessárias.
De acordo com as descobertas da Veracode, 79% dos desenvolvedores optam por nunca atualizar bibliotecas de terceiros após sua inclusão inicial em sua base de código para evitar a quebra de funcionalidade. Isso ocorre mesmo diante do fato de que 65% das atualizações de biblioteca de código aberto contêm pequenas alterações e correções que provavelmente não causarão problemas funcionais.
Além disso, o estudo mostrou que 50% dos projetos levam mais de 65 dias para resolver falhas de alta gravidade. Ou seja, 13,7 vezes mais tempo do que o normal para consertar metade do que está na lista de pendências do diretor de segurança quando falta pessoal e mais de sete meses para lidar com 50% disso quando falta informação.
Veja isso
RCE no Log4j é explorada por hackers apoiados pela China
Falha no Log4j pode se tornar ‘endêmica’, alerta painel dos EUA
Infelizmente, os dados da Veracode mostram que o Log4Shell não foi o alerta que muitos na indústria de segurança esperavam que fosse. Em vez disso, o Log4j sozinho continua a ser uma fonte de risco de um em cada três casos e pode muito facilmente ser uma das várias maneiras que os invasores podem aproveitar para comprometer um determinado alvo.
A recomendação para as empresas é verificar seu ambiente, encontrar as versões de bibliotecas de código aberto em uso e, em seguida, desenvolver um plano de atualização de emergência para todas elas.
Para ter acesso ao relatório completo da Veracode, em inglês, clique aqui.
