Segundo um relatório da empresa de segurança de apps Veracode, vários aplicativos Log4J ainda usam uma versão vulnerável da biblioteca.
Log4Shell é uma falha de execução remota de código (RCE) não autenticada que permite assumir o controle total dos sistemas com Log4j 2.0-beta9 e até 2.15.0.
A falha foi descoberta como um zero-day explorado ativamente em 10 de dezembro de 2021, e seu impacto generalizado, facilidade de exploração e enormes implicações de segurança funcionaram como um convite aberto aos atores da ameaça.
A circunstância levou a uma extensa campanha para notificar os mantenedores dos projetos e administradores de sistemas afetados, mas, apesar dos numerosos avisos, um número significativo de organizações continuou a usar versões vulneráveis muito depois dos patches estarem disponíveis.
Dois anos após a divulgação da vulnerabilidade e o lançamento das correções, ainda existem muitos alvos vulneráveis ao Log4Shell.
Aproximadamente 38% dos aplicativos que usam a biblioteca Apache Log4j estão usando uma versão vulnerável a problemas de segurança, incluindo Log4Shell, uma vulnerabilidade crítica identificada como CVE-2021-44228 que carrega a classificação de gravidade máxima, apesar dos patches estarem disponíveis há mais de dois anos.
Aplicativos Log4J ainda usam uma versão vulnerável da biblioteca
Sim. Um relatório da empresa de segurança de aplicativos Veracode, baseado em dados coletados entre 15 de agosto e 15 de novembro, destaca que problemas antigos podem persistir por longos períodos.
A Veracode coletou dados durante 90 dias de 3.866 organizações que usam 38.278 aplicativos que contam com Log4j com versões entre 1.1 e 3.0.0-alpha1.
Desses aplicativos, 2,8% usam 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, falha de execução remota de código que foi corrigida na versão 2.17.1 do framework.
Por fim, 32% estão usando o Log4j versão 1.2.x, que atingiu o fim do suporte desde agosto de 2015. Essas versões são vulneráveis a diversas 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.
Isso está próximo do que os especialistas em gerenciamento da cadeia de suprimentos de software da Sonatype relatam em seu painel Log4j, onde 25% dos downloads da biblioteca na semana passada dizem respeito a versões vulneráveis.
O uso contínuo de versões desatualizadas de bibliotecas indica um problema contínuo, que Veracode 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 quebras de funcionalidade.
Isso é verdade mesmo que 65% das atualizações de bibliotecas de código aberto contenham 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.
Leva 13,7 vezes mais tempo do que o normal para corrigir metade do que está em sua lista de pendências quando há falta de pessoal e mais de sete meses para lidar com 50% disso quando há falta de informações.
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 por si só continua a ser uma fonte de risco em 1 em cada 3 casos e pode muito facilmente ser uma das múltiplas maneiras pelas quais os invasores podem aproveitar para comprometer um determinado alvo.
A recomendação para as empresas é examinar seu ambiente, encontrar as versões das bibliotecas de código aberto em uso e, em seguida, desenvolver um plano de atualização emergencial para todas elas.
