Dropbox viola la fiducia SSO con Lenovo, Proton torna in outage dopo Francoforte

🛡️ Executive Summary

• Account Dropbox sono stati violati sfruttando Lenovo ID creati con indirizzi email delle vittime e successivamente accettati attraverso il login federato.
• Dropbox non rileva accesso o download dei file, ha corretto il problema e invalidato le sessioni precedentemente autenticate tramite Lenovo ID.
• Proton registra un nuovo outage parziale attribuito a guasti hardware residui dopo il surriscaldamento del data center di Francoforte del 27 agosto.

Due incidenti differenti riportano al centro lo stesso problema: quanto può essere affidabile un servizio digitale quando la sicurezza o la disponibilità dipendono da componenti esterni alla piattaforma principale. Dropbox sta notificando ad alcuni utenti accessi non autorizzati avvenuti tra il 4 e il 21 agosto 2026, dopo che aggressori sono riusciti a utilizzare Lenovo ID associati agli indirizzi email delle vittime per entrare negli account attraverso il meccanismo di autenticazione federata. Proton affronta invece un nuovo outage parziale che interessa Mail, VPN, Drive, Pass e altri servizi. In questo secondo caso non emerge un attacco informatico: l’azienda collega i problemi a guasti hardware residui provocati dal surriscaldamento del data center di Francoforte che aveva già causato il blackout globale del 27 agosto.

Dropbox: accessi non autorizzati attraverso Lenovo ID

Dropbox ha iniziato a inviare comunicazioni agli utenti coinvolti spiegando di avere osservato accessi non autorizzati agli account tra il 4 e il 21 agosto. Secondo il testo delle notifiche riprodotto pubblicamente, i log non mostrerebbero evidenze che i file siano stati visualizzati o scaricati, elemento importante per distinguere l’accesso abusivo all’account da una violazione già confermata dei contenuti conservati nel cloud. Il vettore individuato riguarda l’integrazione con Lenovo, utilizzato da Dropbox come identity provider per consentire agli utenti di autenticarsi attraverso un Lenovo ID verificato. L’indagine avrebbe stabilito che un problema nel processo di verifica dell’email di Lenovo permetteva a un soggetto non autorizzato di registrare un account Lenovo utilizzando l’indirizzo di posta della vittima e successivamente utilizzare quell’identità per entrare nel corrispondente account Dropbox. La partnership tra i due servizi è reale e documentata anche dalla pagina ufficiale Dropbox dedicata all’integrazione Lenovo, che prevede esplicitamente servizi cloud collegati all’ecosistema del produttore hardware.

Il problema non riguarda soltanto Lenovo ma il collegamento automatico dell’identità

Il passaggio tecnicamente più delicato riguarda il modo in cui viene gestito il Single Sign-On. Secondo la ricostruzione disponibile, l’attaccante poteva creare un Lenovo ID utilizzando l’indirizzo email della vittima, selezionare successivamente l’accesso Dropbox tramite Lenovo e ottenere dal provider un token contenente lo stesso indirizzo associato all’account Dropbox esistente. A quel punto Dropbox avrebbe collegato automaticamente l’identità federata all’account sulla base della corrispondenza dell’email, senza richiedere la password Dropbox, una verifica aggiuntiva sull’account già esistente o una conferma esplicita dell’utente per autorizzare il nuovo identity provider. La vulnerabilità iniziale nella verifica dell’indirizzo viene attribuita a Lenovo, ma la portata dell’incidente dipende quindi anche dalla fiducia transitiva concessa dal servizio destinatario: un provider esterno certifica un attributo, Dropbox accetta quell’attributo e genera una sessione. È esattamente il tipo di problema che rende l’identità federata una componente critica della sicurezza moderna, perché compromettere il processo di attestazione a monte può rendere inutile la robustezza della password dell’account finale. Dropbox dichiara di avere corretto il problema e invalidato tutte le sessioni precedentemente autenticate tramite Lenovo ID.

Leggi anche: Furto di dati e segreti di autenticazione per Dropbox Sign

Password e MFA possono essere aggirate quando la fiducia passa dall’identity provider

