Windows-Angriffe entgegen der Vertrauensstellung

Windows Domänen lassen sich durch Vertrauensstellungen zusammenbringen. Wird der Zugriff nur in eine Richtung benötigt kann man das Vertrauen auch nur einseitig aussprechen – aber sind damit Angriffe in die andere Richtung ausgeschlossen? Leider nicht, denn es gibt Wege um das Vertrauen entgegen der „Direction of Access“ auszunutzen. 

In dem Artikel starten wir erst mit ein paar Grundlagen, um dann den konkreten Angriff vorzustellen. Zum Schluss geben wir noch Tipps für Gegenmaßnahmen und Detektionsmöglichkeiten. 

Vertrauensstellung, was ist das? 

Eine der Kernaufgaben des Active Directory (AD) ist es dafür zu sorgen, dass Nutzer sich bei verschiedenen Diensten und Systemen im eigenen Netz anmelden können. Dafür vertrauen alle Domänenmitglieder dem eigenen Domain Controller (DC), dass dieser die Authentizität der Nutzer gut prüft. 

Aber das Vertrauen kann auch über die Grenzen einer Domäne oder eines Forests hinausgehen1. Dazu wird in beiden Domänen eine Vertrauensstellung (Trust) eingerichtet. Im einfachsten Fall ist sie beidseitig, dann können Nutzer aus beiden Domänen Ressourcen in der jeweils anderen Domäne nutzen. Aber man kann auch nur eine einseitige Vertrauensstellung (One-Way Trust) einrichten, dann können Nutzer der einen Domäne Ressourcen der anderen Domäne nutzen aber nicht umgekehrt. Hier kommt man leicht mit den Richtungen und Begriffen durcheinander, daher findet sich in jeder guten AD-Anleitung ein Bild wie dieses: 

Für unser Beispiel würde dies also so aussehen: 

Ein Angreifer, der in der vertrauten Domäne (hier PARTNER.local) ein Konto oder gar die ganze Domäne übernommen hat, kann natürlich über die Vertrauensbeziehung auch Ressourcen in der anderen Domäne nutzen (entlang der “direction of access”). Bei der beidseitigen Vertrauensstellung gilt das logischerweise in beide Richtungen, aber auch bei der einseitigen Vertrauensstellung gibt es einen Grenzfall wie ein Angreifer, der bereits den Domain Controller übernommen hat, sich entgegen der “direction of access” weiterbewegen kann: 

Kerberos über Grenzen hinweg, die Theorie 

Für die verteilte Anmeldung nutzt Active Directory das Kerberos-Protokoll, das ursprünglich aus der akademischen Welt kommt und ganz im Sinne der akademischen Zusammenarbeit auch bereits alles für die hochschulübergreifende Zusammenarbeit mitbringt. Das Konzept hinter der Vertrauensstellung heißt bei Kerberos Cross-Realm-Authentifizierung.  

Innerhalb eines Realms (oder Domäne in AD-Terminologie) meldet sich der Nutzer initial beim Authentisierungsserver (AS) an und erhält ein Sitzungsticket (Ticket Granting Ticket, TGT). Mit diesem Ticket kann der Nutzer dann beim Ticket-Granting-Server (TGS) Service-Tickets beantragen und sich dann mit diesen bei den Systemen und Services ausweisen, die er nutzen möchte. 

Für die Cross-Realm-Authentifizierung wird dann einfach der fremde TGS wie ein Dienstserver im eigenen Realm betrachtet. Der Nutzer fragt also seinen Heimat-TGS nach einem Ticket für den Fremd-TGS. Dieses Ticket funktioniert dann analog zu einem TGT im anderen Realm. Der Nutzer beantragt mit diesem dann ein Service-Ticket beim Fremd-TGS für den eigentlichen Service, den er nutzen möchte. In beiden Schritten werden die gleichen Befehle ausgetauscht. 

In der Praxis sind der TGS und der AS keine getrennten Server, sondern zwei Funktionen des Key Distribution Centers (KDC), die beide über den UDP-Port 88 erreicht werden. In der Windows-Welt ist das ein Service auf dem Domain Controller.  

Um den Angriff gleich verstehen zu können, müssen wir noch einen Schritt tiefer gehen. Die Tickets, die bei Kerberos immer wieder ausgetauscht werden, sind Datenstrukturen, die mit einem symmetrischen Schlüssel verschlüsselt sind. Diese Schlüssel werden für Nutzer, Services und auch die Zwischenschritte am TGS in Principals gespeichert. Die Schlüssel für die Sitzungstickets (TGT) sind beispielsweise im Principal “krbtgt” gespeichert. 

