Oracle ha negato il breach, ma ricercatori e clienti confermano:…

Il 20 marzo 2025 un hacker con lo pseudonimo _rose87168_ ha pubblicato su BreachForums la disponibilità di oltre 6 milioni di record sottratti da più di 140.000

{"main_topic":"oracle","topics":["oracle","cloud","cybersecurity","vulnerabilita","cve"]}

Il 20 marzo 2025 un hacker con lo pseudonimo _rose87168_ ha pubblicato su BreachForums la disponibilità di oltre 6 milioni di record sottratti da più di 140.000 tenant Oracle Cloud, mettendo in vendita credenziali SSO/LDAP, chiavi OAuth2 e configurazioni interne. Oracle ha smentito qualsiasi violazione attraverso un portavoce citato da The Register, ma Trustwave Holdings Inc. ha analizzato i campioni e riferito coerenza con ambienti Oracle reali, mentre BleepingComputer ha verificato l'autenticità contattando direttamente aziende coinvolte. L'incidente riapre il caso della vulnerabilità CVE-2021-35587, patchata nel gennaio 2022 ma ancora presente su endpoint esposti.

Punti chiave

L'hacker _rose87168_ ha dichiarato il 20 marzo 2025 di possedere 6 milioni di record da oltre 140.000 tenant Oracle Cloud, con credenziali e chiavi di federazione identity.
Oracle ha negato pubblicamente la violazione; Trustwave e BleepingComputer hanno invece confermato l'autenticità di campioni dei dati trapelati attraverso verifiche dirette con aziende interessate.
La vulnerabilità sfruttata è CVE-2021-35587 in Oracle Access Manager, con punteggio CVSS 9.8 CRITICAL, risolta da Oracle nel Critical Patch Update di gennaio 2022 ma non applicata su sistemi cloud esposti.
A metà aprile 2025 Oracle avrebbe iniziato notifiche private ai clienti descrivendo l'evento come breach di "sistema legacy", in contrasto con la negazione pubblica iniziale.

Il meccanismo: CVE-2021-35587 e il gap di patch su cloud esposti

La vulnerabilità CVE-2021-35587 colpisce Oracle Access Manager, componente di gestione dell'identità e dell'accesso federato. Il National Vulnerability Database assegna alla falla un punteggio CVSS 3.1 di 9.8 con vettore AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: accesso da rete, complessità bassa, nessun privilegio richiesto, nessuna interazione utente, impatto massimo su confidenzialità, integrità e disponibilità. Oracle ha rilasciato la correzione nel Critical Patch Update di gennaio 2022. CISA ha inserito la vulnerabilità nel catalogo KEV (Known Exploited Vulnerabilities) nel novembre 2022, segnalando attività di sfruttamento attivo nel campo.

Secondo Audita.tech, che riporta analisi di CloudSEK, l'hacker avrebbe sfruttato endpoint Oracle Cloud rimasti esposti e non patchati dal 2022. La persistenza di sistemi legacy con Access Manager vulnerabile in ambiente cloud — nonostante la disponibilità di fix da oltre tre anni — indica un problema di igiene di patch su infrastrutture gestite o co-gestite dal vendor. Il dossier non specifica se Oracle abbia mantenuto diretto controllo operativo sui sistemi interessati o se la responsabilità della mancata applicazione ricada su clienti in configurazioni ibride.

L'evidenza: quando vendor e ricercatori dicono cose diverse

La fonte principale, Federprivacy, riporta la dichiarazione Oracle attraverso The Register: "non c'era stata alcuna violazione di Oracle Cloud... le credenziali pubblicate non sono per Oracle Cloud. Nessun cliente Oracle Cloud ha subito una violazione o perso dati". La formulazione è semanticamente precisa: Oracle Cloud come prodotto marchiato, non "Oracle Cloud" come qualsiasi risorsa ospitata da Oracle.

Contro questa negazione, Trustwave Holdings Inc. ha pubblicato analisi il 27 marzo 2025 attestando che la struttura dei dati in vendita è coerente con ambienti Oracle reali. BleepingComputer ha proceduto a verifica diretta: ha contattato aziende citate nei campioni e ottenuto conferma di autenticità. Il dossier non quantifica il numero esatto di aziende che hanno riconosciuto propri dati. La discrepanza tra negazione pubblica Oracle e conferme indipendenti costituisce il nucleo dell'ambiguità investigata in questo articolo.

