Schwachstelle öffnet Türen in mehr als 3.000 Hotels

Es mag bequem klingen: Die Zimmertür im Hotel lässt sich ganz ohne Schlüssel oder Karte vom Smartphone aus entriegeln. Doch was passiert, wenn die Logik eines solchen Systems nicht ausreichend abgesichert ist?

Zimmertüren von Hotels aus über 25 Ländern ließen sich mit einer neu entdeckten Schwachstelle öffnen. Bequem? Ja, über das Internet und ohne Zugangsdaten. Dazu konnten sämtliche Reservierungsinformationen (u. a. Name, E-Mail, Reservierungszeitraum und Raumnummer) eingesehen werden. Doch wie kam es dazu?

Zusammenfassung

Die Firma straiv ist ein innovativer und digitaler Begleiter für Hotelbranchen. Als solcher bieten sie unter anderem Online-Check-ins und digitale Türöffnungen an. Was den Sicherheitsforschern Björn Brauer, Deniz Adrian und David Mathiszik bei einem Hotelbesuch jedoch auffiel: Angreifenden wäre es dank einer fehlerhaften Zugangskontrolle in der API möglich, den Check-in und das Öffnen von Türen auch ohne Autorisierung über das Internet zu bedienen.

Im Rahmen einer vertraulichen Offenlegung (engl. Responsible Disclosure oder auch Coordinated Vulnerability Disclosure – CVD) wurden die technischen Details daraufhin direkt an den Hersteller übermittelt. straiv reagierte zeitnah und behob die Sicherheitslücke in ihrer Anwendung umgehend.


Dank ihres Software-as-a-Service-Ansatzes konnte das Unternehmen das Sicherheitsrisiko zeitgleich für alle Kunden mitigieren. Es wird daher auch keine CVE-ID für diese Schwachstelle vergeben. Die Veröffentlichung der Schwachstelle erfolgt in Abstimmung mit dem Hersteller frühestens einen Monat nach der erfolgreichen Behebung.

Die Ursache: Broken Access Control

Broken Access Control belegt aktuell Platz 1 unter den beliebtesten (lies: häufigsten) Schwachstellen in Webanwendungen (siehe: A01:2021 – OWASP Top 10). Auch hier war eine fehlerhafte Zugriffskontrolle die Ursache.

Für gewöhnlich erhalten Gäste eine E-Mail mit einem Link zu ihrer Reservierung. Über diesen werden sie auf die Webanwendung von straiv weitergeleitet. Dort können Buchungsinformationen, die Reisedaten und alle Begleiterprofile eingesehen werden. Ein weiterer Menüreiter führt zu den digitalen Zimmerschlüsseln. Darüber kann die Zimmertür während des eigenen Buchungszeitraums gesteuert werden. Dies geschieht über die API von straiv.io.

Normale API-Anfragen schienen mindestens durch einen HTTP-Header (X-Token), einen Code (cryptcode) und die Reservierungsnummer (reservation) geschützt zu werden. Wurde auch nur einer der Werte verändert, so wurde der Zugriff erwartungsgemäß verwehrt. Fehlten jedoch alle Werte gleichzeitig, wurde nur noch die Reservierungsnummer interpretiert.

In der folgenden beispielhaften Anfrage wurden sämtliche Authentifizierungsparameter, bis auf die Reservierungsnummer, leer gelassen und die API antwortete dennoch mit Informationen zur Reservierung.

POST /api/v2/auth HTTP/2
Host: start.straiv.io
X-Token:
X-Code:
X-Version: 12.3.0
Content-Type: application/json
{
    "cryptcode":"",
    "platform":"linux",
    "browser":"Firefox",
    "version":"115.0",
    "tokens":[],
    "reservation":"3XXXXX"
}

Das Ergebnis enthielt neben anderen Informationen auch einen validen token, der für weitere API-Anfragen genutzt werden konnte.

So lieferte der folgende API-Aufruf noch mehr Kundendetails:

GET /api/v2/vblo/pms/reservation?reservation_id= HTTP/2
Host: start.straiv.io
Accept: application/json, text/plain, */
X-Token: sXXXXXXXXXXXXXXXXXXXh
X-Code: XXXX
X-Version: 12.3.0

