Le configurazioni errate di Microsoft Exchange aprono la strada agli attacchi di spoofing

Alexander Romanov
11 Settembre 2024
0

Nel 2023, Microsoft ha annunciato un cambiamento nella gestione di DMARC in Microsoft Exchange. Nonostante l’avviso, molti utenti non hanno seguito le raccomandazioni di Microsoft per impostare un filtraggio avanzato, o forse non si sono accorti della modifica. Di conseguenza, gli utenti che non hanno configurato correttamente Microsoft Exchange ora sono esposti al rischio di spoofing delle e-mail (tipo di attacco informatico che impiega in varie maniere la falsificazione dell’identità), e ciò potrebbe portare a compromissioni delle e-mail, violazioni dei dati e altro ancora.

Circa il 36% di tutte le violazioni dei dati nell’UE e negli Stati Uniti ha origine da attacchi di phishing. Le e-mail di phishing sembrano spesso provenire da fonti legittime, come “admin@micr0soft.com” o “IT administratoremail@google.com,” e presentano righe dell’oggetto e contenuti progettati per catturare l’attenzione degli utenti, ad esempio informazioni su stipendi, paghe, ecc.

In alcuni casi, gli hacker possono falsificare gli indirizzi e-mail per far sembrare che la posta elettronica provenga da una fonte attendibile, come “tuo_capo@tuasocietà.com.” Siccome il client di posta elettronica riconosce l’indirizzo del mittente come corrispondente a quello del responsabile IT, potrebbe mostrare automaticamente la foto del contatto associato, aumentando ulteriormente l’illusione di legittimità. Questo rende molto più semplice ingannare gli utenti e indurli a compiere azioni dannose, come l’inserimento di credenziali, l’avvio di applicazioni dannose o il trasferimento di denaro su un conto sconosciuto.

Quali protocolli sono previsti per proteggerci dal phishing?

DMARC, DKIM e SPF: protezione dell’e-mail dallo spoofing

Il Simple Mail Transfer Protocol (SMTP)è un protocollo utilizzato per inviare messaggi di posta elettronica. È stato creato per la prima volta nel 1982, senza alcuna considerazione per la sicurezza delle e-mail. Inizialmente si pensava che la sicurezza sarebbe stata gestita con altri mezzi. Oggi, il traffico SMTP tra i server di posta elettronica può essere crittografato e autenticato tramite il protocollo TLS. Tuttavia, l’SMTP originale non includeva alcun modo per autenticare le e-mail.

Dato che l’e-mail rimane il bersaglio principale per le minacce alla sicurezza informatica, come spam, phishing e lo spoofing delle e-mail, sono stati sviluppati tre protocolli principali per migliorare la sicurezza delle e-mail:

Sender Policy Framework (SPF): Questo protocollo verifica se un server di posta è autorizzato a inviare messaggi e-mail per un determinato dominio, utilizzando DNS.
DomainKeys Identified Mail (DKIM): Questo protocollo consente di firmare digitalmente le e-mail, dimostrando che provengono da un server di posta autorizzato. Le firme DKIM consentono ai provider di posta elettronica di verificare l’autenticità del dominio del mittente.
Domain-based Message Authentication, Reporting, and Conformance (DMARC): Questo protocollo determina come gestire le e-mail che non superano i controlli SPF o DKIM. Consente di decidere l’azione appropriata quando un’e-mail non riesce ad autenticarsi.

Esempio di flusso di un’e-mail

Il server A invia una richiesta DNS per trovare il server MX (Mail Exchange) di ourcompany.com.
Il server A invia un messaggio di posta elettronica da user@company.com a user2@ourcompany.com tramite uno dei server MX (server B).
Il server B verifica l’e-mail:

- Controlla se l’e-mail proviene da un server autorizzato (verifica SPF).
- Si assicura che l’e-mail abbia una firma DKIM valida.
- Segue le azioni specificate dalla policy DMARC.

Ad esempio, se il server A non è elencato nei record SPF e il messaggio di posta elettronica non ha una firma DKIM valida, e se il dominio company.com ha una policy DMARC impostata su “Rifiuta”, allora il server B dovrebbe rifiutare il messaggio di posta elettronica.

Ma se il server di ricezione è configurato per ignorare queste policy? E se la decisione non fosse dell’admin MX? Oppure, quando non si sa di avere un ulteriore server di posta elettronica, o come funziona? Approfondiamo questo argomento.

Microsoft Exchange Online

È possibile configurare e utilizzare Exchange Online come server di posta. In questo caso, non è necessario un server Exchange in locale o un antispam di terze parti. Se si utilizza Exchange Online senza server in locale o un server MX di terze parti, questo scenario non si applica. Questo scenario copre due casi:

Ambiente ibrido: se si dispone di Exchange in locale e i servizi Exchange online e in locale comunicano tramite connettori.
Utilizzo di un server MX di terze parti: se si utilizza una soluzione di terze parti per la sicurezza delle e-mail o per il controllo dello spam.

Se si decide di mantenere il proprio registro MX puntato alla propria organizzazione in sede, tutti i messaggi inviati a qualsiasi destinatario di qualsiasi organizzazione verranno instradati prima attraverso l’organizzazione locale. Un messaggio destinato a un utente di Exchange Online viene instradato prima tramite l’organizzazione in loco e quindi recapitato al destinatario in Exchange Online. Questo percorso può essere utile per le organizzazioni che dispongono di policy di conformità che richiedono che i messaggi inviati a e da un’organizzazione siano esaminati da una meccanismo di annotazioni. Se si sceglie questa opzione, Exchange Online Protection non sarà in grado di eseguire una scansione efficace dei messaggi di spam.

Qual è il problema? Utilizzando MX diversi da quelli di Microsoft, tutte le e-mail verranno verificate da questo MX di terze parti. Dovrebbe andare bene, no? No. Se non avete bloccato la vostra organizzazione di Exchange Online per accettare solo la posta dei vostri servizi di terze parti, o se non avete abilitato il filtraggio avanzato per i connettori, chiunque potrebbe inviarvi un’e-mail tramite ourcompany.protection.outlook.com o ourcompany.mail.protection.outlook.com, e la verifica DMARC (SPF e DKIM) verrà saltata.

Se si utilizza un server MX di terze parti, è necessario configurare almeno un connettore in ingresso aggiuntivo, seguendo le raccomandazioni di Microsoft. In caso di configurazione ibrida, è necessario creare un connettore Partner con lo stesso IP/certificato utilizzato nel connettore in sede. In aggiunta, è possibile implementare: