Notizie
Spring4Shell: la nuova vulnerabilità che interessa Java e fa paura quanto Log4Shell

Tempo di lettura: 4 minuti.
Il 29 marzo 2022, una società cinese di ricerca sulla cybersicurezza ha fatto trapelare un attacco che potrebbe avere un impatto sulla maggior parte delle applicazioni Java aziendali, a livello globale. Un'indagine sul problema ha mostrato che la causa principale era una vulnerabilità nel framework di programmazione open-source ampiamente utilizzato, gratuito e sviluppato dalla comunità, chiamato Spring Core.
Cos'è Spring Core?
Il framework Spring è la base per la maggior parte delle applicazioni aziendali scritte nel linguaggio di programmazione Java. I nostri dati recenti mostrano che Spring Core è usato dal 74% delle applicazioni Java. In particolare, Spring fornisce l'”impianto idraulico” delle applicazioni aziendali in modo che i team possano concentrarsi sulla logica di business a livello di applicazione, senza inutili legami con specifici ambienti di distribuzione.
Cos'è Spring4Shell?
A partire dal 30 marzo, il team di Contrast Security Labs ha confermato la vulnerabilità 0-day attraverso l'uso di un poc pubblico, Spring4Shell, che potrebbe essere la fonte di Remote Code Execution (RCE).
Spring traduce il corpo e i parametri di una richiesta HTTP e li trasforma in un oggetto di dominio per gli sviluppatori da utilizzare. Questo rende la loro vita più facile.
Nel processo di costruzione di un grafico di oggetti da dare allo sviluppatore, Spring fa particolare attenzione a non permettere agli attaccanti di controllare qualsiasi parte di Class, ProtectionDomain e ClassLoader dell'istanza che viene creata. Sfortunatamente, le modifiche all'oggetto Class in Java 9 hanno fatto sì che i controlli effettuati da Spring non fossero più sufficienti.
Il codice in questione è mostrato qui:
PropertyDescriptor[] pds = this.beanInfo.getPropertyDescriptors();
per (PropertyDescriptor pd : pds) {
if (Class.class == beanClass && ("classLoader".equals(pd.getName()) || "protectionDomain".equals(pd.getName())))) {
// Ignorare i metodi Class.getClassLoader() e getProtectionDomain() - nessuno ha bisogno di legarsi a questi
continuare;
}
Questo codice tenta di limitare l'accesso dall'override di questi percorsi del grafico degli oggetti:
Class.getClassLoader() -> ClassLoader
Class.getProtectionDomain() -> ProtectionDomain
Tuttavia, poiché l'oggetto Class ora espone un metodo getModule(), gli attaccanti possono ora prendere questo percorso leggermente diverso:
Class.getModule() -> Module -> Module.getClassLoader()
L'introduzione di Class#getModule() non poteva essere prevista direttamente quando hanno scritto questo codice, anche se potremmo avere un dibattito animato sulla robustezza di questo stile di controllo.
Le conseguenze di consegnare agli utenti il controllo delle proprietà di ClassLoader dipendono dalle caratteristiche di ClassLoader che vengono sfruttate.
L'exploit e il PoC in corso mostrano un attaccante che sfrutta le caratteristiche di WebAppClassLoaderBase di Tomcat 9. L'exploit funziona in poche fasi:
- L'attaccante cambia l'obiettivo della funzione di log del ClassLoader per creare un nuovo file JSP dannoso
- L'attaccante usa alcuni trucchi per scrivere codice dannoso nel file JSP, creando una backdoor
- L'attaccante quindi fa una richiesta alla nuova backdoor JSP che poi invoca i comandi di sistema
- Java 9 è stato rilasciato nel luglio del 2017, quindi questa vulnerabilità è stata sfruttabile in app e API di produzione per cinque anni.
Il video qui sotto mostra l'exploit in poche rapide richieste. L'exploit invia un payload all'indice dell'applicazione Spring boot di base. L'exploit sfrutta la configurazione mancante del binding e crea un JSP dannoso sul filesystem in una directory accessibile al web. Da lì, viene inviata una richiesta con il comando “id” per richiedere l'ID corrente dell'utente che ritorna come “uid=0(root) gid=0(root) groups=0(root)” che mostra in questo caso l'applicazione è in esecuzione come root.
Come faccio a sapere se sono vulnerabile?
Ci sono alcuni requisiti perché un'applicazione sia vulnerabile:
- Utilizzi un'applicazione Spring (fino alla versione 5.3.17 inclusa)
- La tua applicazione gira su Java 9+
- Si usa il form binding con coppie nome=valore – non si usa la più popolare conversione di messaggi di Spring in JSON/XML
- Non usate una allowlist -oppure non avete una denylist che blocchi campi come “class”, “module”, “classLoader”
Quali sono le condizioni di vulnerabilità per l'exploit attualmente in circolazione?
Tutte le condizioni di cui sopra, e in più dovete avere Tomcat in esecuzione (una gamma di versioni ancora sconosciute, ma certamente inclusa la 9), perché l'exploit sfrutta il ClassLoader di Tomcat e la funzione di logging per scrivere un JSP maligno e backdoor.
È prudente assumere che arriveranno exploit che sfruttano diversi class loader o un altro contesto ambientale e che qualsiasi applicazione Spring vulnerabile che soddisfa le condizioni della prima sezione sarà vulnerabile.
Come posso mitigare il problema?
Per ora, Contrast Labs raccomanda:
- 1) Per tutti coloro che stanno usando Spring core e il binding a tipi non basilari come i POJO, impostare i campi consentiti per specificare i soli binding che desiderate che la vostra applicazione usi. Documentazione Spring
- 2) Per i clienti di Contrast, Protect può rilevare e bloccare l'attuale exploit pubblico che circola sul web. Tuttavia, gli autori di exploit troveranno rapidamente il modo di aggirarlo. L'exploit in circolazione installa una backdoor che è semplice da rilevare e bloccare. Stiamo lavorando su controlli più robusti al momento e li rilasceremo appena possibile.
Per ora, per proteggersi dall'exploit attualmente in circolazione, assicuratevi che Contrast Protect sia abilitato sulle vostre applicazioni Spring (specialmente quelle su JDK 9+). Come potete vedere nel video qui sotto, quando Protect è configurato correttamente, blocca l'attacco.
Spring4Shell con Protect Video:
Per aiutare a proteggere le vostre applicazioni dall'exploit attualmente in circolazione, ecco le impostazioni che dovreste abilitare nelle vostre applicazioni monitorate da Protect in modalità di blocco.
- (a) Iniezione di comandi in modalità di blocco Esempio quando Command Injection è in modalità di blocco.
- (b) Per una maggiore visibilità degli attacchi rivolti al vostro ambiente – Abilitate gli scudi CVE per CVE-2014-0112 e CVE-2014-0114 (questi scudi CVE specifici sono per problemi di Struts, tuttavia, a causa della natura simile dei payload, questo fornisce visibilità sugli attacchi attraverso Probes)
Notizie
Sony indaga sul presunto attacco informatico
Tempo di lettura: < 1 minuto. Sony è al centro di un’indagine riguardo a un presunto attacco informatico, mentre diversi gruppi di hacker rivendicano la responsabilità dell’attacco, creando confusione e incertezza sulla reale entità del danno.

