Sicurezza Informatica
Spring4Shell: la nuova vulnerabilità che interessa Java e fa paura quanto Log4Shell
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)
Sicurezza Informatica
USA nordcoreani lavorano nell’IT e finanziano armi
Tempo di lettura: 2 minuti. Cinque individui accusati di schemi informatici per finanziare il programma di armi nucleari della Corea del Nord, con conseguenze legali significative. Scopri i dettagli delle accuse e delle sanzioni.
Le autorità statunitensi hanno incriminato cinque individui coinvolti in schemi informatici volti a generare entrate per il programma di armi nucleari della Corea del Nord. Questi schemi prevedevano la frode identitaria e l’infiltrazione nei mercati del lavoro statunitensi per ottenere lavori IT remoti. Tra gli arrestati, una cittadina americana, un uomo ucraino e tre cittadini stranieri sono accusati di diverse attività criminali, tra cui frode e riciclaggio di denaro.
Arizona: accusata di aiutare Nordcoreani per lavori IT remoti
Christina Marie Chapman, 49 anni, di Litchfield Park, Arizona, è stata accusata di aver aiutato cittadini nordcoreani a ottenere lavori IT remoti presso oltre 300 aziende statunitensi, generando milioni di dollari per il programma di missili balistici della Corea del Nord.
Dettagli dello schema
Secondo l’accusa federale, Chapman ha raccolto 6,8 milioni di dollari in questo schema, fondi che sono stati incanalati verso il Dipartimento dell’Industria delle Munizioni della Corea del Nord, coinvolto nello sviluppo di missili balistici. Lo schema prevedeva l’uso delle identità di più di 60 persone residenti negli Stati Uniti per ottenere lavori IT per cittadini nordcoreani presso oltre 300 aziende statunitensi.
Metodi utilizzati
Chapman e i suoi co-cospiratori avrebbero utilizzato informazioni personali compromesse per ottenere questi lavori e hanno gestito un “laptop farm” presso una delle sue residenze per far sembrare che i dipendenti nordcoreani lavorassero dagli Stati Uniti. I laptop venivano forniti dai datori di lavoro e i lavoratori utilizzavano proxy e VPN per apparire come se si connettessero da indirizzi IP statunitensi. Chapman riceveva anche gli stipendi dei dipendenti presso la sua abitazione.
Impatto e conseguenze
Questo complotto ha colpito una varietà di settori, tra cui un’importante rete televisiva nazionale, una principale azienda tecnologica della Silicon Valley, un produttore di difesa aerospaziale, un’iconica casa automobilistica americana, una catena di vendita al dettaglio di alta gamma e una delle aziende di media e intrattenimento più riconoscibili al mondo, tutte Fortune 500.
Nicole Argentieri, capo della Divisione Criminale del Dipartimento di Giustizia, ha sottolineato che questi crimini hanno beneficiato il governo nordcoreano, fornendo un flusso di entrate e, in alcuni casi, informazioni proprietarie rubate dai co-cospiratori. Chapman è stata arrestata mercoledì e, se condannata, potrebbe affrontare fino a 97,5 anni di carcere. In un caso correlato, un uomo ucraino, Oleksandr Didenko, è stato accusato di un complotto simile e potrebbe affrontare fino a 67,5 anni di carcere.
Sicurezza Informatica
Norvegia raccomanda di sostituire le VPN SSL
Tempo di lettura: 2 minuti. Il Centro Nazionale per la Sicurezza Informatica della Norvegia raccomanda di sostituire le VPN SSL con IPsec per prevenire violazioni di sicurezza.
Il Centro Nazionale per la Sicurezza Informatica della Norvegia (NCSC) ha raccomandato di sostituire le soluzioni SSL VPN/Web VPN con alternative più sicure a causa della continua sfruttamento delle vulnerabilità associate a questi dispositivi di rete.
Raccomandazioni e tempistiche
L’NCSC consiglia alle organizzazioni di completare la transizione entro il 2025, mentre quelle soggette alla “Safety Act” o che operano in infrastrutture critiche dovrebbero adottare alternative più sicure entro la fine del 2024. La raccomandazione principale è di passare a Internet Protocol Security (IPsec) con Internet Key Exchange (IKEv2).
Problemi delle VPN SSL
Le VPN SSL/WebVPN forniscono accesso remoto sicuro utilizzando i protocolli SSL/TLS, creando un “tunnel di crittografia” tra il dispositivo dell’utente e il server VPN. Tuttavia, le implementazioni di SSLVPN non seguono uno standard unico, portando a numerose vulnerabilità sfruttate dai hacker per violare le reti. Esempi recenti includono le vulnerabilità di Fortinet e Cisco sfruttate da gruppi di hacker come Volt Typhoon e le operazioni di ransomware Akira e LockBit.
Vantaggi di IPsec con IKEv2
IPsec con IKEv2 offre maggiore sicurezza crittografando e autenticando ogni pacchetto di dati e riducendo il margine di errore di configurazione rispetto alle soluzioni SSLVPN. Anche se IPsec non è privo di difetti, rappresenta una riduzione significativa della superficie di attacco per incidenti di accesso remoto sicuro.
Misure proposte
Le misure proposte includono:
- Riconfigurazione o Sostituzione delle Soluzioni VPN Esistenti: Migrare tutti gli utenti e i sistemi al nuovo protocollo.
- Disabilitazione delle Funzionalità SSLVPN: Blocco del traffico TLS in ingresso.
- Autenticazione Basata su Certificati: Migliorare l’autenticazione per l’accesso remoto.
Misure temporanee
Per le organizzazioni che non possono adottare immediatamente IPsec con IKEv2, l’NCSC suggerisce misure temporanee come il logging centralizzato delle attività VPN, restrizioni geografiche rigorose e il blocco dell’accesso da provider VPN, nodi di uscita Tor e provider VPS.
L’NCSC ha emesso queste raccomandazioni per migliorare la sicurezza delle reti aziendali e prevenire ulteriori violazioni. L’adozione di soluzioni più sicure come IPsec con IKEv2 rappresenta un passo importante per proteggere le infrastrutture critiche e i dati sensibili dalle minacce informatiche.
Sicurezza Informatica
Turla usa Lunar contro le agenzie governative europee
Tempo di lettura: 2 minuti. Hacker russi utilizzano i nuovi malware LunarWeb e LunarMail per violare le agenzie governative europee nella ricerca di Eset
Ricercatori di sicurezza hanno scoperto due nuove backdoor, denominate LunarWeb e LunarMail, utilizzati per compromettere istituzioni diplomatiche di un governo europeo nel Medio Oriente e questi malware, attivi dal 2020 sotto il ceppo di Lunar, sono attribuiti all’APT sponsorizzato dallo stato russo, Turla.
Catena di attacco Lunar
Secondo il rapporto di ESET, l’attacco inizia con email di spear-phishing contenenti file Word con macro dannose per installare la backdoor LunarMail. Questo stabilisce la persistenza creando un componente aggiuntivo di Outlook che si attiva ogni volta che il client di posta viene avviato.
I ricercatori hanno anche osservato l’uso potenziale di uno strumento di monitoraggio di rete open-source mal configurato, Zabbix, per distribuire il payload LunarWeb. Questo componente viene eseguito tramite una richiesta HTTP con una password specifica, decrittando ed eseguendo i componenti del loader e del backdoor.
Funzionamento della backdoor Lunar
LunarWeb e LunarMail sono progettati per una sorveglianza prolungata e nascosta, il furto di dati e il mantenimento del controllo sui sistemi compromessi. LunarWeb è utilizzato sui server, emulando traffico legittimo e nascondendo comandi in file di immagini tramite steganografia.
LunarMail si installa su workstation con Microsoft Outlook, usando un sistema di comunicazione basato su email per lo scambio di dati con il server C2.
Tecniche di persistenza e attacco
I malware Lunar utilizzano tecniche sofisticate per mantenere la loro presenza sui dispositivi infetti, inclusi estensioni delle policy di gruppo, sostituzione di DLL di sistema e distribuzione come parte di software legittimi. I payload vengono decrittati da un loader chiamato LunarLoader usando cifrature RC4 e AES-256.
Attribuzione e sofisticazione degli attacchi
Le somiglianze nei TTP (tattiche, tecniche e procedure) osservate indicano che il toolset Lunar è stato sviluppato e operato da individui multipli, con vari gradi di sofisticazione nelle compromissioni. Gli attacchi più recenti hanno rivelato che i backdoor sono stati utilizzati in operazioni non rilevate dal 2020.
Indicatori di compromissione
ESET ha fornito una lista di indicatori di compromissione (IoC) per file, percorsi, rete e chiavi di registro osservati negli ambienti compromessi. La lista completa è disponibile qui.
- Inchieste1 settimana fa
Perchè il motore di ricerca OpenAI fa paura ai giornalisti?
- L'Altra Bolla1 settimana fa
Meta arriva l’intelligenza artificiale per la Pubblicità
- L'Altra Bolla1 settimana fa
TikTok: azione legale contro Stati Uniti per bloccare il divieto
- L'Altra Bolla1 settimana fa
Meta testa la condivisione incrociata da Instagram a Threads
- L'Altra Bolla1 settimana fa
X sotto indagine dell’Unione Europea
- Robotica6 giorni fa
Come controllare dei Robot morbidi ? MIT ha un’idea geniale
- Smartphone1 settimana fa
Xiaomi 14 e 14 Ultra, problemi di condensa nelle fotocamere
- Smartphone1 settimana fa
Google Pixel 8a vs Pixel 8: quale scegliere?