CVE-2024-23897: Jenkins

Zusammenfassung

• CVE-2024-23897, bekannt gegeben am 24. Januar 2024, ist eine Sicherheitslücke in Jenkins CI/CD, die dazu führen kann, dass beliebige Dateien gelesen werden.
• Mit Stand vom 30. Januar 2024 hat Censys 83.509 Jenkins-Server im Internet beobachtet, von denen 79.952 (~96%) potenziell verwundbar sind.
• Benutzern wird dringend empfohlen, ein Upgrade auf Jenkins 2.442 für die Standardversion von Jenkins und 2.426.3 für Long-Term Support (LTS)-Editionen durchzuführen.
• Wenn möglich, sollten Jenkins-Server nicht direkt mit dem Internet verbunden sein.

Einführung

Jenkins-Server im Internet.

Am 24. Januar 2024 wurde eine kritische Sicherheitslücke für das Continuous Integration and Continuous Deployment (CI/CD) System Jenkins bekannt gegeben, die derzeit als CVE-2024-23897(Vendor Advisory 3314) verfolgt wird. Bei Erfolg könnte ein nicht authentifizierter Angreifer eine Remote Code Execution (RCE) nutzen, um beliebige Dateien zu lesen (mit einigen Einschränkungen).

In der Standardkonfiguration hat ein nicht authentifizierter Angreifer keine Standardberechtigungen und kann nur die ersten zwei oder drei Zeilen einer beliebigen Klartextdatei lesen. Wenn er authentifiziert ist, kann ein Angreifer jede beliebige Klartextdatei vollständig lesen.

Wenn der Jenkins-Server jedoch mit einer der beiden unten aufgeführten "gefährlichen" Optionen konfiguriert wurde:

• "Nutzern erlauben, sich anzumelden"
• "Anonymen Lesezugriff zulassen"

Benutzer mit den oben genannten Rechten können sowohl Klartext- als auch Binärdateien vollständig lesen (wobei die Binärdateien in Klartext umgewandelt werden).

Das Problem rührt von einer der Programmierbibliotheken her, die Jenkins zum Parsen von Argumenten verwendet, die an ein Befehlszeilendienstprogramm gesendet werden. Die betreffende API, args4j, verfügt über eine Funktion, die "@"-Zeichen, gefolgt von einem Dateipfad, durch den tatsächlichen Inhalt der Datei ersetzt. Versionen von Jenkins LTS vor und einschließlich 2.426.2 und Jenkins Release 2.441 und früher deaktivieren diese spezielle Funktion nicht, was dazu führt, dass ein Angreifer beliebige Dateien im Jenkins-Dateisystem lesen kann.

Die wenigen Proof-of-Concept-Exploits , die bisher veröffentlicht wurden, waren nur in der Lage, beliebige Dateien zu lesen; sie führen nicht beliebige Befehle aus. Das bedeutet, dass ein Angreifer möglicherweise sensible Dateien wie /etc/passwd lesen kann (die in Wirklichkeit gar nicht so sensibel ist, da die echten gehashten Passwörter in /etc/shadow stehen). Die Verwendung dieses Exploits allein verschafft dem Angreifer keine entfernte Shell. Ein Angreifer könnte jedoch Glück haben und ein in einer bestimmten Datei gespeichertes Kennwort finden, das wiederum verwendet werden könnte, um weiteren Zugriff zu erhalten.

Kurz gesagt, dieser Exploit führt zwar einen Befehl aus, beschränkt sich aber auf die Dienstprogramme, auf die der Jenkins-Server Zugriff hat (z. B. die Jenkins-CLI über einen WebSocket), deren Ergebnisse möglicherweise verwendet werden können, um erweiterten Zugriff zu erlangen.

Das soll nicht heißen, dass dies kein Problem ist; technisch gesehen handelt es sich um einen "RCE", da ein (spezifischer) Befehl ausgeführt wird , und wir wollen dies keineswegs herunterspielen. Wir sagen auch nicht, dass ein Angreifer keine Datei finden könnte, mit der er sich zusätzlichen Zugriff verschaffen könnte (z. B. einen privaten SSH-Schlüssel); es ist nur so, dass der Schweregrad aufgrund der Konfiguration des Jenkins-Servers bisher stark eingeschränkt ist.

Für die Details der verschiedenen Konfigurationsschweregrade und eine großartige Beschreibung der genauen Datentypen, die exfiltriert werden können, empfehlen wir die Beschreibung von Horizon3.ai zu CVE-2024-23897 und den Beitrag von Sonar zum selben Thema.

Um zu verstehen, warum dies unter den richtigen Bedingungen ein Problem sein könnte, müssen wir zunächst verstehen, was Jenkins ist, was es tut, warum die Leute es benutzen und welche potenziellen Sicherheitsauswirkungen es hat, wenn einer dieser Dienste übernommen wird.

Was ist Jenkins?