Für den ersten Schritt, die initiale Anmeldung am AS, basiert der Schlüssel auf dem Nutzerpasswort. Für die anderen Fälle sind auch andere Wege möglich, aber in Windows wird für die Fälle, in denen kein Nutzer involviert ist, einfach ein zufälliges Passwort generiert und daraus der Schlüssel abgeleitet. 

Innerhalb einer Domäne bzw. eines Realms ist das auch einfach, da wir hier ja über eine zentral verwaltete Principal- bzw. Benutzer-Datenbank reden. Wenn wir jetzt aber die Grenzen überschreiten wollen, muss es in beiden Datenbanken einen gleichartigen Eintrag mit dem gleichen Schlüssel (also dem gleichen Passwort) geben. Auf der einen Seite der Grenze, um das Ticket verschlüsseln zu können, und auf der anderen Seite, um es wieder entschlüsseln zu können.  

Die Umsetzung im AD 

Jetzt wollen wir uns anschauen, was bei einer Vertrauensstellung in einem Windows Active Directory (AD) passiert. 

Das Trusted Domain Object (TDO) 

Um sich zu merken, mit welchen anderen Domänen oder Forests eine Vertrauensstellung existiert, wird pro Vertrauensstellung im “System”-Container der dazugehörigen Domänen (bzw. den Root-Domänen bei Forest-Trusts) jeweils ein Objekt angelegt – ein sogenanntes Trusted Domain Object (TDO). Auch bei einseitigen Vertrauensstellungen wird an beiden Enden ein TDO angelegt (einmal als eingehende, einmal als ausgehende Vertrauensstellung).  

In den Attributen des Objekts werden alle Einstellungen für die Vertrauensstellung gespeichert. In dem Objekt wird zudem ein Passwort für das TDO gespeichert. Und zwar zum einen wie man es sonst von Benutzern und Computern kennt als Hash bzw. abgeleiteter Schlüssel und in diesem Fall zusätzlich auch im Klartext. Das Passwort wird automatisch alle 30 Tage geändert und – um Störungen beim Passwortwechsel vorzubeugen – wird jeweils das aktuelle sowie das vorherige Kennwort im TDO gespeichert. Das Passwort, und das ist wichtig, ist für beide Objekte gleich. 

Das Objekt kann man in der MMC unter “Active Directory-Benutzer und -Computer” sehen, wenn man zuvor unter “Ansicht” die “Erweiterten Features” aktiviert hat. Dort findet es sich dann unter dem vollen Namen der jeweils anderen Domäne. 

Der versteckte User 

Das es auf beiden Seiten einen gleichartigen Eintrag mit dem gleichen Schlüssel geben muss, hatten wir schon bei der Kerberos-Theorie gesehen. In der Windows-Welt sind die beiden TDO aber nicht die einzigen Repräsentanten der Vertrauensstellung. 

Schaut man sich die Nutzerliste auf der Seite der vertraueten Domäne (bei uns PARTNER.local) z. B. im ADSI-Editor etwas genauer an, findet sich dort ein User dessen Namen an die vertrauenden Domäne erinnert – in unserem Fall finden wir einen Benutzer HISOCORP$

ADSI-Editor auf dem PARTNER-DC.

In vielen anderen Ansichten wie der MMC wird der Nutzer ausgeblendet. Praktischerweise hat dieser versteckte Benutzer das gleiche Passwort, das auch in beiden TDO-Objekten im Klartext gespeichert wird. 

Der Angriff entgegen der Vertrauensrichtung 

Nach so viel Theorie und Grundlagen wollen wir jetzt endlich schauen, wie wir das Vertrauen gegen den Strom ausnutzen können. Noch einmal zur Erinnerung: Wir wollen gegen die erlaubte “Direction of Access” arbeiten. 

Der Trick ist jetzt, dass der versteckte Nutzer in der vertrauten Domäne ein fast normaler Nutzer ist, und wir sein Passwort kennen. 

Dann besteht der Angriff aus diesen Schritten: 

  1. Die vertrauende Domäne kompromittieren (in unserem Beispiel HISOCORP.local) 
  2. Auf dem kompromittierten DC das Passwort aus dem Trusted Domain Object (TDO) auslesen
  3. Mit dem bekannten Nutzernamen und dem ausgelesenen Passwort bei der vertrauenden Domäne (in unserem Beispiel PARTNER.local) anmelden. Also ein TGT beziehen.
  4. Mit dem TGT können jetzt Dienst-Tickets bezogen werden und ggf. Dienste genutzt werden. 

