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.

Jirassic Park: Das zwischenzeitliche Aussterben der Confluencer

Atlassian ist seit Jahren als eines der Unternehmen bekannt, die ihre Kunden mit besonders viel Enthusiasmus in die Cloud locken – manche würden vielleicht sogar scheuchen sagen. Immerhin verspricht man sich dort (zu Recht) mehr Agilität und damit auch mehr Nutzen für die Kunden.

Nun hat das Umarmen der Wolke einige, die sich darauf voll eingelassen haben, böse gebissen. Ein Wartungsskript, das eigentlich nur Legacy-Daten löschen sollte, entfernte darüber hinaus die produktiven Daten von 400 Kunden samt Informationen zu gebuchten Produkten, Nutzern und Drittanbieteranwendungen. Zwar waren umfangreiche Wiederherstellungssysteme vorhanden, trotzdem sollte der Wiederaufbau für einen Großteil der Betroffenen bis zu zwei Wochen dauern.

Nun gibt es zwei Sichten auf die Misere. Die eine: Das passiert On-Prem auch, nur dann steht es (meist) nicht in der Zeitung. Das ist auch richtig. Und allein die Cloud zu verdammen ist in diesem Fall sicherlich nicht hilfreich. Andererseits zieht das andere Extrem, den Cloud-Betrieb von der Verantwortung völlig freizusprechen, auch nicht komplett. Immerhin bauen wir uns mit IaaS, PaaS und SaaS erhöhte Komplexität und damit auch mehr „Single“ Points of Failure, mindestens aber Klumpenrisiken auf.

Die Verantwortung, für die geschäftskritischen Daten einer Vielzahl von Organisationen verantwortlich zu sein, muss daher mit einem umso größeren Maß an Professionalität und Due Diligence einhergehen. Die – zumal nicht-amerikanischen – Cloud-Anbieter (Atlassian sitzt in Sydney) werden sich daran messen lassen müssen, ob sie schneller besser werden, als wir ihnen unser Geld und unsere Verantwortung hinterherwerfen.

https://www.heise.de/news/Atlassian-Ausfall-der-Cloud-Dienste-Jira-Confluence-dauert-noch-zwei-Wochen-6669601.html

Keine Gaudi: Fast Super-Cloud-GAU bei Microsoft

Bei Microsoft ist eingetreten, wovor sich viele Cloud-Anbieter insgeheim fürchteten: Getroffen hat es Azure mit seiner Cosmos DB, einer beliebten NoSQL-Datenbank. Das Datenbankmanagement wird dabei ganz im Sinn von PaaS weitgehend von Microsoft übernommen.

Nun haben Sicherheitsforscher eine Schwachstelle in der Funktion Jupyter-Notebook entdeckt. Dieses Feature war erst im Februar diesen Jahres durch Microsoft aktiviert worden. Der Vorgang zeigt, wie wichtig es ist, die Konfiguration in allen genutzten Cloud-Diensten beständig im Blick zu behalten und gerade neue Features sicherheitstechnisch kritisch zu bewerten.

Die Entdecker WIZ Research haben zur Schwachstelle folgendes Video erstellt:

Eine Webseite mit Informationen zur Schwachstelle ist hier zu finden: https://chaosdb.wiz.io/

Laut Microsoft kam es glücklicherweise nicht zu einem aktiven Ausnutzen dieser Schwachstelle, siehe folgende Stellungnahme:

Positiv hervorzuheben ist, dass nur zwei Tage nach Meldung der Sicherheitslücke das betroffene Jupyter-Notebook-Feature durch Microsoft deaktiviert wurde, sowie der offene Umgang mit der Schwachstelle.

Fix Once, Secure Everywhere

Dies zeigt einen weiteren Vorteil der Cloud: Wenn eine Schwachstelle im Zuständigkeitsbereich des Cloud-Anbieters liegt, muss diese in der Regel nur durch den Cloud-Anbieter gefixt werden. Auf der anderen Seite ist dies auch ein Unterscheidungsmerkmal in Bezug auf Anbieterqualität: Nur ein Cloud-Anbieter, der schnell reagiert, bietet den Kundendaten entsprechenden Schutz.

CV? Neee…

