Oracle Cloud: 6 milioni di record esposti — cosa è successo davvero
Un attore di minaccia ha sottratto credenziali SSO e chiavi LDAP da Oracle Cloud Infrastructure. Il vendor ha inizialmente negato tutto. I dati erano già in vendita online.
Cos’è successo
A fine marzo 2025 un attore di minaccia conosciuto come “rose87168” ha pubblicato su BreachForums la disponibilità di un dataset contenente milioni di record estrapolati dai sistemi Oracle Cloud. Il campione pubblicato includeva hash di password, file Java KeyStore (JKS), chiavi private di cifratura e credenziali LDAP/SSO associate a istanze Oracle Identity Manager.
Secondo la ricostruzione dei ricercatori di CloudSEK — una delle prime aziende di threat intelligence a pubblicare un’analisi tecnica dettagliata — l’attaccante avrebbe sfruttato la vulnerabilità CVE-2021-35587, una falla critica (CVSS 9.8) in Oracle Access Manager che consente l’accesso non autenticato tramite URL malformati. Questa vulnerabilità era nota dal 2021 e patchata da Oracle, ma evidentemente non applicata su alcuni endpoint esposti.
Oracle ha inizialmente risposto con una dichiarazione pubblica in cui negava qualsiasi breach: “No Oracle Cloud customers experienced a breach or lost any data”. Tuttavia, giornalisti di BleepingComputer hanno verificato in modo indipendente l’autenticità di alcuni record del campione contattando direttamente le aziende citate, che hanno confermato la corrispondenza con i loro dati reali.
“La negazione iniziale di Oracle ha complicato la risposta agli incidenti per centinaia di organizzazioni, che non sapevano se agire o attendere.” — Kevin Beaumont, ricercatore di sicurezza indipendente (aprile 2025)
La cronologia dell’incidente
Fine marzo 2025 — L’attore “rose87168” pubblica il post su BreachForums con campioni di dati e richiede un pagamento per non diffondere l’intero dataset.
2 aprile 2025 — Oracle rilascia una dichiarazione pubblica negando qualsiasi violazione dei sistemi cloud e dei dati dei clienti.
4–7 aprile 2025 — BleepingComputer e CloudSEK confermano l’autenticità di record specifici. Alcune aziende riconoscono i propri dati nel campione pubblicato.
Metà aprile 2025 — Secondo report di BleepingComputer, Oracle avrebbe iniziato a notificare alcuni clienti in modo privato, descrivendo l’evento come breach di un “sistema legacy”.
Aprile–maggio 2025 — La CISA tiene monitorata la situazione. Diverse organizzazioni avviano procedure di incident response e rotazione delle credenziali compromesse.
Cosa contenevano i dati rubati
Il dataset pubblicato includeva diverse categorie di informazioni sensibili. Secondo l’analisi tecnica di CloudSEK, erano presenti:
Credenziali di autenticazione: hash di password (in formato bcrypt e altri), nomi utente e indirizzi email associati a tenant Oracle Identity Manager. Alcuni hash sono stati già tentati con attacchi offline.
Chiavi crittografiche: file Java KeyStore (JKS) contenenti certificati e chiavi private usati per la firma e la cifratura delle comunicazioni tra servizi Oracle. La compromissione di questi file può consentire attacchi di tipo man-in-the-middle o impersonificazione di servizi.
Dati di configurazione LDAP: credenziali e parametri di connessione ai directory server aziendali. Questi dati sono particolarmente critici perché spesso consentono l’accesso a infrastrutture Active Directory on-premise tramite federated identity.
La caratteristica più preoccupante non è il volume dei dati — è la qualità. Chiavi private e credenziali SSO offrono un punto d’ingresso diretto alle reti aziendali, non solo ai sistemi cloud.
La vulnerabilità alla base: CVE-2021-35587
La falla sfruttata è classificata con punteggio CVSS 9.8 (critico) e riguarda Oracle Access Manager, il componente responsabile della gestione delle identità e dell’autenticazione SSO in Oracle Fusion Middleware. La vulnerabilità consente a un attaccante remoto non autenticato di compromettere il sistema tramite l’invio di richieste HTTP appositamente costruite.
Oracle aveva rilasciato la patch nel Critical Patch Update di gennaio 2022. Tuttavia, la persistenza di sistemi non aggiornati — specialmente negli endpoint di Oracle Cloud esposti su Internet — ha reso possibile l’exploitation anche anni dopo. La CISA aveva già incluso questa CVE nel suo catalogo Known Exploited Vulnerabilities (KEV) nel novembre 2022, richiedendo alle agenzie federali statunitensi di applicare la patch entro tre settimane.
Fonti: CISA KEV Catalog · NVD/NIST CVE-2021-35587 · Oracle Critical Patch Update gennaio 2022 · BleepingComputer (aprile 2025) · CloudSEK (aprile 2025)
Perché Oracle ha negato — e cosa ci insegna
La risposta iniziale di Oracle ha suscitato forte critica nella comunità di sicurezza. Secondo alcune interpretazioni, la dichiarazione aziendale sarebbe stata tecnicamente vera ma deliberatamente fuorviante: Oracle avrebbe qualificato il sistema compromesso come “Oracle Classic” — un ambiente legacy — e non come “Oracle Cloud Infrastructure” nel senso moderno del termine, consentendo così la negazione formale del breach.
Questo schema comunicativo — negare un breach attraverso distinzioni semantiche — è problematico perché ritarda la risposta degli utenti colpiti. Ogni ora in cui le credenziali compromesse rimangono attive aumenta il rischio di uso malevolo. Il GDPR impone alle organizzazioni europee che abbiano subito la compromissione di dati personali di notificare l’autorità competente entro 72 ore dall’accertamento.
Il quadro più ampio: cloud e falsa percezione di sicurezza
Il breach Oracle non è un caso isolato. Nel 2024, secondo l’IBM X-Force Threat Intelligence Index 2025, il 30% di tutti gli incidenti analizzati ha riguardato ambienti cloud. Il vettore più comune rimane il furto di credenziali, seguito dallo sfruttamento di vulnerabilità note non patchate.
Il modello di responsabilità condivisa del cloud — in cui il provider garantisce la sicurezza dell’infrastruttura sottostante, ma il cliente è responsabile della configurazione, della gestione delle identità e del patching — richiede che entrambe le parti facciano la loro parte. Quando un provider nega o minimizza un incidente, rompe questo patto fiduciario e trasferisce un rischio inaccettabile agli utenti.
