Con Email spoofing si indica la falsificazione dell’indirizzo del mittente di un messaggio di posta elettronica.

Lo spoofing si appoggia a criticità note del sistema di invio della posta elettronica, ed in particolare usa le debolezze del protocollo di invio (SMTP) nato in un ambiente molto diverso da quello attuale, probabilmente più interessato a far funzionare le cose che a romperle.

Un server SMTP accetta comandi testuali, che possono essere inviati usando un client telnet ed aprendo una sessione sulla porta 25 (che è tradizionalmente la porta di ascolto, in chiaro, di SMTP). In realtà, proprio per cercare di limitare gli abusi, si è cercato di far diventare i server SMTP un po’ più furbi in varie maniere, ad esempio introducendo il concetto di autenticazione, per cui un utente deve avere credenziali note (deve essere identificabile) per poter inviare email; un altro sistema, che alcuni provider usano, è quello di consentire l’interazione con il server di posta solo ad utenti che si connettono mediante una rete specifica (in sostanza usando della access list). Servizi come quello di autenticazione hanno richiesto una estensione del vecchio protocollo SMTP, che è diventato un ESMTP (Extended SMTP RFC 1869).

I server SMTP aperti (vale a dire che non effettuano nessun controllo su chi invia la posta) non sono ben visti, ragione per cui vengono generalmente inseriti in liste dei cattivi, (blacklisted) e molti server di posta rifiutano di ricevere mail inviate dai loro indirizzi.
Vediamo come si comporta un server SMTP aperto, e come sia facile inviare una email falsificando l’indirizzo del mittente: per fare le cose semplici supponiamo avere un server SMTP aperto all’indirizzo 10.0.0.254 mail.dominio.loc e che il mio client sia 10.0.0.10. client.dominio.loc. Possiamo costruire un’eamil con mittente contraffatto inviando i comandi al server mediante una sessione telnet sulla porta 5. La mia sessione di invio di email seguirà questa traccia (C client, S server) :

C telnet 10.0.0.254 25                            (apertura di una sessione sul server sulla porta 25) 
S: 220 mail.server.loc  Simple Mail Transfer Service Ready
C: HELO client.dominio.loc
S: 250 Hello client.dominio.loc
C: MAIL FROM:<[email protected]>   (possiamo scrivere qui l'indirizzo dell'email che vogliamo far comparire come mittente)
S: 250 OK
C: RCPT TO:<[email protected]>
S: 250 OK
C: DATA
S: 354 Send message content; end with <CRLF>.<CRLF>
C: <viene inviato il messsaggio>
C: .                                                       (il punto indica la fine dell'invio del messaggio)
S: 250 OK, message accepted for delivery: queued as 12345
C: QUIT
S: 221 Bye

Con i server SMTP che richiedono autenticazione le cose stanno in maniera leggermente diversa. La traccia che vediamo è presa da server reale (aruba, come si vede chiaramente), nell’invio da una mia casella di posta ad un un’altra; questa volta usiamo il tracciato dell’analizzatore di protocollo, e non la sequenza dei comandi da console.

Innanzi tutto vediamo i tre frame di handshaking del TCP IP. Notare l’incremento del Sequence number, che indica l’apertura di sessione, ed i Flag (S syn, AS ack syn, A ack) tipici dell’handshaking a tre vie del TCP IP.

Partissimo completamente da zero, vedremmo anche la risoluzione del nome del mail server in indirizzo IP, ma qui era già nella cache del client. A seguito dell’apertura di sessione si presenta il server, che dichiara le sue capacità rispondendo al client ESMTP ed un bel 220 (service ready).

Il client apre con EHLO (non HELO) che è la keyword di apertura ESMTP, cui il server risponde 250 (operazione completata). A questo punto il server passa in attesa del comando AUTH; se non lo riceve chiude la sessione.

Il client invia dunque AUTH PLAIN (password NON Criptata, per l’occasione). In generale sarà bene che la password sia crittografata con un metodo che il server possa comprendere.

Il server risponde 235, authentication succeeded. In generale teniamo presente che i codici della forma 2xx indicano successo, 4xx transient failure (qualcosa non va, ma il messaggio è valido e le cose potrebbero aggiustarsi in futuro), 5xx permanent failure (qualcosa è andato storto in maniera definitiva). L’RFC 1893 “Enhanced Mail System Status Codes” dice di più sui codici di errore .

A questo punto il client, autenticato, DICHIARA (MAIL FROM) l’indirizzo di email da cui sta inviando il messaggio (il server NON E’ in grado di verificarlo; può rifiutare il messaggio se l’identificativo non corrisponde con l’identità di autenticazione, ma spesso non è così e il client può inserire nella stringa MAIL FROM qualunque indirizzo di email).
Infine indica RCPT TO: l’indirizzo del destinatario (il client può inviare diversi RCPT TO per indicare diversi destinatari).

Successivamente il comando DATA inizia il trasferimento del messaggio. La sessione termina con QUIT.

Una lista dei codici di risposta ESMTP si trova in RFC 3643 (e 1893, ora obsoleta).

Una bella descrizione dell’autenticazione SMTP si trova (in inglese) in

http://www.fehcom.de/qmail/smtpauth.html. Buona lettura.

Attenzione: alcune delle pratiche descritte potrebbero essere illegali o comunque contrarie alle norme di corretto utilizzo di internet e vengono illustrate a scopo di studio. Tutti gli esercizi debbono essere fatti solo su reti di test interne.