Una panoramica sul mondo della Sicurezza Informatica, del Networking, della Virtualizzazione e non solo. Blog particolarmente indicato per i reparti IT che comunque alterna articoli scritti per specialisti con articoli formulati con linguaggio semplice e comprensibile a tutti.

Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

venerdì 17 giugno 2022

Ondata di spam con corpo reale

Capita sovente che il nostro Osservatorio Spam incontri questa specifica tipologia di email fraudolenta, ovvero un'email inviata apparentemente da noi o da un nostro interlocutore e contenente del testo realmente inviato in passato.

 

Chi invia realmente?

A questo punto dobbiamo fare una distinzione: il mittente è davvero la nostra casella, oppure lo è solo la descrizione?

Il protocollo SMTP è un protocollo obsoleto che ha sulle spalle molti decenni, nato in un tempo dove gli attacchi informatici erano irrisori e spesso innocui. Non deve meravigliare che io possa mandare facilmente un'email fingendomi qualcun altro.

Leggendo il sorgente del messaggio posso fare una distinzione tra quello che è il campo "Descrizione" e quella che è la reale casella di posta.

Caso 1: 

From: "Barack Obama" <b.obama@whitehouse.gov> (descrizione corretta, casella corretta [alterata])

In questo caso ho potenzialmente inviato un'email a nome di Obama. La descrizione è corretta (e chiunque può scrivere quel che vuole, non è nemmeno oggetto di controllo) ed il campo della casella è stato alterato.

Presupponendo che non sia stata violata proprio la casella originaria, non ci dobbiamo preoccupare troppo di questo caso in quanto, se il MailServer ricevente è stato correttamente configurato (per effettuare check su SPF, DKIM, DMARC, rDNS PTR), si renderà conto che l'indirizzo che invia questa email non è autorizzato a farlo scartandone il contenuto.

Quindi:  

  • SE la casella è stata violata, LA riceveremo.  
  • SE è un tentativo di invio per conto di terzi e tutto è configurato correttamente, NON la riceveremo.

 

Caso 2:

From: "Barack Obama" <pippo@pluto.jp> (descrizione corretta, casella diversa)

In questo caso la descrizione è corretta, tuttavia la casella da cui arrivano le email è pippo@pluto.jp che evidentemente non è quella di Obama.

In questo caso plausibilmente è stata violata la casella di Pippo che può lecitamente inviarci email, non possiamo far nulla se non segnalare questo spam al nostro sistema antispam affinchè il dominio pluto.jp venga considerato come compromesso. Ribadisco: nella descrizione purtroppo ognuno può scrivere ciò che vuole.


Caso 3:

From: "b.obama@whitehouse.gov" <pippo@pluto.jp> (descrizione corretta, casella diversa)

Questo caso è assolutamente identico a quello di prima, ma l'attaccante ha messo nella descrizione la casella originaria. Come abbiamo visto, ognuno nella descrizione ci può mettere quel che vuole, quindi per il mailserver di destinazione questo non è e non può essere oggetto di controllo. L'utente facilmente potrà passare con il mouse sulla descrizione e scoprire che sotto, in realtà, si cela una casella diversa.

Ricordate, una cosa è la descrizione, una cosa è la casella. Sono due cose diverse ed i client spesso visualizzano solo la descrizione e non la casella, accertarsi SEMPRE della casella che ha inviato è fondamentale.


Perchè c'è del testo reale nel corpo dell'email?

Questa è una bella domanda e non è semplice rispondere. Di sicuro qualcuno ha esfiltrato il contenuto delle email ed ora utilizza queste informazioni per veicolare una campagna di spam più efficace.

Deduciamo, tuttavia, che qualora ci avessero forato la casella di posta, le email sarebbero partite con il nostro indirizzo vero, quindi se il mailserver non vede traffico, le credenziali della casella non sono state compromesse.

Rimane però un dubbio: come ha fatto un attaccante ad accedere a queste email? Possiamo dedurre qualche scenario, ma prima dobbiamo comprendere che il transito di un'email avviene sostanzialmente su 3 momenti diversi:

 

  1. Nel primo momento, il Client comunica con il MailServer e gli passa l'email da inviare.
  2. Nel secondo momento, i due MailServer comunicano tra di loro e quello mittente invia a quello di destinazione l'email.
  3. Nel terzo momento il destinatario chiede al proprio MailServer se ci sono nuove email, e quest'ultimo gli consenga la posta recentemente pervenuta.

Sono tre fasi diverse che possono avvenire sia in chiaro, sia in maniera crittografata (e quindi impedendo che chiunque possa leggerne il contenuto). Nella prima e nella terza i rispettivi client inviano le credenziali di accesso, ragione per cui è vitale che almeno queste due fasi avvengano in maniera crittografata.

 

