Rilevamento di Spring4Shell: Nuova vulnerabilità Java segue le orme del noto Log4j
Indice:
Quando arriva la primavera, i bug fioriscono. Una nuova vulnerabilità estremamente grave nel Spring Cloud Function è stata individuata il 29 marzo 2022. Una vulnerabilità facile da sfruttare che colpisce il modulo Spring Core – un framework utilizzato nelle applicazioni Java, e richiede JDK9+. Se sfruttata, questa vulnerabilità di Spring Core consente agli hacker di eseguire attacchi di esecuzione di codice remoto (RCE).
Finora, si ritiene che Spring4Shell abbia un potenziale critico difetto RCE di Log4j.
Rileva Spring4Shell
Per garantire che il tuo sistema non sia stato compromesso, utilizza le seguenti regole rilasciate dal team SOC Prime insieme a Florian Roth. Le fseguenti regole rilevano possibili tentativi di sfruttamento della vulnerabilità SpringCore RCE.
Possibile accesso iniziale tramite tentativo di sfruttamento di Spring4Shell (via web)
Oltre alle rilevazioni Sigma sopra, puoi utilizzare la regola YARA rilasciata da Florian Roth:
Possibili schemi di sfruttamento di Spring4Shell – Regole YARA
Segui gli aggiornamenti sui contenuti di rilevamento relativi a Spring4Shell nel repository Threat Detection Marketplace della piattaforma SOC Prime qui. Sei uno sviluppatore di contenuti di rilevamento? Unisciti alla più grande comunità di difesa informatica del mondo potenziata dal programma Threat Bounty per attingere alla forza della comunità di cybersecurity e guadagnare ricompense ricorrenti per il tuo prezioso contributo.
Visualizza tutto il contenuto Unisciti a Threat Bounty
Analisi dell’exploit Spring4Shell
Una nuova vulnerabilità zero-day Spring4Shell che sta attualmente guadagnando slancio è stata individuata il 29 marzo 2022, nel Spring Framework – uno dei framework più richiesti in Java. L’applicazione Spring fornisce strumenti per gli sviluppatori per costruire alcuni dei modelli comuni nei sistemi distribuiti. La nuova vulnerabilità di Spring Cloud è già stata soprannominata Spring4Shell per la somiglianza con la vulnerabilità di Apache Log4j2 che ha generato un enorme clamore nel dicembre 2021.
L’impatto di SpringShell su sistemi compromessi è inevitabile: l’exploit, proprio come Log4Shell, è molto facile da realizzare. Successivamente, gli avversari sono in grado di creare script che scansionano Internet e sfruttano automaticamente i server suscettibili poiché lo sfruttamento coinvolge solo un semplice POST HTTP a un’app vulnerabile. Gli attori delle minacce possono utilizzare queste falle per eseguire comandi sul server, garantendo loro il controllo remoto completo del dispositivo infetto.
Inoltre, le Spring Cloud Functions possono essere utilizzate in funzioni serverless cloud come AWS Lambda e Google Cloud Functions, rendendo i tuoi account cloud un bersaglio per gli hacker desiderosi di sfruttare al massimo questa vulnerabilità.
Non è necessario menzionare che questa falla nel progetto Spring si basa su configurazioni specifiche per essere sfruttata con successo. In alcuni casi, lo sfruttamento di questa falla è semplice, poiché tutto ciò che un aggressore deve fare è inviare una richiesta POST appositamente formattata a un sistema mirato. Tuttavia, lo sfruttamento di tali configurazioni richiederà un investimento extra di tempo e risorse da parte dell’attaccante per avvelenare correttamente i payload mirati a un’applicazione Spring e ottenere il controllo completo del sistema.
Al 31 marzo 2022, non c’è un CVE associato a questa particolare falla, anche se ci sono altre due nuove vulnerabilità rivelate relative al progetto Spring – CVE-2022-22963 e CVE-2022-22950.
I rischi potenziali e reali inflitti da questa vulnerabilità RCE di Spring Core su applicazioni reali del mondo reale devono ancora essere determinati.
Unisciti a SOC Prime’s Detection as Code piattaforma per ottenere continuamente gli ultimi aggiornamenti sugli sviluppi del panorama delle minacce, migliorare la copertura delle minacce e scavalcare gli attaccanti raggiungendo i contenuti di rilevamento più rilevanti allineati con la matrice MITRE ATT&CK.