.
Dois anos após a divulgação da vulnerabilidade Log4Shell no utilitário de registro Log4j baseado em Java de código aberto, cerca de um em cada quatro aplicativos depende de bibliotecas desatualizadas, deixando-as abertas à exploração.
Uma pesquisa da loja de segurança Veracode revelou que a grande maioria dos aplicativos vulneráveis podem nunca ter atualizado a biblioteca Log4j depois que ela foi implementada pelos desenvolvedores, já que 32% estavam executando versões EOL anteriores a 2015.
Investigações anteriores da Veracode também mostraram que 79 por cento de todos os desenvolvedores nunca atualizam bibliotecas de terceiros depois de introduzi-las em projetos, e dado que o Log4j2 – a versão específica do Log4j afetada pela vulnerabilidade – remonta a 2014, isso poderia explicar o grande proporção de aplicativos sem patch.
Uma minoria muito menor está executando versões que eram vulneráveis no momento da divulgação da vulnerabilidade Log4j em dezembro de 2021. Apenas 2,8 por cento ainda estão usando as versões 2.0-beta9 a 2.15.0 – versões pós-EOL que permanecem expostas ao Log4Shell, o setor- apelido cunhado para a exploração da vulnerabilidade.
Cerca de 3,8 por cento ainda estão executando a versão 2.17, uma versão pós-patch do registrador Java que não está exposta a ataques Log4Shell, mas é vulnerável a um bug separado de execução remota de código (RCE) (CVE-2021-44832).
Os pesquisadores acreditam que isso ilustra uma minoria de desenvolvedores que agiram rapidamente quando a vulnerabilidade foi divulgada pela primeira vez, como era o conselho na época, e retornaram aos hábitos mais antigos de deixar as bibliotecas intocadas.
Ao todo, apenas 35% permanecem vulneráveis ao Log4Shell e quase 40% são vulneráveis a falhas de RCE.
As versões EOL do Log4j também são vulneráveis a três bugs críticos adicionais anunciados pelo Apache, elevando o total para sete problemas de classificação alta e crítica.
“Em um nível superficial, os números acima mostram que o enorme esforço para remediar a vulnerabilidade Log4Shell foi eficaz na mitigação do risco de exploração da vulnerabilidade de dia zero. Isso não deveria ser surpreendente”, disse Chris Eng, diretor de pesquisa da Veracode.
“A maior história no aniversário de dois anos, no entanto, é que ainda há espaço para melhorias quando se trata de segurança de software de código aberto. Se o Log4Shell fosse outro exemplo em uma longa série de alertas para adotar código aberto mais rigoroso práticas de segurança, o fato de que mais de um em cada três aplicativos executam atualmente versões vulneráveis do Log4j mostra que há mais trabalho a ser feito.
“A principal conclusão aqui é que as organizações podem não estar cientes de quanto risco de segurança de código aberto estão expostas e como mitigá-lo”.
O maior problema em jogo não é apenas a falha na aplicação de patches. De acordo com a Sonatype, o número de downloads do Log4j contendo versões vulneráveis apenas nos últimos sete dias é de 26% de um total de 3,7 milhões.
É um fenômeno que também não mudou muito desde a divulgação do Log4Shell, com 26% de todos os downloads desde dezembro de 2021 vulneráveis à exploração RCE.
Quando foi revelada pela primeira vez, a vulnerabilidade no Log4j catalisou o medo generalizado na comunidade infosec, dada a sua natureza crítica e o número de organizações cujo software dependia dela – um número que a Veracode acreditava ser de cerca de 88% na altura.
As previsões eram de que o bug era tão perigoso, tão explorável e tão sério que assombraria a indústria durante muitos meses até 2022, e outros, como o Departamento de Segurança Interna dos EUA, especularam que poderia durar mais de uma década.
A diretora da Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) disse na época que era a vulnerabilidade “mais séria” que ela já havia visto em sua carreira.
No entanto, a acção rápida e as campanhas de sensibilização urgentes acabaram por significar que os danos não foram tão intensos como muitos inicialmente temiam.
No entanto, o Log4Shell causou alguns problemas de alto perfil, como um ataque a uma rede do governo dos EUA nas mãos de cibercriminosos patrocinados pelo Estado iraniano, e o Ministério da Defesa belga poucas semanas após o início do furor.
Embora a maioria das organizações tenha corrigido versões seguras em semanas, em vez de lidar com explorações, muitas vezes a maior dor sentida foi o próprio processo de correção, que poderia ter envolvido centenas de aplicativos, dependendo da organização. ®
.