La "negazione tecnica" come strategia di comunicazione

A metà aprile 2025, secondo Audita.tech, Oracle ha iniziato notifiche private ai clienti descrivendo l'evento come breach di "sistema legacy". Questa informazione, riportata indirettamente, se confermata documenta una biforcazione comunicativa: negazione pubblica assoluta, ammissione privata circoscritta. Il dossier non contiene il testo integrale delle notifiche private né la loro portata.

"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 indipendente, citato da Audita.tech

La citazione di Kevin Beaumont identifica un costo operativo misurabile: il ritardo nella rotazione credenziali e nell'attivazione di controlli compensativi. Il brief non documenta quali specifiche azioni correttive Oracle abbia raccomandato nelle comunicazioni private, né se il vendor abbia fornito strumenti di verifica ai clienti.

Perché è importante

Il dossier non specifica la natura esatta dei dati esposti oltre alle categorie dichiarate dall'hacker: credenziali, chiavi OAuth2, configurazioni interne. Non documenta se le chiavi private in possesso dell'attore siano crittograficamente attive o revocabili, né il volume effettivo di dati realmente compromessi rispetto ai 6 milioni dichiarati. La data effettiva della compromissione precede il 20 marzo 2025, ma il brief non la determina.

Il brief non documenta misure correttive specifiche indicate da Oracle nelle notifiche private, né raccomandazioni operative esplicite per i clienti. Non specifica se autorità privacy o la SEC abbiano avviato indagini formali. Lo stato delle indagini interne Oracle resta unknown.

L'incidente si colloca in un pattern più ampio di "denial breach" da vendor cloud: dichiarazioni tecnicamente difendibili — "nessun breach del servizio marchiato X" — che operativamente ritardano la risposta dei clienti. Per le aziende con federazione identity verso sistemi on-premise, la compromissione di credenziali SSO/LDAP in cloud espone directory aziendali indipendentemente dalla classificazione ufficiale dell'evento.

Domande che il caso solleva

Come può un vendor negare un breach tecnicamente e ammetterlo privatamente?

Il brief documenta solo che Oracle ha usato formulazione pubblica circoscritta a "Oracle Cloud" come prodotto, mentre notifiche private riferite da Audita.tech usavano termine "sistema legacy". La distinzione tra piattaforma classica e moderna permette negazioni semanticamente vere su una definizione ristretta, senza coprire infrastrutture cloud gestite sotto etichetta storica. Il brief non contiene testo integrale delle comunicazioni private.

Perché una vulnerabilità patchata nel 2022 è ancora sfruttabile nel 2025?

Il dossier indica che CVE-2021-35587 è stata patchata nel gennaio 2022 e inserita nel catalogo CISA KEV nel novembre 2022. La presenza di endpoint esposti non aggiornati tre anni dopo il rilascio della correzione suggerisce problemi di gestione del ciclo di vita su componenti cloud, ma il brief non specifica se la mancata applicazione dipenda da Oracle o da configurazioni clienti in ambienti ibbridi.

Cosa confermano esattamente le aziende interessate?

Trustwave ha riferito coerenza con ambienti Oracle reali. BleepingComputer ha ottenuto conferma di autenticità da aziende contattate direttamente. Il brief non quantifica né identifica queste aziende, né distingue tra conferma di singoli record e convalida dell'intero dataset. Il numero preciso di conferme resta unknown.

Il caso Oracle Cloud del marzo-aprile 2025 non si risolve con la verifica tecnica di una violazione, ma con la misura del divario tra ciò che un vendor può legittimamente negare in pubblico e ciò che i suoi clienti devono invece presumere vero per proteggersi. Quando credenziali federate e chiavi di accesso aziendale circolano su forum criminali, la distinzione tra "cloud" e "legacy" è semantica per il comunicato stampa, non per il team di sicurezza che deve ruotare password e invalidare sessioni. Il costo della negazione tecnica non è reputazionale: è operativo, misurato in giorni di ritardo nella risposta a un incidente già in corso.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti