SMTP Smuggling – eine neue Bedrohung von einem alten Protokoll

Wie sicher schon viele mitbekommen haben, wurde eine neue Schwachstelle im Simple Mail Transfer Protocol (SMTP) letzten Dezember von dem Cyber-Sicherheitsunternehmen SEC Consult publik gemacht (SMTP Smuggling – Spoofing E-Mails Worldwide – SEC Consult (sec-consult.com). Dank dieser können Angreifer Mails «schmuggeln» und somit die Authentisierungsmechanismen (SPF, DKIM und DMARC) umgehen. Somit kann sich jemand als eine komplett andere Person ausgeben und der Empfänger hat den Eindruck, dass dies eine legitime Mail ist.

Kurz gesagt, ist es durch das SMTP Smuggling dem Angreifer möglich, gefälschte Mails zu versenden, welche dann von einem betroffenen SMTP-Server in (mehrere) einzelne Mails aufgespaltet werden. Dies schafft der Angreifer dadurch, indem die Art und Weise ausnutzt wird, wie bestimmte Server das Ende einer SMTP-Konversation bzw. vom DATA-Befehl interpretieren.

Laut RFC5321 (RFC 5321 – Simple Mail Transfer Protocol (ietf.org)) ist der DATA-Befehl immer mit <CRLF>.<CRLF> zu beenden und <CR> oder <LF> dürfen nicht einzeln verwendet werden (datatracker.ietf.org/doc/html/rfc5321#section-2.3.8).

(CR = Carriage return (Wagenrücklauf, Zeilenanfang) | LF = Line feed (Zeilenvorschub)

(S =  Server / Empfänger | C = Client / Sender)

Beispiel:

S: 220 smtp.recipientserver.com<CRLF>
C: HELO bender.ch<CRLF>
S: 250 smtp.recipientserver.com<CRLF>
C: MAIL FROM :<test@bender.ch><CRLF>
S: 250 2.1.0 OK <CRLF>
C: RCPT TO :<recipient@recipientserver.com><CRLF>
S: 250 2.1.5 OK <CRLF>
C: DATA <CRLF>
S: 354<CRLF>
C: Test Message<CRLF>
C: <CRLF>.<CRLF>
S: 250 2.0.0 OK<CRLF>

Jedoch gibt es viele Systeme (darunter auch die Cisco E-Mail Security Appliance), welche SMTP nach Postel’s Law (siehe auch RFC 761) behandeln – ganz nach dem Motto: «Be conservative in what you do, be liberal in what you accept from others». Sie akzeptieren als End of Mail Data Sequence nicht nur ein <CRLF>.<CRLF>, sondern auch andere Kombinationen wie <CR>.<CR>, <LF>.<LF> oder <CR><LF>.<LF>, um den DATA-Befehl zu beenden. Dies ist allerdings seit RFC 2821 (April 2001) nicht mehr erlaubt (datatracker.ietf.org/doc/html/rfc2821#section-2.3.7).

Wichtig ist: Es gibt sowohl das ausgehende als auch das eingehende SMTP Smuggling. Das ausgehende Smuggling betrifft die Sender Server, und wie diese sich verhalten und beim eingehenden befasst man sich mit dem Empfängerteil.

Ich habe meine Domäne bender.ch bei dem Mailhoster Mailhoster «CH» registriert und versende meine Mails über diesen. Dieser Mailhoster wird auch von anderen verwendet, wie auch von Robyn mit ihrer Domäne robyn.ch. Nun möchte ich an bestimmte Empfänger Mails mit der robyn.ch-Domäne senden, ohne dass Robyn etwas davon mitkriegt und die Empfänger denken, die Mail sei wirklich von Robyn versendet worden.

Durch ein <CR><LF>.<LF> im DATA-Befehl kann ich nun ohne Probleme ein weiteres Mail anfügen und somit im Namen von «robyn.ch» ein Mail an den Zielserver zu übergeben. Wichtig dabei: Beide Domains verwenden denselben Mailserver des Hosters und dieser ist für beide Domains im SPF Record eingetragen. Anbei ein kurzes Beispiel (in Grün), wie ein Mail geschmuggelt werden könnte:

(S =  Server / Empfänger | C= Client / Sender)

S: 220 smtp.recipientserver.com<CRLF>
C: HELO bender.ch<CRLF>
S: 250 smtp.recipientserver.com<CRLF>
C: MAIL FROM :<test@bender.ch><CRLF>
S: 250 2.1.0 OK <CRLF>
C: RCPT TO :<recipient@recipientserver.com><CRLF>
S: 250 2.1.5 OK <CRLF>
C: DATA <CRLF>
S: 354<CRLF>
C: From : test@bender.ch<CRLF>
C: To : recipient@recipientserver.com<CRLF>
C : Subject : Test Message<CRLF>
C: Test Message<CRLF>
C: <LF>.<CR><LF>          <- Hier wird das Empfängersystem überlistet!
C: MAIL FROM:admin@robyn.ch <CRLF>
C: RCPT TO :<recipient2@recipientserver.com<CRLF>
C: DATA<CRLF>
C: From : admin@roby.ch<CRLF>
C: To : recipient2@recipientserver.com<CRLF>
C: Subject : Send Information
C: Hi there<CRLF>
C: Please send me you password. <CRLF>
C: Regards, the admin<CRLF>
C: <CRLF>.<CRLF>

Wie oben ersichtlich ist, wird zuerst ganz normal eine Mail an den Empfängerserver gesendet, jedoch wird der DATA-Befehl nicht korrekt beendet und eine weitere Mail wird eingeschleust. Das Empfängersystem interpretiert aber die Zeile C: <LF>.<CR><LF> trotzdem als Ende der Mail, beginnt dann sogleich mit der nächsten Zeile und versteht dies als neue Mail vom gleichen Senderserver.

Da Robyn und ich die gleichen SPF-Einträge haben (v=spf1 include: spf.mailhoster.ch -all), wird der SPF Check auch nicht fehlschlagen, wenn die Mail in zwei Mails aufgesplittet wird.

Somit erreicht meine gefälschten Mails von robyn.ch die Empfänger ohne Probleme und wenn ich meinen Job gut gemacht habe, merken diese rein gar nichts.

Die grossen Mailhoster wie Microsoft, Google, GMX etc. haben schon reagiert und blockieren nun das ausgehende SMTP Smuggling. Somit können User von diesen Services keine Mails mehr von anderen Domänen schmuggeln.

Doch wie sieht es bei dem Empfängersystemen aus?

Auch hier haben die grössten Anbieter bei dies bei sich gefixt. Weitere Anbieter haben schon Updates oder Workarounds veröffentlicht. Auch Postfix konnte schon ein Update und Workaround veröffentlichen.

Postfix:

SMTP Smuggling (postfix.org)

Exchange:

Bei Exchange On-Premises kann man anscheinend barelinefeedrejectioneneabled anpassen auf true und dann sollten solche Nachrichten abgelehnt werden.

learn.microsoft.com/en-us/powershell/module/exchange/set-receiveconnector?view=exchange-ps#-barelinefeedrejectionenabled

Im Idealfall hat man aber vor dem Exchage Server ein Mailgateway, welches solche Mails dort schon abweisen kann.

SEPPmail:

SEPPmail Version 13.0.10 beinhaltet die neue Postfix-Version, welche das Problem behebt.

SEPPmail.cloud:

Benutzt ebenfalls eine neue Postfix-Version

xorlab:

Die xorlab Security Platform verwendet in Version 6.23.10 auch die neue Postfix-Version.

Cisco Secure E-Mail:

Bei Cisco wird das jetzige Verhalten nicht als Schwachstelle anerkannt, sondern als Feature. Man kann das Verhalten, bzw. wie die E-Mail Security Appliance die alleinstehenden <CR> und <LF> behandelt, konfigurieren und anpassen, wie man dies wünscht. Es gibt bei den Listener-Einstellungen drei Optionen:

Clean: Ergänzt automatisch alleinstehenden <CR> oder <LF> mit <CRLF>.

Reject: Blockiert eine Mail welche einzelne <CR> oder <LF> beinhaltet.

Allow: Lässt die Mail durch und ersetzt die alleistehenden <CR> oder <LF> nicht (wird in späteren Versionen nicht mehr als Option zur Verfügung stehen).

Als diese Schwachstelle bekannt wurde, haben wir dies intern angeschaut und auch getestet. Bei unseren Tests wurde aber schnell klar, dass die Allow-Option keinen Unterschied bringt zu Clean und die Mails trotzdem aufgesplittet werden.

Stand 14.01.2023 testen wir noch die Option Reject auf Praxistauglichkeit, da diese die korrekte Option und Einstellung wäre, da diese RFC-konform wäre und Mails, welche alleinstehende <CR> oder <LF> beinhalten, blockiert. Bisher ist uns erst ein Absender untergekommen, welcher tatsächlich falsch formatierte Mails verschickt.

Wir empfehlen, in der E-Mail Secrutiy Appliance entweder die Mail Flow Policies so anzupassen, dass nur eine Nachricht pro Verbindung zugelassen wird:

Dadurch werden externe MTAs, welche viele Mails zustellen wollen (z.B. ein Newsletter), für jedes einzelne Mail eine neue SMTP-Verbindung aufbauen müssen. Dies führt zu einer etwas höheren Systemauslastung, wir rechnen aber mit keinen spürbaren Auswirkungen.

Oder alternativ:

Auf dem eingehenden Listener die Option Reject wählen. Dadurch werden falsch formatierte Mails sofort abgewiesen und der Sender wird eine Bounce-Meldung (Non Delivery Report) erhalten. Das Cisco Secure E-Mail Gateway wird die so abgewiesene Meldung im Mail-Log folgendermassen ausweisen: «Receiving Failed: Illegally formed message body (bare CR or LF characters).»

www.avantec.ch/themen/e-mail-security

www.avantec.ch/loesungen/cisco-security

www.tec-bite.ch/drei-neue-features-von-xorlab-activeguard

www.tec-bite.ch/der-wahrscheinlich-einfachste-weg-an-administrative-privilegien-zu-kommen

www.tec-bite.ch/die-darknet-trends-2024