[English]Mit dem Sicherheitsupdate vom November 2024 hat Microsoft seine Exchange 2016- und Exchange 2019-Server mit einer neuen Funktion versehen. Microsoft Exchange warnt nun bei empfangen zu E-Mails, die eine Spoofing-Schwachstelle (Exchange Server non-RFC compliant P2 FROM header detection) ausnutzen. Einziges Problem: Die Sicherheitsupdates vom November 2024 sind aktuell gestoppt.
Anzeige
Non-RFC compliant P2 FROM header detection
Im Blog-Beitrag Microsoft Exchange Server Updates 12. November 2024 hatte ich über die Neuerungen berichtet, die mit den Sicherheitsupdates für Exchange 2016- und Exchange 2019-Server ausgerollt wurden. Dabei wurde eine neue Funktion implementiert, um nicht RFC 5322-kompatible P2-FROM-Header in eingehenden E-Mail-Nachrichten zu erkennen.
Der P2-FROM-Header in einer E-Mail ist Teil des Nachrichtenkopfes, der dem E-Mail-Client des Empfängers (z. B. Outlook) angezeigt wird. Es ist die E-Mail-Adresse oder der Name des Absenders (wenn der Absender intern ist), der im Feld „Von" angezeigt wird, wenn Sie eine E-Mail in Ihrem Posteingang anzeigen.
Spoofing-Schwachstelle CVE-2024-49040
Im November 2024 wurde dann von Microsoft bestätigt, dass es in Exchange 2016- und Exchange 2019-Server die Spoofing-Schwachstelle CVE-2024-49040 gibt, und diese mit dem November 2024-Sicherheitsupdate geschlossen wird.
Vsevolod Kokorin von Solidlab hat diese Schwachstelle entdeckt und im Mai 2024 in diesem Beitrag darüber berichtet. Problem ist, dass SMTP-Server die Empfängeradresse von Mails unterschiedlich auswerten, was ein E-Mail-Spoofing ermöglicht. Die Kollegen von Bleeping Computer haben diese Erkenntnisse hier thematisiert.
Anzeige
Microsoft warnt vor CVE-2024-49040 Spoofing
Nachdem Microsoft von Solidlab über die Spoofing-Schwachstelle CVE-2024-49040 in Exchange Server informiert wurde, hat man das Ganze untersucht. Microsoft schreibt, dass die Schwachstelle durch die aktuelle Implementierung der P2 FROM-Header-Überprüfung verursacht wird, die während des Transports erfolgt. Die aktuelle Implementierung lässt einige nicht RFC5322-konforme P2 FROM-Header passieren. Das kann dazu führen, dass der E-Mail-Client (z. B. Microsoft Outlook) einen gefälschten Absender anzeigt, als wäre er legitim.
Ab dem Microsoft Exchange Server Updates 12. November 2024 können Exchange Server E-Mail-Nachrichten, die potenziell schädliche Muster im P2 FROM-Header enthalten, erkennen und kennzeichnen. Wird vom Exchange Server eine verdächtige Nachricht erkannt, wird dem Text der E-Mail-Nachricht automatisch der folgende Haftungsausschluss vorangestellt:
Der Exchange Server fügt außerdem den X-MS-Exchange-P2FromRegexMatch-Header zu jeder E-Mail-Nachricht hinzu, die von dieser Funktion erkannt wird. Administratoren können eine Exchange Transportregel (ETR) verwenden, um den Header zu erkennen und eine bestimmte Aktion auszuführen.
Microsoft gibt im Support-Beitrag ein Beispiel an. Die Erkennung von Spoofing-Mails ist bei installiertem November 2024-Sicherheitsupdate automatisch bei Exchange Server 2016/2019 aktiviert. Administratoren können die Funktion mithilfe von New-SettingOverride deaktivieren – die PowerShell-Befehle sind im Support-Beitrag ebenfalls erwähnt.
Anzeige
Was ist ein P2-FROM-Header?
Ich habe in verschienden Berichten zu dem Thema diesen Begriff gelesen und verstehe nicht, was damit ausgedrückt werden soll. Im Bereich von SMTP und Internet-E-Mail kenne ich mich aus, dort wird dieser Begriff nicht verwendt. Es gibt in dem Zusammenhang ein "Header-From" und ein "Envelope-From", aber kein "P2-From". Daher ist der Verweis auf RFC 5322 für mich auch nicht hilfreich, es kommt schließlich im ganzen RFC kein "P2" vor.
Wenn es ein Spezialbegriff auf dem Microsoft-Exchange-Universum ist, warum findet man bei Microsoft keine Erkläung dazu?
Erklärungen P1 und P2:
P1 ist der äußere und P2 ist der innere Header der email.
P1 ist in RFC 5321 und P2 iist n RFC 5322 standardisiert.
P1 wird für den Transport benutzt, analog wie ein Briefumschlag mit Adressat und Absender..
P2 ist wie das Stück Papier im Inneren des Briefumschlags, wo ebenfalls eine Adressat und ein Absender drauf stehen, welche aber von dem Adressat und dem Absender auf dem Umschlag abweichen können, etwa wenn im Auftrag eines anderen geschickt wird.
P1 ist Pflicht (sonst kein Transport).
P2 ist keine Pflicht (ohne P2 wäre die email dann wie eine Postkarte).
SPF prüft P1.
Falls Im Auftrag eines anderen gesendet wurde, dann muss der P2-Auftraggeber die SPF um die Daten des P1-Auftragnehmers erweitern, sonst Abweisung der email bei SPF-Prüfung.
Email-Programme zeigen normal nur das Innere an (P2), aber man kann auch den kompletten Header anzeigen lassen.
Im P2-Header kann man durch geschicktes Einfügen von Befehlen andere Adressen einfügen (spoofing), den SMTP resetten und dadurch emails umleiten.
Erklärungen und Grafiken dort durchlesen:
answers. microsoft. com/en-us/msoffice/forum/all/what-is-p1-and-p2-header/7f266f21-e055-44c9-96a7-93aae32fca68
www. msxfaq. de/internet/smtp_p1p2_felder.htm
blog. ahasayen. com/email-message-p1-and-p2-headers/
Ich finde, man sollte das email-Konzept komplett neu erfinden, es simpler und sicherer machen.
"Im P2-Header kann man durch geschicktes Einfügen von Befehlen andere Adressen einfügen (spoofing), den SMTP resetten und dadurch emails umleiten."
ERNSTHAFT?
1. Ein Mail-Server sollte niemals etwas mit dem sog. "P2-Header" machen, also kein Routing/Transport/etc. (höchstens eine Spoofing-Auswertung, wobei dies auch keinesfalls zuverlässig wäre), ansonsten wäre das Teil broken-by-design.
2. Wenn durch den sog. "P2-Header" der Mail-Client irgendetwas "triggern" würde (bzw. den P2-Header vor der Anzeige nicht genau untersuchen würde), dann läuft aber auch beim Mail-Client gehörig was falsch.
Eine Beschreibung der Schwachstelle ist oben Artikel verlinkt:
blog. slonser. info/posts/email-attacks/
Wenn man also in die Adresse ein Carriage-Linefeed (\r\n) einbaut, dann hat der Empfänger ein Problem, weil die Adresse dann falsch interpretiert wird und man dann SMTP-Befehle wie RSET (Reset) ausführen kann.
"This means we can insert external SMTP commands, reset the current SMTP session using the RSET command, and send arbitrary emails from the service."
"This means we have the opportunity to insert CRLF in the address. Therefore, let's try to use SMTP injection."
Deine sog. SMTP Injection bezieht sich hier aber auf "envelope from" und "envelope rcpt to", also die von MS so benannten P1-Header.
Wenn Mail-Server hier kein korrektes Parsing der Envelope addresses vornehmen, dann ist das ein Mail-Server Problem. Und selbst wenn sich in der Übertragung nach dem DATA SMTP-Cmd. auch noch so lustige UTF-8 (etc.) Zeichen im Data-Block befinden sollten (in der sich ja auch der "mail from" Header, der von MS so genannte P2-Header befindet), dann darf kein Mail-Server der Welt etwas aus dem Data-Block "ausführen". bzw. darauf hören, außer auf das Ende des Data-Blocks (\r\n.\r\n). Ansonsten hat der Coder versagt.
Hast Du Dich eigentlich schon mal mit dem SMTP Protocol beschäftigt?
> ohne P2 wäre die email dann wie eine Postkarte
Email ist eine Postkarte, wenn nicht PGP/SMIME verschlüsselt völlig unabhängig von P1 oder 2
Das ist nicht ganz richtig. Ich habe für unsere Hauptdomäne z. B. die Exchange-Konnektoren zu konfiguriert, dass seit Jahren sogar für alle anderen Mail-Server ein- wie ausgehend nur SMTP-Verbindungen zulassen, die verschlüsselt und mit einem bis zu einer Wurzelzertifizierungsstelle als gültig überprüfbaren TLS-Zertifikat ankommen. Ist das nicht der Fall, wird noch nicht einmal die Serververbindung aufgebaut. Das kann der normale gewerbliche E-Mail-Nutzer vielleicht nicht riskieren, weil ihm dann Auftragseingänge durch die Lappen gehen könnten. Aber ich kann mir meine Kunden zum Glück aussuchen.
Und sowohl der Script-Kiddy-E-Mail-Server-Nutzer wie auch ich bekommen beim Versandversuch einen NDR mit präziser Fehlermeldung (zumindest für den, der lesen kann und ein Gehirn hat), also z. B. ungültiges oder abgelaufenes oder nicht vorhandenes Zertifikat.
Solche kommen bei uns vielleicht 2-3x im Jahr vor, erst neulich sogar von einem großen IT-Systemhaus. Mit dem Chef habe ich dann gesprochen und eine Nachricht – ohne konkrekt auf ihn als Kunden hinzuweisen – an seinen Mail-Provider geschickt, dass dies sogar ein Verstoß gegen die EU-DSGVO ist. Und siehe da, auf Bitten des Chefs, also deren Kunden, tat sich nichts, ginge angeblich nicht, nur bei teureren Verträgen… Aber nach meinem Wink mit dem Zaunpfahl ging es dann plötzlich doch… Einige muss man eben zu ihrem Glück (oder Weiterbildung) zwingen.
In Verbindung mit der Tatsache, dass es heute wohl keinen Client mehr gibt, der unverschlüsselt mit seinem E-Mail-Server kommuniziert, ist durch die hiesige Einstellung sichergestellt, dass – anders als bei einer Postkarte – der gesamte Transportweg nur verschlüsselt – wenn auch nicht E2E – stattfindet. Das ist schon beruhigend, wie ich finde. Nutzt aber ansonsten keiner, weil dadurch sonst zu viele Halbwüchsige ausgesperrt werden.
Ich verweise dann stets gerne auf https://checktls.com, wo man einfach links mal seine oder andere Domänen einträgt und dann auf klickt. Danach auf . Dort muss unter dann ein grünes stehen.
Ansonsten nutzen wir gpg4win (nur für Signaturen) oder Cloud-Freigaben mit 2FA, zur Not/extrem selten auch 7z mit AES-Kennwort.
Happy Testing.
Man müsste vermutlich erst einmal klären, was mit dem Vergleich "wie eine Postkarte" eigentlich gemeint ist.
Auf eine (Urlaubs-)Postkarte wird üblicherweise keine Absenderadresse geschrieben. Da sehe ich noch am ehesten einen Bezug zum Thema "From"-Angabe, um die es in dem Artikel geht. Insofern wäre eine Urlaubskarte vielleicht mit einer Bounce-Nachricht zu vergleichen, die standardgemäß ein leeres Envelope-From aufweist. ;-)
Ansonsten kann man den "Postkarten"-Vergleich so interpretieren, dass bei einer Postkarte jeder, der sie in die Finger bekommt, den Text sofort lesen kann, ohne Spuren zu hinterlassen, im Gegensatz etwa einen aufgerissenen Umschlag bei einem Brief. Das ist bei E-Mails ohne Ende-zu-Ende-Verschlüsselung ebenso.
Eine durchgängige Transportverschlüsselung bei E-Mail ist daher ganz nett, aber vom Schutz vor unbefugtem Mitlesen her weiterhin auf dem Niveau "Postkarte". Auf jedem der beteiligten Mailserver liegt die Nachricht zumindest zeitweise unverschlüsselt vor und kann von jedem, der dort (zu Recht oder zu Unrecht) Administratorrechte hat, ohne weiteres gelesen werden. Auf dem absendenen Mailserver liegt die Mail üblicherweise sogar dauerhaft im Ordner für gesendete Nachrichten und kann dort nicht nur vom legitimen Absender gelesen werden, sondern in bösartige Hände abhanden kommen, was in der Vergangenheit eine äußerst erfolgreiche Betrugsmasche erst ermöglicht hat (Pseudo-Mail-Antworten von Emotet, Qakbot, Pikabot und Co., die bei den Empfängern glaubwürdig wirkten, weil sie auf eine tatsächlich stattgefunden habenden Mailaustausch Bezug nahmen). Auch auf dem Mailserver des Empfängers liegt die Nachricht üblicherweise auf längere Zeit unverschlüsselt vor, so dass auch dort jeder, der Zugriffsrechte auf das Postfach hat (inkl. des Administrators) die Mail jederzeit lesen kann.
Durchgängige Transportverschlüsselung mit Überprüfung der Zertifikate der jeweiligen Gegenstelle halte ich auch nicht für eine besonders zu lobende Ausnahmeerscheinung. Im Rahmen der Snowden-Affäre hat vor einigen Jahren hat das Thema der Zertifikatüberprüfung bei Mailservern in der Öffentlichkeit auch etwas Aufmerksamkeit erfahren, als mit "E-Mail made in Germany" dies als Fortschritt angepriesen wurde. Inzwischen würde ich das als "ganz normal" einstufen, weil es praktisch jeder so macht.
Die Variante, mit keinem externen Mailservern zu reden, der keine Transportverschlüsselung (mit einem von einer üblichen CA unterschriebenen, gültigen X.509-Zertifikat) anbietet, kann sich in der Tat nicht jeder leisten, weil es dafür zu viele schludrig betriebene Server auf der ganzen Welt gibt. Aber die Mailprovider, die etwas auf Datenschutz und Datensicherheit geben, bieten auf Wunsch ihren Kunden genau eine solche Konfiguration an. Das ist jetzt auch nichts so extrem Neues. Bei mailbox.org kann man das als Kunde schon seit vielen Jahren so haben, wenn man möchte.
Es bleibt aber dabei, dass man bei E-Mail eine Ende-zu-Ende-Verschlüsselung benötigt (wie in dieser Diskussion erwähnt bieten sich da S/MIME oder PGP/MIME an), wenn man dafür sorgen möchte, dass der Inhalt der Mail nicht an jedem Server mitgelesen werden kann (oder "Verteilzentrum" bzw. "Poststelle", wie man das bei der analogen Post nennen würde).
Nur eben leider wird sich das Verschlüsseln von E-Mails nicht durchsetzen, da dazu jeder Empfänger und Versender einen öffentlichen Schlüssel irgendwo veröffentlichen müsste. PGP bietet dazu ein Server-Netzwerk, wird aber eben wohl nur von 0,00001 % der E-Mail-Nutzer verwendet, und wenn, dann auch eher zur Signatur.
What is P1 and P2 header?
P1 und P2 Header ist anscheinend mal wieder die Microsoft Sprech(Betrachtungs)weise.
Korrekt wäre: "envelope from" Address / "header from" Address
Hier von einer Spoofing Schwachstelle zu sprechen ist mal wieder Microsoft-typisch und "ach, es ist Euch JETZT erst aufgefallen, dass der Mail-Verkehr SO stattfindet?".
In einem idealen Fall sollten "envelope from" und "header from" identisch sein, sind es aber oft nicht und müssen sie auch meiner Meinung nach gar nicht sein.
Der "envelope from" ist der sogenannte "return path" und sollte in einem Mail Header als "Return-Path: " auftauchen.
Was das "envelope rcpt to" betrifft, so speichert zum Beispiel der Postfix-Mail-Server dies unter "X-Original-To: " ab, bzw. im "Delivered-To: " das eigentliche Postfach.
Wenn der Exchange dies genauso machen würde, könnte man im Outlook hier leicht einen Mechanismus einbauen, der eine "bessere" Auswertung zulassen würde, als einfach stupide nur die Standard-Mail-Header aus der Mail selbst zu verwenden…
Auf der anderem Seite: wenn flächendeckend SPF (und zwar korrekt, viele setzen das nicht für alle ihre erlaubten Absende-Mail-Server), DKIM und DMARC zum Einsatz kämen, wäre es -die entsprechend scharfen Reject-Policies vorausgesetzt- wesentlich leichter, evtl. Mail-Spoofing einzudämmen.
Aber was weiß ich schon…
100 % ACK! Danke dafür, dem ist nichts hinzuzufügen.
Exchange und MS362 ist ja genau für solche Hobbyadmins gedacht, die nicht mehr wissen, wie EMail funktioniert.