Il caso di phishing in Exchange Online

Questo post è il racconto e l’analisi dettagliata di un probabile problema di sicurezza di Exchange Online presente il 26/01/2024 e vissuto personalmente. Evidenzieremo il comportamento di un’email di phishing in ingresso nel nostro tenant Microsoft 365 e la sua redirezione in un’altra casella postale gestita da un altro tenant Microsoft 365 di un nostro partner. Entreremo inevitabilmente nei meandri tecnici dei protocolli SPF, DKIM, DMARC e ARC terminando con alcune indicazioni generali.

Il contesto

Talvolta capita di configurare alcune redirezioni esterne nelle nostre caselle di posta. Succede quando si lavora con partner che, per necessità d’immagine, devono avere un indirizzo di posta nel nostro tenant Microsoft 365 ma, per gestione ordinaria, vogliono ricevere le email anche nelle loro caselle di posta personali. Oppure quando alcuni fornitori devono riceve email sul nostro dominio di posta ma devono leggerle per forza nella loro casella (es: commercialisti, legali, amministratori delegati).

Quindi, il caso odierno è:

• Mario Rossi ha una casella mario.rossi@azienda.it nel nostro tenant (non importa la licenza).
• Mario Rossi ha la sua casella postale personale mario@mariorossi.it nel suo tenant (non importa la licenza).
• La redirezione esterna è fortemente sconsigliata per problemi di coerenza dei protocolli SPF e DKIM, tant’è che la troviamo vietata di default nei nostri tenant ma noi l’abbiamo abilitata seguendo questo articolo.
• Il nostro dominio di posta azienda.it è correttamente configurato seguendo il prodotollo DMARC con policy=reject ed il nostro tenant ha tutte le policy di antispam settate affichè vengano rigettate le email di phishing, come indicato in questo articolo.
• Una email di phishing (con indirizzo from: noreply@azienda.it) entra nella nostra organizzazione Exchange Online diretta verso la casella postale di Mario Rossi.
• Mario Rossi ha configurato la redirezione esterna verso la sua casella personale.

Con lo schema seguente analizziamo il dettaglio di cosa succede tramite i punti da (1) a (5):

(1) La mail di phishing in ingresso nell’organizzazione azienda.it

Evidenziamo i campi fondamentali del header della email in ingresso:

La mail parte dall’indirizzo ip 188.225.34.192 con un dominio SPF (mail from) mworx.ru impersonificando nel from il nostro dominio azienda.it senza alcuna firma DKIM. Il DMARC fa il suo mestiere e indica di rigettare la mail in ingresso (dmarc=fail action=oreject). Exchange Online Protection lo capisce, lo esplicita nel campo Authetication-Results ma, in più ed inutilmente, alza il valore del SCL a 5 classificandola anche come email di spam nella scala da 0 a 9. Perchè dovrebbe dichiarare spam una mail che va rigettata?

(2) La mail non va in consegna nella nostra casella di posta

Dato che possediamo la regola nell’antispam policy che onora il verdetto DMARC dei domini sorgente, questa email non va in consegna nella casella azienda.it di Mario Rossi. Non la troviamo neanche nella quarantena o nel message explorer di Defender for Office365. La vediamo solo nel message tracking.

(3) La mail non viene rigettata completamente e viene comunque rediretta

Posto che tutte le caselle postali presenti in Exchange Online, con ogni tipo di licenza, sono protette dal phishing DMARC; lo stesso non vale per le caselle esterne frutto di una redirezione. Exchange Online non onora la policy DMARC e redirige ciecamente la mail (anche se phishing) verso la casella postale esterna ma prima compie due operazioni documentate:

1) Applica la firma DKIM con queste regole:

• Se il dominio mittente non è gestito dal tenant usa il dominio DKIM di default (azienda.onmicrosoft.com)
• Se il dominio mittente è gestito dal tenant (e la configurazione DKIM del dominio esiste) usa la firma DKIM del dominio mittente

Il tutto ha senso in quanto è importante porre una firma DKIM da parte del tenant che redirige, questo garantisce il destinatario e dà forza ad un’operazione voluta. In caso di configurazione di Exchange Hybrid o relay autenticati con connettori è fondamentale che questo accada.

