SMTP Smuggling und Exchange

Die Firma Cybersicherheitsunternehmen SEC Consult hat am 18. Dez 2023 ein Verfahren beschrieben, wie bestimmte Mailserver per Mail missbraucht werden können, wenn Sie die RFC5321/RFC5322 nicht konsequent auslegen. SEC Consult hat im Juni 2023 die Lücken festgestellt, an die Hersteller gemeldet und GMX, Microsoft und andere haben ihre Systeme schon entsprechend abgesichert. POSTFIX, SENDMAIL und EXIM müssen auch angepasst werden.

Vortrag von SEC Consult auf der  37C3
https://media.ccc.de/v/37c3-11782-smtp_smuggling_spoofing_e-mails_worldwide

Der Vortrag beschreibt das Smuggling mit <lf>.<cr><lf>  und nicht <lf>.<lf>
Insofern sind einige Tests und Bilder hier noch nicht aktuell.

Risikoeinschätzung

Ehe Sie die ganze Seite lesen müssen: Ihr Mailserver oder das darunterliegende Betriebssystem ist nicht direkt in Gefahr aber wenn ihr Mailserver für diesen Missbrauch empfänglich ist, dann sendet ihr Server mit einer beliebigen Absenderadresse an einen beliebigen Empfänger und der böse Absender kann von ihrem Vertrauenslevel profitieren. Das Risiko ist höher, wenn der Absender sich an ihrem Server authentifizieren kann oder der Absender eine interne Adresse als Absender missbraucht.

Das BSI hat am 22.12 2023 eine Meldung mit dem Schweregrade "Grau" dazu veröffentlicht
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2023/2023-292569-1032.html

Die Lücke

SMTP Smuggling ist aber ein gutes Beispiel, dass die Validierung von anderen Systemen oder Benutzern eingelieferten Daten nicht locker sondern "streng" erfolgen sollte. Die auf dieser Seite beschriebe Lücke beruht darauf, dass ein Mailserver sich nicht streng an die RFC hält, in der das Ende einer Mailübertragung durch eine Zeile gekennzeichnet wird, die nur einen "Punkt" hat.


RFC: https://datatracker.ietf.org/doc/html/rfc5321#section-4.2.5


https://www.rfc-editor.org/rfc/rfc5322

In der DOS/Windows-Welt wurde eine neue Zeile schon immer durch ein "<cr><lf>" eingeleitet. Diese Zeichen kommen nun mal noch als der alten Nadeldrucker und Terminal-Technik, und bedeuten:

<cr>  Carriage Return,  d.h. fahren den Druckkopf oder Cursor an den Anfang
<lf>  LineFeed, d.h. schiebe das Papier eine Zeile weiter bzw. den Cursor in die nächste Zeile

Aber Linux und Windows habe hier eine andere Einstellung:

Unter Unix wird ein sogenannter Zeilenvorschub (engl.: line feed, ASCII-Zeichen LF) als Markierung eines Zeilenendes verwendet.
Macintosh verwendet übrigens das Zeichen für Wagenrücklauf (engl.: carriage return, ASCII-Zeichen CR).
Und Windows benutzt eine Kombination dieser beiden Zeichen, nämlich CR-LF.
Quelle: Unterschiede / Gemeinsamkeiten zwischen Windows und Linux https://www.selflinux.org/selflinux/html/win_vs_linux03.html

SMTP-Missbrauch

Diese kleinen Unterschiede, die ein Anwender eigentlich nie sieht, können bei der Kommunikation zwischen Servern aber einen Unterschied machen. Wie SMTP genau funktioniert, habe ich auf SMTP-Telnet beschrieben, so dass ich hier nur noch eine Kurzfassung einer Verbindung anzeige, bei der über eine Verbindung zwei separate Mails gesendet werden. Nach der Herstellung der Verbindung (Grün) sehen Sie die Meldungen des empfangenden Servers (Gelb) und die Übertragungen des Senders (blau). Das Ende einer Zeile wir sauber per "<CR><LF>" signalisiert.

Wenn der Server aber für SMTP Smugging anfällig ist, dann wird er auch folgende Verbindung annehmen aber erst einmal den Body als eine Mail betrachten.

Die meisten Mailserver nehmen Mails ja erst einmal "an" und speichern die Mail in einer Warteschlange zur weiteren Verarbeitung. Fast alle Systeme nutzen Spamfilter und prüfen z.B. die Adresse im "MAIL FROM"-Header mittels SPF, SenderID und andere Systeme. Die im Body quasi versteckte zweite Mail bleibt so aber erst einmal unbemerkt und wird auch nicht gesondert geprüft.

