Il 1° dicembre 2021, abbiamo iniziato a ricevere segnalazioni sporadiche di insuccessi nella consegna da indirizzi proton.me a Gmail. Ciò corrispondeva a un drastico calo della reputazione del dominio proton.me come visto attraverso gli strumenti di Postmaster di Gmail e un aumento dell’invio da indirizzi IP noti per essere dannosi.
Era chiaro sia dagli IP di invio dannosi (prevalentemente in Russia) sia dalle nostre metriche che le email spam che danneggiavano la reputazione del dominio di Proton Mail non provenivano dai nostri server. Tuttavia, gli strumenti di Postmaster indicavano che tutte le email ricevute da Gmail da proton.me erano “completamente autenticate”, inclusi quelle fraudolente.
Questo, a sua volta, ha causato l’inclusione delle email fraudolente nell’algoritmo di Google per determinare la reputazione del dominio e l’abbassamento sufficiente affinché la consegna delle email legittime dai nostri server fosse influenzata.
Sospettavamo un attacco di replay DKIM, in cui una singola email spam originariamente inviata da Proton Mail veniva reinviata a molti utenti Gmail nel tentativo di sfruttare la nostra capacità di consegna e reputazione per aggirare le misure anti-spam di Google. A un certo punto, circa il 98% delle email ricevute da Gmail che affermavano di essere di Proton Mail erano in realtà spam, il che significa che gli spammer stavano inviando una quantità di email equivalente a 50 volte il nostro traffico in uscita normale verso Google.
Abbiamo immediatamente ruotato la nostra chiave di firma DKIM per prevenire (temporaneamente) che le email venissero accettate da DKIM e abbiamo contattato il team anti-abuso di Google, che ha rapidamente implementato una soluzione ai filtri anti-spam di Gmail e ripristinato la consegna delle email legittime.
Le email inviate da proton.me, proton.me/mail e domini personalizzati non sono state interessate da questo problema.
Come funzionano gli attacchi di replay DKIM
Prima di poter spiegare come è successo, dobbiamo prima delineare come le email sono strutturate, consegnate e autenticate su internet.
Le email sono messaggi MIME (Multipurpose Internet Mail Extensions), costituiti da intestazioni e sezioni che contengono il corpo del messaggio e possibilmente allegati. Le intestazioni contengono alcuni campi che saranno familiari a qualsiasi utente di email (A, CC, Da, Oggetto) ma anche informazioni nascoste che vengono utilizzate per autenticare l’email.
Tuttavia, nessuna delle intestazioni è effettivamente utilizzata per instradare l’email alla sua destinazione finale. Il destinatario e il mittente dell’email sono specificati separatamente come parte della busta dell’email, metafora molto adeguata. Se il messaggio email, incluse le sue intestazioni, è paragonabile a una lettera di carta, allora la busta dell’email in cui viene inserita la “lettera” contiene gli indirizzi del destinatario e del mittente, come una vera e propria busta.
Il punto chiave è che il destinatario sulla busta non deve necessariamente corrispondere a un destinatario nelle intestazioni A o CC — esempi tipici di questo sono le email inviate tramite CCN o indirizzate a “destinatari non divulgati”.
Forse ancora più sorprendentemente, il mittente sulla busta non deve corrispondere all’intestazione Da dell’email. Questo ha anche uno scopo legittimo — le spedizioni di massa spesso specificano un “indirizzo di ritorno” diverso dall’intestazione Da per analizzare problemi di consegna o utilizzare servizi terzi per inviare email. Questa flessibilità è anche importante per consentire agli utenti di inoltrare messaggi da una casella di posta all’altra.
Questi indirizzi di ritorno sono autenticati tramite SPF (Sender Policy Framework), che autorizza l’invio di messaggi da server specifici o indirizzi IP utilizzando record DNS speciali. Ma questo valida solo il server che invia l’email; non assicura che il contenuto dell’email non sia stato manomesso. Per questo, abbiamo bisogno di DKIM (Domain Keys Identified Mail).
DKIM utilizza anche record DNS speciali, ma piuttosto che una lista di indirizzi IP, questi record contengono chiavi utilizzate per firmare il contenuto dell’email e certe intestazioni associate. La firma crittografica risultante è aggiunta al messaggio come un’intestazione speciale, e il server di posta o il client del destinatario può verificare questa firma rispetto al contenuto dell’email alla consegna. Ma il dominio DKIM nella firma può anche essere diverso da quello nell’intestazione Da nel messaggio stesso. Se la firma DKIM viene verificata, ciò conferma solo che il messaggio è passato attraverso i server di posta del dominio di firma e non è stato modificato da allora, non che il messaggio provenga da dove afferma.
Per verificare effettivamente che il dominio nell’intestazione Da abbia inviato il messaggio, abbiamo bisogno di DMARC (Domain-based Message Authentication, Reporting, and Conformance). Per superare DMARC, un’email deve passare o SPF o DKIM, e il dominio nell’intestazione Da deve essere “allineato” con il corrispondente dominio SPF o DKIM. L’intestazione Da è ciò che l’utente vede effettivamente, quindi DMARC è un elemento fondamentale per assicurare che un’email provenga realmente da dove afferma, essendo l’unica politica che collega l’intestazione Da al dominio di invio o di firma.
(new window)Ora torniamo all’attacco. Il motivo per cui gli attacchi di replay DKIM funzionano e perché Gmail ha considerato quelle email di spam replayed “autenticate” è legato al fatto che DMARC richiede l’allineamento di DKIM o SPF, ma non di entrambi. Il messaggio replayed aveva una firma DKIM valida da proton.me, il che significava che superava DMARC. Questo messaggio è stato poi inviato abbastanza volte da influenzare la reputazione del dominio proton.me nel sistema di Gmail, diventando infine abbastanza bassa da influire sulla recapitabilità delle email legittime.
Come preveniamo gli attacchi di replay
Il fatto che DMARC venga superato se il dominio DKIM o il dominio SPF sono allineati con il dominio Da è una caratteristica della specifica, non un difetto. In particolare, ciò consente l’inoltro delle email e permette l’invio di email da parte di terze parti fidate. Tuttavia, per i fornitori di servizi email, come Proton, Gmail o Yahoo, ciò consente anche questo tipo di attacchi di replay, poiché qualsiasi utente può inviare un’email, farla firmare dal dominio corrispondente, poi rinviarla mantenendo la firma intatta.
Questo è uno dei motivi per cui Proton e altri fornitori di servizi email investono pesantemente nella propria tecnologia e sistemi anti-spam. Questi sistemi sono complessi e spesso si basano su euristiche complicate per separare lo spam dalle email legittime. In questo caso, gli aggressori hanno trovato una vulnerabilità nel sistema anti-spam di Gmail e sono riusciti a sfruttarla.
Apprezziamo la prontezza di Google nel risolvere il problema.
Come puoi prevenire l’impersonificazione del tuo dominio
Gli attacchi di replay DKIM sono un problema principalmente per i fornitori di servizi email o altre organizzazioni che offrono indirizzi email su un dominio condiviso. Tuttavia, gli attacchi di autenticazione email in generale rappresentano un rischio per qualsiasi organizzazione. Ecco alcuni consigli per aiutarti a garantire che nessun altro possa impersonare il tuo dominio o utilizzarlo per inviare messaggi fraudolenti.
- Configura SPF, DKIM e DMARC – Anche se imperfette, queste politiche sono fondamentali per assicurare che le tue email vengano recapitate e siano resistenti allo spoofing. Se utilizzi Proton per ospitare il tuo dominio, la nostra procedura guidata di configurazione del dominio spiegherà come impostarlo e proteggerlo dallo spoofing.
- Ruota regolarmente le tue chiavi DKIM – Ruotare le nostre chiavi DKIM ci ha permesso di fermare rapidamente l’attacco e guadagnare tempo per la soluzione definitiva. Anche se noioso e rischioso da fare manualmente, il sistema di gestione delle chiavi DKIM(new window) di Proton ci ha permesso di farlo facilmente in pochi minuti, e questo sistema è lo stesso utilizzato per tutti i domini ospitati su Proton. Il sistema ruota anche automaticamente le chiavi regolarmente per ridurre il rischio di compromissione delle chiavi.
- Sovrascrivi sempre le intestazioni Da, A e CC – La maggior parte delle implementazioni DKIM firma sempre le intestazioni Da, A e CC se presenti in un’email, impedendone la modifica in caso di reinvio del messaggio. Tuttavia, se queste intestazioni mancano, spesso non vengono firmate, aprendo la porta ad attacchi di replay con intestazioni contraffatte che rendono le email fraudolente apparentemente legittime. La sovrascrittura mitiga questi attacchi firmando queste intestazioni sensibili in tutti i casi, anche se vuote. Se utilizzi Proton per inviare le tue email, questa sovrascrittura viene eseguita automaticamente dai nostri server di posta.
- Presta attenzione ai sottodomini – Se utilizzi record CNAME per delegare parti del tuo sito web a terze parti, potresti anche permettere a queste terze parti di inviare email a nome del tuo dominio principale. Questo perché, per impostazione predefinita, DMARC considera i domini allineati se hanno una relazione genitore-figlio — ovvero, sub.esempio.com si allinea con esempio.com. Puoi forzare l’allineamento esatto per SPF, DKIM o entrambi con le opzioni aspf e adkim nella tua politica DMARC. Tuttavia, sii consapevole che ciò può influenzare l’integrazione con servizi di mailing di terze parti.
Dopo che clicchi Invia su Proton Mail, succede molto.
Se tutto funziona correttamente da parte nostra, l’invio di una mail sembra facile come un click, ma in realtà si basa su una complessa rete di politiche interconnesse e interdipendenti. Eventi come questo attacco di replay dimostrano quanto possa essere complesso verificare qualcosa di apparentemente semplice come “Chi ha inviato questa email?”
Su Proton Mail, stiamo costantemente investigando su nuovi protocolli e politiche per assicurare che i milioni di email inviate tramite la nostra piattaforma ogni giorno siano recapitate in modo affidabile e sicuro. Monitoriamo inoltre continuamente la posta in arrivo per ottimizzare i nostri sistemi di autenticazione e abbiamo sistemi e analisti pronti 24/7 per contrastare spam e attacchi di phishing.
Questa è una parte fondamentale per creare un internet dove la privacy è la norma e non potremmo farlo senza il supporto della comunità Proton. Grazie.
