O Spring4Shell foi Abusado em Campanha para Empurrar 0 Mirai
As implementações baseadas no Java parecem ser o presente que continua sendo dado. Com relatórios ocasionais de esforços contínuos para explorar o Log4j , a vulnerabilidade que estava na mente de todos no inverno, agora estão chegando notícias da exploração ativa da mais recente vulnerabilidade significativa descoberta na biblioteca do Spring Core Java.
O Malware Mirai Transformado em Arma Usado na Campanha
A campanha de ataque usando o Spring4Shell está sendo monitorada por duas empresas de pesquisa de segurança separadas. Agora, as equipes de pesquisa estão identificando um velho conhecido sendo usado para explorar a vulnerabilidade no Spring4Shell.
Ambas as empresas de segurança notaram que uma versão armada do malware Mirai, comumente associada ao uso de botnets, estava sendo usada para explorar ativamente a falha no Spring4Shell.
Ao examinar os sistemas vulneráveis à nova campanha que leva o Mirai a abusar do Spring4Shell, os pesquisadores identificaram uma série de características encontradas em sistemas suscetíveis à exploração. Isso inclui a presença da estrutura Spring, a execução de correções anteriores à 5.2.20 e o JDK atualizado para as versões 9 ou mais recentes. A falha no Spring4Shell é conhecida por não afetar plataformas que executam o Java Development Kit mais antigo, tal como o JDK 8.
O Apache Tomcat e configurações específicas de vinculação de parâmetros do Spring, definidas para usar um tipo de parâmetro não básico, também estão entre os recursos específicos para os sistemas vulneráveis.
Primeiras Tentativas de Abusar da Falha e Adiar a Data do Mirai para o Final de Março
Honeypots operados por pesquisadores detectaram as primeiras tentativas de invasão no último dia de março de 2022.
Os ataques que implantam o malware Mirai transformado em arma nos sistemas vulneráveis ao Spring4Shell foram principalmente focados em alvos localizados em Cingapura e na região.
Os pesquisadores esperam que os ataques que tentam explorar a vulnerabilidade Spring4Shell só aumentem em volume nos próximos meses, já que a falha foi bem documentada e os detalhes estão disponíveis para os agentes de ameaças também. A correção continua tão essencial como sempre, mas semelhante ao caso do Log4j, o problema aqui não é a correção, mas o grande número de sistemas executando código vulnerável. Nesse sentido, mesmo 1% dos sistemas sem patch de milhões é um número significativo de alvos potenciais para a exploração.