SMTP smuggling aka Postmasters Weihnachtsstress
E-Mails, die E-Mails schmuggeln und so Phishing-Mails ermöglichen!? Kein Spaß für Postmaster kurz vor den Weihnachtsferien. - Wir zeigen, was Admins jetzt tun können.
Wer ist Schuld an der ganzen Aufregung? Der CCC. Naja zumindest indirekt. Timo Longin von SEC Consult hat sich verschiedene MTA-Implementierungen angesehen und Unstimmigkeiten darin gefunden. Diese stellt er in seinem Vortrag "SMTP Smuggling – Spoofing E-Mails Worldwide" auf dem 37. Chaos Communication Congress vor, der klassisch in den Tagen nach Weihnachten stattfindet. Vorab hat er am 18.12. einen Blogartikel zu "SMTP Smuggling - Spoofing E-Mails Worldwide - Introducing a novel technique for e-mail spoofing" über seine Ergebnisse veröffentlicht.
Worum geht es dabei? Unter bestimmten Umständen ist es möglich in eine E-Mail eine zweite E-Mail rein zu schmuggeln, die beim Absender als solche nicht gesehen wird, aber auf der Empfängerseite in der Zustellung von beiden E-Mails resultiert.
Da auf der Absenderseite die "geschmuggelte" Mail nicht nach den eigenen Regeln geprüft wird, aber auf der Empfängerseite eine normale E-Mail daraus erstellt wird, ist es möglich E-Mail-Absender zu spoofen. Wenn die gespoofte Absenderadresse der geschmuggelten Mail in derselben Infrastruktur beheimatet ist, ist sogar das SPF valide.
Der Kern des Problems ist dabei nicht mal das in seiner Grundfunktion 41 Jahre alte SMTP Protokoll, sondern die verschiedenen Workarounds für alle nicht RFC-konformen MTAs, Bash oder was auch immer Skripte.
Dabei geht es im Endeffekt um nichts anderes als den Zeilenumbruch und die unterschiedliche Anwendung in den Betriebssystemen. Windows verwendet CR LF (\r\n), Mac OS CR (\r), Unixoide LF (\n). Wenn in SMTP-Clients nicht explizit auf den richtigen Zeilenumbruch geachtet wird, nutzt man unter Linux also schnell nur LF und nicht CR LF wie im SMTP-RFC gefordert.
Damit Postmaster nicht ständig Ärger mit solchen Clients haben, prüfen verschiedene MTAs die benutzten Newline Character weniger strikt. Unter anderem auch Postfix (das vor ein paar Tagen stolze 25 Jahre alt geworden ist. Herzliche Glückwünsche hier auch unsererseits).
Andere MTAs halten sich strikter an die RFCs.
Wie lassen sich aber nun E-Mails schmuggeln?
Die Idee ist im Body einer E-Mail SMTP-Protokoll Kommandos so unter zu bringen, dass diese von einem MTA verarbeitet werden.
Hier eine normale SMTP-Kommunikation:
=== Trying 127.0.0.1:25...
=== Connected to 127.0.0.1.
<- 220 example.com ESMTP Postfix\r\n
-> HELO example.com\r\n
<- 250 example.com\r\n
-> MAIL FROM:<root@example.com>\r\n
<- 250 2.1.0 Ok\r\n
-> RCPT TO:<user@example.com>\r\n
<- 250 2.1.5 Ok\r\n
-> DATA\r\n
<- 354 End data with <CR><LF>.<CR><LF>\r\n
-> Date: Fri, 22 Dec 2023 09:28:54 +0100\r\n
-> To: user@example.com\r\n
-> From: root@example.com\r\n
-> Subject: test\r\n
-> Message-Id: <20231222092854.2423319@example.com>\r\n
-> \r\n
-> This is a test mailing\r\n
-> \r\n
-> \r\n
-> .\r\n
<- 250 2.0.0 Ok: queued as 5A9712003E9\r\n
-> QUIT\r\nHELO, MAIL FROM, RCPT TO und DATA sowie QUIT gehören hierbei zum SMTP-Protokoll. Alles zwischen "354 End data with <CR><LF>.<CR><LF>" und "250 2.0.0 Ok" ist der E-Mail-Inhalt mit Header und Body-Bereich.
Wichtig ist dabei zu wissen, dass während einer SMTP-Session auch mehrere Mails übertragen werden können. Anstatt die Verbindung mit QUIT zu beenden, könnte ein Client mit einem neuen MAIL FROM Kommando auch eine weitere E-Mail übertragen.
Wenn ich nun geschickt im Body-Bereich SMTP-Kommandos unterbringe, könnte ich damit eine weitere E-Mail herein schmuggeln. Dafür muss die erste Mail erst einmal beendet werden. Das passiert mit Steuerungs-Code <CR><LF>.<CR><LF> (\r\n.\r\n). Damit einzelne Punkte mit Newlines nicht zum unerwünschten Abbruch der Mail führen, werden diese vom Client kodiert (mit 2 Punkten ..).
Das heißt entweder wird der Steuerungs-Code kodiert und es gibt keine geschmuggelte Mail oder es werden 2 Mails generiert. Für den MTA macht das erst einmal keinen Unterschied und ist vom SMTP-Protokoll auch alles soweit valide.
Interessant wird es jetzt, wenn wir unterschiedliche MTA-Implementierungen haben und mit unterschiedlichen newline characters arbeiten. Das heißt, dass ein MTA ein falsches \n.\n als Steuercode für das Ende einer E-Mail erkennt, ein anderer genau das ignoriert.
Genau das hat Timo Longin analysiert und dabei einen Weg gefunden E-Mails zu schmuggeln. Wenn der MTA des Absenders (strikt nach RFC) \n.\n nicht als Steuercode akzeptiert, gehören die dann folgenden Zeilen für diesen MTA weiter zum E-Mail-Inhalt (Body).
Wird die E-Mail nun an einen MTA übertragen, der als Workaround aber auch \n.\n akzeptiert, wird an dieser Stelle die erste E-Mail terminiert und die weiteren Zeilen neu verarbeitet. Nach dem SMTP-Protokoll richtig kodiert, kann so eine weitere Mail erstellt werden. Der empfangende MTA kann keinen Unterschied feststellen.
=== Trying 127.0.0.1:25...
=== Connected to 127.0.0.1.
<- 220 example.com ESMTP Postfix\r\n
-> HELO example.com\r\n
<- 250 example.com\r\n
-> MAIL FROM:<root@example.com>\r\n
<- 250 2.1.0 Ok\r\n
-> RCPT TO:<root@external.invalid>\r\n
<- 250 2.1.5 Ok\r\n
-> DATA\r\n
<- 354 End data with <CR><LF>.<CR><LF>\r\n
-> Date: Fri, 22 Dec 2023 09:28:54 +0100\r\n
-> To: user@example.com\r\n
-> From: root@example.com\r\n
-> Subject: test\r\n
-> Message-Id: <20231222092854.2423319@example.com>\r\n
-> \r\n
-> This is a test mailing\r\n
--->\n
--->.\n
# Terminierung Mail 1
<- 250 2.0.0 Ok: queued as 96F8C20051F\r\n
---> MAIL FROM:<ceo@example.com>\r\n
<--- 250 2.1.0 Ok\r\n
---> RCPT TO:<ceo@external.invalid>\r\n
<--- 250 2.1.5 Ok\r\n
---> DATA\r\n
<--- 354 End data with <CR><LF>.<CR><LF>\r\n
---> Date: Fri, 22 Dec 2023 09:28:54 +0100\r\n
---> To: ceo@external.invalid\r\n
---> From: ceo@example.com\r\n
---> Subject: Our business plan\r\n
---> Message-Id: <20231222092854.2423319@example.com>\r\n
---> \r\n
---> This is a test mailing\r\n
-> \r\n
-> \r\n
-> .\r\n
# Terminierung Mail 2
<- 250 2.0.0 Ok: queued as 5A9712003E9\r\n
-> QUIT\r\nSpoofing als sicherheitskritische Gefahr
Ist so eine geschmuggelte Mail und die daraus generierte 2. Mail auf der Empfangsseite nun sicherheitskritisch? Erstmal nicht! Der MTA auf der Empfängerseite verarbeitet einfach beide Mails nach seinen ganz normalen Policies. Das heißt auch für die geschmuggelte Mail werden alle Prüfungen durchlaufen, auf Spam und Viren gecheckt usw.
Dabei gibt es sogar einige Dinge, die in der geschmuggelten E-Mail nicht umgesetzt werden können. Zum Beispiel ist es normalerweise nicht möglich, die geschmuggelte E-Mail mit einer DKIM-Signatur zu versehen, da der benötigte private DKIM-Schlüssel meist nur auf dem Server des Absenders vorliegt. Außerdem ist bei einer aufgeteilten Mail (also 1. Mail und abgeschnittene geschmuggelte 2. Mail) auch die DKIM-Signatur der 1. Mail defekt, da der Body-Hash nicht mehr passt.
Anders sieht es leider beim SPF aus. Wenn die Absender-Domain der geschmuggelten Mail den Ausgangsserver im SPF inkludiert hat, ist auch der SPF der geschmuggelten Mail valide. Und damit, in diesem Fall jetzt leider, auch DMARC valide. Denn DMARC setzt entweder valides DKIM oder valides SPF (mit aligned SMTP- / Header-From) voraus.
Die eigentliche Gefahr beim SMTP smuggling ist die Umgehung der Sender-Policies auf der sendenden Seite. Hier wird nämlich nur die 1. Mail insgesamt geprüft. Der geschmuggelte Teil wird als Inhalt des Body interpretiert. Daher wird natürlich auch nicht geprüft, ob beispielsweise root@example.com auch mit der Adresse ceo@example.com senden darf. Auch wenn hier die gleiche Domain verwendet wird, gilt das natürlich auch für verschiedene Domains.
Das heißt es ist mit dieser Methode möglich im Namen anderer über die korrekte Infrastruktur E-Mails zu versenden - also Spoofing.
In der Analyse von Timo Longin war das zum Beispiel bei IONOS (1&1, web.de, gmx.de) möglich. Da der SPF bei IONOS sehr weit angelegt war, konnten potenziell mindestens tausende Domains gespooft werden.
Technisch etwas schwieriger, aber trotzdem möglich war es bei outlook.com, also Microsoft 365, mit seinen Millionen Domains.
Sowohl IONOS als auch Microsoft haben ihre Software bereits angepasst und verhindern die Ausnutzung. Details dazu findet Ihr im Blogartikel bei SEC Consult.
Cisco Secure Email (Cloud) Gateway waren je nach Setting auch betroffen. Da keine ausführlichen Tests weiterer MTAs vorgenommen wurden, ist unklar ob Cisco ESA Appliances oder andere MTAs auch potenziell betroffen sein könnten.
Postfix und das SMTP smuggling
Postfix gehört zu der Kategorie MTAs, die falsche Newlines akzeptieren. Damit erstellt Postfix eben auch eine E-Mail aus dem geschmuggelten Teil des Bodies einer manipulierten Mail. (Ausgehende Mails müssen hier gar nicht betrachtet werden, denn Postfix sieht und prüft die 1. Mail und die 2. geschmuggelte Mail beide nach allen Policies und Regeln.)
Im Gegensatz zu vielen anderen Workarounds lässt sich dieser Umstand im Postfix bisher noch nicht abschalten. Wietse Venema arbeitet bereits an einem Fix. Dieser wird aber erst im neuen Jahr erscheinen.
Es gibt aber bereits jetzt Mechanismen im Postfix, die SMTP smuggling verhindern. Aus Prinzip handelt es sich nämlich um Pipelining, also dem Senden mehrerer SMTP-Kommandos ohne vorher die Antwort der Gegenstelle abzuwarten. Während die SMTP-Commands der 1. Mail vom MTA generiert werden und dieser damit auch die Antworten sauber verarbeitet, werden die geschmuggelten SMTP-Commands alle auf einmal gesendet.
Im Postfix ist Pipelining, wieder aus Kompatibilitätsgründen, standardmäßig aktiv. Aber auch für Pipelining gibt es Regeln. Zum Beispiel, dass zumindest nach dem DATA-Kommando auf eine Serverantwort zu warten ist. Das passiert bei den geschmuggelten Kommandos natürlich nicht.
Wie sieht die konkrete Config für Postfix nun aus?
Postfix kennt in den letzten Versionen (3.8.1, 3.7.6, 3.6.10 und 3.5.20) die SMTPD Option smtpd_forbid_unauth_pipelining. Diese ist im Default "no" und muss aktiviert werden.
Alternativ gibt es für ältere Versionen die Restriction-Regel reject_unauth_pipelining. Aber Achtung: Postfix kann Pipelining erst nach dem DATA Kommando auswerten - also muss das in die smtpd_data_restrictions.
/etc/postfix/main.cf
smtpd_forbid_unauth_pipelining = yes
# oder
smtpd_data_restrictions = reject_unauth_pipeliningUnd wer möchte, kann die SMTP Erweiterung Pipelining auch gar nicht mehr anbieten:
smtpd_discard_ehlo_keywords = silent-discard,pipeliningDas Abschalten von Pipelining kann sich natürlich auch auf zusammengeschusterte SMTP-Clients auswirken. Bei eigenen Clients muss man hier dann einen Workaround finden. Desktop-Clients oder Webmailer sollten davon nicht betroffen sein. Und bei der Server to Server Kommunikation kann man valides SMTP auch durchaus verlangen.
Fazit
Also zusammengefasst ist das Problem am SMTP smuggling, dass eine ungünstige Verkettung verschiedener SMTP-Implementierungen zu Spoofing-Mails führen können, die nach SPF valide sind. Die beiden Anbieter IONOS und Microsoft haben ihre Systeme bereits abgesichert und es gibt für Postfix einfache Einstellungen, die diese Art von manipulierten Mails ablehnen.
Kritisch ist höchstens der Zeitpunkt. Gerade wenn die Postmaster in ihren wohlverdienten Weihnachtsurlaub gehen, haben die Spammer ein neues Spielzeug bekommen, bei dem gar nicht so klar ist, wo es überall funktioniert.
Wir wünschen allen Admins und Postmastern dennoch eine ruhige Weihnachtszeit und einen guten Rutsch!
Weitere Beiträge zum Thema
Enterprise Mail Security with Open Source?
Enterprise Grade Mailcluster mit Open-Source?
Kommentare
1 Antwort zu SMTP smuggling aka Postmasters Weihnachtsstress
Kleine Korrektur, im Artikel steht: „Cisco Secure Email (Cloud) Gateway waren je nach Setting auch betroffen. Da keine ausführlichen Tests weiterer MTAs vorgenommen wurden, ist unklar ob Cisco ESA Appliances oder andere MTAs auch potenziell betroffen sein könnten.„
Cisco ESA heißt seit einigen Jahren Secure Email Gateway, das ist das selbe Produkt. Dort muss man ähnlich wie bei Postfix auch aktiv werden und eine Option setzen um die Interpretation falscher Zeilenumbrüche zu deaktivieren. Dies passiert nicht automatisch, auch nicht in Ciscos Cloud-Angebot. Es gibt bisher auch keine Warnung durch Cisco an seine Kunden.
Solange dies nicht geschieht sind Ciscos Produkte weiterhin anfällig und waren es nicht nur.