Compreso questo, possiamo tornare al punto, ovvero "Come ha fatto un attaccante ad esfiltrare il testo delle email?". Vediamo qualche scenario:

  • La comunicazione tra i MailServer (MTA-to-MTA) non è stata crittografata, quindi un attaccante posizionato in un punto qualsiasi tra il nostro mailserver e quello del nostro interlocutore ha potuto vedere in chiaro le email esfiltrandone il contenuto. Si tratta di un classico Man-In-The-Middle o MITM Attack. E' evidente che buona prassi vuole che i mailserver siano in grado di offrire ed accettare crittografia nella loro interlocuzione.
  • Come sopra, ma causato da un'assenza di crittografia lato client di posta. Quando configuriamo un client, possiamo scegliere se utilizzare protocolli come SSL o TLS (crittografati) piuttosto che inviare tutto in chiaro. Tuttavia questo secondo scenario a mio avviso è meno plausibile perchè l'attaccante, in questo caso, avrebbe avuto accesso anche alle password (a differenza di quando due mailserver parlano tra di loro) e quindi avrebbe compromesso la casella reale ottenendo una campagna d'attacco ancor più plausibile ed efficace.
  • Un virus ad hoc può aver esfiltrato le email dal client di posta. Troppo spesso, difatti, i PC vengono più o meno adeguatamente protetti, ma non i dispositivi mobili. Per mia esperienza questo è il caso più frequente, ovvero uno smartphone con un virus in grado di accedere alle email ed estrarne il contenuto per poi essere utilizzato in queste campagne.

 

Il contrasto allo spam

Lo spam segue un andamento spesso prevedibile, composto fondamentalmente da 3 fasi che si ripetono all'infinito:

  1. Una nuova tipologia di spam, in grado di non essere completamente o parzialmente rilevata, viene propagata in rete
  2. Gli antispam identificano la nuova tipologia di spam
  3. I MailServer aggiornano il proprio motore antispam rendendo la nuova tipologia di spam inoffensiva

Andamento Spam

Queste fasi si ripetono pressochè all'infinito. Quindi è del tutto naturale che, in determinati periodi, si riceva più spam del solito. Il periodo che intercorre tra la nuova tipologia di spam e la scoperta del suo "antidoto" può durare da poche ore a delle settimane.

Vanno fatte, tuttavia, delle considerazioni:

  • Alcune tipologie di spam possono essere molto complesse da rilevare. Basti pensare ad un'email indesiderata che contenga una riga di testo ed un link. Questo tipo di spam è difficile da identificare, salvo non inasprire troppo i controlli (si veda il punto successivo) con il deleterio effetto di "catturare" anche le email lecite.
  • I filtri antispam (dopo una fase di analisi preliminare) si basano su dei punteggi. Concettualmente è prassi lavorare con un'impostazione tale da evitare che email lecite finiscano nella posta indesiderata, anche se questo provoca inevitabilmente la non identificazione di una porzione di posta indesiderata "border line". Si pensi al sistema antispam come ad una bilancia in continua oscillazione. Se lo scopo è quello di evitare di perdere email importanti, allora qualche email di spam ogni tanto può passare. Se lo scopo è quello di non ricevere assolutamente spam, allora dovremo accettare il compromesso di vedere qualche email lecita finire nella cartella "indesiderata". La grandezza delle maglie di questa "rete" è a discrezione dell'amministratore del MailServer. Personalmente ritengo che far finire email lecite nello spam abbia la controindicazione di costringere l'utente a vedersi la cartella delle indesiderate, vanificando del tutto il lavoro dell'antispam. Ragione per cui preferisco un approccio meno perentorio.

Bilanciamento Antispam

  • 5 email non rilevate su 1.000, sono un buon risultato e non c'è da allarmarsi. 5 email di spam non rilevato su 10, invece, devono destare attenzione. I numeri vanno sempre contestualizzati: a volte non diminuisce la capacità del MailServer di rilevare lo spam, ma aumenta semplicemente il numero di email fraudolente inviate verso il nostro dominio, sovente oggetto di maggiori attenzioni.
  • Un'ondata di spam può essere generata da problemi di sicurezza. Account compromessi, server con problemi, telefoni compromessi, etc. possono propagare spam ai destinatari abituali contenuti nella rubrica degli account stessi. Non è, difatti, inusuale che grandi provider possano incorrere in importanti problemi di sicurezza che poi si riflettono sulla rubrica dei propri utenti. 

 

 

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.