SMTP Smuggling-Fallout oder: Wer muss jetzt eigentlich was patchen?

Dieser Artikel ist auch auf Englisch verfügbar.

tl;dr 1: Alle, die einen verwundbaren Server betreiben, müssen die verfügbaren Patches einspielen.
tl;dr 2: Patchen alleine wird in vielen Fällen nicht reichen, die Konfiguration muss ggf. auch angepasst werden.

Die Veröffentlichung der als “SMTP Smuggling” betitelten Sicherheitslücke in vielen Mailservern (Timo Longin, SEC Consult) am 18.12.2023 und die darauf folgende Präsentation auf dem 37. Chaos Communication Congress (37C3, verfügbar unter media.ccc.de) in Hamburg verursachte bei einigen Kunden zwischen Weihnachtsbraten und Sektkorken noch einmal kurze Aufregung, denn die Implementierung des für den weltweiten E-Mail-Versand verwendeten Protokolls SMTP auf diversen Mailservern weist eine Schwachstelle auf, die das Versenden von E-Mails unter fremdem Namen erlaubt.

E-Mail-Spoofing, also das Fälschen der Absenderadresse, ist nicht gerade eine neue Erfindung und wird unter anderem durch Maßnahmen wie SPF oder DMARC erschwert, bei denen der empfangende Server überprüfen kann, ob der sendende Server wirklich berechtigt ist, eine E-Mail für die jeweilige Domain des Absenders zu verwenden. Doch diese Maßnahmen erschweren nur das Versenden von E-Mails mittels fremden Servern. Was aber, wenn der versendende Server missbräuchlich verwendet wird?

“SMTP-Smuggling” nutzt Schwachstellen auf der Empfängerseite aus, um genau das zu tun. Das SMTP-Protokoll erlaubt prinzipiell, mehrere E-Mails in einem einzigen Kommando zu verschicken. Hierbei werden die einzelnen E-Mails mittels einer Sequenz von Zeichen, dem sogenannten END-OF-DATA Markers getrennt, die dem verarbeitenden Server anzeigen, wo eine E-Mail zu Ende ist und die nächste beginnt. Nun ist die entsprechende Zeichenfolge in den zugehörigen RFCs (Request for Comments, sozusagen die Definitionen der Standards für die gängigen Protokolle) 5321 und 5322 definiert und alle Mailserver richten sich auch grundlegend nach diesen Angaben, um miteinander zu kommunizieren. Jedoch erlauben einige Mailserver-Implementierungen Abweichungen von diesem Standard, um auch mit Servern kompatibel zu sein, die sich nicht zu 100% daran halten – und damit klar den RFCs widersprechen. Genau hier ist die Schwachstelle zu suchen.

Die Zeichenfolge für das Ende einer E-Mail ist laut RFC <CR><LF>.<CR><LF> (<CR> steht für “carriage return”, also den von der Schreibmaschine bekannten Wagenrücklauf zum Anfang der Zeile und wird auch als \r dargestellt, <LF> bedeutet “line feed”, also das Springen in die nächste Zeile und wird auch als \n dargestellt). Kurz gesagt also einen Punkt, der in einer einzelnen Zeile steht. Nun stellen aber Windows- und Unix-basierte Systeme den Zeilenumbruch unterschiedlich dar. Während Windows <CR><LF> nutzt, verwenden beispielsweise Linux und MacOS nur <LF>. Andere Systeme verwendeten früher stattdessen <CR>, wobei unklar ist, ob diese Schreibweise heute noch Anwendung findet. Sofern Mailserver sie aus Kompatibilitätsgründen akzeptieren, tut das auch nichts zur Sache. Je nachdem, an welche Schreibweise sich der Mail-Client hält, kann der END-OF-DATA Marker also mal <CR><LF>.<CR><LF>, <CR>.<CR> oder auch <LF>.<LF> sein. Es gibt noch weitere Schreibweisen, die von einigen Mailservern akzeptiert werden, doch die genannten sind die gängigsten. Viele Mailserver akzeptieren also zwecks Kompatibilität mehrere mögliche Marker-Schreibweisen.

