0
0
Os atacantes que querem explorar a vulnerabilidade crítica de execução de código remoto divulgada na ferramenta de registro Apache Log4j há mais de quatro meses ainda têm uma vasta gama de alvos para ir atrás.
Em uma varredura recente usando o mecanismo de pesquisa Shodan, a Rezilion encontrou mais de 90.000 servidores expostos à Internet contendo uma versão vulnerável do software. O fornecedor de segurança acredita que o número representa apenas uma pequena fração dos alvos de invasor disponíveis porque ele só considera enfrentar publicamente servidores executando software de código aberto. Se servidores de rede internas e servidores executando aplicativos proprietários forem contabilizados, o número total de alvos vulneráveis provavelmente será muito maior, disse Rezilion.
Um relatório da Rezilion esta semana que resumiu os resultados de seu estudo apontou outros pontos de dados que parecem reforçar a conclusão da empresa.
Entre eles estão dados de um serviço de digitalização de código aberto do Google chamado Open Source Insights, que mostrou que apenas 7.140 pacotes Java de um total de 17.840 pacotes afetados foram corrigidos para Log4Shell desde que a falha foi divulgada. Outro ponto de dados do Sonatype descobriu que, a partir de 20 de abril de 2022, cerca de 36% das versões do Log4j sendo baixadas ativamente do repositório de aplicativos Maven Central Java ainda eram vulneráveis ao Log4Shell — um número que permaneceu praticamente inalterado desde fevereiro.
“Semelhante a outras vulnerabilidades históricas de alto perfil, embora quatro meses se passaram, ainda há uma enorme superfície de ataque vulnerável ao Log4Shell”, diz Yotam Perkal, diretor de pesquisa de vulnerabilidades da Rezilion. “Os 90.000 servidores vulneráveis de acesso público provavelmente são apenas a ponta do iceberg em termos de superfície de ataque vulnerável real.”
A Fundação Apache divulgou a vulnerabilidade Log4Shell (CVE-2021-44228) juntamente com uma versão atualizada e fixa do software em 9 de dezembro de 2021. A falha está presente em praticamente todos os ambientes de aplicação Java, é considerada trivialmente fácil de explorar, e dá aos atacantes uma maneira de obter controle completo sobre sistemas vulneráveis. Muitos especialistas em segurança consideram a falha uma das mais perigosas a serem divulgadas na memória recente, e pediram às organizações que instalem a versão atualizada e fixa do software o mais rápido possível.
Apesar das altas preocupações, houve muito poucos casos divulgados publicamente da falha sendo explorada em uma grande violação. No entanto, há temores consideráveis de que, em muitos casos, os atacantes já tenham explorado silenciosamente a falha para obter acesso a redes corporativas e estão esperando um momento oportuno para atacar.
Especialistas em segurança apontaram a onipresença da falha e a dificuldade envolvida em detectá-la — arquivos Java contendo a falha às vezes podem ser enterrados dentro de aplicações — como razões potenciais para o ritmo lento de remediação até agora.
Rezilion disse que uma questão é que muitas pessoas estão usando involuntariamente software que depende de versões vulneráveis do Log4j, seja porque eles não têm visibilidade em seus componentes de software ou estão usando softwares de terceiros vulneráveis. A falha do Log4j também provou ser desafiadora de detectar em ambientes de produção.
A ponta do iceberg?
Perkal diz que os 90.000 servidores vulneráveis que o Rezilion encontrou através de uma pesquisa do Shodan continham componentes de código aberto com versões obsoletas — e, portanto, potencialmente vulneráveis — do Log4j; componentes com versões Log4j atualizadas que continham evidências de uso de versões vulneráveis anteriores e potenciais; e servidores Minecraft voltados para o público com versões log4j vulneráveis.
“Provavelmente há muitos servidores executando esses aplicativos em redes internas e, portanto, não visíveis publicamente através do Shodan”, diz Perkal. “Devemos assumir que também existem aplicativos proprietários, bem como produtos comerciais ainda executando versões vulneráveis do Log4j.”
Significativamente, todos os componentes de código aberto expostos continham um número significativo de vulnerabilidades adicionais que não estavam relacionadas ao Log4j. Em média, metade das vulnerabilidades foram divulgadas antes de 2020, mas ainda estavam presentes na versão “mais recente” dos componentes de código aberto, diz ele. A análise da Rezilion mostrou que, em muitos casos, quando os componentes de código aberto foram corrigidos, levou mais de 100 dias para que a versão corrigida ficasse disponível através de plataformas como o Docker Hub.
Nicolai Thorndahl, chefe de serviços profissionais da Logpoint, diz que a detecção de falhas continua sendo um desafio para muitas organizações, porque enquanto o Log4j é usado para fazer login em muitos aplicativos, os provedores de software nem sempre divulgam sua presença em notas de software. “Então, muitas empresas realmente não sabem se ele está sendo usado em seu sistema ou não”, diz Thorndahl.
Muitas vezes, muitos aplicativos estão usando versões antigas do Log4j que não estão mais sendo suportadas e são vulneráveis. “Muito poucas, se houver, as empresas têm um [banco de dados de gerenciamento de configuração] tão detalhado que mostraria onde estão usando o Log4j”, diz ele.
Thorndahl espera que haja mais ataques explorando a falha, embora tenha havido muito poucos até agora.
“O mais provável é que o que veremos seja, talvez quatro meses, talvez um ano, como vimos antes, é que os incidentes serão divulgados [onde] as empresas detectaram que foram violadas e a vulnerabilidade do Log4j foi usada e provavelmente tiveram acesso por um longo período de tempo”, diz ele.
FONTE: DARK READING