Ghost Sender i Exchange Online: En MX-record er ikke en brannmur

Angrepsmuligheten som InfoGuard Labs beskriver som «Ghost Sender», er reell: En angriper kan omgå en foranstilt e-postgateway og levere direkte til Exchange Online. Forutsetningen er imidlertid at tenant-en fortsatt aksepterer denne direkte veien. Dette er ikke en universell sårbarhet i Exchange Online, men en ufullstendig sikret e-postflyttopologi.

En Mail Transfer Agent som betjener postkasser for et domene, tar i utgangspunktet imot SMTP-forbindelser fra internett. MX-recorden viser vanlige avsendere den ønskede leveringsveien. Den er verken en brannmurregel eller en tilgangsliste, og hindrer ingen i å kontakte et kjent Exchange Online-endepunkt direkte.

Hva «Ghost Sender» faktisk viser

Scenariet som InfoGuard Labs beskriver, ser slik ut:

1. En organisasjon har postkassene sine i Exchange Online.
2. Den offentlige MX-recorden peker til en foranstilt Secure Email Gateway.
3. Exchange Online-endepunktet på *.mail.protection.outlook.com er fortsatt direkte tilgjengelig fra internett.
4. Administratoren har ikke begrenset Exchange Online slik at bare den foranstilte gatewayen kan levere der.
5. En angriper ignorerer MX-recorden og leverer meldingen direkte til Exchange Online.

Den tiltenkte veien er dermed:

Internet -> Drittanbieter-Filter -> Exchange Online -> Postfach

Denne veien er imidlertid fortsatt åpen:

Angreifer -> Exchange Online -> Postfach

Dette er en alvorlig feilkonfigurasjon. Det foranstilte filteret kan omgås på denne veien; forfalskede avsendere, phishing og CEO-svindel blir dermed betydelig enklere. InfoGuard fortjener anerkjennelse for å ha synliggjort problemet, undersøkt utbredelsen og publisert en enkel test.

Men hvor er egentlig produktfeilen her?

Også medienes spissing hjelper lite med å sette dette i perspektiv. Heise har overskriften om at Exchange Online slipper forfalskede e-poster «uten videre gjennom», selv om bare bestemte, ufullstendig herdede tredjeparts- og hybridkonfigurasjoner er berørt. Crow in the Cloud formulerer det langt mer presist: ikke et sikkerhetshull i snever forstand, men et design- og konfigurasjonsproblem.

«An MTA is doing MTA-Things»

Hver Exchange Online-tenant har et offentlig SMTP-endepunkt. Dette endepunktet er ingen hemmelighet, og det skal heller ikke være det. Microsoft forklarer selv at Exchange Online som standard tar imot meldinger som er adressert direkte til postkasser som driftes der: Dette er rett og slett slik e-post fungerer.

Også SMTP selv beskriver MX-recorden som en mekanisme for å finne det ordinære målsystemet. Dette innebærer ingen plikt for målserveren til å avvise forbindelser via enhver annen tilgjengelig vert. En angriper må ikke følge den skilte veien. Hvis en annen MTA er tilgjengelig, kjenner mottakerdomenet og aksepterer meldingen, vil den bli prøvd – på samme måte som spammere i flere tiår har forsøkt å kontakte dårligere beskyttede backup-MX-systemer.

Den som setter et tredjepartsfilter foran, endrer standardtopologien. «Exchange Online er min internett-e-postgateway» blir til «bare tredjepartsgatewayen min kan overføre internett-e-post til Exchange Online». Denne nye Trust-Border oppstår ikke gjennom en DNS-oppføring. Den må håndheves uttrykkelig på det mottakende systemet.

Microsoft dokumenterer nettopp dette: Ved en ekstern MX skal det opprettes en Inbound Connector av typen Partner, som for SenderDomains * bare godtar sertifikatet eller kilde-IP-adressene til den foranstilte tjenesten. Meldinger som leveres direkte forbi gatewayen, blir da avvist. Dette står ordrett i Microsofts veiledning «Manage mail flow using a third-party cloud service with Exchange Online».

Frank Carius beskriver også denne «sideinngangen» inngående i MSXFAQ.

SPF, DKIM og DMARC er ikke dørvakter

InfoGuard viser meldinger der SPF, DKIM og DMARC feiler, men som likevel havner i postkassen. Det ser spektakulært ut, men er ingen kryptografisk «bypass» av disse mekanismene. E-postene kommer nettopp ikke vellykket gjennom. De leverer fail. Det avgjørende er hvilken lokal handling det mottakende systemet utleder av dette resultatet.