Statt die API zu verwenden, kann auch die remote_url aus der Antwort der ersten API-Anfrage verwendet werden, um bequem über die Webanwendung auf die Reservierung zuzugreifen:

HiSolutions hat keine Enumeration von Nutzerdaten durchgeführt und über das Abschätzen der Auswirkungen dieser Schwachstelle hinaus nicht mit der API oder den Buchungen interagiert. Prinzipiell standen alle Funktionalitäten des legitimen Benutzers uneingeschränkt zur Verfügung.

Mitigation

Für die Kunden von straiv bestand kein weiterer Handlungsbedarf. Die Sicherheitslücke wurde von den Entwicklern ernst genommen und umgehend geschlossen.

Grundsätzlich lassen sich Fehler dieser Art durch folgende allgemeine Empfehlungen verhindern:

  • Vertrauen Sie keinen Nutzereingaben – validieren Sie diese.
    Verlassen Sie sich nie auf die Gültigkeit von jeglichen Werten, die von den Endbenutzern beeinflusst werden können. Dazu gehören auch Cookie-Werte, Anfragenparameter und HTTP-Header. Auch auf serverseitig gespeicherte Informationen sollte nich blind in allen Kontexten vertraut werden.
  • Überprüfen Sie Gültigkeit aller Werte serverseitig. Weisen Sie leere oder ungültige Authentifizierungsinformationen zurück. Achten Sie bei der Implementierung von Tests auf eine vollständige Abdeckung aller Randszenarien (ein, mehrere oder auch alle Werte sind unerwartet, NULL, nicht definiert, vom falschen Typ, etc.).
  • Verwenden Sie starke Authentifizierungsmethoden.
    Implementationen sind stets abhängig von der Anwendung und dem Kontext. Greifen Sie, wenn möglich, auf bewährte und praxiserprobte Bibliotheken und Authentifizierungslösungen zurück. Verwenden Sie besonders in Bezug auf sensitive Informationen Zwei-Faktor-Authentifizierung. Stellen Sie zudem sicher, dass alle automatisch generierten Schlüssel, Codes und Token nicht leicht zu erraten und somit vor Brute-Force-Angriffen geschützt sind (vgl. UUID v4).
  • Durchsatzbegrenzung (engl. Rate Limiting) der API-Anfragen:
    Begrenzen Sie die mögliche Anzahl der Anfragen von einzelnen Systemen, um dem Missbrauch, wie der schnellen Enumeration von gültigen Reservierungen, vorzubeugen.

In ihrem Update hat straiv mindestens eine Anfragenbegrenzung aktiviert und Reservierungsnummern auf ein nicht-erratbares Format geändert.

Wie HiSolutions helfen kann

HiSolutions bietet spezialisierte Penetrationstests für Webanwendungen und Infrastrukturen an. Hierbei greifen wir auf langjährige Erfahrung zurück und kombinieren die Fähigkeiten modernster Scantechnologien mit manuellen Prüfverfahren, um die bestmögliche Testabdeckung zu gewährleisten.

Stellen Sie sicher, dass Schwachstellen gefunden und behoben werden, bevor Sie ausgenutzt werden können und kontaktieren Sie uns unter +49 30 533 289 0 oder dem Kontakformular für ein kostenloses Erstgespräch.

Koordinierte Veröffentlichung

  • 22.05.2024 HiSolutions sammelt Details zur Schwachstelle.
    Finder: Björn Brauer, Deniz Adrian & David Mathiszik
  • 23.05.2024 HiSolutions informiert betroffene Hotelkette und wird an straiv weitergeleitet.
  • 25.05.2024 straiv vereinbart einen Termin für die Übermittlung aller Details.
  • 04.06.2024 HiSolutions teilt alle Details mit straiv.
  • 06.06.2024 straiv veröffentlicht ein Update und HiSolutions bestätigt den Fix.

CVE-2024-24272 – DualSafe Password Manager Leaks Credentials

During an investigation, HiSolutions discovered a credential leak of a password manager that was installed as browser extension. After reporting the vulnerability, the vendor was quick to respond and implemented a fix.

Summary

The DualSafe Password Manager by iTop before version 1.4.24 leaks credentials as plaintext in a log file that can be accessed by the local user without knowledge of the master secret (CWE-532). This vulnerability was assigned CVE-2024-24272.

Update to the newest version (at least 1.4.24) as soon as possible and replace potentially leaked credentials.

Vulnerability Details

The following details were produced in a test setup with the vulnerable version 1.4.21 of the DualSafe Password Manager installed in Chrome. After storing and using several credential pairs via the blue extension icon on the top right corner, the log file started showing some entries that contain the plaintext credentials.

Logging is done via a text file in the directory of the browser extension, in this case: C:\Users\User\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\lgbjhdkjmpgjgcbcdlhkokkckpjmedgc\000003.log (file name may vary).

The following image depicts the credential pair stored in DualSafe (right) as well as the log file that contains the same password as plaintext (left).

DualSafe password manager and its log file. Cleartext credentials are marked in the log file.
DualSafe Password Manager leaks plaintext password in log file.

One interesting thing to note is that, while the log file contains some credentials as plaintext in a structure like this one: cacheTabinfoes1_1Þ{"[...]":{"confirmItem":{"pwd":"<password>",[...], "type":"login","uname":"<user>","uri":["<url>"]}}}, there are also similar structures with the key pwd but their value is encrypted. Though the observed log events did not indicate the exact trigger for an entry with a plaintext password, passwords could already be extracted after just a few login attempts.

Usually, the password manager requires a master secret to unlock and access the stored credentials. This vulnerability allows an attacker to harvest stored credentials from the log file without knowing the master secret.

Remediation

iTop announced a fix in version 1.4.24.

Shortly after reporting the vulnerability details to iTop, a fix was implemented and rolled out across Firefox, Edge, and Chrome. Update to the newest version as soon as possible and check for potentially leaked passwords in the described location (the exact path depends on the browser).

Should passwords have been leaked this way, rotate them after updating the extension.

Responsible Disclosure Timeline

  • 04.01.2024 – HiSolutions contacts iTop
  • 30.01.2024 – HiSolutions contacts iTop again after no response
  • 31.01.2024 – iTop responds and requests vulnerability details
  • 31.01.2024 – HiSolutions provides all vulnerability details
  • 01.02.2024 – iTop announces that a fix has been implemented and will be published soon
  • 02.02.2024 – iTop requests a delay before publication to roll out the fix
  • 05.02.2024 – iTop releases 1.4.24 on Firefox and Edge
  • 15.02.2024 – iTop releases 1.4.24 on Chrome
  • 12.03.2024 – HiSolution requests green light for publication
  • 13.03.2024 – iTop accepts and states that 1.4.24 fixes the vulnerability

Credits

This vulnerability was discovered by Paula T., Joshua Z. and Pascal B. (HiSolutions AG). We also thank iTop for their swift response and remediation regarding this vulnerability.

Ivanti noch immer im Visier

Im letzten Digest haben wir Sie bereits über die Offenlegung von vier Schwachstellen in den Ivanti-Produkten Connect Secure und Policy Secure informiert. Seit Erscheinen des Newsletters hat sich noch eine weitere Schwachstelle dazugesellt. Ivanti hat seitdem auch zwei weitere Runden mit Patches veröffentlicht, um die Lücken zu schließen.

HiSolutions sieht als Incident-Response-Dienstleister immer noch neue Angriffe, die in Verbindung mit den Schwachstellen stehen. Falls es noch nicht getan wurde, sollten Sie ihre Ivanti-Produkte schnellstmöglich patchen und eine Kompromittierung mit dem Ivanti Integrity Checker überprüfen. Besonders die Schwachstelle mit der Kennung CVE-2024-21893 wird massenhaft auch durch State Actors ausgenutzt. Falls der Verdacht auf eine Infektion besteht, leiten Sie Sofortmaßnahmen ein und kontaktieren Sie uns oder einen anderen IR-Dienstleister.

Ivantis Artikel zur jüngsten Schwachstelle mit relevanten Patch-Informationen:
https://forums.ivanti.com/s/article/CVE-2024-22024-XXE-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure

