Atualmente percebe-se que a vulnerabilidade Log4Shell perdeu interesse público, mas a superfície de ataque permanece, segundo a Rezilion.
Já se passaram quatro meses desde que o Log4Shell, uma vulnerabilidade crítica de dia zero na onipresente biblioteca Apache Log4j, foi descoberta, e os analistas de ameaças alertam que a aplicação das correções disponíveis ainda está muito atrasada.
Embora o interesse público e o foco da comunidade infosec tenham mudado para vulnerabilidades e explorações mais recentes, o Log4Shell continua sendo um problema de grande escala e um grave risco de segurança.
Log4Shell perdeu interesse público, mas a superfície de ataque permanece
Sim. A vulnerabilidade Log4Shell perdeu interesse público, mas a superfície de ataque permanece, pois um novo relatório publicado pela Rezilion mostra um quadro terrível, revelando uma grande superfície de ataque em uma ampla gama de produtos de software.
Este é um problema grave devido ao seu potencial impacto (execução remota de código) e à facilidade de exploração (disponibilidade de PoCs).
De acordo com o relatório da Rezilion, que apresenta dados de vários pontos, o Log4Shell, rastreado como CVE-2021-44228, ainda está presente em tantos produtos de software que formular uma explicação lógica é um desafio.
Por exemplo, ao analisar o Log4j Download Dashboard da Sonatype, vemos que uma porcentagem constante de quase 40% ainda está baixando versões vulneráveis do Log4j mesmo no final de abril.
Embora isso tenha sido anteriormente atribuído a pesquisadores de segurança, analistas ou até mesmo agentes de ameaças testando suas explorações, a persistência da porcentagem em níveis altos após todo esse tempo exclui esses cenários.
Ao analisar os dados do serviço Open Source Insights do Google, a Rezilion descobriu que dos 17.840 pacotes de código aberto usando o Log4j como dependência, apenas 7.140 foram atualizados para uma versão fixa. Portanto, 60% deles permanecem vulneráveis ao Log4Shell.
Ao pesquisar a categoria específica de contêineres de código aberto no Shodan, a Rezilion encontrou mais de 90.000 aplicativos voltados para a Internet potencialmente vulneráveis que contêm versões obsoletas do Log4j.
Um exemplo notável é o Apache Solr, contando 1.657 implantações públicas e ainda usando Log4j-core-2.16.0-jar.
Outros contêineres populares corrigidos com um grande atraso em abril de 2022 são Apache Storm e Apache skywalking-oap, enquanto o WSO2 API Manager foi corrigido em março de 2022.
Obviamente, as versões mais recentes do contêiner ainda não foram adotadas por todos os usuários, então ainda existem dezenas de milhares de implantações vulneráveis voltadas para a Internet.
Depois, há aqueles que usam o Log4j 1.2.17 obsoleto e não mais suportado, incluindo Atlassian Crucible, Apache zeppelin, Bitnami Kafka e Bitnami Spark. Há um equívoco de que o Log4Shell não afeta a ramificação da versão mais antiga, mas isso não é verdade.
Finalmente, ao olhar para os servidores do Minecraft, que é o ponto de onde a descoberta do Log4Shell começou, a Rezilion descobriu 68.000 servidores potencialmente vulneráveis.
A Rezilion sugere que o estado de correção de hoje resulta de vários fatores que contribuem para o problema, incluindo a falta de processos adequados de gerenciamento de vulnerabilidades e baixa visibilidade.
O Log4j é difícil de detectar em ambientes de produção e as organizações nem sempre percebem que o estão usando por meio de software de terceiros.
Em resumo, as empresas não sabem se estão usando, não sabem qual versão usam e não sabem quais versões são seguras de usar.
Depois, há vários casos especiais, como o uso de políticas granulares de atualização de software em ambientes em contêineres que favorecem a estabilidade operacional e não obtêm as atualizações de software mais recentes disponíveis.
Como os boletins da CISA sobre a exploração ativa de falhas destacaram repetidamente, os hackers não se importam com a idade de uma vulnerabilidade, desde que ela os coloque em um dispositivo de destino.
Muitas vezes vemos bugs de 10 anos ainda sendo explorados ativamente na natureza, e o Log4Shell parece um excelente candidato para facilitar a continuação dessa prática.
Quatro meses após a descoberta e aplicação de patches, o Log4Shell ainda está presente, portanto, verifique seu ambiente, descubra qual versão você está usando e desenvolva um plano de atualização de emergência.
Se você achar que estava usando uma versão vulnerável todo esse tempo, assuma o compromisso e continue nesse caminho para verificar sinais de atividade maliciosa e erradicar qualquer backdoor plantado.