SPF kontrollerer om et system har lov til å sende for konvoluttavsenderen. DKIM kontrollerer en signatur. DMARC kobler disse resultatene til det synlige avsenderdomenet og publiserer ønsket behandling. Selv den gjeldende DMARC-standarden RFC 9989 fastslår uttrykkelig at mottakeren kan ta hensyn til denne ønskede behandlingen, men ikke er forpliktet til det. DMARC er et viktig signal, men ingen nettverksbasert tilgangskontroll.

Ved en foranstilt gateway kommer det i tillegg at Exchange Online først ser IP-adressen til denne gatewayen, ikke den opprinnelige avsenderens. Til dette finnes Enhanced Filtering for Connectors: Den rekonstruerer den opprinnelige kilden og forbedrer SPF-, DKIM-, DMARC-, anti-spoofing- og anti-phishing-vurderinger. Enhanced Filtering er imidlertid heller ingen dørlås. Den erstatter ikke den restriktive Partner Connector.

Feilkonfigurasjonen blir særlig tydelig når en administrator svekker eller helt omgår EOP-kontrollen via SCL-bypass fordi det foranstilte produktet allerede skal filtrere, samtidig som direkte internettlevering står åpen. Da har vedkommende ikke fått en beskyttelsesmekanisme «omgått», men bevisst unnlatt å sørge for effektiv beskyttelse ved én av to innganger.

Man kan absolutt kritisere Microsoft dersom en melding med tydelig synlig autentiseringsfeil havner i innboksen uten advarsel. Man kan kritisere semantikken i connector-typene, dokumentasjonen og manglende varsler i Configuration Analyzer. Alt dette er legitime punkter. Men eksistensen av et offentlig tilgjengelig SMTP-endepunkt er ingen sikkerhetssårbarhet.

«Direct Send» er ikke det samme som «direkte levering»

To ting blandes sammen i diskusjonen:

• Direct Send hos Microsoft betegner anonyme meldinger der konvoluttavsenderen (5321.MailFrom) bruker et eget Accepted Domain for tenant-en.
• Direkte levering til Exchange Online betegner generelt en SMTP-melding som ignorerer den publiserte tredjeparts-MX-en og leveres direkte til Exchange-endepunktet. Avsenderen kan da også bruke et vilkårlig eksternt domene.

For Direct Send finnes det en egen innstilling:

Set-OrganizationConfig -RejectDirectSend $true

Alternativer forklart

Alternativ	Virkning
-RejectDirectSend $true	Avviser anonyme direkteleveringer der konvoluttavsenderen bruker et Accepted Domain for tenant-en

Innstillingen er fornuftig dersom Direct Send ikke behøves. Den forhindrer spoofing av interne domener via denne veien. Den stenger imidlertid ikke hele sideinngangen for vilkårlige eksterne avsendere. Microsoft beskriver det nøyaktige virkeområdet i cmdlet-dokumentasjonen for RejectDirectSend. Den som vil forhindre «Ghost Sender» fullstendig, trenger fortsatt tilgangsbegrensning via Partner Connector eller en passende e-postflytregel.

Må Microsoft virkelig gjøre alt for administratoren?

Nei. Den som legger et ekstra e-postfilter inn i en produksjonstransportkjede, overtar ansvaret for denne transportkjeden.

Leverandøren kan ikke pålitelig gjette om det i tillegg til den eksterne MX-en finnes skannere, multifunksjonsenheter, SaaS-tjenester, hybridservere, partnerreléer eller andre legitime systemer som må sende direkte til Exchange Online. En automatisk «MX-en peker et annet sted, så blokker alt annet» ville avbryte ønskede e-postflyter i en rekke reelle miljøer. Derfor må administratoren definere den ønskede tillitsgrensen eksplisitt.

Likevel bør Microsoft gjøre det enklere for de ansvarlige. En god Configuration Analyzer bør oppdage en ekstern MX uten restriktiv Partner Connector og varsle tydelig. Oppsettsdialogen kunne forklare at en connector av typen «Din organisasjon» riktignok identifiserer passende forbindelser, men ikke automatisk avviser upassende forbindelser. Secure-by-default-innstillinger og bedre driftsrapporter ville også være velkomne.

Dette ville være fornuftig produktherding. Det endrer imidlertid ikke den tekniske vurderingen: En usikker spesialtopologi forblir en usikker konfigurasjon og blir ikke en zero-day bare fordi den er utbredt.

Slik stenges sideinngangen

For miljøer med et foranstilt filter bør minst disse punktene stå på sjekklisten:

