attacchi di compressione SSL / TLS sui server di posta (smtp)

Gli attacchi di compressione come CRIME e BREACH funzionano attivando la trasmissione ripetuta di quasi lo stesso messaggio con solo lievi modifiche, con queste modifiche controllate dall'attaccante. Osservando la dimensione compressa del messaggio, l'attaccante può quindi ragionare se la stringa controllata dall'attaccante è contenuta nel messaggio oppure no. Questo è usato per indovinare il valore di dati sensibili, come il cookie di sessione oi token CSRF in caso di HTTP.

Con HTTP questi attacchi funzionano contro i casi in cui la risposta dal server riflette input dal client (per indovinare token CSRF in risposta) o facendo in modo che il client invii la stessa richiesta con leggere varianti dell'URL o dei dati del corpo per indovinare il cookie nella richiesta HTTP. L'input controllato dall'attaccante è possibile poiché HTTP consente le richieste cross-site, ovvero l'utente malintenzionato può fare in modo che il client esegua una richiesta specifica e quindi guardare la richiesta e la risposta crittografate.

Ma l'SMTP funziona in modo diverso. Di solito non c'è alcun modo per l'attaccante di fare in modo che il client invii una e-mail specifica ancora e ancora con solo modifiche minime e controllate da attaccanti. Sebbene si possano costruire scenari in cui quasi la stessa posta viene inviata in modo automatico con alcuni input controllati dagli hacker in entrata (vedere answer from @Giles ) secondo me, in tutti i casi praticamente rilevanti, tali attacchi di compressione non funzioneranno con SMTP.

Tuttavia, è meglio non usare la compressione a livello TLS (usata da CRIME) che si spera sia il default nelle moderne librerie crittografiche. Per quanto riguarda la compressione a livello di applicazione utilizzata da BREACH: mentre è comune utilizzare tale compressione in HTTP (dichiarata dall'intestazione Content-Encoding ) non è definita alcuna compressione a livello di applicazione in SMTP o MIME (che è il formato di incapsulamento per i messaggi). Mentre c'è un x-gzip64 proposto non l'ho mai visto usato in pratica o supportato da veri client di posta.

Il principio base alla base degli attacchi di compressione + crittografia sottostanti è che l'attaccante può far sì che il mittente invii molti messaggi crittografati contenenti lo stesso testo, incluso un valore segreto che l'utente malintenzionato vuole trovare, ad eccezione di un segmento controllato dal attaccante. L'esempio canonico per CRIME e BREACH è una risposta web, incluso un cookie (segreto che l'utente malintenzionato vuole trovare) e alcuni input che l'utente malintenzionato inietta tramite una risorsa di terze parti (ad esempio, un annuncio).

Potresti riuscire a eseguire un attacco simile contro SMTP se riesci a raccogliere gli stessi ingredienti: email quasi identiche, tutte contenenti il segreto che vuoi ottenere, e che differiscono solo o principalmente in qualche valore che tu può controllare. Nota che l'SMTP è utilizzato sul lato dell'invio, che di solito è più difficile da attaccare: è facile curiosare con gli utenti wifi (basta piantare un hotspot falso), ma ci vuole un attaccante di livello abbastanza alto per curiosare sulle connessioni in un datacenter. / p>

Ad esempio, supponiamo che tu stia cercando di trovare l'indirizzo email di un utente di un servizio e che il servizio sia configurato per inviare all'utente alcuni avvisi via email, come un feed RSS-to-mail. Se è possibile inserire dati nel feed RSS ( wibble waffle To: [email protected]: [email protected]: [email protected]: [email protected] ), è possibile eseguire un attacco di tipo CRIME per trovare l'indirizzo email. Questo particolare attacco ha molti problemi pratici: si basa sull'e-mail che viene consegnata alla vittima, quindi è piuttosto evidente (si può provare a mirare al cestino dello spam), e potrebbe incorrere in limiti di velocità (migliaia di richieste web non sono altro che è possibile che migliaia di e-mail per lo stesso account vengano catturate dalla protezione antispam).

Ecco un altro esempio con un feed news-to-email in cui è possibile iniettare notizie false. Questa volta, supponi che l'e-mail contenga un link "unsubscribe" che contiene un token segreto. Invia un sacco di notizie false e trova il token segreto dal link "annulla iscrizione". È abbastanza comune per i server accettare richieste di annullamento dell'iscrizione senza autenticare l'utente, soprattutto quando tutto il server conosce l'e-mail dell'utente (oltre ai dati di marketing associati) e non esiste un account associato a cui l'utente possa accedere. In questo modo potresti annullare in modo fraudolento l'iscrizione di un utente dal loro feed. Si spera che, se il server ha un account utente, il token segreto da solo non ti consente di fare nient'altro sull'account.

Un altro segreto a cui potresti essere interessato è una specie di token di autorizzazione. Supponiamo che un server utilizzi un token segreto inviato via email (o qualsiasi altro metodo di comunicazione) come fattore per confermare una transazione, e si può curiosare sul traffico di quel server o sul traffico del destinatario. Supponiamo che questo token sia tutto ciò che serve per confermare la transazione. Il tuo obiettivo è di attivare una transazione a tuo vantaggio (ad esempio un trasferimento di denaro verso di te) e trovare il token associato. Puoi iniziare la transazione in modo da poterne controllare la descrizione. Esiste un modo sbagliato per il server: utilizzare un OTP basato sul tempo, che verrà ripetuto su molte transazioni. Speriamo che il server funzioni correttamente, con un valore casuale appropriato diverso per ogni transazione.

Nota che, ad eccezione del caso in cui il segreto che vuoi trovare è l'indirizzo email del destinatario, puoi portare l'attacco sul lato client, contro IMAP o POP crittografato piuttosto che SMTP.