Jenkins ist im Kern ein System zur Erstellung und Bereitstellung von Software. Jeder, der schon einmal in einem Unternehmen oder einem Bereich gearbeitet hat, der Programmierer und Entwickler benötigt, musste wahrscheinlich schon einmal ein Software-Build-System verwenden. Jenkins ist eine der bekanntesten (manchmal auch berüchtigten) Plattformen für kontinuierliche Integration. Sie ist quelloffen und für jeden, der sie nutzen möchte, leicht zugänglich. Neben "einfachen" Aufgaben wie der Kompilierung eines oder mehrerer Projekte und der Erstellung von Paketen kann Jenkins diese Anwendungen auch automatisch in Kundennetzen bereitstellen.

Dieser Dienst ist oft ein Katalysator für den gesamten Code-Implementierungszyklus eines Unternehmens, und aus diesem Grund können wir besser verstehen, warum er als äußerst wertvolles Ziel für Angreifer gilt.

Jenkins ist die Lieferkette...

...oder zumindest ein sehr wichtiger Teil davon.

Wenn man ein einzelnes Produkt als den wahren weichen Unterbauch der Lieferkette eines Softwareunternehmens (oder eines Entwicklungsteams) bezeichnen würde, dann wären es die Build-Server. Dieser Server enthält nicht nur (mehrere) Kopien des Quellcodes eines Unternehmens, sondern oft auch alle Bestandteile eines einzelnen Builds, einschließlich der Schlüssel, Konfigurationen und Passwörter, die für das Zusammenstellen und Bereitstellen einer Anwendung benötigt werden (obwohl dies projektspezifisch sein kann). Oft wird Jenkins als letzte Instanz verwendet, um festzustellen, ob eine Software produktionsreif ist.

Im schlimmsten Fall könnte ein Angreifer, der einen Build auf einem Jenkins-Server verändern kann, theoretisch sowohl die Build- als auch die Deployment-Pipeline vergiften, indem er bösartigen Code oder Befehle als Teil des Auftrags einschleust. Dies ist bereits beim SolarWinds-Vorfall im Jahr 2020 geschehen, bei dem Angreifer über die CI/CD-Pipeline Hintertüren in die Orion-Netzwerküberwachungssoftware des Unternehmens einbauen konnten. Diese wurden dann automatisch an Tausende von Kunden verteilt, getarnt als normales Update.

"Um im Unternehmen Fuß zu fassen, kompromittierte der Bedrohungsakteur das "Herz" der CI/CD-Pipeline, in der Code getestet, verpackt, containerisiert und signiert wird, und änderte dann erfolgreich den Quellcode von SolarWinds." - CyberArk

Vorfälle wie SolarWinds2k machen den Zugang zu einem Continuous-Integration- (CI) oder Continuous-Deployment- (CD) System zu einer wahren Goldgrube für Angreifer. Oder zumindest zu einem sehr begehrten Einstiegspunkt.

Damit soll nicht gesagt werden, dass diese Jenkins-Schwachstelle mit der Schwachstelle identisch ist, die beim SolarWinds-Angriff verwendet wurde, sondern lediglich als Beispiel dafür dienen, was mit administrativem Zugriff auf die Build- und Deployment-Systeme eines Unternehmens erreicht werden könnte.

Die Sichtweise Censys

Ein Hinweis für die Leser.

In den folgenden Abschnitten behandeln wir alle Jenkins LTS-Versionen kleiner oder gleich Version 2.426.2 und Jenkins-Versionen kleiner oder gleich 2.441 als anfällig für dieses CVE, wie im Herstellerhinweis angegeben. Dabei wird nicht berücksichtigt, ob die richtigen Bedingungen gegeben sind, um die Gesamtheit der Text- und Binärdateien zu lesen (anonymer Lesezugriff oder authentifizierte Benutzer), da unser Scanner diese Details nicht direkt meldet, und es soll nicht heißen, dass die Welt in Flammen steht; wir melden nur die rohe Anzahl der Jenkins-Server im Internet, um eine Vorstellung vom potenziellen Umfang dieses Problems zu vermitteln.

Jenkins im Internet

Insgesamt beobachtetCensys 83.509 Jenkins-Server im Internet. Von diesen laufen 79.952 Hosts mit einer anfälligen Version, während nur 3.557 Hosts mit einer der behobenen Versionen gepatcht wurden. Das bedeutet, dass nur 4,2 % der Hosts, auf denen Jenkins im Internet läuft, vor dieser Sicherheitslücke sicher sind, während 95,7 % potenziell anfällig sind.

Der obige Screenshot zeigt die letzten acht Tage der verwundbaren und nicht verwundbaren Jenkins-Server, die wir im öffentlichen Internet finden konnten. Wir sehen, dass am 25. Januar 2024, einen Tag nach der Bekanntgabe der Sicherheitslücke, etwas mehr als 300 Server mit den neuesten nicht angreifbaren Versionen liefen. In den nächsten Tagen wird eine konstante Anzahl von Jenkins-Servern vom Netz genommen und/oder auf die neueste Version aktualisiert werden.

* Der 24.01.2024 ist das Datum der Veröffentlichung der Empfehlung. Beachten Sie, dass unsere Statistiken hier um 11 AM ET erstellt wurden.

