Spring4Shell: Pesquisadores ainda procuram aplicativos exploráveis ​​do mundo actual

Pesquisadores de segurança Prosseguir para procurar aplicativos “na natureza” do mundo actual que podem ser explorados usando a vulnerabilidade de execução remota de código (RCE) no Spring Core, conhecido como Spring4Shell.

Mas no momento da redação deste artigo, a VentureBeat não está ciente de nenhum relatório público de aplicativos do mundo actual que são suscetíveis à exploração Spring4Shell.

“Nossa equipe de pesquisa está investigando isso e ainda não identificamos um aplicativo explorável”, disse a Randori Assault Crew em comentários fornecidos por email à VentureBeat na sexta-feira. A equipe, parte do fornecedor de gerenciamento de superfície de ataque Randorina quarta-feira liberado um script que pode ser usado para testar a suscetibilidade à vulnerabilidade Spring4Shell.

“Um sistema deve estar usando uma combinação específica de Tomcat, Java runtime e versões do framework Spring para ser potencialmente vulnerável – ele deve ter todos os ingredientes certos. No entanto, para ser vulnerável, os ingredientes precisam ser usados ​​da maneira certa – ou seja, o código deve ser implementado de uma certa maneira”, disse a equipe Randori nos comentários ao VentureBeat.

“É difícil identificar remotamente a versão do framework Spring”, disse a equipe. “Mesmo quando é conhecido, um invasor também deve conhecer um endpoint válido que united states of america o padrão vulnerável em seu código. Todos os itens acima tornam improvável que veremos algo semelhante à escala de Log4j.”

A equipe Randori acrescentou que continua monitorando ativamente quaisquer alterações, como avisos de fornecedores. Até agora, vários fornecedores ter liberado avisos indicando que eles estão investigando a possibilidade de que seus produtos sejam vulneráveis ​​ao Spring4Shell – mas nenhum é conhecido por ter confirmado a vulnerabilidade à falha RCE.

Na natureza

A comunidade de segurança tem tido uma “enorme luta para encontrar aplicativos vulneráveis ​​na natureza”, disse o profissional de segurança Chris Partridge, que compilou detalhes sobre a vulnerabilidade Spring4Shell. no GitHubem uma mensagem para VentureBeat na sexta-feira.

Partridge disse que está ciente de apenas um único relatório da exploração Spring4Shell funcionando em estado selvagem.

E essa instância não envolve realmente o aplicativo de outro fornecedor, mas, em vez disso, demonstrou que um exploit para a falha Spring4Shell poderia funcionar contra o código de amostra fornecido pelo Spring. Colin Cowie, analista de ameaças da Sophos, demonstrou isso em um submit na quarta-feira, assim como o analista de vulnerabilidade Will Dormann.

Isso provou que a vulnerabilidade Spring4Shell RCE é viável na natureza – e sugeriu que é provável que os aplicativos do mundo actual são vulneráveis para a falha, Dormann disse em um tuitar Quarta-feira.

Ainda assim, embora os aplicativos exploráveis ​​do mundo actual não tenham sido divulgados, isso não isenta as organizações que usam o well-liked framework Java Spring da necessidade de correção. A maioria ainda deve corrigir quando puderem, de acordo com especialistas que conversaram com a VentureBeat esta semana.

Outras explorações possíveis

Em parte, isso ocorre porque muito permanece desconhecido sobre o Spring4Shell, cujos detalhes vazaram na terça-feira e seus riscos potenciais. Em primeiro lugar, é provável que os invasores encontrem novas maneiras de explorar a vulnerabilidade de código aberto.

Assim, qualquer um que use o Spring deve considerar a implantação do patch – não apenas aqueles que sabem que têm uma configuração vulnerável, disse o CTO do Praetorian Richard Ford.

Como o Spring4Shell é uma “vulnerabilidade mais geral” – como o Spring observou em seu weblog sobre a vulnerabilidade na quinta-feira – o melhor conselho é que todos os usuários do Spring devem corrigir, se possível, disse Ford. Com o pace, “pode haver explorações mais gerais disponíveis”, disse ele.

Mesmo com o pior cenário para Spring4Shell, porém, é “muito improvável vamos acabar em uma situação semelhante” como Log4Shell, disse Ford.

Log4Shell — que generation divulgado em dezembro e afetou o device de log Apache Log4j — acredita-se que tenha impactado a maioria das organizações, devido ao uso generalizado do Log4j.

Requisitos de exploração

Na quinta-feira, a Spring publicou uma postagem no weblog com detalhes sobre patches, requisitos de exploração e soluções alternativas para Spring4Shell. A vulnerabilidade RCE, que está sendo rastreada no CVE-2022-22965, afeta o JDK 9 ou awesome e possui vários requisitos adicionais para que seja explorado, diz a postagem do weblog da Spring.

A exploração inicial exige que o aplicativo seja executado no Apache Tomcat como uma implantação WAR, que não é a maneira padrão de implantação de aplicativos – limitando um pouco o escopo do impacto da vulnerabilidade. O padrão, por outro lado, não é vulnerável à exploração inicial do Spring4Shell.

Na sexta-feira, foram lançadas novas versões do Apache Tomcat que abordam o vetor de ataque envolvido com a vulnerabilidade.

A coisa an important a ter em mente, no entanto, é que “mesmo que a exploração atual actual [a] configuração específica, a vulnerabilidade ainda é geral o suficiente e pode ser explorada de diferentes maneiras”, disse Manasi Prabhavalkar, gerente de produto da equipe de resposta a vulnerabilidades da Aqua Safety, em um email para a VentureBeat.

Conforme relatado pelo Spring, a vulnerabilidade envolve o acesso ao ClassLoader, observou Prabhavalkar. Mas mesmo que a exploração atual seja específica do Tomcat e actual de algumas pré-condições específicas, “outros ataques a outros tipos de ClassLoader também podem ser possíveis”, disse ela. “Provavelmente existem outros objetos mutáveis ​​acessíveis dessa maneira que podem levar à exploração dessa vulnerabilidade.”