Tempo di lettura: minuto.
Sony è attualmente al centro di un'indagine interna riguardo a un presunto attacco informatico. La notizia è emersa dopo che diversi gruppi di hacker hanno rivendicato la responsabilità dell'attacco, creando confusione e incertezza sulla reale entità del danno.
Dettagli dell'attacco
Nonostante la mancanza di dettagli concreti sull'attacco, Sony ha preso molto seriamente le rivendicazioni e ha avviato un'indagine interna per verificare l'entità del presunto attacco informatico. La società sta lavorando attivamente per identificare eventuali vulnerabilità nei propri sistemi e per assicurarsi che i dati degli utenti siano al sicuro.
Disaccordo tra gli hacker
La situazione è ulteriormente complicata dal fatto che diversi gruppi di hacker hanno rivendicato la responsabilità dell'attacco a Sony. Questo ha creato un clima di incertezza e confusione, rendendo difficile per gli investigatori determinare chi sia effettivamente dietro l'attacco. I gruppi di hacker sono in disaccordo tra loro, ognuno affermando di essere il vero responsabile dell'attacco a Sony.
Risposta di Sony
Sony ha rilasciato una dichiarazione in cui afferma di essere a conoscenza delle rivendicazioni e di stare lavorando incessantemente per verificare la loro veridicità. La società ha inoltre assicurato agli utenti che sta adottando tutte le misure necessarie per proteggere i loro dati e prevenire futuri attacchi informatici.
Mentre l'indagine è ancora in corso, è fondamentale che gli utenti restino vigili e adottino misure di sicurezza aggiuntive per proteggere i propri dati e informazioni personali. La situazione è in continua evoluzione e ulteriori dettagli emergeranno nei prossimi giorni.
Notizie
Nuovo APT “AtlasCross” usa la Croce Rossa Americana come esca per Phishing
Tempo di lettura: 2 minuti. Un nuovo gruppo di hacker, AtlasCross, usa la Croce Rossa Americana come esca per phishing, consegnando malware backdoor e rimanendo in gran parte non rilevato.

Tempo di lettura: 2 minuti.
Un nuovo gruppo di hacker APT denominato ‘AtlasCross' prende di mira le organizzazioni con esche di phishing che si spacciano per la Croce Rossa Americana per consegnare malware backdoor. La società di cybersecurity NSFocus ha identificato due trojan precedentemente non documentati, DangerAds e AtlasAgent, associati agli attacchi del nuovo gruppo APT. NSFocus riferisce che gli hacker di AtlasCross sono sofisticati ed elusivi, impedendo ai ricercatori di determinare la loro origine.
Catena di attacco AtlasCross

