EXO und DMARC Reject

Ende Jun 2024 war es wohl möglich als "Microsoft" eine Mail an einen Tenant zu senden, die nicht als Phishing erkennt wurde, obwohl die Domain Microsoft.com eine DMARC-Richtlinie mit "p=reject" hatte. Hier erkläre ich ich die Zusammenhänge.

Diese Seite im im Rahmen einer Meldung auf Twitter (https://x.com/slonser_/status/1801521692314927433) entstanden, aber die dort beschriebene Lücke schafft angeblich einen "DMARC=pass" und dürfte daher einen anderen Fall darstellen.

Bei der Analyse der Zusammenhänge hat mich Sören Beiler aus dem NoSpamProxy-Team von Net at Work tatkräftig unterstützt. Vielen Dank.

Was ist passiert?

Wenn Sie folgende Mail im Posteingang finden, dann sollten sie schon sehr sicher sein, ob diese authentisch ist oder nicht.

Das ist natürlich nur eine Testmail aber sie wurde von einer "anonymen" IP-Adresse an meinen Tenant gesendet und nicht als Phishing blockiert. Im Header konnte ich sehen:

Authentication-Results: spf=pass (sender IP is 5.230.152.42)
 smtp.mailfrom=uclabor.de; dkim=none (message not signed)
 header.d=none;dmarc=fail action=oreject
 header.from=microsoft.com;compauth=none reason=451
Received-SPF: Pass (protection.outlook.com: domain of uclabor.de designates
 5.230.152.42 as permitted sender) receiver=protection.outlook.com;
 client-ip=5.230.152.42; helo=ich; pr=C
Received: from ich (5.230.152.42) by
 AMS0EPF0000019E.mail.protection.outlook.com (10.167.16.250) with Microsoft
 SMTP Server id 15.20.7677.15 via Frontend Transport; Wed, 19 Jun 2024
 13:51:04 +0000
from: <security@microsoft.com>
to: <frank@carius.de>
Subject: test
Message-ID:
 <1ae2dcba-1463-4a85-9fd3-e47c897f80df@AMS0EPF0000019E.eurprd05.prod.outlook.com>
Return-Path: dmarctest@uclabor.de

Wenn Sie genau hinsehen, dann finden Sie in der ersten Zeile schon alle Informationen, die sie brauchen:

Header Bedeutung

smtp.mailfrom=uclabor.de

Ich habe die Mail per SMTP eingeliefert und der P1-Absender ist aus der Domain "uclabor.de"

dkim=none (message not signed)

Die Nachricht war nicht DKIM signiert. DKIM wird auf den kompletten Header inklusive des P2-Absenders "microsoft.com" und dafür kann ich mangels Zugriff auf den Schlüssel keine Signatur erstellen

header.d=none

 

header.from=microsoft.com

Wie nicht anders zu erwarten, ist aus dem Header die Absenderadresse security@microsoft.com auf die Domain "microsoft.com" umgesetzt worden

dmarc=fail

Da die Absenderdomain im Envelope (P1) und im Header (P2) unterschiedlich sind, passt das Alignment von DMARC nicht und ergibt ein Fail. Mögliche Werte sind

pass
fail
bestguesspass
none

action=oreject

Das ist der RootCause: oreject heisst "OverwriteReject", d.h. Microsoft hätte die Mail eigentlich abgelehnt aber etwas anderes hat dies verhindert. Mögliche Werte sind:

permerror
temperror
oreject
pct.quarantine
pct.reject

compauth=none reason=451

 

Auch die zweite Zeile sollten wir mit bewerten:

Received-SPF: Pass (protection.outlook.com: domain of uclabor.de designates
 5.230.152.42 as permitted sender) receiver=protection.outlook.com;
 client-ip=5.230.152.42; helo=ich; pr=C

Ich habe natürlich eine Mail mit meiner uclabor.de-Adresse von einer IP-Adresse versendet, die für diese Domain auch authentisch ist. Das kann ich, im Gegensatz zu DKIM problemlos machen.

Einlieferung per SMTP

Wenn Sie so eine Mail selbst einmal generieren wollen, dann können Sie diese per TELNET einfach an die Microsoft 365-Server senden. Sie müssen erst einmal den MX-Record für ihre Domain aus dem Admin Center ermitteln, unter der Microsoft Mails annimmt.

nslookup -q=MX <tenantname>.onmicrosoft.com

Starten Sie dann einen "TELNET <servername> 25" und geben Sie nacheinander ein:

HELO testmailserver.example.com
mailfrom: <absender@angreiferdomain.tld>
rcptto: <user@<tenantname.onmicrosoft.com>
Data
from: security@microsoft.com
to:<user@<tenantname.onmicrosoft.com>
Subject: Spoofing Message

Dies ist eine Spoofing Message
.

Jede Zeile muss mit einem CR/LF abgeschlossen und beachten Sie bitte die Leerzeile zwischen Envelope und Header und die letzte Zeile enthält nur ein "Punkt". Zudem sollten Sie natürlich mit ihrem System die "einfachen" Spamfilter auf Basis ihrer IP-Adresse überwinden, d.h. nutzen Sie eine statische IP-Adresse, die per SPF auch für ihre Absenderdomain im Envelope aufgeführt ist.

DMARC bei Microsoft

Die soeben gesendete Beispielmail sollte vom Microsoft 365 Spamfilter zuverlässig als Phishing/Spoofing erkannt und abgeleht oder gelöscht werden. Zumal Microsoft dies per DMARC-Eintrag auch fordert:

Alle Mailserver, die DMARC verstehen, sollten zum einen das "Alignment" der Absenderdomains im Envelope und Header prüfen und bei einem DMARC-Fail diese Mail auch blockieren.

M365 Einstellungen zu DMARC

DMARC ist natürlich auch wieder nur eine RFC  (Request vor Comment) und damit eine "Empfehlung". Leider wissen nicht alle Administratoren, wie Sie ihre Domain korrekt konfigurieren und wenn ein Absender sich beim Empfänger beschwert, weil seine Mails nicht ankommen, dann muss meist der Empfänger erst mal beweisen, dass er nichts falsch macht. Daher hat Microsoft eine Option geschaffen, die DMARC-Prüfung pro Tenant zu steuern. Der Empfänger kann bestimmen, ob eine Mail abhängig von der DMARC-Einstellung auch wirklich abgewiesen oder nur in Quarantäne oder Junk-E-Mail verschoben wird.


Auszug aus https://security.microsoft.com/antiphishing

Diese Einstellung war früher sogar noch "soft" aber wurde nach einiger Zeit dann per Default auf "Streng" gestellt:

Mein Tenant war auch so eingestellt aber dennoch landet die Mail in meinem Posteingang. Was läuft hier schief? Is es vielleicht die Vorbedingungen, die der Richtlinie im Text versteckt ist?

Passend dazu gibt es auch eine Anzeige in der Richtlinie, die aber per Default auf "On" steht:

Die Frage bleibt aber dennoch: Wer oder Was bestimmt denn nun, dass die Mail als "Spoofing" erkannt wird und damit die DMARC-Einstellungen greifen? Vielleicht wurde meine Mail gar nicht als "Spoofing" erkannt und Exchange Online hat dann trotz entsprechender Konfiguration die Mails nicht anhand der DMARC-Einstellungen behandelt. In der gleichen Richtlinie gibt es nämlich noch eine Einstellung.

Hier kann (und sollte!) ich nachschauen, ob ein Spoofing mit meinen eigenen Domains geschützt ist. Theoretisch könnte ich hier auch "microsoft.com" manuell addieren aber jede Firma hat sehr viele Absender und warum sollte ich jede Domain selbst pflegen, wenn der Domaininhaber per DNS-TXT-Record schon vorgibt, wie DMARC ausgelegt werden sollte?

Wenn Sie den MX-Eintrag nicht direkt zu Exchange Online verweisen lassen, sondern einen 3rd Party Spamfilter wie NoSpamProxy o.a. einsetzen, dann sollten Sie folgende Informationen beachten:


https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about?view=o365-worldwide#spoof-protection-and-sender-dmarc-policies

Microsoft scheint zu prüfen, ob ihr MX-Record zu einem anderen Service geht und wendet dann DMARC nur an, wenn Sie über EXO Enhanced Filtering den eingehenden Connector zu dieser 3rd Party-Lösung konfiguriert haben.

Basis / E5 / DefenderATP

Ich habe natürlich nicht nur einen Tenant, sondern gleich mehrere Tenants, die ich für Test heranziehe. Ich habe daher einen Tenant mit Office 365 E3 und einen zweiten Tenant mit Microsoft 365 E5-Lizenz als Gegenstelle getestet, die ansonsten aber identisch konfiguriert sind, d.h. alles steht auf den Standardwerten, wie Microsoft diese vorgibt. Dabei ergab sich schon ein Unterschied:

E3 -> Spoofing Mail kam im Postfach an
E5 -> Spoofing Mail kam NICHT Postfach an.

Es gibt hier anscheinend einen Unterschied allein anhand der Lizenzen.

Hier muss ich noch weiter auf den Grund gehen

Transportregel zum Ablehnen

In der Anfangszeit hat Microsoft zwar eine DMARC-Analyse gemacht aber weder DMARC-Reports an die Domain gesendet noch Mails zurückgewiesen. Mittlerweile sendet Microsoft zumindest "DMARC Aggregate Reports", wenn der MX-Record der Absenderdomain auf Microsoft 365 verweist. Forensische Reports werden gar nicht versendet.

Aber ein Exchange Administrator konnte anhand des "Headers" sehen, wie die DMARC-Prüfung und das Ergebnis erfolgt sind.

Authentication-Results: ... dmarc=fail action=oreject ...

Im Feld "Authentication-Results" finden wir folgende Rückmeldungen:

dmarc=fail          action=oreject
dmarc=pass          action=<unterschiedliche Werte>
dmarc=bestguesspass action=<unterschiedliche Werte>
dmarc=none          action=<unterschiedliche Werte>

Interessant ist nur die "action=oreject", denn diese Mail wäre eigentlich abgelehnt worden aber ein "OverwriteReject" hat dies verhindert.

Microsoft mein wohl immer noch, dass sie einem "DMARC p=reject" einer Absenderdomain nicht vertrauen sollten, weil sie ja doch falsch sein könnte und damit die Support Tickets für nicht zugestellte Mails ansteigen würden.

Die Lösung ist für den Fall einfach und genau genommen gibt es zwei Optionen:

  • Spoof intelligence in der ATP-Anti phishing policy einschalten
    Auf hhttps://security.microsoft.com/antiphishing sollten Sie in der AntiPhish-Policy sicherstellen, dass "Spoof intelligence=On" ist und in den Actions die DMARC-Aktionen auf den gewünschten Aktionen steht.

    Interessanterweise ist die Einstellung in meinem Microsoft 365 E3 und Microsoft 265 E5-Tenant identisch. Dennoch verhalten sie beide Tenants unterschiedlich.
  • Transportregelll
    Wenn Sie diese Option mangels Lizenz nicht nutzen können, dann können Sie über eine Transport-Regel auf das Feld "Authentication-Results" und den String "dmarc=fail action=oreject" die gewünschte Aktion konfigurieren.

Irgendwie finde ich es irritierend, dass E3/E5-Tenants sich unterschiedlich verhalten und jeder Administrator noch eine Transportregel einrichten müsste, um DMARC so umzusetzen, wie es der Absender fordert.

Zumal Microsoft am 19. Jul 2024 ja groß eine entsprechende Änderung publiziert hat:

For our enterprise customers, you can now choose how to handle emails that fail DMARC validation and choose different actions based on the policy set by the domain owner, such as p=reject or p=quarantine.
If the recipient domain's MX record points to Office 365, by default, we will honor the sender’s DMARC policy and reject (p=reject) or quarantine (p=quarantine) the email as instructed. However, you can change this behavior and specify different actions for different policies
Quelle: Announcing New DMARC Policy Handling Defaults for Enhanced Email Security
https://techcommunity.microsoft.com/t5/exchange-team-blog/announcing-new-dmarc-policy-handling-defaults-for-enhanced-email/ba-p/3878883

Das ist genau die Einstellung, die ich gerne hätte aber anscheinend funktioniert der Microsoft Spamfilter so zumindest Ende Jun 2024 nicht. Allerdings ist auch das alte Verhalten keine Verletzung der RFC

"Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the Domain Owner has published a "reject" policy".
RFC7489, section 6.7 https://datatracker.ietf.org/doc/html/rfc7489#section-6.7

Insofern ist die Ignoranz des DMARC-Eintrags laut RFC7489 nicht verboten.

Zwischenstand

Exchange Online prüft zwar jede eingehende Mail anhand SPF, DKIM und DMARC aber wendet die vom Absender veröffentlichten DMARC-Richtlinien anscheinend nicht immer an. Es ist dennoch unstimmig, wenn im Sommer 2023 angekündigt wird, man möchte die DMARC-Einstellungen als Default respektieren, aber ein Jahr später kann ich immer noch eine Mail mit dem Absender "security@microsoft.com" an einen Microsoft 365 Tenant senden und sie kommt direkt im Postfach an.

Die meisten 3rd Party Lösungen sind hier strenger unterwegs und zumindest meine Kollegen aus dem NoSpamProxy Team schütteln mit dem Kopf. Wenn ein Absender schon eine DMARC-Richtlinie erstellt, dann kommuniziert der damit aus meiner Sicht, dass er diese auch angewendet haben möchte.

Wenn ich aber in der AntiPhish-Policy alles richtig konfiguriert habe, dann sollte Exchange Online sich auch dran halten. Da es aktuell aber noch relativ wenig Firmen mit einem DMARC-Eintrag gibt und noch weniger ein "p=reject" haben, könnte man drüber hinweg schauen. Aber dagegen spricht das Phishing mit der Microsoft.com-Domain.

Weitere Links