~/docs/SMTP_smuggling

Premessa

In questi giorni si sta parlando molto di questo nuovo tipo di attacco chiamato “SMTP smuggling”. Vista la sua portata ho deciso di creare questo articolo per spiegare – nella maniera più semplice e sintetica possibile – di cosa si tratta e il suo principio di funzionamento.

TL;DR

SMTP Smuggling è una vulnerabilità di sicurezza che consente ad un utente malintenzionato di inviare e-mail da un indirizzo di mittente falso, bypassando i controlli di sicurezza.

L’attacco sfrutta un difetto nel modo in cui alcuni server di posta elettronica gestiscono le linee di fine di riga nei messaggi SMTP. In particolare, alcuni server accettano linee di fine di riga formattate in modo errato, come \n.\r\n.

L’attaccante può sfruttare questo difetto per creare un messaggio SMTP con due parti:

  • La prima parte contiene un messaggio legittimo, inviato da un indirizzo di mittente reale.
  • La seconda parte contiene un messaggio dannoso, inviato da un indirizzo di mittente falso.

Il messaggio viene inviato a un server di posta elettronica vulnerabile, che accetta la prima parte del messaggio, ma non la seconda. La seconda parte del messaggio viene quindi “smuggle” (contrabbandato) nel server di posta elettronica, senza essere rilevato.

Quando il destinatario apre il messaggio legittimo, riceve anche il messaggio dannoso.

Contromisura SPF

Prima che un server SMTP in ingresso accetti un’e-mail verifica l’autenticità del mittente tramite meccanismi di autenticazione dell’e-mail come SPF, DKIM e DMARC. Questo è importante perché altrimenti gli aggressori potrebbero inviare e-mail solo da domini arbitrari.

Img. 1 – Esempio di record SPF

Se non invii da uno di questi intervalli IP, il controllo SPF fallirebbe e la tua email molto probabilmente non verrà inoltrata o verrà contrassegnata come spam. Ma quale dominio viene effettivamente controllato?

Il problema con SPF di per sé è che viene controllato solo il dominio MAIL FROM dall’a busta di posta’envelope del messaggio. L’intestazione From del messaggio, che viene ulteriormente visualizzata nell’e-mail ricevuta, può avere un valore arbitrario.

Contromisura DKIM

Discorso simile vale anche per DKIM (DomainKeys Identified Mail). DKIM consente di firmare i dati del messaggio, inclusa l’intestazione From. Questa firma può poi essere verificata dal destinatario con una chiave pubblica che risiede nel DNS. Tuttavia, non viene stabilito quale dominio detenga la chiave pubblica.

In questo caso, il messaggio proveniente da “user@sender.example” potrebbe essere firmato, ma la chiave di verifica si trova in “dkim._domainkey.attacker.example”. Questa posizione deriva dalla concatenazione del selettore (s=) “dkim”, del valore statico “_domainkey” e del dominio (d=) “attacker.example”. Pertanto, anche se un’e-mail può avere un record SPF valido e una firma DKIM valida, non esiste alcun meccanismo per stabilire se l’e-mail proviene o meno da un mittente dannoso.

Img. 2 – Fonte: https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

Contromisura DMARC

DMARC introduce il cosiddetto “allineamento degli identificatori” per SPF e DKIM e consente ai mittenti di specificare le politiche di allineamento per entrambi i metodi. In parole semplici verifica se il dominio “From” dell’e-mail è in linea con i controlli SPF e/o le firme DKIM. Pertanto, il controllo DMARC fallisce se c’è una mancata corrispondenza tra il dominio MAIL FROM e From, dove altrimenti il controllo SPF passerebbe.

Conseguenze

Come scritto all’inizio dell’articolo l’SMTP smuggling è una vulnerabilità che consente ad un utente malintenzionato di inviare e-mail da un indirizzo di mittente falso bypassando gran parte dei controlli di sicurezza.

Questa tecnica offre terreno fertile ad attaccanti di inviare mail sempre più sofisticate di phishing, portando di conseguenza anche l’utente più attento a possibili “incidenti di percorso”.

Sebbene alla scrittura di questo articolo numerosi player internazionali hanno già sistemato i loro server di posta è bene tenere a mente le normali procedure di verifica “manuali”.

EOF

Rispondi