Aktueller Artikel auf TheHackerNews:

https://thehackernews.com/2024/02/chinese-hackers-exploiting-ivanti-vpn.html

Ivantis VPN-Software von neuen Schwachstellen heimgesucht

Der erste Blick in den Eierkorb führt uns zu Ivanti mit ihrer VPN-Software: Nachdem am 10. Januar durch den Hersteller zwei Sicherheitslücken veröffentlicht wurden, sind nun am 31. Januar zwei weitere Schwachstellen entdeckt worden. Diese werden seit geraumer Zeit aktiv ausgenutzt. Die neuen Lücken sind mit dem Patch der älteren Schwachstellen aufgetaucht und wurden mit den Updates direkt mitgeflickt.

Besonders problematisch ist die Kombination der ersten beiden Schwachstellen. Damit wird es möglich, willkürliche Kommandos auf den Systemen auszuführen. Während die erste Schwachstelle einen Authentication-Bypass in der Webkomponente von Ivanti ICS und Policy Secure ermöglicht, kann man bei der zweiten Schwachstelle eine Command-Injection in den Webkomponenten von Ivanti Connect Secure und Policy Secure vornehmen. Diese Kombination aus Rechteerlangung und Remote Execution ist äußerst problematisch.

Die durch Ivanti zur Verfügung gestellten Updates bieten vorläufige Gegenmaßnahmen für den alten Angriffsvektor sowie gegen die neu gefundenen Lücken. Patchen Sie als Kunde von Ivanti Ihre Produkte so schnell wie möglich!

Mit den weiteren gefundenen Schwachstellen kommen eine Privilege Escalation sowie eine Server Side Request Forgery dazu. Die SSRF-Schwachstelle, die Zugriff auf bestimmte Ressourcen ohne Authentifizierung erlaubt, wird bereits aktiv ausgenutzt. Das BSI erwartet eine steigende Verwendung dieser Sicherheitslücke.

Ausgenutzt werden die Schwachstellen derzeit von verschiedenen Akteuren, darunter die Gruppe UTA0178. Ziele der Angreifer sind häufig Regierungen, Telekommunikationsunternehmen, Verteidigungsunternehmen und Fortune-500-Unternehmen weltweit. Die Entdeckung dieser Vielzahl an Zero-Days, gepaart mit dem beobachteten Verhalten der Angreifer und der Wahl der Zielorganisationen lassen auf Threat-Actors schließen, die über weitreichende Ressourcen und Kenntnisse verfügen.

 Eine Prüfung auf eine Kompromittierung ist beim Einsatz der Ivanti-Produkte in allen Fällen notwendig.

Die letzte Meldung auf heise finden Sie hier:

https://www.heise.de/news/Ivanti-Neues-ausgenutztesSicherheitsleck-Updates-endlich-verfuegbar-9615184.html

Einen technischen Deep-Dive zu den Schwachstellen finden Sie hier:

https://www.mandiant.com/resources/blog/investigating-ivanti-zero-day-exploitation

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.

Schwachstelle in Confluence

In der Wiki-Software Confluence ist vor kurzem eine Lücke in der Wiederherstellungsfunktion bekannt geworden. Angreifer können diese auch ohne Zugangsdaten nutzen, um eigene Administrator-Accounts anzulegen. Mit diesen lassen sich dann weitere Manipulationen durchführen – zum Beispiel Plug-ins installieren, die wiederum einen weiterreichenden Zugriff auf das Betriebssystem des Servers ermöglichen. Die Lücke wird bereits bei selbstgehosteten Confluence-Servern, die im Internet erreichbar sind, ausgenutzt, und wir unterstützen bereits mehrere Betroffene bei der Bewältigung des Vorfalls.

https://confluence.atlassian.com/security/cve-2023-22518-improper-authorization-vulnerability-in-confluence-data-center-and-server-1311473907.html

Was haben drei Töne mit Informationssicherheit zu tun?

Als am späten Abend des 25. August bei mehreren Zügen der polnischen Bahn PKP plötzlich eine Notbremsung ausgelöst wurde, dachten einige gleich an einen komplexen Cybervorfall. Mehr als 20 Züge wurden zum Halten gebracht, und weitere wurden anschließend aus Sicherheitsgründen gar nicht erst auf die Strecken gelassen.

