Ghost Sender in Exchange Online: un record MX non è un firewall
La consegna diretta a Exchange Online aggira un gateway a monte se il tenant non la blocca esplicitamente. Il rischio è reale; la causa è una configurazione incompleta del flusso di posta.
La possibilità di attacco descritta da InfoGuard Labs come «Ghost Sender» è reale: un aggressore può aggirare un gateway e-mail a monte e consegnare direttamente a Exchange Online. Il presupposto, tuttavia, è che il tenant continui ad accettare questo percorso diretto. Non si tratta di una vulnerabilità universale di Exchange Online, bensì di una topologia di flusso di posta protetta in modo incompleto.
Un Mail Transfer Agent che gestisce le caselle di posta di un dominio accetta per principio connessioni SMTP da Internet. Il record MX indica ai mittenti regolari il percorso di consegna desiderato. Non è né una regola firewall né un elenco di accesso e non impedisce a nessuno di contattare direttamente un endpoint noto di Exchange Online.
Cosa mostra realmente «Ghost Sender»
Lo scenario descritto da InfoGuard Labs è il seguente:
- Un’organizzazione gestisce le proprie caselle di posta in Exchange Online.
- Il record MX pubblico punta a un Secure Email Gateway a monte.
- L’endpoint di Exchange Online in
*.mail.protection.outlook.comresta direttamente raggiungibile da Internet. - L’amministratore non ha limitato Exchange Online in modo che solo il gateway a monte possa effettuare consegne.
- Un aggressore ignora il record MX e recapita il proprio messaggio direttamente a Exchange Online.
Il percorso previsto è quindi:
Internet -> Drittanbieter-Filter -> Exchange Online -> PostfachTuttavia, resta aperto questo percorso:
Angreifer -> Exchange Online -> PostfachSi tratta di una configurazione errata da prendere sul serio. Il filtro a monte può essere aggirato lungo questo percorso; mittenti falsificati, phishing e CEO fraud ne risultano notevolmente facilitati. A InfoGuard va riconosciuto il merito di aver reso visibile il problema, averne analizzato la diffusione e pubblicato un test facile da usare.
Ma dove sarebbe esattamente il difetto del prodotto?
Anche l’enfasi mediatica aiuta poco a inquadrare la questione. Heise titola che Exchange Online lascia passare e-mail falsificate «senza problemi», sebbene siano interessate solo determinate configurazioni di terze parti e ibride non completamente rafforzate. Crow in the Cloud lo formula in modo molto più preciso: non una falla di sicurezza in senso stretto, bensì un problema di progettazione e configurazione.
«An MTA is doing MTA-Things»
Ogni tenant di Exchange Online dispone di un endpoint SMTP pubblico. Questo endpoint non è un segreto e non deve esserlo. Microsoft stessa spiega che Exchange Online accetta per impostazione predefinita i messaggi indirizzati direttamente alle caselle ospitate: è semplicemente il funzionamento dell’e-mail.
Anche SMTP stesso descrive il record MX come un meccanismo per individuare il sistema di destinazione regolare. Da ciò non deriva alcun obbligo per il server di destinazione di rifiutare le connessioni attraverso ogni altro host raggiungibile. Un aggressore non deve attenersi al percorso indicato. Se un altro MTA è raggiungibile, conosce il dominio del destinatario e accetta il messaggio, verrà tentato, proprio come gli spammer cercano da decenni di contattare sistemi MX di backup meno protetti.
Chi antepone un filtro di terze parti modifica la topologia standard. Da «Exchange Online è il mio gateway di posta Internet» si passa a «solo il mio gateway di terze parti può trasferire posta Internet a Exchange Online». Questo nuovo Trust-Border non nasce da una voce DNS. Deve essere imposto esplicitamente sul sistema ricevente.
Microsoft documenta esattamente questo: con un MX esterno va creato un Inbound Connector di tipo Partner che, per SenderDomains *, accetta solo il certificato o gli indirizzi IP di origine del servizio a monte. I messaggi consegnati direttamente, aggirando il gateway, vengono quindi rifiutati. Questo è riportato testualmente nella guida Microsoft «Manage mail flow using a third-party cloud service with Exchange Online».
Anche Frank Carius descrive dettagliatamente questo «ingresso secondario» nella MSXFAQ.
SPF, DKIM e DMARC non sono buttafuori
InfoGuard mostra messaggi per i quali SPF, DKIM e DMARC falliscono e che arrivano comunque nella casella di posta. Sembra spettacolare, ma non è un «bypass» crittografico di questi meccanismi. Le e-mail non superano affatto i controlli con successo. Forniscono fail. È determinante quale azione locale il sistema ricevente deduca da tale risultato.
SPF verifica se un sistema è autorizzato a inviare per il mittente dell’envelope. DKIM verifica una firma. DMARC collega questi risultati al dominio del mittente visibile e pubblica un trattamento richiesto. Anche l’attuale standard DMARC RFC 9989 afferma espressamente che il destinatario può considerare tale trattamento richiesto, ma non è obbligato a farlo. DMARC è un segnale importante, ma non un controllo di accesso alla rete.
Con un gateway a monte si aggiunge il fatto che Exchange Online vede inizialmente l’indirizzo IP di quel gateway e non quello del mittente originario. A questo serve Enhanced Filtering for Connectors: ricostruisce la fonte originaria e migliora le valutazioni SPF, DKIM, DMARC, anti-spoofing e anti-phishing. Tuttavia, nemmeno Enhanced Filtering è una serratura. Non sostituisce il Partner Connector restrittivo.
La configurazione errata diventa particolarmente evidente quando un amministratore indebolisce il controllo EOP tramite SCL bypass o lo rimuove del tutto, poiché dovrebbe già filtrare il prodotto a monte, ma allo stesso tempo lascia aperta la consegna diretta da Internet. In tal caso non gli è stato «aggirato» un meccanismo di protezione: ha deliberatamente previsto che uno dei due ingressi non abbia più una protezione efficace.
Si può certamente criticare Microsoft se un messaggio con un errore di autenticazione chiaramente visibile finisce nella posta in arrivo senza avviso. Si possono criticare la semantica dei tipi di connettore, la documentazione e gli avvisi mancanti nel Configuration Analyzer. Sono tutti punti legittimi. L’esistenza di un endpoint SMTP pubblicamente raggiungibile non è però una falla di sicurezza.
«Direct Send» non equivale a «consegna diretta»
Nella discussione vengono confusi due aspetti:
- Direct Send indica per Microsoft messaggi anonimi il cui mittente dell’envelope (
5321.MailFrom) utilizza un proprio Accepted Domain del tenant. - Consegna diretta a Exchange Online indica in generale un messaggio SMTP che ignora l’MX di terze parti pubblicato e viene consegnato direttamente all’endpoint Exchange. Il mittente può anche utilizzare un dominio esterno qualsiasi.
Per Direct Send esiste un’apposita impostazione:
Set-OrganizationConfig -RejectDirectSend $trueL’impostazione è utile se Direct Send non è necessario. Impedisce lo spoofing del dominio interno tramite questo percorso. Tuttavia, non chiude l’intero ingresso secondario per mittenti esterni arbitrari. Microsoft descrive l’esatto ambito di applicazione nella documentazione del cmdlet per RejectDirectSend. Chi vuole impedire completamente «Ghost Sender» continua a necessitare della limitazione di accesso tramite Partner Connector o di un’adeguata regola di flusso di posta.
Microsoft deve davvero fare tutto al posto dell’amministratore?
No. Chi inserisce un filtro e-mail aggiuntivo in una catena di trasporto produttiva si assume la responsabilità di tale catena di trasporto.
Il fornitore non può stabilire in modo affidabile se, oltre all’MX esterno, scanner, dispositivi multifunzione, servizi SaaS, server ibridi, relay di partner o altri sistemi legittimi debbano inviare direttamente a Exchange Online. Un blocco automatico del tipo «l’MX punta altrove, quindi blocco tutto il resto» interromperebbe flussi di posta desiderati in numerosi ambienti reali. L’amministratore deve pertanto definire esplicitamente il confine di fiducia desiderato.
Ciononostante, Microsoft dovrebbe facilitare il lavoro ai responsabili. Un buon Configuration Analyzer dovrebbe rilevare un MX esterno senza Partner Connector restrittivo e visualizzare un avviso chiaro. La procedura guidata di configurazione potrebbe spiegare che un connettore di tipo «La tua organizzazione» identifica le connessioni appropriate, ma non rifiuta automaticamente quelle inappropriate. Sarebbero inoltre benvenute impostazioni secure-by-default e migliori report operativi.
Questo sarebbe un utile rafforzamento del prodotto. Tuttavia, non cambia la valutazione tecnica: una topologia speciale insicura resta una configurazione insicura e non diventa uno zero-day solo per la sua ampia diffusione.
Come chiudere l’ingresso secondario
Per gli ambienti con filtro a monte, almeno questi punti dovrebbero far parte della checklist:
- Documentare completamente il flusso di posta. Quali sistemi sono effettivamente autorizzati a consegnare a Exchange Online? Sono inclusi anche percorsi ibridi, applicativi e di emergenza.
- Configurare un Partner Connector restrittivo. Utilizzare
SenderDomains *e limitare la consegna a un certificato (preferibile) o a intervalli di IP di origine gestiti. Un connettore di tipoOnPremiseso «La tua organizzazione» non impone questo effetto di default deny (vedi ad esempio: routing della posta tra Apache James e Exchange Online). - Configurare correttamente Enhanced Filtering. Se EOP deve continuare a filtrare, l’IP originale e le informazioni del mittente devono essere ricostruiti correttamente. I bypass SCL-
-1generalizzati devono essere esaminati criticamente. - Disattivare Direct Send se non utilizzato. Prima, verificare con Message Trace o con i report disponibili se scanner o applicazioni ne dipendono.
- Non effettuare la modifica alla cieca. Testare e poi monitorare gli intervalli IP del gateway, le modifiche ai certificati, il flusso di posta ibrido e i percorsi speciali
onmicrosoft.com, Teams e altri.
Un esempio semplificato per la variante basata su IP è il seguente:
New-InboundConnector `
-Name "Only from upstream mail gateway" `
-ConnectorType Partner `
-SenderDomains * `
-RestrictDomainsToIPAddresses $true `
-SenderIpAddresses <IP-Bereiche-des-Gateways> `
-RequireTls $trueOve possibile, il vincolo al certificato è preferibile a una allowlist IP. Le modifiche vanno prima effettuate in un test controllato, poiché una allowlist errata trasforma molto rapidamente l’ingresso secondario aperto in un’interruzione completa della posta.
Il semplice autotest
Il test mostrato da InfoGuard (e dalla MSXFAQ) è utile:
Send-MailMessage `
-SmtpServer <tenantname>.mail.protection.outlook.com `
-To admin@<tenantdomain> `
-From noreply@example.com `
-Subject "EXO Nebeneingang" `
-Body "Testmail direkt zum Tenant"Con un Partner Connector correttamente limitato, è prevedibile un rifiuto SMTP come 5.7.51 TenantInboundAttribution; Rejecting. Una regola di trasporto alternativa può prima accettare il messaggio e poi spostarlo in quarantena; oltre alla risposta SMTP, vanno pertanto controllati anche Message Trace, quarantena e casella di posta. Send-MailMessage (deprecato) serve qui solo come illustrazione facilmente comprensibile. Qualsiasi strumento SMTP di test controllato assolve lo stesso scopo.
Un test utile con un’etichetta fuorviante
«Ghost Sender» non è un nuovo exploit SMTP. È un nome efficace per un ingresso secondario aperto, la cui protezione Microsoft documenta da tempo e che l’amministratore ha lasciato aperto.
L’aspetto ironico è che InfoGuard definisce il problema, nel proprio articolo, «widespread and systematic misconfiguration» e conclude con la frase «Ghost-Sender is a misconfiguration». Anche il Security Response Center di Microsoft inizialmente non ha classificato la segnalazione come vulnerabilità. I fatti sono dunque presenti nell’articolo: purtroppo, solo il titolo, l’e-mail di test e il branding «Vulnerability» suggeriscono un’interpretazione più drammatica.
La parte sensata della pubblicazione è il campanello d’allarme: molte aziende apparentemente non hanno sigillato correttamente il proprio flusso di posta. La parte problematica è l’affermazione che Exchange Online presenti per questo una vulnerabilità universale. No: Exchange Online si comporta qui anzitutto come un MTA. Diventa insicuro a causa di un confine di fiducia non configurato fino in fondo.
Bisogna davvero fare tutto al posto dell’amministratore? No. Ma a quanto pare occorre ricordare continuamente che il routing DNS non sostituisce il controllo degli accessi.
Commenti
I commenti vengono caricati da GitHub / Giscus.