Verwendet man nun einen Mail-Server, der END-OF-DATA Marker anders interpretiert als der empfangene Server, kann man dies ausnutzen, um der Empfängerseite statt einer mehrere E-Mails unterzujubeln. Da der sendende Server an dieser Stelle nicht bemerkt, dass er mehr als eine E-Mail versendet (faktisch tut er dies aus seiner Sicht auch nicht, dazu gleich mehr), greifen an dieser Stelle auch keine Maßnahmen, um das Versenden unter falschem Absender zu verhindern.

Sicherheitsbewusste Administratoren konfigurieren ihre Mailserver derart, dass vor dem Absenden einer E-Mail geprüft wird, ob der Nutzer, der diese E-Mail versenden möchte, die Berechtigung hat, mit der angegebenen Absenderadresse zu versenden. Dies geschieht beispielsweise bei Postfix über den Konfigurationsparameter reject_authenticated_sender_login_mismatch, der in der unter $smtpd_sender_login_maps definierten Datenbank abgleicht, welcher User mit welchen Mailadressen versenden darf. Eine E-Mail beinhaltet im SMTP-Header immer mindestens zwei Angaben zu Sender (MAIL FROM) und Empfänger (RCPT TO), wobei die Empfänger-Adresse das Ziel der E-Mail definiert. Die Sender-Adresse wird in solchen Fällen vom Mailserver vor dem Versenden gegen eine Liste der E-Mail-Adressen abgeglichen, die dem angemeldeten Nutzer zugeordnet sind. Wird eine E-Mail-Adresse als Absender eingetragen, für die man keine Sendeberechtigung besitzt, verweigert der Server dann den Versand.

Fügt man nun mittels des (dem sendenden Server unbekannten) END-OF-DATA Markers direkt eine weitere E-Mail an die bestehende E-Mail an, bemerkt der sendende Mailserver nicht, dass eine weitere E-Mail im Datensegment existiert. Für diese “geschmuggelte” E-Mail wird also absenderseitig keine Prüfung auf die Berechtigung zum Versand mit der dort angegebenen Absenderadresse durchgeführt und die E-Mail wird versandt. Die einzige Einschränkung ist: Die Absenderadresse muss von einer der Domains stammen, für die der Server sendeberechtigt ist. Ganz konkret geht es hier um die via SPF oder DMARC via DNS festgelegte Sendeberechtigung und Signierung, die gerade bei Clouddiensten oft über einige wenige Gateways für alle verwalteten Domains abgebildet werden.

Als Beispiel verwenden wir hier einen Server, der <CR><LF>.<CR><LF> bzw. \r\n.\r\n als END-OF-DATA Marker verwendet und unzulässigerweise andere Marker zulässt. Ein Beispiel für eine Valide E-Mail von user@sender an user@receiver sähe folgendermaßen aus:

mail FROM: user@sender\r\n
rcpt TO: user@receiver\r\n
data\r\n
From: user@sender\r\n
TO: user@receiver\r\n
Subject: Erste E-Mail\r\n
\r\n
Dies ist die erste E-Mail\r\n
\r\n.\r\n

Eine präparierte E-Mail sähe wie folgt aus (hier wird der dem sendenden Server unbekannte Marker <LF>.<LF> bzw. \n.\n verwendet):

mail FROM: user@sender\r\n
rcpt TO: user@sender\r\n
data\r\n
From: user@sender\r\n
TO: user@receiver\r\n
Subject: Erste E-Mail\r\n
\r\n
Dies ist die erste E-Mail\r\n
\n.\n
mail FROM: admin@sender\r\n
rcpt TO: user@receiver\r\n
data\r\n
From: admin@sender\r\n
TO: user@receiver\r\n
Subject: Geschmuggelte E-Mail\r\n
\r\n
Dies ist die geschmuggelte E-Mail\r\n
\r\n.\r\n