Die Angreifer mussten sich nicht aufwendig über mehrere Netzgrenzen hinweg bis in die Steuerungstechnik des Bahnnetzes hacken. Der Angriff erfolgte per Funksignal. Eine Folge von drei Tönen auf einer bestimmten Frequenz reichte aus, um die Züge zu stoppen. Dahinter steckt die Sicherheitsmaßnahme (Sicherheit im Sinne von Safety) RADIOSTOP des PKP-Funksystems. Diese Funktion kann an jedem Funkgerät im Zug oder an der Strecke ausgelöst werden und sorgt dafür, dass im Gefahrenfall alle Züge im Empfangsbereich so schnell wie möglich zum Stehen kommen. Bei einem Unfall geht eine sehr große Gefahr von anderen, insbesondere entgegenkommenden Zügen aus – und diese an sichsehr hilfreiche Funktion ermöglicht es, schnell reagieren zu können.

Die Tonfolge ist wohlbekannt und steht sogar in EU-Dokumenten, und die notwendige Funktechnik ist leicht selbst zu bauen. Bei einer Analyse auf der Webseite des Technik-Magazins Wired sprach sich der Sicherheitsforscher Lukasz Olejnik daher dagegen aus, den Vorfall als Cybervorfall zu bewerten. Aber muss ein Cybervorfall sich immer um kompromittierte Computer drehen? Mit den vermutlich selbst zusammengelöteten Funkgeräten, konnten doch auch Schutzziele der Bahn verletzt werden.

Aber andersrum gefragt: Hätten Sie den analogen Zugfunk in Ihre Betrachtungen zur Informationssicherheit einbezogen? Gibt es auch in Ihrem Haus Sicherheitslösungen, die im Gefahrenfall beispielsweise Türen öffnen oder den Serverraum trotz Netzersatzanlage vom Strom trennen?

Wie das polnische Beispiel ausgeht, ist noch offen. Obwohl erste Verdächtige verhaftet und passendes Equipment gefunden wurde, gab es einige Tage lang auch in anderen Landesteilen weitere Vorfälle.

Vorfallupdates – Microsoft und LastPass

Zu zwei Vorfällen, die wir bereits in unserem Digest behandelt haben, gab es in den letzten Tagen Neuigkeiten, die ich gern aufgreifen möchte.

Zuerst zu Microsofts Problem mit unberechtigten Anmeldungen in der Cloud, ein Thema aus dem letzten Digest. Eine zentrale Rolle spielte dabei ein privater Schlüssel, den die Angreifer erbeutet hatten, und mit dem sie sich dann beliebige Zugangstoken selbst unterschreiben konnten. Zu diesem Fall gibt es inzwischen von Microsoft eine detaillierte Beschreibung, wie der Schlüssel über mehrere Stufen aus dem produktiven Server auf eine Testumgebung gelangen konnte. Es wird vermutet, dass er dort von den Angreifern entwendet wurde.

Zusammengefasst wurde zur Rekonstruktion eines Fehlers ein Crashdump des produktiven Servers in die Testumgebung zur Analyse kopiert. Dabei hätte der Crashdump keine Schlüssel enthalten dürfen und falls doch, hätte es an mehreren Stellen in dem Kopierprozess auffallen müssen – keiner der Filter hat jedoch angeschlagen. Das ist aus meiner Sicht eine der Lektionen aus dem Vorfall: Vertraue keinem automatischen Bereinigungsprozess – gerade bei komplexen, unstrukturierten Daten wie Crashdumps –, sondern behandle diese Daten so sensibel wie die ursprünglichen.

Die andere Lektion ist, dass sich die Spur ab der Testumgebung verliert. Es waren keine Protokolldaten mehr da, um die Spur weiter zu verfolgen. Es bleibt also eine bloße Vermutung, dass die Schlüssel über diesen Weg zu den Angreifern gelangten. Gerade bei weiter zurückliegenden Vorfällen stehen auch unsere Forensiker immer wieder vor dem Problem, dass Protokolldaten fehlen. Entweder sie wurden gar nicht erst aufgezeichnet oder aber automatisch gelöscht bzw. überschrieben.