Next Hop

Interessant wird es nun, wenn die Mail von dem ersten System an das nächste System weiter gibt. Dafür fallen direkt zwei Szenarien ein:

Szenario Beschreibung

Ausgehend: Client mit SMTP Auth

Der einliefernde Client ist ein Benutzer, der sich anmeldet und über den Weg eine Mail authentifiziert an seinen Smarthost zur weiteren Verteilung einliefert. Das ist bei quasi allen Anwendern der Fall, die ihre Mails per POP3/IMAP4 anrufen und per SMTP z.B. auf Port 587 mit Anmeldung weiterreichen. Wenn hier der Provider dieses "Smuggling" nicht erkennt und die erhaltene Mail dann aufteilt und ungeprüft weitersendet, dann werden zwei Mails darauf und die Absender-Adresse kann gefälscht werden.

Eingehend: vorgelagerte Spamfilter

Das zweite Szenario sind Firmen, die einen vorgelagerten Spamfilter haben. Die Mail aus dem Internet kommt bei dem Spamfilter an und nur die erste Mails wird anhand des "MAIL FROM" und "RCPT TO" geprüft. Die zweite für den Spamfilter versteckte Mail könnte als Absender z.B. eine interne Mailadresse des CEO nutzen, um mehr Erfolg bei Phishing zu haben.

Es könnte natürlich noch weitere Umgebungen geben. Kritisch ist es immer, wenn ein System das "<LF>" als legitime Trennung von zwei Mails ansieht aber nur die ersten "MAIL FROM", "RCPT TO"-Einträge für eine Validierung heranziehen.

Werkzeugmacher

SEC-Consult hat auf seiner Webseite schon einige Gegenstellen durchprobiert und sich zuerst auf die "Free-Postfachprovider" wie GMX, Outlook.com, Gmail geprüft, indem Sie sich dort ein Postfach besorgt und per SMTP-AUTH solche Mails eingeliefert haben. Die Frage bleibt natürlich, wie Sie dies selbst testen können. Outlook, Thunderbird o.ä. sind natürlich keine gute Clients hierfür aber PowerShell kann und dabei helfen. Zuerst habe ich mir Gedanken über den Body gemacht und schon hier zeigt PowerShell sehr gut das Verhalten von Windows. PowerShell unterstützt die beiden Sonderzeichen mit:

`r = <CR> Carriage Return
`n = <LF> NewLine

Ein "<CR>" alleine ohne ein <LF> überschreibt die Zeile1.

Ein <LF> alleine startet nicht nur eine neue Zeile sondern auch von "Vorne". Bei einem Nadeldrucker wäre einfach nur das Papier eine Zeile weiter gerutscht und der Druckkopf hätte an der gleichen Stelle fortgesetzt. Aber mit dem Handwerkzeug können wir nun einen "Body" zusammenbauen, der für Tests genutzt werden kann. Zuerst habe ich mich aber noch mal vergewissert, dass ich Strings zur besseren Lesbarkeit zusammensetzen kann, ohne dass die Powershell ein verstecktes "<CR><LF>" addiert:

Nachdem das geklärt ist, kann ich folgenden Body zusammenbauen.

$body = "Dies ist Zeile 1 des Body der ersten Mail`r`n"
$body += "Dies ist Zeile 2 des Body der ersten Mail"
$body += "`n.`n"
$body += "MAIL FROM: <badguy@msxfaq.net>`r`n"
$body += "RCTP TO: <smtp-smugging@msxfaq.com>`r`n"
$body += "DATA`r`n"
$body += "From: <badguy@msxfaq.net>`r`n"
$body += "To: <smtp-smugging@msxfaq.com>`r`n"
$body += "Subject: Message2`r`n"
$body += "Subject: Message2`r`n"
$body += "Body Message 2 Line1"

Nun bleibt noch die Frage, wie ich diese Mail sende und was mein Mailversender damit anstellte. Denn der "Punkt" im Body kann ja auch in einer regulären Mail vorkommen.

"Punkt-Mail"

Wenn der "Punkt" so eine besondere Funktion hat, dann wollte ich doch mal sehen, wie die Übertragung aussieht, wenn ich im Body wirklich einmal einen alleinstehenden "Punkt" auf einer Zeile habe. Das ist per PowerShell schnell zusammengesetzt:

Diesen Body habe ich per "Send-MailMessage" an einen Mailserver gesendet und sie sehen gut, dass mittels "Content-Transfer-Encoding: quoted-printable" der Punkt und die Zeilenumbrüche für die normale Erkennung unsichtbar gemacht werden.