Auf Schritt 1 gehen wir nicht näher ein. Für die folgenden Schritte nehmen wir an, es ist bereits gelungen die Domäne zu kompromittieren und Zugriff auf einen Domain Controller (DC) zu erlangen. Das ist keine kleine Annahme und damit haben wir bereits vollen Zugriff auf alle Ressourcen auf dieser Seite der Vertrauensstellung. 

Auf dem DC können wir jetzt für Schritt 2 das bekannte Tool Mimikatz nutzen. Für das Auslesen des TDO gibt es einen eigenen Befehl: lsadump::trust /patch 

Im TDO ist das gemeinsame Passwort im Klartext gespeichert – in der Ausgabe oben jedes Zeichen als eine Hexadezimalzahl nach dem Stichwort „CLEAR“ – sowie verschiedene Hashwerte vom Passwort.  

Den NT-Hash (rc4_hmac_nt) können wir direkt für Schritt 3 nutzen. Die beiden anderen Hashes/Schlüssel wurden mit einem anderen Salt erzeugt und entsprechen daher nicht den Hashes, die bei der vertrauten Domain im versteckten Nutzer gespeichert sind. Aber wir kennen jetzt ja das Klartextpasswort und die Berechnungsformel für die Nutzer-Schlüssel, können also diese beiden Werte auch selbst berechnen. 

Wir nehmen in Schritt 3 den einfachsten Weg und melden uns direkt mit dem erbeuteten NT-Hash an. Dafür bietet sich beispielsweise die impacket-Suite an. Damit können wir direkt ein TGT beziehen: 

Das TGT können wir in Schritt 4 dann zum Beispiel für einen Zugriff auf eine Dateifreigabe per SMB nutzen: 

Im Beispiel wird auf die SYSVOL-Freigabe des fremden DC zugegriffen. Das geht, weil diese Freigabe grundsätzlich von allen Nutzern (Gruppe „Domänenbenutzer“) gelesen werden kann.

Da der Nutzer in der normalen Administration nicht sichtbar ist, ist er weder Mitglied in anderen Gruppen noch wurde der User selbst für Dienste oder Zugriffe explizit berechtigt. In einem realen Netz finden sich aber auch häufig weitere Freigaben und Dienste, die alle gemeinsam nutzen und die für die allgemeine Gruppe der Domänenbenutzer freigegeben sind. 

Bei der Bewertung von Sicherheitslücken wird immer unterschieden, ob sie auch ohne Login oder nur nach erfolgreicher Authentifizierung möglich sind. Und genau diesen Sprung zum authentifizierten Angreifer konnten wir jetzt machen, unabhängig davon wie wenig Rechte dem versteckten Nutzer eingeräumt wurden.  

Ein Beispiel sind Kerberoasting-Angriffe, die darauf abzielen, Service-Konten zu übernehmen, die nicht mit einem zufällig automatisch generierten Passwort, sondern mit einem menschlich erdachten Passwort gesichert sind. Einzige Voraussetzung für diesen Angriff ist der Zugriff auf ein funktionierendes Nutzerkonto in der Domäne. Dieser Nutzer muss gar keine Zugriffsrechte für den zu knackenden Dienst haben, daher funktioniert der Angriff auch mit dem versteckten Nutzer: 

Im Anschluss haben wir Zugriff auf ein Nutzerkonto mit mehr Zugriffsrechten, meist sogar einigen administrativen Rechten und können uns so immer weiter in der Partner-Domäne ausbreiten. 

Mögliche Detektions- und Gegenmaßnahmen 

In den nächsten Abschnitten wollen wir uns anschauen, wie man sich gegen diese Art von Angriffen wappnen kann und auch kurz Maßnahmen besprechen, die zwar naheliegend klingen, aber nicht wirken.  

All diese Maßnahmen zielen auf die Sicherheit der vertrauten Domäne (in unserem Beispiel PARTNER.local). Für die vertrauende Domäne (in unserem Beispiel HISOCORP.local) gibt es unabhängig von dem hier geschilderten Problem auch einiges zu beachten, um nicht durch die Vertrauensstellung Probleme zu bekommen. Da dies aber der geplante Zugriffsweg ist, gibt es dazu bereits passende Anleitungen

Detektion 

Das versteckte Nutzerkonto für die Vertrauensstellung wird nie als Nutzer im eigentlichen Sinn verwendet. Daher sind jegliche Aktivitäten mit der Nutzerkennung (Muster <Domänenkürzel>$) wie das Ausstellen eines TGT (Windows Event 4768), eines Service Tickets (Anfordern Windows Event 4769, Erneuern Windows Event 4770, Fehler Windows Event 4773) oder eine Anmeldung ein eindeutiges Zeichen für eine Ausnutzung.  

Gegenmaßnahmen 

Auf verschiedenen Wegen kann die Anmeldung mit dem versteckten Nutzerkonto verhindert werden. 

Die Systeme der beiden Domänen befinden sich meist auch in unterschiedlichen Netzen, daher kann per Firewall der Zugriff auf Port 88 zum Domain Controller der vertrauten Domäne (in unserem Beispiel PARTNER.local) vom Netz der vertrauenden Domäne (HISOCORP.local) gesperrt werden. In die umgekehrte Richtung ist der Zugriff nötig, damit Nutzer sich Service Tickets für freigegebene Dienste der vertrauenden Domäne ziehen können, in dieser Richtung jedoch nicht. Damit wird der Angriff verhindert, wenn der Angreifer aus dem anderen Netz agiert. Hat der Angreifer unabhängig von der Kompromittierung der vertrauten Domäne auch bereits Netzwerkzugriff auf Systeme der vertrauten Domäne, hilft die Firewallregel nicht. 

Die Nutzung des versteckten Kontos kann auch per GPO unterbunden werden. Dafür muss die Regel „Zugriff vom Netzwerk auf diesen Computer verweigern“ erstellt werden und dort dann manuell das Konto (in unserem Beispiel HISOCPRP$) eintragen werden. Der Kontoname muss händisch eingegeben werden, da bei der „Durchsuchen“-Funktion das Konto auch ausgeblendet ist. Wenn die GPO wirksam ist, kann zwar weiterhin ein TGT für dieses Konto bezogen werden, aber keine Servicetickets. Damit geht auch kein Zugriff auf Dienste (wie Dateifreigaben) oder der oben geschilderte Kerberoasting-Angriff. 

Als weitere Verteidigungsschicht können die Zugriffsrechte für den Nutzer eingeschränkt werden. Der Nutzer ist automatisch Mitglied in der Gruppe „Domänenbenutzer“ und gehört auch zur Gruppe „Benutzer“. Dienste und Dateien sollten nicht für eine der beiden Gruppen freigegeben werden, auch wenn sie von allen genutzt werden sollen. Stattdessen bieten sich für solche Freigaben eine zusätzlich gepflegte Gruppe mit allen aktiven Nutzern an. 

Maßnahmen, die nicht wirken 

Es gibt einige Gegenmaßnahmen, die sehr naheliegend klingen, aber tatsächlich nicht umsetzbar oder hilfreich sind.  

So kann der versteckte Nutzer nicht einfach deaktiviert oder gelöscht werden, entsprechende Versuche führen direkt zu Fehlermeldungen.  

Der Nutzer hat als primäre Gruppe die Gruppe „Domänenbenutzer“. Das ist eine automatische Gruppenzuordnung, das heißt man kann zwar eine andere primäre Gruppe eintragen aber der Nutzer wird dennoch immer Mitglied der „Domänenbenutzer“ bleiben. 

Fazit 

Aus einer einseitigen Vertrauensstellung zwischen Domänen kann sich damit auch ein Risiko entgegen der „Direction of Access“ ergeben. Wird die eine Domäne kompromittiert erhält der Angreifer auch das Passwort für einen versteckten Nutzer in der anderen Domäne. Der hat zwar kaum Zugriffsrechte, aber kann als erster „Fuß in der Tür“ für weiterführende Angriffe genutzt werden. 

Da Risiko lässt sich aber durch Firewallregeln, GPOs und gutes Rechtemanagement adressieren. Ein erfolgreicher Angriff lässt sich auch eindeutig in den Windows Events identifizieren. 


  1. Im Folgenden werden wir der Einfachheit halber immer von einer Domäne sprechen, da sich ganze Forests in diesem Fall wie eine Domäne verhalten ↩︎

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:

Die Forschenden geben an, dass zur Ausnutzung des beschriebenen Verhaltens mindestens zwei Mailserver benötigt werden, was unterschiedlich interpretiert werden kann. Die Angabe ist wörtlich zu verstehen, es braucht mindestens einen sendenden und einen zweiten, empfangenden Mailserver – lokal lässt sich die Lücke nicht ausnutzen. Das bedeutet letztlich, dass ein erreichbarer Mailserver ausreicht, sofern er verwundbar ist.

Im Artikel wird DKIM als eine der Maßnahmen erwähnt, die mit der beschriebenen Schwachstelle möglicherweise ausgehebelt werden können. Dies ist nach unserem Verständnis nicht der Fall, da nach der Auftrennung der eingehenden Nachricht für beide E-Mails die Signaturen nicht mehr stimmen, denn diese schließen auch den DATA-Bereich der Mail ein, der nun verändert ist.

SMTP Smuggling-Fallout  – or: Who should patch now? What and how?

This article is also available in German.

tl;dr 1: All those who run a vulnerable server should patch it really soon.
tl;dr 2: Patching alone usually won’t suffice – in most cases configuration options will have to be changed, too.

This winter season had administrators of of mail servers stirring between christmas cake and new year’s toasts, as the „SMTP Smuggling“ security leak made rounds. It was published on 2023-12-18 by Timo Longin, SEC Consult and presented two weeks later at the (in)famous 37th Chaos Communication Congress (37C3) in Hamburg. The talk has been recorded and is available at media.ccc.de.

The security vulnerability, which allows sending out emails under fake names from valid original servers, affects the standard protocol SMTP which is used worldwide to transfer emails between email servers. Email-Spoofing, i.e. sending out emails under forged sender name, is not exactly a new invention. Nowadays countermeasures like SPF and DMARC  (in combination) provide a means to check whether a mail server is allowed to send mails from a certain domain and server – or not. But what, if validated mail servers could be abused to send out illicit emails?

For efficiency reasons the SMTP protocol allows transferring multiple emails in one session. And this is exactly where the „SMTP-Smuggling“ vulnerability kicks in. When sending multiple emails in one go, the emails are separated by the END-OF-DATA marker as defined in RFCs (Request for Comments, the standards documents defining computer data protocols) 5321 and 5322. All email servers worldwide must basically follow these standards (at least to a certain extent) to be able to send and receive emails. Some mail server software allows for some leniency so slightly deviating or broken mail clients still can participate in email exchange.  And exactly this where SMTP Smuggling attacks.

The aforementioned END-OF-DATA marker is defined as <CR><LF>.<CR><LF> (<CR> is „carriage return“, as the older ones might remember from typewriters for returning to the first column, also written as \r, whereas <LF> is „line feed“, forwarding the paper to the next line, also written as \n).

So this basically is a sole dot in an otherwise empty line.

While Microsoft Windows systems generally define a the marker for the next line as <CR><LF>, Unix-based operation systems like Linux, BSD, MacOS-X etc only use a solo <LF>. On some older or more obscure operating systems other methods are used (e.g. the old Finder-based MacOS (version 7 and older) use(d) a solo <CR> as next-line-marker).

Knowing this it might not come as surprise that for compatibility reasons quite some mail servers accept „a sole dot in an otherwise empty line“ as END-OF-DATA marker regardless wether with standards conforming next-line markers <CR><LF>.<CR><LF>, <CR>.<CR> , or with Unix-style next-line <LF>.<LF> – or other encodings.

So if now a lenient mail server accepts non-conforming END-OF-DATA markers, an attacker can send one single mail that is interpreted as multiple independent mails which are then delivered as defined by the attacker. As a strictly standards-compliant mail server does not recognize broken END-OF-DATA markers as end-of-data, defense mechanisms against faking sender addresses do not work for the embedded second email, and the one mail including the smuggled second is forwarded to the target mail server.

Security-aware server administrators usually have configured their mail servers so that every email is checked whether the delivering user is actually allowed to send the mail with the given sender address. In Postfix mail server configuration this can be set with the option reject_authenticated_sender_login_mismatch, which matches user names to sender addresses in the $smtpd_sender_login_maps database.

Each email contains at least two addresses: one on denoting the sender (MAIL FROM) and the other one the recipient (RCPT TO). When safeguarding the mail server against forgery it can (depending on software and configuration used) check the emails sender against a list of email addresses the user is allowed to use. If the it is not on the delivering user’s list, delivery of the the mail is rejected. The sole exception is that the original server is allowed to send mails for the (original/first) mmail sender domain. The smuggled second/third emails won’t be checked against maybe existing SPF oder DMARC sender restrictions – as the server only is sending one strictly valid mail after all. This is especially relevant for cloud services with many domains with very many mail addresses sharing the same SPF/DMARC configurations

