Buon Giorno
Oggi scrivo di security (oh che cosa curiosa) e, in particolare, di security sulla posta 
.
L’argomento di oggi è il Bounce.
Come sappiamo il protocollo SMTP è un protocollo che, per le sue caratteristiche, è estremamente esposto ad attacchi di diverso genere. Uno tra i tanti è il DoS tramite bounce attack.
In cosa consiste?
Si tratta di sovraccaricare la interfaccia SMTP con milioni di messaggi per far saturare il canale di posta e, se possibile, far riempire le code e magari far crollare il mailserver.
La generazione di tali messaggi viene demandadata a mailserver legittimi che rispondono legittimamente ad un errore di invio al mittente che, però, è ignaro della attività
L’attacco di per se è estremamente semplice da mettere in piedi ed è, al contempo, particolarmente complesso da fermare.
Per altro il problema del bounce può essere anche una conseguenza secondaria di altri attacchi (directory harvest, spam attack e via dicendo). Ma cerchiamo di capire di cosa stiamo parlando e di come si svolgono le cose.
Il bounce
Il primo step è capire cosa sia un Bounce.
Il bounce è nientre altro che la notifica che la mail inviata ad un mailserver è stata ricevuta (positive bounce o positive DSN) o non è stato possibile consegnarla (Bounce o DSN):
http://en.wikipedia.org/wiki/Bounce_message
•A bounce can be two things: –NEW email generated automatically by the receiving system, using information from the original message, sent “back” to the envelope sender –The act of telling the sender the message is rejected •DSN: Delivery Status Notification. IronPort supports only “Negative DSN”. •NDR: Non-delivery record, a.k.a. bounce.
Tale servizio è facoltativo, le RFC lo raccomandano ma non ne danno vincoli forti, anche in termini di struttura del messaggio di reply. Lo scopo del bounce è di notificare al mittente che non è stato possibile consegnare il messaggio al destinatario.
Senza il bounce notification un protocollo come l’SMTP che è, per sua natura, “unreilable” lascerebbe il mittente nel dubbio se la sua mail sia stata o meno deliverata correttamente al destinatario. Sbagliare un’indirizzo di mail è una esperienza che è capitata a chiunque, non avere la notifica dell’avvenuto errore diventerebbe un problema di gestione non secondario in caso di uso professionale di tale protocollo.
Il bounce quindi ha una sua utilità nell’ambito dell’invio della posta. Il problema è che per sua natura il bounce, che ha una sua ragione legittima di esistenza, può essere usato anche per altri scopi.
Data la natura arbitraria del formato è possibile, ad esempio, spingere un utente a cliccare su contatti email o link che indirizzano a servizi di spam o, come descritto in testa a questo post, provocare Denial of services e cosi via.
Vediamo come si genera un Bounce.
Durante la conversazione SMTP client e server della conversazione (mittente e destinatario se volete) si scambiano alcune informazioni.
qui sotto vedete un estratto semplificato di tali conversazioni
Una mail è la composizione di queste conversazioni.
La prima parte (envelope) compone di fatto la componente di indirizzamento SMTP ed è la base su cui vengono generati i bounce di tipo conversational.
la seconda parte (body) è quella che viene poi interpretata a livello di client di posta e da cui il client solitamente estrae le informazioni per i reply to e le altre attività.
Una prima osservazione importante è che il contenuto del campo envelope è obbligatorio in un qualsiasi scambio di posta elettronica. Anche in assenza di elementi nmel campo Data, la presenza degli elementi nel campo envelope è sufficiente per ricevere posta e rispondere. in caso di mancanza di altre indicazioni i client di posta prendono come riferimento per mittente e destinatario i campi dell’envelope.
Una seconda informazione importante è che il controllo sulla coerenza sintattica e correttezza di mittente e destinatario a livello SMTP viene fatta solo sull’envelope e non sul body, che viene gestito poi a livello superiore dal serverclient di posta.
Va inoltre osservato che in caso di posta gestita tramite certificati la unica area che viene soggetta alla coerenza è la componente data, la componente di envelope viene generata on the fly durante la conversazione smtp e quindi non è certificabile.
Questa significa in pratica che la parte di envelope è soggetta a spoofing in maniera molto semplice e che non vi sono obblighi di controllo di default che quanto dichiarato nell’envelope coincida con quanto dichiarato nel body.
Il Bounce viene generato (o può essere generato) in due momenti diversi: o a livello SMTP durante la conversazione con l’MTA di ricezione o a livello di server di posta client) analizzando i dati del body.
Tipicamente a livello di conservazione SMTP la risposta è immediata nel caso la MTA conosca l’elenco degli utenti.Questa carattersitica può essere utilizzata per effettuare directory harvest attack (che verranno esposti in pun prossimo post se volete).
L’interfacciamento con una sorgente LDAP in questo caso può facilitare la gestione solo nel caso si utilizzano meccanismi di ADHA (Anti- Directory Harvest Attack).
Nel caso la MTA non conosca questo elenco tutti i messaggi a questo livello vengono accettati (salvo problemi sintattici) e la generazione di un bounce viene redireta al livello successivo.
Consideriamo quindi come viene solitamante generata una risposta di bounce. Il messaggio che arriva, come detto, contiene una parte generata dalla conversazione SMTP (envelope) e poi dalla componente Body. Consideriamo quindi che ci sia un errore che impedisca la corretta ricezione del messaggio, il sistema genera una risposta di errore:
la struttura di questa risposta può variare sotto diversi aspetti: può, o meno, contenere il messaggio originale, può contenere o meno una parte di script automatico che descrive l’errore ed il relativo codice di errore generato (ad esempio: user unknown, mailbox full e cose del genere).
Il problema:
Una volta chiarito cosa sia il Bounce possiamo iniziare a capire cosa possiamo aspettarci:
supponiamo di avere lo scenario seguente:
un utente “A” invia un messaggio ad un utente “B”
se l’utente “A” sbaglia a scrivere la mail del destinatario abbiamo i seguenti scenari:
1) tutto funziona correttamente ed il mittente immette correttamente l’indirizzo del destinatario:
il destinatario a livello di conversazione SMTP conferma l’accettazione del messaggio e quindi la transazione continua.
2) il mittente sbaglia a scrivere l’indirizzo di email scrivendo in maniera errata il dominio di destinazione.
in questo caso il server di partenza riceve un errore gia a livello di risoluzione DNS. La gestione dell’errore e la relativanotifica al mittente viene gestita direttamente dal server di invio.
In realtà la gestione dell’errore da parte del server mittente potrebbe essere legato anche ad un problema transiente (il DNS giu, oppure server di destinazione che no risponde per altri problemi). A questo proposito si fa riferimento alle indicazioni in RFC inerenti i retry e relativi errori.
3) il mittente sbaglia a scrivere il destinatario ma scrive correttamente il dominio
in questo caso il server di destinazione comunica al mittente che il destinatario non esiste.
abbiamo fondamentalmente 2 casi:
- il detinatario ha l’elenco degli utenti e può comunicare l’errore direttamente a livello SMTP
- il destinatario non ha l’elenco degli utenti e demanda al mailserver la consegna dell’avviso di errore
fin qui siamo nel reame delle operazioni effettuare correttamente.
Complichiamo ora le cose introducendo una modifica al flusso di carattere illecito.
4) Supponiamo quindi che il mittente dichiari il suo indirizzo mittente in maniera non corretta.
In questo caso la notifica dell’errore invece di essere inviata al mittente viene inviata ad una entità terza che non ha nulla a che vedere con la transazione in oggetto.
Il ricevente quindi si trova a ricevere un messaggio proveniente da una fonte legittima (pippo.com) che fa riferimento però ad una transazione da lui mai iniziata.
A causa della origine del meccanismo di generazione del Bounce, il mittente ha grosse difficoltà a controllare la veridicità, o meno, di tale notifica. Il fatto che la struttura di tale notifica è di contenuto variabile e che la sorgente è legittima rende la detection attraverso tradizionali motori antispam estremamente difficile se non quasi impossibile.
Ora immaginiamo di estendere la attività a molte fonti di invio:
Un attaccante attiva una botnet (1) per inviare a diverse fonti migliaia di messaggi (2) con forged sender errato. questi messaggi vengono processati dai vari riceventi e le relative bounce notification vengono inviate al reale target dell’attacco che si vede arrivare miolioni di bounce da sorgenti legittime.
in questa ottica “customer.com” deve sopportare una quantità di messaggi tale che potrebbe portare al collasso della sua struttura.
Per altro al fine di evitare che il sistema attaccato chiuda ai bounce provenienti da uno specifico server l’attacco conivolge non solo una o piu botnet ma anche una elevata quantità di host intermedi, rendendo la detection e la remediation estremamente difficile.
Cosa Fare
Il bounce, seppur prono ad essere utilizzato come strumento di attacco e disturbo, è un elemento fondamentale per il corretto funzionamento dei servizi di posta.
Eliminare i bounce notification non è la risposta corretta in quanto si incide sensibilmente sulla qualità del servizio offerto.
Le possibili alternative alla chiusura di tale fondamentale notifica sono l’utilizzo, in prima istanza, di una MTA di front end che isoli il mail server da internet.
Questa MTA è poi opportuno che sia in grado di interfacciarsi con una struttura LDAP (o AD) al fine di recuperare le mail degli utenti per ridurre il nuomero di transazioni effettuate col mailserver. Tale interfacciamento richiede 2 carattersitiche:
1) che la struttura LDAP (o AD) NON risieda sulla MTA per ragioni di sicurezza ma che vengano effettuate query specifiche alla bisogna.
2) che l’MTA sia in grado di offrire tecnologie anti Harvesting a corredo.
In questo modo l’impatto di un eventuale Ddos viene mitigato.
Un secondo possibile strumento è la introduzione di meccanismi di tagging sulla mail per identificare in maniera univoca i bounce generati in risposta a mail legittime.
l’idea di base è di sfruttare la caratteristicha per cui il client di posta vede il campo from proveniente dal body, mentre l’envelope può essere diverso.
supponiamo quindi che il server mittente sia capace di modificare, con una chiave univoca, i messaggi in uscita, alterando il campo from, ad esempio:
mail from: pippo@pippo.com –> (chiave1)pippo(chiave2)@pippo.com
Ora in caso di bounce il campo utilizzato sarebbe:
(chiave1)pippo(chiave2)@pippo.com
in questo modo il bounce generato da un errore legittimo viene identificato grazie alla presenza della chiave di tagging nell’indirizzo.
In questo caso diventa legittimo scartaretutti i bounce che siano inviati verso mittenti sprovvisti di questo Tag identificativo.
quindi il bounce per (chiave1)pippo(chiave2)@pippo.com viene accettato mentre quello per pippo@pippo.com viene scartato.
Questo meccanismo si chiama BATV Bounce Address Tagged Validation ed è uno strumento interessante per indirizzare questo tipo di problematiche.
il BATV definisce una struttura di tagging specifica:
un envelope sender del tipo
viene sostituito con
prvs=tag-value=mailbox@example.com,
dove prvs, “Simple Private Signature”, è lo schema di taggin definito al momento.
per maggiori indicazioni si può fare riferimento al relativo draft BATV.
Uno dei limiti intrinseci di questo meccanismo è legato al fatto che ad una analisi attenta del messaggio il campo mail from di envelope e body differiscono. Questo può comportare, in alcuni servizi di posta, alla errata interpretazione che si tratti di un forgin e quindi considerare la mail malevola.
Tipicamente questo comportamento si incontra con Lotus Notes e con alcuni servizi antispam.
Nelle implementazioni di ESA è possibile configurare questo servizio (Bounce Verification) sfruttando anche la possibilità di gestire eccezioni per dominio di posta, rendendone quindi possibile l’utilizzo anche in presenza di riceventi non compatibili.
Alla prossima
Antonio
Share this:
Related Posts via Taxonomies
To the official site of Related Posts via Taxonomies.
Discover more from The Puchi Herald Magazine
Subscribe to get the latest posts sent to your email.
Bounce Notification: Good or Bad? by The Puchi Herald Magazine is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