Das zweite Info-Update betrifft den Vorfall beim Passwortmanager LastPass im letzten Jahr, den wir in unserem Januar-Digest thematisierten. Jetzt gibt es einen Verdacht, was mit den gestohlenen Passwörtern passiert sein könnte. Es wird vermutet, dass die Angreifer in den LastPass-Daten Seeds Phrases – also Zugangsdaten für Konten von Krypto-Währungen – gefunden und damit unberechtigte Abbuchungen vorgenommen haben. Taylor Monahan vom Krypto-Wallet-Hersteller MetaMask hatte angesichts einer Reihe von Diebstählen von Krypto-Werten Verdacht geschöpft und die LastPass-Nutzung als gemeinsamen Nenner identifiziert. Sicherheitsexperte Brian Krebs ist in seinem Blog dieser Vermutung nachgegangen und hat noch ein paar weitere Indizien ergänzt.

Eine 10 von 10 – Ivanti CVE-2023‑35078 – Hilfe zur Selbsthilfe


Update vom 10.08.2023:

Für Ivanti Endpoint Manager Mobile (EPMM) wurde am 03.08.2023 eine weitere Schwachstelle (CVE‑2023-35082) mit einer CVSS-Bewertung von 10.0 veröffentlicht. Die Schwachstelle ist ähnlich zu der initial veröffentlichen CVE-2023-35078. Am 07.08.2023 hat Invanti veröffentlicht, dass diese Schwachstelle alle Versionen von EPMM betrifft. Die Maßnahmen zum Schließen der Schwachstelle und einer Identifizierung eines Angriffs wurden in dem Dokument „Hilfe zur Selbsthilfe – CVE‑2023‑35078“ ergänzt.


Update vom 01.08.2023:

Auf Basis der bereits veröffentlichten Expoits konnte der String zur Identifizierung eines Angriffs genauer bestimmt werden. Diese finden Sie in dem Dokument „Hilfe zur Selbsthilfe – CVE-2023 35078“ unter dem Punkt 2.


Update vom 31.07.2023:

Seit dem Wochenende gibt es die ersten öffentlichen Proof of Concept Exploits auf GitHub. Die teilweise in Python geschriebenen Programme ermöglichen eine automatische Ausnutzung der Ivanti Schwachstelle CVE-2023-35078.

Zusätzlich wurde am 28.07.2023 von Ivanti eine weitere Sicherheitslücke (CVE-2023-35081) publiziert. Hierbei handelt es sich um eine Schwachstelle welche es dem Angreifer erlaubt als authentifizierten Administrator beliebige Schreibvorgänge auf dem EPMM-Server durchzuführen.


Am 24. Juli 2023 hat der Hersteller Ivanti Informationen zu der Sicherheitslücke CVE-2023‑35078  veröffentlicht. Die Schwachstelle betrifft die Software „Ivanti Endpoint Manager Mobile“ (EPMM), auch bekannt als MobileIron Core. Um unseren Kunden eine Möglichkeit zu geben, erste Maßnahmen zu ergreifen und ihre Systeme zu prüfen, haben wir einen Leitfaden „Hilfe zur Selbsthilfe – CVE-2023‑35078“ erstellt. Der Leitfaden kombiniert die öffentlichen Informationen der staatlichen Sicherheitsbehörden, Fach-Blogs und die Angaben des Herstellers mit der Expertise der HiSolutions.

Sollten Sie Ivanti bzw. MobileIron Core nutzen, prüfen Sie bitte anhand des Dokuments, ob Sie alle relevanten Maßnahmen ergriffen haben.

HINWEIS: Das Dokument wird laufend aktualisiert. Bitte achten Sie daher auch auf weitere Veröffentlichungen auf unserem Research-Blog. Weitere Informationen und Cybersicherheitswarnungen erhalten Sie auch beim Bundesamt für Sicherheit in der Informationstechnik (BSI) unter https://www.bsi.bund.de/SiteGlobals/Forms/Suche/BSI/Sicherheitswarnungen/Sicherheitswarnungen_Formular.html