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
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...