Um ano após sua descoberta, a Vulnerabilidade Log4j ainda é um problema, apesar das versões corrigidas logo estarem disponíveis.
Esta semana marca o aniversário de um ano da descoberta da vulnerabilidade Log4j/Log4Shell que afeta a biblioteca de registro Java.
E acontece que, apesar de ter passado um ano desde o incidente, o número de downloads de versões vulneráveis do Log4j ainda é alto, pois foi calculado que cerca de 30-40% de todos os downloads são para a versão exposta.
Conforme relatado recentemente, muitas organizações permanecem vulneráveis, apesar das versões corrigidas logo estarem disponíveis.
Vulnerabilidade Log4j ainda é um problema
Para quem não conhece a vulnerabilidade, é notável porque o ataque pode ser realizado em aplicativos Java que registram valores obtidos de fontes externas, por exemplo, exibindo valores problemáticos em mensagens de erro.
A vulnerabilidade Log4j foi um alerta para todas as organizações e um momento que muitos profissionais de segurança gostariam de esquecer.
No entanto, com o uso generalizado do Log4j e uma rede crescente de servidores internos e de terceiros para correção, a vulnerabilidade será sentida por muito tempo.
Observa-se que quase todos os projetos que usam estruturas como Apache Struts, Apache Solr, Apache Druid ou Apache Flink são afetados, incluindo Steam, Apple iCloud, clientes e servidores Minecraft.
A Sonatype produziu um centro de recursos para mostrar o status atual da vulnerabilidade, bem como uma ferramenta para ajudar as empresas a escanear seu código-fonte aberto para ver se ele foi afetado.
O painel mostra a porcentagem de downloads do Log4j que ainda estão vulneráveis (atualmente em torno de 34% desde dezembro passado). Ele também mostra as partes do mundo que tiveram a maior porcentagem de downloads vulneráveis.
Brian Fox, CTO da Sonatype, diz:
“Log4j foi um lembrete da importância crítica de proteger a cadeia de suprimentos de software. Foi usado em praticamente todas as aplicações modernas e afetou os serviços de organizações em todo o mundo. Um ano após o incidente Log4Shell, a situação continua sombria. De acordo com nossos dados, 30-40% de todos os downloads do Log4j são para a versão vulnerável, embora um patch tenha sido lançado 24 horas após a divulgação prematura da vulnerabilidade.”
Além disso, ele acrescenta que é:
“É imperativo que as organizações reconheçam que a maioria dos riscos de código aberto está com os consumidores, que devem adotar as melhores práticas em vez de culpar o código defeituoso. O Log4j não é um incidente isolado: 96% dos downloads de componentes vulneráveis de código aberto tinham uma versão corrigida.”
As organizações precisam de melhor visibilidade de cada componente usado em suas cadeias de suprimentos de software. É por isso que as soluções de análise de composição de software de qualidade são tão importantes hoje, pois o mundo contempla a utilidade dos SBOMs no futuro.
A política de software do Reino Unido e da Europa deve exigir que os consumidores comerciais de software livre sejam capazes de realizar o equivalente a um recall específico, assim como os fabricantes de bens físicos, como a indústria automobilística, esperam.
A visibilidade geral concederá benefícios adicionais às organizações, como a capacidade de tomar decisões sobre ela.
À medida que progredimos, ficou claro que os hackers continuariam a explorar a vulnerabilidade.
Em fevereiro, hackers patrocinados pelo estado iraniano usaram a falha para invadir uma rede do governo dos EUA, minerar ilegalmente criptomoedas, roubar credenciais e alterar senhas.
Então, em outubro, um grupo associado ao governo chinês usou a vulnerabilidade para lançar ataques contra vários alvos, incluindo um país do Oriente Médio e um fabricante de eletrônicos.
A vulnerabilidade Log4j continua a afetar as empresas hoje. Ele ocupa consistentemente o primeiro ou o segundo lugar em relatórios de ameaças de diferentes consultorias de segurança cibernética, afetando 41% das organizações em todo o mundo em outubro de 2022.
Muito bom amigo, vc tem contribuído muito com os usuários do linux.