1. Dokumenter e-postflyten fullstendig. Hvilke systemer har faktisk lov til å levere til Exchange Online? Dette omfatter også hybrid-, applikasjons- og nødveier.
2. Opprett en restriktiv Partner Connector. Bruk SenderDomains * og begrens leveringen til et sertifikat (foretrukket) eller vedlikeholdte kilde-IP-områder. En connector av typen OnPremises eller «Din organisasjon» håndhever ikke denne default-deny-effekten (se for eksempel også: E-postruting mellom Apache James og Exchange Online).
3. Konfigurer Enhanced Filtering riktig. Dersom EOP fortsatt skal filtrere, må opprinnelig IP og avsenderinformasjon rekonstrueres korrekt. Generelle SCL--1-bypasser må vurderes kritisk.
4. Deaktiver Direct Send dersom det ikke brukes. Kontroller først med Message Trace eller tilgjengelige rapporter om skannere eller applikasjoner avhenger av det.
5. Ikke bytt ukritisk. Test og overvåk deretter gateway-IP-områder, sertifikatbytter, hybrid e-postflyt samt onmicrosoft.com-, Teams- og andre spesialveier.

Et forenklet eksempel på den IP-baserte varianten er:

New-InboundConnector `
  -Name "Only from upstream mail gateway" `
  -ConnectorType Partner `
  -SenderDomains * `
  -RestrictDomainsToIPAddresses $true `
  -SenderIpAddresses <IP-Bereiche-des-Gateways> `
  -RequireTls $true

Alternativer forklart

Alternativ	Virkning
-Name	Visningsnavn for den nye Inbound Connector
-ConnectorType Partner	Connector-klasse for eksterne partnersystemer; bare denne typen håndhever avvisning av upassende forbindelser
-SenderDomains *	Connectoren gjelder for e-post fra alle avsenderdomener
-RestrictDomainsToIPAddresses $true	Aktiverer sperren: E-post for de angitte domenene godtas nå bare fra adressene i -SenderIpAddresses
-SenderIpAddresses	Tillatte kilde-IP-adresser eller -områder for den foranstilte gatewayen
-RequireTls $true	Krever TLS-kryptering for forbindelser via denne connectoren

Der det er mulig, bør sertifikatbinding foretrekkes fremfor en IP-tillatelsesliste. Endringer bør først gjøres i en kontrollert test, for en feilaktig tillatelsesliste gjør svært raskt den åpne sideinngangen til et fullstendig e-postutfall.

Den enkle selvtesten

Testen som InfoGuard (og MSXFAQ) viser, er nyttig:

Send-MailMessage `
  -SmtpServer <tenantname>.mail.protection.outlook.com `
  -To admin@<tenantdomain> `
  -From noreply@example.com `
  -Subject "EXO Nebeneingang" `
  -Body "Testmail direkt zum Tenant"

Alternativer forklart

Alternativ	Virkning
-SmtpServer	Målvert: tenant-ens offentlige Exchange Online-endepunkt, bevisst utenom MX-en
-To	Mottakeradresse i tenant-en som testes
-From	Vilkårlig ekstern avsenderadresse; det er nettopp dette sideinngangen ikke lenger skal akseptere
-Subject	Emnelinje, for å kunne finne den igjen i Message Trace
-Body	Meldingstekst

Med en korrekt begrenset Partner Connector forventes en SMTP-avvisning som 5.7.51 TenantInboundAttribution; Rejecting. En alternativ transportregel kan først godta meldingen og deretter flytte den til karantene; derfor må Message Trace, karantene og postkasse kontrolleres i tillegg til SMTP-svaret. Send-MailMessage (deprecated) brukes her bare som en lett forståelig illustrasjon. Ethvert kontrollert SMTP-testverktøy tjener samme formål.

En nyttig test med en misvisende etikett

«Ghost Sender» er ikke en ny SMTP-utnyttelse. Det er et treffende navn på en åpen sideinngang som Microsoft lenge har dokumentert sikringen av, og som administratoren har latt stå åpen.

Det ironiske er at InfoGuard i sitt eget bidrag selv omtaler problemet som «widespread and systematic misconfiguration» og avslutter med setningen «Ghost-Sender is a misconfiguration». Microsofts Security Response Center klassifiserte også først rapporten som ikke en sikkerhetssårbarhet. Faktaene finnes altså i artikkelen: Bare tittelen, test-e-posten og «Vulnerability»-merkingen antyder dessverre en mer dramatisk tolkning.

Den nyttige delen av publiseringen er vekkeropet: Mange selskaper har tilsynelatende ikke låst e-postflyten sin ordentlig. Den problematiske delen er påstanden om at Exchange Online har en universell sikkerhetssårbarhet. Nei: Exchange Online oppfører seg her først og fremst som en MTA. Det blir usikkert gjennom en tillitsgrense som ikke er ferdig konfigurert.

Må man virkelig gjøre alt for administratoren? Nei. Men man må tydeligvis stadig minne om at DNS-ruting ikke erstatter tilgangskontroll.