A single mail dialoge with standards-compliant END-OF-DATA marker <CR><LF>.<CR><LF> looks for example like this (the first two lines defining the envelope, the 4th to 6th line the header) – ending with \r\n.\r\n:

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

In contrast to this an attacker’s email might look like this, using a nonstandard marker for mail separation <LF>.<LF> (or  \n\n respectively):

mail FROM: \r\n
rcpt TO: \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

The receiving server accepts the mail and then processes it. If the server is vulnerable to this attack, it leniently accepts <LF>.</LF> (resp. \n.\n) as END-OF-DATA marker and splits the prepared mail into two – separated by the perceived (yet strictly speaking: invalid) marker. As it already accepted the email delivery, it now delivers two mails: one from user@sender and the other by admin@sender – without being able to recognize admin@sender as invalid as all checks already have been passed. Even experts will have a hard time recognising the smuggled mail as such, because originating server, mail headers and SPF and DMARC checks all are valid.

This is especially dangerous for big mail providers. If for example an attacker sends a thusly prepared mail from an account at hypothetically vulnerable Google mail service (e.g. Testuser234@google.com) and smuggles another mail into it from support@gmail.com, the recipient cannot tell, whether that email is legit and that the attachment-to-be-clicked really should be clicked: it originates from the correct server, all headers are like an original one, SPF and DMARC all check as valid. Big cloud and mail providers often use the same SPF/DMARC policy for thousands of domains, so an attacker could send out mail from any of those domains and still pass SPF/DMARC checks. Luckily the big mail providers already filter out malformed END-OF-DATA markers and thus prevent this attack. But as this is the first but probably not last one of such attacks, and because to all mail server admins have patched their systems yet, it is too early to dismiss the warning.

Aggreviating this problem is that not all providers or manufacturers acknowledge this as possible problem. For example Cisco’s mail filter appliance did not filter but „corrected“ malformed END-OF-DATA markers – insisting that of not being a problem (What they nowadays recognize as possible attack vector). As mail recipient you never know how the sending server might be configured. So on your receiving end the mailserver must be patched accordingly and filter out noncompliant mails. A mail service provider will probably notify its customers as soon as its servers prevent sending corrupt END-OF-DATA markers and thus smuggling forged mails. Patching and proper filtering of corrupt markers is the only way to be able to prevent sending out mails with contraband.

Currently security patches are available dor most mail server software – though it might take some time for those to trickle down the supply chain. And sometimes simple patching won’t fix the problem due to compatibility considerations for existing configurations. For example the Open Source project Postfix (included and often used in Ubuntu) „only“ makes filter options available, that have to be explicitly enabled if there already is an individual server configuration. So the proper options must be configured, the mail service restarted and mail flow checked.

We would like to add two notes on two topics where we tripped over ambiguous wording:

The researchers mentioned that two mail servers are necessary to enable smtp smuggling – which can be interpreted in multiple ways. As the vulnerability cannot be triggered locally, a receiving mail server and an SMTP mail delivered to it are needed. Thus a vulnerable mail server that is reachable via SMTP should suffice.

The article mentioned DKIM as one security measure that could be broken by this vulnerability. This usually is not true according to our research for mails that have been signed on the sending mail server – when the original mail is broken up on the receiving system the mail body (originally including the smuggled mail) has changed and this the original DKIM body checksum won’t match any more.

Da ist der Wurm drin: „Wormable“ CVSS-10-Lücke in Microsoft DNS-Server

Für eine maximal kritische Schwachstelle in sämtlichen Windows-Servern von 2003 bis 2019 hat Microsoft zum Patch Day, zusätzlich zum Fix per Update, auch einen Workaround veröffentlicht, der die Sicherheitslücke für nicht zeitnah patchbare Server schließt. Diese Dramatik beruht auf berechtigten 10 von 10 CVSS-Punkten dank des Potenzials zur Weiterverbreitung zwischen Servern ohne jegliche Benutzerinteraktion („Wurm“).

https://www.heise.de/security/meldung/Patchday-Trojaner-koennte-von-einem-zum-naechsten-Windows-DNS-Server-springen-4844150.html

https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/