Damit ist aber klar, dass ich Send-MailMessage leider nicht nutzen kann, denn der Body wird vor der Übertragung verändert und ich muss selbst eine TCP-Verbindung verwalten. Auch andere "Mailsender" wie BLAT etc. nehmen dem Anwender das Encoding ab und sind daher nicht tauglich.

SMTP per TCP

Für einen eigenen Test habe ich mir daher wieder meine TCP-Vorarbeit von PowerShell und TCP zunutze gemacht und per PowerShell mit der System.Net.Sockets.TcpClient-Klasse direkt eine sehr einfache SMTP-Kommunikation ohne TLS und ohne Authentifizierung genutzt. Für einen internen Exchange Server sollte dies ausreichend sein.

Parallel habe ich die Verbindung per WireShark mitgeschnitten, um genau zu sehen, was hier über die Leitung gegangen ist. Wir sehen genau den Body der Mails und auch den "Punkt", der nur durch "Linefeed" eingeschlossen ist:


Das Bild zeigt noch den alten Versuch mit <lf>.<lf> und nicht <lf>.<cr><lf>

Wenn Sie das Ende der Mail anschauen. dann vermissen Sie vielleicht de Punkt. Ich habe auch erst einmal gesucht aber weiter oben dann gesehen, dass die Mail von meinem Client bzw. dem TCP-Stack in zwei "Chunks" aufgeteilt wurde und im zweiten Paket Punkt mit dem CRLF-Zeichen (0d 0a) zu sehen ist.

Das ist bei Wireshark etwas unglücklich gelöst. Interessant war nun natürlich, was Exchange daraus macht. Hier habe ich gleich zwei Beispiele:

Ergebnis Beschreibung

Exchange Online und Outlook

Eine Mail habe ich über den lokalen Exchange Server und eine Hybrid-Bereitstellung an mein Exchange Online Postfach gesendet. Ich konnte die Mail problemlos in Outlook öffnen aber habe nur genau eine Mail gesehen. Diese hat aber den Body aus der Mail1 und auch den versuchten SMTP-Smuggling-Teil als Body gesehen. Hier hat sich also weder Exchange OnPremises noch Exchange Online übertümplen lassen.

Exchange 2019 OnPremises und OWA

Den gleichen Versuch habe ich kurz darauf auch mit einem Exchange 2019 Postfach durchgeführt. Die Mail wurde auch hier nur genau einmal zugestellt und per OWA konnte ich gut sehen, dass auch hier der "SMTP-Smuggling-Anteil mit im Body der ersten einzigen Mail enthalten war.

Exchange 2019 scheint also gegen diese Variante robust zu sein und lässt sich nicht durch einen Punkt zwischen zwei Linefeeds ("<lf>.<lf>") aus dem Tritt bringen.

Der Test erfolgte am 23. Dez 2023 mit Exchange 2019 mit November 2023 Security Updates auf Windows 2019. Ich habe keine Tests mit Exchange 2016/2013/2010 mehr angestellt.

Sowohl Exchange Online als auch Exchange 2019 scheinen damit nicht mehr für SMTP-Smuggling mit einem "<lf>.<lf>" anfällig zu sein

Das ist natürlich keine Garantie, dass es nicht noch andere Möglichkeiten gibt, einen Mailserver zu überlisten.

Selbst testen

Das folgende Skript können Sie herunterladen und per PowerShell aufrufen, um ihren eigenen Server zu testen.

Achtung
Sie müssen sowohl den Mailserver als auch die Parameter Mail1from, Mail2from, Mail1to, Mail2to mit übergeben oder im Skript durch ihre passenden Werte setzen.
Testen Sie damit bitte nur ihre eigenen Mailserver. Der Missbrauch anderer Server, die für SMTP-Smuggling anfällig sind, kann strafbar sein.

Das Skript ist sehr einfach gestrickt und hat keinerlei Fehlerüberwachung, Fehlerbehandlung und ist definitiv kein vollwertiger SMTP-Client, der mit den unterschiedlichen Rückmeldungen ihres Servers umgehen kann. Das Skript sendet einfach die Befehle entsprechen in der chronologischen Reihenfolge ab und prüft nicht, ob der Server mit einem Fehlercode die weitere Kommunikation nicht mehr akzeptiert.

Test-SMTPSmuggling.ps1
Nach dem Download bitte die Erweiterung ".txt" entfernen.

Sie können die gleichen Aktionen auch mittels SMTP-Telnet durchführen. Durch das Skript ist es einfach etwas einfacher.

Das Skript unterstützt keine SMTP-AUTH-Verbindungen. Sie könnten Sie natürlich noch nachrüsten. Siehe SMTP authentifiziert senden.

Weiter Links