Der empfangende Server empfängt nun die präparierte E-Mail und verarbeitet diese. Handelt es sich um einen verwundbaren Server, interpretiert er den dem versendenden Server unbekannten END-OF-DATA Marker <LF>.</LF> bzw. \n.\n als Trenn-Marker und stellt damit zwei E-Mails zu: Eine von user@sender und eine von admin@sender. Der empfangene Server hat an dieser Stelle keine Möglichkeit zu erkennen, dass es sich nicht wirklich um eine E-Mail von admin@sender handelt. Zudem haben auch Experten, die verdächtige E-Mails anhand deren Header auf Manipulationen oder fremde Herkunft überprüfen sollen, hier einen deutlich schwereren Stand: Die im Mailheader dokumentierten Checks gegen SPF und DMARC sind valide, zudem kann ein Angreifer in der “geschmuggelten” Mail beliebige SMTP-Header platzieren, um diese valide erscheinen zu lassen.

Inwiefern das nun gefährlich ist, wird klar, wenn man einen der großen Mailanbieter als Beispiel einsetzt: Versendet ein Angreifer eine präparierte E-Mail von einem Account bei Google (z.B. Testuser234@gmail.com) und schmuggelt eine weitere E-Mail von support@gmail.com hinein, kann er den Empfänger dazu verleiten, einen Link zu einer von ihm hochgeladenen Malware anzuklicken. Der Nutzer muss an dieser Stelle davon ausgehen, dass der echte Google-Support ihn anschreibt, eine Manipulation ist nicht erkennbar. Wenn – wie bei großen Cloud-Anbietern – auch noch die SPF– und DMARC-Records für hunderttausende Domains identisch gesetzt sind, konnte man beispielsweise auch von einem privaten Mailaccount, der einen dort gehosteten Mailserver nutzt, eine Mail für jede beliebige andere dort gehostete Domain versenden. Die großen Mailanbieter filtern zwischenzeitlich derartige Zeichenketten aus und verbieten den Versand, um das Ausnutzen dieser Sicherheitslücke zu verhindern, jedoch kann das keinesfalls eine generelle Entwarnung bedeuten.

Das Problem ist zum einen, dass nicht alle Anbieter das Problem als solches anerkennen (Cisco vertrat beispielsweise den Standpunkt, dass es sich um ein erwünschtes Verhalten handle und nicht gepatcht werden muss, ist zwischenzeitlich jedoch zurückgerudert). Zum anderen kann man als Empfänger niemals wissen, ob der sendende Server die Patches bereits implementiert hat. Der eigene Mailprovider wird vermutlich seine Kunden darüber zeitnah informieren. Das Patchen der Mailserver verhindert, dass END-OF-DATA Marker nicht-RFC-konform verwendet werden können, um E-Mails wie oben beschrieben an weitere verwundbare Server zu schmuggeln. Damit ist aber das Patchen selbst betriebener Server unbedingt notwendig, denn den Empfang (bzw. die fehlerhafte Verarbeitung) von manipulierten E-Mails von ungepatchten Servern kann man nur an dieser Stelle verhindern.

Die Anbieter der verschiedenen Mailserver stellen inzwischen Patches für ihre Produkte bereit. Es kann jedoch einige Zeit dauern, bis diese für alle Betriebssysteme und Versionen verfügbar sind, manche ältere Versionen werden vermutlich auch keinen Patch erhalten. Oft (zumindest im Falle Postfix) wird auch das einfache Patchen nicht ausreichen: Open Source-Projekte wie Postfix führen neue Konfigurationsparameter ein, die nur in den neuesten Serverversionen automatisch aktiv gesetzt werden. Ältere Versionen, wie sie oft noch in LTS-Varianten von Linux-Servern verwendet werden, benötigen ein wenig Handarbeit. Daher muss nach einem Update auch zwingend geprüft werden, ob die neue Konfiguration greift. Wenn nicht, muss diese zusätzlich angepasst werden und der Dienst neu gestartet werden. Für jeden Mailserver sollte einzeln geprüft werden, ob ein Patch zur Verfügung steht und welche Teile der Schwachstelle damit konkret behoben werden.

Zum Abschluss noch zwei Anmerkungen, da wir über unklare Formulierungen gestolpert sind: