[English]Seit Mitte Dezember 2023 ist das neue, alte, Thema "SMTP Smuggling" in den Medien. Es handelt sich um eine seit gut 20 Jahren bekannte Technik, um Inhalte in eine E-Mail zu schmuggeln, die dort "unter falscher Flagge segeln". Leser haben in diversen Kommentaren bereits auf das Thema hingewiesen (danke dafür, ich hatte es in den Medien selbst mitbekommen). Ich gebe nachfolgenden einen kurzen Überblick, um was es geht und wie es sich auswirken kann.
Anzeige
Was ist SMTP Smuggling?
Beim Versenden von E-Mails kommt das Simple Mail Transfer Protocol (SMTP) zum Einsatz. Dieses Protokoll wurde 1982 unter dem RFC 821 als Standard verabschiedet und ist inzwischen breit im Einsatz.
SMTP Smuggling, Quelle: Sec Consulting
Sicherheitsforscher von Sec Consulting sind bei einer Untersuchung des Simple Mail Transfer Protocols im Juni 2023 auf Schwachstellen gestoßen, die einen Missbrauch ermöglichen. Durch Einfügen von Trennzeichen (CRLF) ist es möglich, in einer Mail verschiedene Inhalte einzufügen, die scheinbar von einem legitimen Absender stammen. Dadurch lassen sich Verifizierungstechniken für Absender (SPF, DKIM und DMARC) aushebeln.
Die Sicherheitsforscher von Sec Consult haben ihre Erkenntnisse zum 18. Dezember 2023 im Beitrag SMTP Smuggling – Spoofing E-Mails Worldwide veröffentlicht und auf dem 37C-Kongress des Chaos Computer Club (CCC) in einem Vortrag präsentiert. Die Aufzeichnung des Vortrags ist auf YouTube abrufbar.
Anzeige
Altbekanntes Problem, neuer Ansatz
Problem bei dem ganzen Ansatz ist, dass die Implementierung von E-Mail-Diensten in SMTP-Anforderungen eingefügte Trennzeichen (CRLF, Nullen etc.) auf unterschiedliche Art und Weise interpretieren. Dieses Problem ist eigentlich seit 20 Jahren bekannt wie man in diesem OWASP-Artikel und die dort zu findende Referenz auf CWE-93 nachlesen kann. Die CVE-2002-1771 aus dem Jahr 2002 weist darauf hin, das eine als CRLF-Injektion beschriebene Methode ein Spam-Proxy (E-Mail-Header hinzufügen) unter Verwendung von E-Mail-Adresse oder Name ermöglicht.
Die Sicherheitsforscher haben im Juni 2023 dann neue Varianten dieser CRLF-Injektionstechniken entdeckt und diese unter dem Begriff SMTP Smuggeling zusammengefasst und beschrieben. Die Möglichkeit, eine Mail unter dem Absender admin@microsoft.com an Fortune-500-Unternehmen zu schicken und trotzdem die SPF-Prüfung zu bestehen, ist nur eines der sich daraus ergebenden Probleme.
Mail-Anbieter kontaktiert, gemischte Reaktionen
Nach internen Recherchen haben die Sicherheitsforscher sich mit mit den betroffenen Anbietern (Microsoft, Cisco, GMX/Ionos) in Verbindung gesetzt. GMX hat wohl binnen zwei Wochen reagiert, Microsoft hat die Probleme nach zwei Monaten gefixt.
Von Cisco erhielten die Sicherheitsforscher die Rückmeldung hatten, dass es sich bei der von uns identifizierten Schwachstelle lediglich um eine Funktion der Software und nicht um einen Fehler bzw. eine Schwachstelle handelt. Deshalb haben sich die Sicherheitsforscher am 17. August an CERT/CC gewandet, und um Hilfe für weitere Gespräche mit Cisco zu gebeten.
Die Hoffnung war zudem, andere potenziell betroffene Anbieter (wie sendmail) über die Kommunikationsplattform VINCE einzubeziehen. Mein Kenntnisstand ist, dass das Cisco Secure Email Gateway sich bisher nur durch manuelle Eingriffe gegen SMTP Smuggeling härten lässt.
Ärger bei der Offenlegung
Im Rahmen der verantwortungsvollen Offenlegung (Responsible Disclosure) durch obigen Blog-Beitrag und den Vortrag auf der 37C3 kam es dann zu Verstimmungen bei den Entwicklern von Projekten wie Postfix, die wohl überrascht wurden. Die Entdecker schieben dies in einem Nachtrag zu ihrer Veröffentlichung, auf Missverständnisse und unklarer Kommunikation. Aufgrund des Feedbacks von kontaktierten E-Mail-Anbietern und der Tatsache, dass mehrere andere Anbieter über die VINCE-Plattform von CERT/CC in diese Diskussion einbezogen wurden, ohne Einspruch zu erheben, habe man die breiteren Auswirkungen der Offenlegung falsch eingeschätzt. Aufgrund verschiedener Annahme haben die Sicherheitsforscher Ende November bei CERT/CC nachgefragt, ob die Details veröffentlicht werden könnten und erhielten die Bestätigung, dass dies zu tun.
Aussage: Da der Beitrag auf der 37C3-Konferenz Ende Dezember 2023 akzeptiert wurde (Info ging am am 3. Dezember 2023 zu) und die Sicherheitsforscher der Meinung waren, dass Cisco-Benutzer vor der anfälligen Standardkonfiguration gewarnt werden sollten, fiel der Beschluss, die Informationen vor dieser Konferenz zu veröffentlichen. Am 5. Dezember wurden CERT-Bund (BSI Deutschland) und CERT.at per verschlüsselter E-Mail über das geplante Veröffentlichungsdatum des Blog-Beitrags zum 18. Dezember 2023 informiert. Der Mail fügten die Sicherheitsforscher die vollständigen Details des Blog-Beitrags sowie einen weiteren Aufruf zur Warnung der Cisco-Benutzer bei. Es gab wohl keine Einwände zur Veröffentlichung.
Scheint wohl bei den Postfix-Entwicklern etwas Ärger verursacht zu haben, wie man einer auf X (siehe obiger Screenshot) sehen kann. Die Postfix-Entwickler Wietse Venema und Viktor Dukhovni haben aber umgehend auf die Bedrohung durch SMTP-Schmuggel reagiert und kurzfristige Workarounds veröffentlicht, wie die Schwachstelle behoben werden kann. Artikel zum Thema finden sich auch bei The Hacker News oder auf Deutsch bei heise.
Risiko-Einschätzung für Exchange
Für die Leserschaft dieses Blog, die oft mit Microsoft Exchange unterwegs ist, noch eine kurze Ergänzung des Sachverhalts. Ich bin auf Twitter bereits Ende Dezember 2023 auf nachfolgenden Tweet von Frank Carius gestoßen.
Frank hat das Ganze in seinem Beitrag SMTP Smuggling und Exchange aufbereitet und gibt eine Einschätzung: 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.
Vom BSI gibt es diese Einschätzung vom 22. Dezember 2023. Die Kernaussagen zur Veröffentlichung des Cybersicherheitsunternehmens SEC Consult zur neuen Angriffstechnik mittels "Simple Mail Transfer Protocol (SMTP) Smuggling".
Beim SMTP Smuggling machen sich die Angreifenden zunutze, dass verschiedene SMTP-Implementierungen die Kennzeichnung des Endes einer E-Mail-Nachricht unterschiedlich interpretieren. Sie können so E-Mails versenden, die durch ein betroffenes E-Mail-System in mehrere E-Mails aufgespalten werden. Auf diesem Weg entstehen neue E-Mails, die gefälschte Absender nutzen (Spoofing), Authentifizierungsmechanismen, wie SPF, DKIM und DMARC umgehen oder Warnungen, wie z.B. eine Spam-Markierung in der Betreffzeile, nicht mehr tragen.
Durch die Ausnutzung von Unterschieden in der Interpretation einer Sequenz zwischen ausgehenden und eingehenden SMTP-Servern können Angreifende gefälschte E-Mails im Namen vertrauenswürdiger Domänen versenden. Dies ermöglicht wiederum verschiedenste Social Engineering- bzw. Phishing-Angriffe.
Das gesamte BSI-Dokument lässt sich als PDF-Datei herunterladen.
Anzeige
Posteo.de war und ist von SMTP Smuggling nicht betroffen
Weil?
Laut dieser offiziellen Cisco-Quelle:
https://bst.cisco.com/quickview/bug/CSCwh10142
weisen die Cisco-Produkte KEINE Schwachstelle auf. Selbst bei der Default-Einstellung "Clean", die laut Sec-Consult für SMTP-Smuggling anfällig sein soll, würden keine "security checks bypassed.".
Damit widerspricht die Cisco-Aussage der Aussage der Sec-Consult-Sicherheitsforscher.
Gruß Max.
weiß jemand ob Hetzner betroffen ist/war?
Naja gerade Postfix und Exim zu vergessen… die beiden größten OpenSource Projekte überhaupt in dem Bereich, das Bounty kassieren, und dann kurz vor Weihnachten die Projekte sinnlos kurzfristig unter Druck setzen.. war schon unterste Schublade.
Nicht das SMTP Protokoll ist fehlerhaft sondern manche Implementierungen erlauben mehr als sie sollten.
Wo liest Du im obigem Text die Information, dass ich "SMTP als fehlerhaft" eingestuft habe? Es steht explizit drin, dass das Problem in den Implementierungen liegt. Oder habe ich was übersehen?
ich denke er meint
"im E-Mail-Protokoll mit Missbrauchspotential"
"sind bei einer Untersuchung des Simple Mail Transfer Protocols"
Könnte sein, ist aber eine Interpretation, die ich so in meinem Text nicht sehe und auch nicht beabsichtigt habe. Sonst hätte ich explizit von Design-Schwächen bei SMTP geschrieben.
Ist das nicht irgendwie auch eine Design-Schwäche? Letzen Endes liegt der Ursprung des Problems doch wohl im unterschiedlichen Zeilentrenner der DOS/Windows- (CRLF) und der Unix-Welt (LF). Für Sendmail aus der Unix-Welt wurde eine Ausnahme zugelassen (LF) bzw. LF.LF statt CRLF.CRLF für das End-Of-Data.
Wäre eine andere Zeichensequenz, die die unterschiedlichen Zeilentrenner nicht explizit mit einbezieht, nicht besser gewesen als diese missverständliche Kombination? Oder sind die beteiligten Programme alle nicht wirklich RFC-konform?
genau, wenn non-rfc compliant mails vom Mail server akzeptiert und dann entsprechend falsch/od. gefährlich interpretiert werden. Hier wird also vom Client gegen den RFC Standard verstoßen und manche Server akzeptieren das, was dann zu der Lücke führt.
Konkret Server die gegen RFC5321-4.1.1.4 und RFC5322-2.3 verstoßen sind für die Lücke SMTP smuggling angreifbar.
Ich habe mir mal den 4.1.1.4 angesehen. Das mit dem "MUST NOT" ist schon eindeutig. Wie die Beteiligten auf die Idee kommen konnten, für sendmail die LF.LF-Ausnahme zu implementieren und dabei gegen den RFC zu verstoßen, ist mir ehrlich gesagt ein Rätsel.
Allerdings ist mir auch schleierhaft, wieso ein CRLF.CRLF oder als genereller Zeilentrenner das CRLF festgelegt wurde, wenn doch das LF bereits als solcher existierte.
"Allerdings ist mir auch schleierhaft, wieso ein CRLF.CRLF oder als genereller Zeilentrenner das CRLF festgelegt wurde, wenn doch das LF bereits als solcher existierte."
CRLF.CRLF definiert das Ende des "Data"-Bereichs, also das der eigentlichen Email, das was im Umschlag liegt.
Das CRLF.CRLF gewählt, weil CRLF.CRLF in einem normalen Unix Text Dokument nicht vor kam.
Wer macht schon einen einzelnen harten Absatz der nur einen einzelnen Punkt enthält?
Es musste irgendwie "simple", also mit Tastatureingaben, das Ende des "Data" Bereichs definiert werden. In druckbaren Zeichen und es durfte nicht aufwändig sein.
Wie hättest Du das gelöst?
Heute kann man die Länge des Data mit einem Befehl vorgeben.
Der Empfänger muss diesen aber nicht auswerten…
Das mit dem CRLF anstelle von LF kam von Microsoft. Sie wollten nicht kompatibel sein. Darum würde auch der Backslash als Verzeichnis Trenner eingefügt. Man hat sich damit einige Nachteile eingefangen, aber man war "anders".
Warum hat man über nur LF genommen?
Weil es Platz sparte…
Tur mir Leid wenn ich mich hier ungeau ausgedrückt habe: habe den Text natürlich vollständig gelesen, finde aber die Überschrift irreführend, da die meiner Meinung nach schon eher auf das Protokoll und nicht die Implementierung abzielt.
Ein "Problem im Email Protokoll" hätte ich jetzt so nie verstanden, dass damit die Implementierung gemeint sein könnte.
Es sind 2 Effekte:
Das was da ausgenutzt wurde ist ein Feature.
Man wollte damals vermeiden, das für jede einzelne Email eine neue TCP Verbindung ausgehandelt werden muss, die Rechenleistung und Speicher belegt. (Auch eine geschlossene TCP Verbindung belegt noch einige Zeit Speicher. Damals waren 8MByte Speicher viel.(EMACS = eight megabyte and constantly swapping))
Bei der Implementierung der neuen anti spam features wurde dieses, kaum noch genutzte Feature, bei manchen SMTP Servern übersehen.
2. SMTP sollte "simple" sein. Das heißt, man sollte es einfach per Telnet manuell anwenden können.
Man hat sich daher für eine "inband" Signalisierung entschieden.
Das Ende des Textkörpers einer Email wurde durch die Zeichenfolge CRLF.CRLF definiert. Also einen "harten Absatz" mit einem einzelnen Punkt "." . Damals war LF als Zeilenende in den Unix Welt ja üblich.
Es war die Aufgabe des E-Mail-Clients, ein CRLF, der im Text vorkam zu erkennen und zu escapen.
Manche heutige Clients könnte man austricksen und so ein crlf.crlf erzeugen, mit dem die State machine des SMTP Servers wieder in den Befehls Modus gesetzt wurde, aber nicht dessen Anti Spam und Autorisierung.
Das "Problem" besteht m.E. seit 40 Jahren.
Das man das so aufgebauscht hat ist nicht schön, nett gesagt.
Das man email Clients austricksen kann, ist etwas, was Spammer nicht brauchen. Und wie hier ganz richtig berichtet, ist das ein uraltes Feature, dass den Spammern sicher bekannt war.
Wäre interessant zu hören, warum sie das nicht genutzt haben.
Vermutlich weil es auch ohne ausreichend funktionierte.
Spätestens seit Ende 2008 ist das Problem im RFC Standard gefixt. Mail Server, die sich daran nicht halten können dann zb anfällig für smtp smuggling sein.
Postfix hat ja einen temporären Fix veröffentlicht, den habe ich eingespielt. Wie sieht das mit sendmail aus? Finde da auf die Schnelle nichts… Weiß da jemand mehr?
Snapshot 8.18.0.2 existiert.
Wenn ich danach suche finde ich lediglich diesen Thread:
https://groups.google.com/g/comp.mail.sendmail/c/zwJW9907Zgo
So richtige Infos finde ich leider nicht…
"Die Möglichkeit, eine Mail unter dem Absender admin@microsoft.com an Fortune-500-Unternehmen zu schicken und trotzdem die SPF-Prüfung zu bestehen, ist nur eines der sich daraus ergebenden Probleme."
Das funktioniert nur, wenn der Mail-Server einen SPF für die Domain "Microsoft.com" hätte.
Man konnte also nur andere Usernamen durchschmuggeln, nicht irgendwelche Adressen.
Wenn der Server einen SPF für die Domain hätte, würde er natürlich auch relayen.
Und andersherum würde er eine eingeschmuggelte fremde Domain mit einem "550 relaying denied" zurückweisen/schicken und gar nicht erst annehmen, weil er die Domain nicht auflösen kann. Insofern funktioniert das Beispiel mit "admin@microsoft.con" trotz des Schmuggel-Fehlers heute nicht mehr. Man könnte nur als peter@gmx.de eine Email mit dem Mail from heinz@gmx.de durchschmuggel.
Das steht auch so in der gelinkten Beschreibung zum Postfix Patch.
Früher, als das Protokoll erfunden wurde hätte es funktioniert, weil damals Third-party-relaying generell erlaubt und gern gesehen war, weil es zum guten, freundlichen Ton gehörte.
Heute unvorstellbar. Und darum funktioniert es heute nicht mehr.
Gibt es irgendwelche Posting sperren nach 00:30?
Oder wohin sind meine letzten beiden Kommentare gelangt?
Ist der Spam-Filter kaputt?
Waren zu viele Fipptehler drin?
Oder gibt's irgendwelche Probleme mit dem Server/CDN/Cache?
Dieser Kommentar ist für mich sichtbar.
Seltsam.
Das andere waren "Antworten" auf andere Kommentare.
gibt es da ein Problem, wenn es zu viele Antworten gibt, die sich auf einen Kommentar beziehen?
Dann war früher aber schon der Link unten rechts "Antworten" unsichtbar.
Ich sehe Postings von Dir von 0:11 und 0:33. Möglicherweise ist die Nachtschicht des Moderatorenteams von Borncity am Wochenende personell etwas unterbesetzt 🤣
Was mich interessieren würde:
Wurde dieses Feature eigentlich von Spammern genutzt?
Hat da wer Zahlen dazu?
CRLF ist wesentlich älter als Microsoft. Es stammt aus der Zeit, als Computer noch Zeilendrucker bzw. Fernschreiber als primäres Ausgabegerät hatten. Ein LF hat die Walze nur eine Zeile nach unten gedreht, erst das CR hat den Schlitten wieder an den Start der Zeile zurück bewegt. Daß ein LF implizit auch einen CR beinhaltet kam erst mit den Bildschirmsichtgeräten auf.
Entweder die Leute, die diesen Vortrag beim CCC gehalten haben, sind unter 30 Jahre alt, wohnen unter einem Stein oder ist richtiges "Fachpersonal". Letzteres würde mich bei der CCC "Entwicklung" der letzten Jahre nicht wundern.