L’episodio è particolarmente significativo perché dimostra che password forte e autenticazione multifattore non proteggono necessariamente da un errore nel federation layer. Dropbox utilizza normalmente codici di sicurezza aggiuntivi quando rileva accessi da dispositivi o località sconosciuti e, nella propria documentazione sul codice monouso, presenta questo controllo come un ulteriore livello per impedire accessi non autorizzati. Ma un flusso federato può seguire regole differenti: se l’identità presentata da un provider considerato affidabile viene accettata come prova sufficiente, la sicurezza dell’account dipende anche dalla qualità della verifica eseguita dal partner. Il problema non è nuovo per Dropbox sotto il profilo generale dell’identità. Nel 2024 Dropbox Sign aveva subito un incidente molto diverso, con esposizione di informazioni comprendenti token OAuth, chiavi API e dati collegati all’autenticazione multifattore. Nel caso Lenovo non risulta una compromissione della stessa infrastruttura e non va quindi confuso con quel precedente, ma entrambi mostrano quanto i componenti dedicati a identità, token e sessioni siano spesso più sensibili della semplice protezione del file archiviato.

Proton torna in difficoltà dopo il guasto termico di Francoforte

Contemporaneamente, Proton registra un nuovo problema di disponibilità. La pagina ufficiale di stato segnala dal pomeriggio del 1° settembre un’interruzione che coinvolge una piccola parte degli utenti e interessa numerosi componenti dell’ecosistema: Proton Mail, Proton VPN, Proton Calendar, Proton Drive, Proton Docs, Proton Pass, Proton Wallet, Lumo e Proton Meet risultano in stato di partial outage. Alle 16:42 CEST, Proton ha fornito una spiegazione più precisa: l’infrastruttura starebbe affrontando guasti hardware residui probabilmente collegati ai danni causati dall’episodio di surriscaldamento della settimana precedente, con capacità operativa temporaneamente ridotta mentre vengono portate online ulteriori risorse. Il riferimento è al grave incidente del 27 agosto, quando Proton aveva individuato un problema critico al sistema di raffreddamento del data center di Francoforte e aveva iniziato a deviare il traffico verso siti di backup. L’outage era stato successivamente risolto senza perdita di dati, ma la comunicazione odierna dimostra che il danno infrastrutturale non è stato completamente assorbito.

Il failover non elimina automaticamente il danno fisico all’infrastruttura

Il caso Proton mostra un problema diverso da Dropbox ma altrettanto importante per i servizi cloud: la ridondanza protegge dalla perdita immediata del servizio, non cancella necessariamente le conseguenze di un guasto materiale. Durante l’incidente del 27 agosto Proton aveva trasferito traffico verso infrastrutture alternative dopo aver identificato il guasto al raffreddamento di Francoforte. Quella strategia ha permesso di ripristinare progressivamente i servizi, ma server, storage, networking e componenti di alimentazione sottoposti a temperature anomale possono manifestare successivamente errori intermittenti o fallimenti differiti. Proton parla infatti di capacità ridotta e della necessità di aggiungere nuova infrastruttura. Nella stessa giornata l’azienda aveva inoltre effettuato una breve manutenzione di emergenza tra le 15:12 e le 16:12 CEST, completata regolarmente, e ha programmato per il 2 settembre un ulteriore intervento destinato a rafforzare l’infrastruttura. La coincidenza temporale non autorizza però a identificare la manutenzione come causa del nuovo outage: Proton attribuisce esplicitamente il problema ai guasti hardware residui legati all’incidente termico precedente.

Continua con:

• Microsoft risolve outage MFA e MySignIn dopo errori 504 su Microsoft 365

Fiducia e resilienza diventano lo stesso problema visto da due estremità

Dropbox e Proton non stanno affrontando lo stesso tipo di incidente. Nel primo caso esiste una violazione della sicurezza dell’identità: un soggetto non autorizzato riesce a ottenere una sessione valida sfruttando una catena di fiducia tra due provider. Nel secondo esiste un problema di resilienza infrastrutturale, con hardware danneggiato che riduce la capacità disponibile anche dopo il ripristino iniziale. Il punto comune è però evidente. I servizi digitali moderni sono composti da dipendenze e relazioni di fiducia che si estendono oltre il dominio visibile all’utente: identity provider, sistemi SSO, data center, raffreddamento, reti, failover e piattaforme di autenticazione diventano parti della stessa superficie operativa. Per Dropbox la correzione deve impedire che la semplice corrispondenza di un’email proveniente da un provider esterno sia sufficiente a collegare una nuova identità a un account esistente senza step-up authentication o consenso esplicito. Per Proton il problema riguarda invece la capacità di assorbire il guasto fisico di un sito senza continuare a operare per giorni con margini ridotti. Due incidenti differenti mostrano quindi lo stesso principio: la sicurezza di un servizio è forte soltanto quanto il componente esterno al quale decide di concedere fiducia, e la disponibilità soltanto quanto l’infrastruttura realmente pronta a sostituire quella che fallisce.