Leider gibt es – anders als für Schwachstellen in Anwendungen und Betriebssystemen – keine dedizierte Datenbank für Schwachstellen in Cloud-Diensten. Denn CVE-Nummer werden nur vergeben, wenn die die Software durch den Kunden kontrollier- bzw. installierbar ist (https://cloudsecurityalliance.org/blog/2018/08/13/cve-cloud-services-part-1/).

Blitze-Wolke

HAFNIUM-Schwachstellen: Office 365/Microsoft 365/AD FS indirekt auch bedroht

[GTranslate]

Von Inés Atug, Markus Drenger und Daniel Jedecke.

Nach der Veröffentlichung des Out-of-Band-Patches für die als HAFNIUM bekannt gewordenen Schwachstellen in Exchange Servern haben viele Admins, die zuvor eine Migration nach Office 365 (jetzt Microsoft 365) durchgeführt hatten, aufgeatmet. Denn Microsoft zufolge ist Exchange Online von Hafnium nicht betroffen. Hiermit meint der Hersteller jedoch das Produkt an sich: Exchange Online ist weiterhin nicht direkt angreifbar. Aber Vorsicht: Es kann je nach Aufbau dennoch möglich sein, dass Angreifer auf den Cloud-Dienst durchgreifen können. 

In vielen Fällen ist in Unternehmen ein hybrider Aufbau etabliert, bei dem ein Exchange-Server weiterhin lokal betrieben wird. Sollte dieser Exchange-Server die HAFNIUM-Schwachstellen aufweisen, könnten Angreifer hierüber Zugriff auf das lokale Netzwerk erhalten (siehe Abbildung Schritt (1)) und sich dann über Lateral Movement im Netz weiterbewegen (Schritt (2)). Mittelbares Ziel des Angriffs ist in der Regel der Zugriff auf ein hochwertiges System wie beispielsweise das Active Directory oder die Active Directory Federation Services (AD FS) zu. Bei Zugriff auf letzteren können die Angreifer unter Umständen den geheimen Schlüssel entwenden (Schritt (3)), sich damit als jeder beliebige legitime Nutzer in der Cloud ausgeben (Schritt (4)) und somit Zugriff (lesen, verändern, löschen) auf alle in der Cloud gespeicherten Daten bekommen (Schritt (5)).

Angriff auf die Cloud/ADFS via HAFNIUM/ProxyLogon

Ob und wie leicht dies möglich ist, hängt stark davon ab, wie der lokale Aufbau umgesetzt ist. Wir erleben im Bereich der Forensik und Beratung hier gute wie auch ungünstige Umsetzungen. Prinzipiell sollte das Ziel immer sein, Lateral Movement in der On-Premise-Umgebung wie auch in der Cloud zu minimieren. Hierfür gibt es bewährte Verfahren, welche sich bei geeigneter Konfiguration dazu eignen, die Bewegungen der Angreifer im Netz zu erschweren:

  • Frühzeitiges Patchen von Sicherheitslücken: Die wichtigste Maßnahme, die auch bei Hafnium eine Kompromittierung mit hoher Wahrscheinlichkeit unterbunden hätte, ist das schnelle Patchen der Systeme. Hier herrscht bisweilen noch der Irrglaube, dass kritische Sicherheitslücken innerhalb von 30 Tagen zu patchen seien. Dies wurde und wird teilweise sogar noch von IT-Sicherheitsstandards vorgeschlagen. Sicherheitslücken, die mittels Fernzugriff automatisiert und unauthentifiziert ausgenutzt werden können, so wie dies bei Hafnium der Fall ist, zeigen jedoch deutlich, dass hier möglichst innerhalb von Stunden anstatt Tagen gepatcht werden sollte.
  • Administrative Trennung von Active Directory und Exchange Server: Eine weitere Maßnahme, die lokal umgesetzt werden sollte, ist die administrative Trennung zwischen Active Directory und Exchange. Oft sind die Systeme über Jahre gewachsen und eng miteinander verbunden. So trennt die Angreifer nach erfolgreicher Kompromittierung oft nur ein Powershell Kommando von der AD-Übernahme. Hier ist es wichtig, die 2017 von Microsoft im Rahmen der Konferenzen Blue Hat und Black Hat vorgestellten Probleme zu mitigieren. Hierfür eignet sich Split-Permissions (https://docs.microsoft.com/en-us/exchange/understanding-split-permissions-exchange-2013-help und https://docs.microsoft.com/de-de/exchange/permissions/split-permissions/configure-exchange-for-split-permissions?view=exchserver-2019). Eine weitere Maßnahme ist die Verwendung der Local Administrator Password Solution (LAPS) von Microsoft. Hierbei wird auf jedem Host ein separates Admin-Passwort gesetzt, um so das Springen nach einem erfolgreichen Angriff (beispielsweise mittels Pass-the-Hash-Angriffsarten) zu erschweren.
  • Umsetzen des Konzepts administrativer Zonen: Da AD FS das Sprungbrett in die Cloud Welt ist, sollte dieser Zugang besonders gesichert werden. Hierzu empfiehlt Microsoft seit längeren einen Aufbau, in dem verschiedene administrative Sicherheitszonen (engl. tiers) voneinander getrennt werden sollten. Ein entsprechend gesicherter Exchange Server würde hier in Zone 1 stehen und ein Active Directory in Zone 0. Ein Sprung zwischen diesen Zonen soll mit den umzusetzenden Maßnahmen stark erschwert werden. Für den AD FS empfiehlt Microsoft ebenfalls den Aufbau in der Zone 0 (https://docs.microsoft.com/de-de/windows-server/identity/ad-fs/design/best-practices-for-secure-planning-and-deployment-of-ad-fs).
  • Multifaktorauthentifizierung: Sowohl in der Cloud als auch in der lokalen IT-Umgebung sollten administrative Zugriffe mittels starker Multifaktorauthentifizierung abgesichert werden.
  • Protokollierung und Monitoring: Damit ein unberechtigter Zugriff möglichst schnell bemerkt wird, sollte ein feinmaschiges Monitoring- und Protokollierungskonzept etabliert sein. Insbesondere in der Cloud-Umgebung gehört das Monitoring neben der Zugriffssteuerung zu den wichtigsten Sicherheitsmaßnahmen. 
  • Datenklassifizierung: Sollte es doch zu einem Einbruch gekommen sein und die Angreifer möchten Daten exportieren, dann sollte mittels der Datenklassifizierung Sicherheitsmaßnahmen greifen, die zumindest die als vertraulich oder streng vertraulich klassifizierten Daten außerhalb der Cloud und des Kundennetzwerks unlesbar darstellen. 
  • Datensicherung: Sollte es zu einem Einbruch gekommen sein und es werden die Daten mittels Ransomware verschlüsselt, dann sollte man auf eine unveränderbare extern gespeicherte Datensicherung zurückgreifen können.

Die obigen Ausführungen zeigen, dass ein ganzheitliches und aktuelles Sicherheitskonzept notwendig ist, um möglichen Sicherheitslücken umfassend entgegenzuwirken. Überprüfen Sie daher regelmäßig Ihre Sicherheitsmaßnahmen und passen Sie diese ggfs. an geänderte Anforderungen an. Insbesondere, wenn Sie lokale Dienste von außen erreichbar konfigurieren oder Cloud-Dienste mit der lokalen IT-Umgebung koppeln, sollten das Sicherheitskonzept überprüft und nachgeschärft werden. Sprechen Sie uns gerne dazu an!  

HiSolutions Research

OAuth-Phishing

Im Rahmen von COVID-19 wurden viele neue Phishing-Kampagnen verzeichnet – darunter auch sogenannte OAuth-Phishing-Angriffe gegen Office 365. Hierbei werden Phishing-Mails an Benutzer gesendet, die, wenn sie auf den in der Mail enthaltenen Link klicken, gefragt werden, ob sie Berechtigungen an eine App übergeben wollen. Mit der Bestätigung autorisiert der Benutzer dann die App für den Zugriff auf seine Daten. Der Ablauf des OAuth-Phishings ist in der untenstehenden Abbildung dargestellt.

Ablauf OAuth-Phishing

Doch die Vorgehensweise ist nicht neu. Bereits 2017 kam es zu einer großen Phishing-Welle, die Google Docs-Benutzer dazu einlud, ein geteiltes Dokument aufzurufen. Für diese Angriffe mittels OAuth-Apps werden die Funktionalitäten des OAuth-Protokolls genutzt. Mit OAuth kann ein Benutzer einer Anwendung den Zugriff auf seine Daten erlauben, die von einem anderen Dienst bereitgestellt werden. Der Zugriff der Anwendung erfolgt dabei ohne Benutzerkennung und Passwort. Somit können auch eine Passwortänderung oder die Einführung einer Multifaktorauthentifizierung die Vergabe der Berechtigungen nicht mehr rückgängig machen.

Es wird hier also keine Schwachstelle im OAuth-Protokoll ausgenutzt. Stattdessen wird der Benutzer dazu gebracht, Berechtigungen zu übergeben, ohne dass ihm dies bewusst ist. Hierzu werden Links mit zu Office 365 oder Google G Suite ähnlich klingenden Domainnamen verwendet, und auch die App-Namen werden so gewählt, dass ein unbedarfter Benutzer diese mit dem jeweiligen Cloud-Dienst assoziiert.

Ein OAuth-Phishing-Angriff ist im Nachhinein schwer erkennbar, da kein schadhafter Code ausgeführt wird. Stattdessen können Daten gelesen und je nach Berechtigung auch geändert oder gelöscht werden. So kann ein Angriff unbemerkt bleiben oder wird erst dann bemerkt, wenn in einer weiteren Angriffsphase Daten verschlüsselt wurden oder ein CEO-Fraud begangen wurde.

Damit es erst gar nicht zu einem Zugriff mittels OAuth-Phishing kommt, sind folgende Maßnahmen zu empfehlen:

  1. Schulung der Mitarbeiter, um OAuth-Phishing-Angriffe zu erkennen
  2. Drittanbieter-Apps nur mittels Whitelisting zulassen oder die Nutzung ganz untersagen
  3. In Office 365 können Drittanbieter-Apps mittels der CASB-Lösung von Microsoft (Cloud App Security) überwacht werden. Dieses Feature steht jedoch nur in der E5-Lizenz zur Verfügung.

Falls man vermutet, dass man mittels einer OAuth-App kompromittiert wurde, dann kann man dies in Office 365 über das von Microsoft für Office 365 veröffentlichte Vorgehen[1] nachvollziehen und die Berechtigungen der jeweiligen App deaktivieren. Grundsätzlich sollte die verdächtige App deaktiviert werden und es sollten die Berechtigungen entzogen werden. Anschließend sollten die Zugriffsprotokolle überprüft werden, um den Umfang der Kompromittierung zu verstehen.


[1] https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants

Alles ist verbunden – Multiple Single Points of Failure

Von großen – im Sinn von weitreichenden – Cloudausfällen war an dieser Stelle und in den Weiten des Internets in letzter Zeit häufig zu hören. Denn je mehr der Markt reift (sprich, je mehr Unternehmen relevante Teile ihrer Infrastruktur in die Wolke verlagern) und je mehr sich der Kuchen des Cloud-Geschäfts im Wesentlichen auf eine Handvoll großer Cloudanbieter und ein paar Dutzend Security-Services-Anbieter verteilt, desto größer kann der Impact eines einzelnen Zwischenfalls sein. Nun war Cloudflare an der Reihe, dies am eigenen Astralleib zu erfahren: Ein harmlos erscheinender regulärer Ausdruck, der weltweit bösartiges „Inline“-JavaScript herausfiltern sollte, brachte die Prozessorlast sämtlicher Filter auf 100 %, sodass bei den vielen Cloudflare-Kunden für eine halbe Stunde nichts mehr ging. Dann war das Problem erkannt und die Funktion gekillt – im Gegensatz zu Google im Mai konnte Cloudflare die Managementinterfaces nämlich ohne Probleme erreichen. Hatte der DDoS- und Websecurity-Spezialist aus Kalifornien schlampig gearbeitet? Ja und nein, die neue Funktion war zwar per Knopfdruck sofort weltweit, aber immerhin nur im Testmodus ausgespielt worden, der nichts hätte blocken sollen. <Ironie>Dass die Komplexitätstheorie bei den seit Jahrzehnten als mögliche Ressourcenmonster verrufenen RegExen einen Strich durch die Rechnung machen würde, konnte ja niemand ahnen … </Ironie>

In einer überraschenden Fügung des Schicksals hätte der Ausfall beinahe ein längst in eine dunkle Flasche verbanntes Monster wiederbelebt: 2017 hatte der junge Malware-Forscher Marcus “MalwareTech” Hutchins in einem heldenhaften Einsatz (siehe Lesetipps am Ende dieses Digests) per „Sinkhole“, also eine geistesgegenwärtig reservierte Domain, der Welt den größten Teil der ersten WannaCry-Angriffswelle erspart. Diese Sinkhole-Domain erhält bis heute riesige Mengen an Anfragen von schlummernden WannaCry-Infektionen, die nachfragen, wann sie denn nun endlich losschlagen sollen.Später wurde ebendiese pro bono (und natürlich für den Werbeeffekt) von Cloudflare übernommen – und war seither nie down. Um ein Haar hätte der Cloudflare-Ausfall also ein Heer von Schläfern erweckt, die Schäden von hunderten Millionen hätten verursachen können. Glücklicherweise genügte die immerhin noch ausgelieferte Fehlermeldung (HTTP-Code 502), um die Viren zu beruhigen. Sie schlummern also weiter auf unseren ungepatchten Systemen und laben sich an unseren technischen Altlasten …

HiSolutions Research

Paging Münchhausen – Cloud braucht Cloud

Am 2. Juni standen weite Teile der Google Cloud für bis zu vier Stunden still. Dass Google damit die Jahres-SLAs gerissen hat, ist nur ein Teil des Problems, schließlich kamen und kommen Downtimes auch in selbstbetriebener IT immer wieder vor. Bedenklich ist vielmehr, dass es zu einem derart langen länderübergreifenden Ausfall kommen konnte, obwohl Google derart viel in Redundanz, Notfallplanung und Desaster Recovery investiert. Und zwar technisch wie konzeptionell. Nach ersterem Maßstab hat sich der Betreiber nicht viel vorzuwerfen, denn der Root-Cause war eine schwer vorauszusehende Interaktion drei verschiedener Bugs. Das Problem war schnell erkannt, verstanden und die Lösung schnell entworfen.

Allerdings gibt es zwei große Lessons Learned hier (für Google wie für die Kunden der großen Cloudanbieter): Erstens, die komplexen internen Abhängigkeiten der Gesamtsysteme, die Cloud-Dienste/-Rechenzentren/-Angebote darstellen, sind noch nicht ausreichend verstanden. Denn erst beim Incident-Handling fiel auf, dass man zur Behebung des Problems die, *tada*, Google Cloud benötigt, welche ja gerade nicht verfügbar war. Es fehlt also noch die Fähigkeit eines Baron Münchhausen, sich am eigenen Schopf aus dem Sumpf zu ziehen, sogenanntes Bootstrapping, im Energiesektor als Schwarzstartfähigkeit bekannt. Eine solche vorrätig zu halten, kostet Geld, was dem Kostendruck in der Cloud zuwiderläuft.

Das zweite Thema ist noch eine Ebene prinzipieller: Die großen Kosten- und Effizienzvorteile erzielt man im Cloud-Computing durch weitgehende Automatisierung – und die braucht als Basis Mono- oder zumindest Oligokulturen. Wie in der industriellen Landwirtschaft steigt mit der Effizienz hierbei auch das Risiko, dass ein einzelner Schädling/eine einzelne Schwachstelle/Bug/Fehlkonfiguration ganze Landstriche verwüsten und Hungersnöte auslösen kann. Meist wird man dies mittels viel Chemie unter Kontrolle halten können – was aber wieder nur das Risiko konzentriert und vertagt.

Sicher ist: Das dicke Ende kommt noch – und wir tun uns auf Dauer keinen Gefallen, wenn wir die Auseinandersetzung damit einfach nur in die Zukunft verschieben.

Zum Thema Cloud Security empfehle ich unseren aktuellen Webcast „Wege in die Cloud – aber sicher!”

Sicher in die Wolken

Immer mehr Unternehmen nutzen sie heute. Doch nur wenige wagen bisher den Schritt, ihre Kerngeschäftsprozesse komplett in die Cloud zu verschieben. HiSolutions unterstützt die Lufthansa bei der sicheren Migration.

Abdou-Naby Diaw, Deutsche Lufthansa AG, & Timo Kob, HiSolutions AG: Sicher in die Wolken. Wie HiSolutions die Lufthansa Group beim Weg in die Cloud unterstützt, in: <kes>  Special Sicheres Cloud-Computing, Februar 2019. [PDF]