Das gleiche Muster haben wir schon einmal bei Produkten wie Confluence gesehen: Wenn eine Sicherheitslücke bekannt gegeben wird, sinkt die Zahl der Online-Server insgesamt, anstatt konstant zu bleiben. Dies deutet darauf hin, dass Administratoren bei Bekanntgabe einer Sicherheitslücke ihre Server vom Internet entfernen, anstatt sie zu aktualisieren, indem sie sie entweder hinter eine Firewall stellen oder ganz vom Netz nehmen. Dies könnte auch darauf hindeuten, dass viele dieser Server gar nicht genutzt wurden (d. h. es handelte sich um Testinstanzen oder etwas Ähnliches).

Die folgenden Diagramme und Tabellen zeigen die Anzahl der verwundbaren und nicht verwundbaren Versionen von Jenkins in allen autonomen Systemen und Ländern, in denen sie sich zum 30. Januar 2024 befinden.

Autonome Systeme (30. Januar 2024)

Länder (30. Januar 2024)

Anfällige Jenkins-Server im Quantenraum

Censys Wir haben knapp 600 Hosts im Internet gefunden, auf denen mehrere Versionen der Jenkins-Software über mehrere Ports laufen, und etwas mehr als 60 Hosts, auf denen sowohl eine verwundbare als auch eine nicht verwundbare Version von Jenkins läuft.

In der Abbildung unten sehen wir zum Beispiel einen einzelnen Host, auf dem eine gepatchte Version von Jenkins LTS auf TCP-Port 80, aber eine verwundbare Version auf TCP-Port 9001 läuft.

Identifizierung von Jenkins-Diensten

Mit Censys sind Sie nur eine Suchanfrage davon entfernt, alle laufenden Jenkins-Server im Internet aufzuspüren:

• Dienstleistungen: (software.vendor: jenkins und software.product: jenkins)

Eine der einfachsten Möglichkeiten, nicht nur festzustellen, ob auf einem Host ein Jenkins-Server läuft, sondern auch die genaue Version des laufenden Dienstes zu ermitteln, ist die Analyse der HTTP-Antwort-Header und die Suche nach dem X-Jenkins-Schlüssel, dessen Wert häufig die aktuelle Version des Servers angibt.

Ein Host, auf dem Jenkins läuft.

In den meisten Fällen führt eine HTTP-Anfrage an den Jenkins-Server zu einem 403-Statuscode, der uns als Client darüber informiert, dass der Server eine Authentifizierung erfordert; mit anderen Worten: Wenn Sie diese URL in Ihrem Browser aufrufen, wird ein Anmeldeformular angezeigt.

Derselbe Host, aber in einem Browser.

Aber der obige Screenshot ist nicht die einzige Ansicht, die Sie mit Censys und Jenkins sehen können. Ein Jenkins-Server kann so konfiguriert werden, dass dem allgemeinen Internet ein anonymer/Gast-Zugang gewährt werden kann, wodurch jeder Benutzer die Möglichkeit hat (zumindest) die verschiedenen Jobs und Builds, die derzeit konfiguriert sind, zu sehen.

Wenn Sie die Suchabfrage Censys so abändern, dass sie eine HTML-Titelsuche enthält, können Sie viele Beispiele für Jenkins-Server mit globalem Lesezugriff auf das System finden:

• services: (software.vendor: jenkins und software.product: jenkins und http.response.html_title: "Dashboard [Jenkins]")

Es ist anzumerken, dass viele der gefundenen Jenkins-Server mit Lesezugriff auf das Dashboard nicht unbedingt falsch konfiguriert sind, da viele Open-Source-Projekte Jenkins als Mittel zum Erstellen und Testen ihrer Software verwenden. Aber es ist etwas, das man beachten sollte.

Unterscheidung zwischen Jenkins LTS und Jenkins Release

In dem Advisory wird darauf hingewiesen, dass Jenkins-Versionen bis einschließlich Version 2.441 für dieses CVE anfällig sind. Auf der anderen Seite sind auch Versionen von Jenkins LTS kleiner oder gleich 2.426.2 anfällig. Da es eine kleine Überschneidung zwischen diesen beiden Codebäumen gibt, brauchen wir eine Möglichkeit, einen Jenkins LTS (Long Term Support) Server von einem normalen Jenkins Server zu unterscheiden.

Glücklicherweise enthält der Wert der Version im HTTP-Antwort-Header von X-Jenkins entweder drei Ziffern (Major, Minor, Patch, getrennt durch einen Punkt) für LTS-Versionen und nur zwei Ziffern (Major, Minor, getrennt durch einen Punkt) für Standard-Versionen. Endlich haben wir einmal einen Anbieter, der die semantische Versionierung korrekt durchführt.

Was kann getan werden?

• Beachten Sie den Herstellerempfehlungder besagt, dass Benutzer auf Jenkins 2.442 oder LTS-Version 2.426.3 aktualisieren sollten.
• Verwenden Sie diese Censys Suchanfrage um Jenkins-Server zu finden, die dem Internet ausgesetzt sind.
• Censys ASM-Kunden haben Zugriff auf ein neues Risiko, das potenziell anfällige Jenkins-Server identifiziert (suchen Sie nach "CVE-2024-23897").