2) Applica il protocollo ARC di default che regola ed “autentica” tutte le redirezione esterne da Microsoft 365.

Nel nostro caso però, le due operazioni sono la chiave di volta per capire l’articolo in quanto il dominio impersonificato dal mittente è azienda.it che è gestito dal nostro tenant ed ha la configurazione DKIM consigliata.

Il nostro tenant appone quindi la firma DKIM del nostro dominio e, successivamente, applica le firme ARC… Anche se la mail originale è phishing (?!?).

NOTA: la mail rediretta esternamente uscirà dai server del Relay Pool che hanno un loro set di indirizzi ip non inclusi nel record SPF di Exchange Online (include:spf.protection.outlook.com). Il tutto per proteggere l’attendibilità dei propri server di spedizione e non rischiare di inquinare gli indirizzi ip delle spedizioni autenticate.

(4) Il tenant partner mariorossi.it vede la redirezione firmata e accetta la mail

Un tenant Microsoft 365 che riceve la nostra email rediretta vede le due informazioni chiave che la rendono attendibile. Evidenziamo i campi fondamentali del header della email in ingresso (abbiamo troncato le firme DKIM e ARC per semplificazione):

• L’ip sorgente, che comincia con 40.95.0.0, evidenzia l’uso del Relay Pool in quanto si tratta di un’email rediretta ma, in questo caso, non cambia il verdetto perchè il dominio SPF (mworx.ru) era già insicuro alla spedizione iniziale. Anche grazie a questo dettaglio possiamo dimostrare l’insufficienza del protocollo SPF per la protezione delle nostre comunicazioni.
• E’ presente la firma DKIM del dominio azienda.it correttamente configurata nel tenant sorgente della redirezione (DKIM-Signature).
• L’autenticazione ARC del tenant Microsoft sorgente viene apposta dopo la firma DKIM: il campo ARC-Authentication-Results evidenzia che il protocollo SPF non verificato nel dominio mworx.ru serve a nulla perchè esiste la firma DKIM del dominio azienda.it quindi il DMARC passa e ARC passa… Booooom.
• Il tutto è dimostrato ed esplicitato anche nel campo Authentication-Results tramite l’autenticazione composita al massimo della fiducia (compauth=pass reason=100).

Mi duole evidenziale che il tenant destinazione non guarda il campo dell’header della mail originale che viene inserito nell’Authentication-Results-Original dove era chiaro, fin dall’inzio, che la mail sorgente della redirezione era phishing, perfino certificato dal dmarc=fail.
Dal contenuto e dalla forma della mail viene comunque alzato il livello di spam portando il valore SCL a 6 ma non basterà per evitare la consegna.

(5) La mail di phishing va in consegna nella casella postale destinazione mario@mariorossi.it

Anche se il tenant destinazione onora la policy DMARC nelle sue antispam policy non può che considerare positivamente la firma DKIM del tenant azienda.it quindi consegna la mail nella casella destinazione con SCL=6. Grazie a quest’ultimo controllo la mail finisce nella posta indesiderata ma con una motivazione legata pricipalmente al contenuto. E’ inutile pensare che la junk mail sia uno strumento di protezione in quanto i nostri utenti possono tranquillamente sposare l’oggetto dannoso ed aprirlo senza difficoltà.

Conclusioni

Il comportamento spiegato in questo articolo è attualmente al vaglio del Product Group di Exchange Online ma ci insegna molto sulla lunga strada che dobbiamo ancora percorrere per raggiungere una vera protezione dei nostri ambienti di posta. Prima di tutto ci fa capire che dovremmo togliere le redirezioni esterne dalle nostre configurazioni ma è altrettanto importante che i grandi provider pubblici applichino in maniera restrittiva tutte le specifiche del protocollo DMARC estendendo la protezione a monte, prima delle eventuali redirezioni… Sempre. Il rispetto della policy DMARC non è più da considerarsi una feature di sicurezza da POTER applicare. E’ l’unico standard in grado di eliminare il phishing, cambiamo prospettiva, il rispetto della policy DMARC è da DOVER applicare.