Gli attacchi di AtlasCross iniziano con un messaggio di phishing che finge di essere dalla Croce Rossa Americana, chiedendo al destinatario di partecipare a un “September 2023 Blood Drive”. Queste email contengono un allegato di un documento Word abilitato per macro (.docm) che invita la vittima a fare clic su “Abilita contenuto” per visualizzare il contenuto nascosto. Tuttavia, facendo ciò si attiveranno macro malevoli che infetteranno il dispositivo Windows con i malware DangerAds e AtlasAgent.
Dettagli AtlasAgent

AtlasAgent è un trojan personalizzato in C++ e le sue funzioni principali includono l'estrazione di dettagli host e processo, impedendo l'avvio di numerosi programmi, eseguendo ulteriore shellcode sulla macchina compromessa e scaricando file dai server C2 dell'attaccante. Al primo avvio, il malware invia informazioni ai server dell'attaccante, inclusi nome del computer locale, informazioni sull'adattatore di rete, indirizzo IP locale, informazioni sulla scheda di rete, architettura e versione del sistema operativo e una lista di processi in esecuzione.
Conclusione
Nonostante il rapporto di NSFocus sia il primo a dettagliare il nuovo gruppo di hacking, AtlasCross rimane una minaccia in gran parte sconosciuta che opera con motivi poco chiari e un ambito di targeting oscuro. La selezione mirata dell'attore della minaccia, i trojan su misura e i loader di malware, combinati con una preferenza per metodi di infezione discreti rispetto all'efficienza, hanno permesso loro di operare non rilevati per una durata indefinita.
Notizie
Hacker sfruttano attivamente una falla in Openfire per criptare i server
Tempo di lettura: 2 minuti. L’applicazione degli aggiornamenti di sicurezza disponibili è urgente per prevenire ulteriori attacchi. È cruciale applicare tutti gli aggiornamenti di sicurezza per i server non appena diventano disponibili.

Tempo di lettura: 2 minuti.
Gli hacker stanno sfruttando attivamente una vulnerabilità di alta gravità nei server di messaggistica Openfire per criptare i server con ransomware e distribuire cryptominer. Openfire è un server di chat open-source basato su Java, scaricato 9 milioni di volte e utilizzato estensivamente per comunicazioni di chat sicure e multi-piattaforma.
Dettagli della vulnerabilità
La falla, tracciata come CVE-2023-32315, è un bypass dell'autenticazione che colpisce la console di amministrazione di Openfire, permettendo agli aggressori non autenticati di creare nuovi account amministrativi sui server vulnerabili. Utilizzando questi account, gli aggressori installano plugin Java maligni (file JAR) che eseguono comandi ricevuti tramite richieste HTTP GET e POST. Questa pericolosa falla impatta tutte le versioni di Openfire dalla 3.10.0, datata 2015, fino alla 4.6.7 e dalla 4.7.0 alla 4.7.4.
Risposta di Openfire e Attacchi in Corso
Nonostante Openfire abbia risolto il problema con le versioni 4.6.8, 4.7.5 e 4.8.0, rilasciate a maggio 2023, VulnCheck ha segnalato che a metà agosto 2023, oltre 3.000 server Openfire erano ancora in esecuzione con una versione vulnerabile. Dr. Web ora segnala segni di sfruttamento attivo, poiché gli hacker hanno preso vantaggio della superficie di attacco per le loro campagne maligne.
Modalità di attacco
Il primo caso di sfruttamento attivo visto da Dr. Web risale a giugno 2023, quando la società di sicurezza ha indagato su un attacco ransomware a un server che è avvenuto dopo che CVE-2023-32315 è stato sfruttato per violare il server. Gli aggressori hanno sfruttato la falla per creare un nuovo utente amministrativo su Openfire, acceduto, e usato per installare un plugin JAR maligno che può eseguire codice arbitrario.
Ransomware sconosciuto
BleepingComputer ha trovato molteplici rapporti da clienti che affermano che i loro server Openfire sono stati criptati con ransomware, con uno che afferma che i file sono stati criptati con l'estensione .locked1. Non è chiaro quale ransomware sia dietro questi attacchi, ma le richieste di riscatto sono generalmente piccole, variando da 0,09 a 0,12 bitcoin ($2.300 a $3.500).
- Editoriali2 settimane fa
Vannacci è diventato ricco grazie alle armi spuntate del Mainstream
- L'Altra Bolla2 settimane fa
Elon Musk e X Corp. contro lo stato della California sulla legge AB 587
- Editoriali2 settimane fa
Zelensky fa uso di cocaina? I dubbi e le paure su un alleato “tossico”
- L'Altra Bolla2 settimane fa
Corte d’appello USA: Governo Biden e l’FBI hanno viziato le opinioni social
- L'Altra Bolla3 settimane fa
YouTube sperimenta pulsante “Iscriviti” luminoso
- DeFi3 settimane fa
MetaMask ecco la funzione di scambio ETH in valuta fiat
- L'Altra Bolla2 settimane fa
YouTube e l’intelligenza artificiale insieme per la creatività pubblicitaria
- Tech2 settimane fa
Google Pixel 8: le novità che fanno crescere l’attesa