stuub/rcity-cve-2024-27198CVE-2024-27198 & CVE-2024-27199 PoC - RCE, Erstellung von Admin-Konten, Benutzer-Enumeration, Serverinformationen
Ausnutzung von CVE-2024-27198 & CVE-2024-27199
RCity ist ein Python-Skript, das mit einem verwundbaren TeamCity-Server interagiert. Die CVE ermöglicht die Erstellung unbefugter Admin-Konten und umgeht 403-Fehler auf der Domain. Gleichzeitig wird über den Debug/Processes-Pfad auch RCE erreicht.
Um das Skript zu verwenden, musst du die URL des Ziel-TeamCity-Servers als Befehlszeilenargument mit dem Argument -t oder --target angeben:
python3 RCity.py -t http://teamcity.com:8111
Du kannst die Ausführlichkeit der Ausgabe mit der Option -v oder --verbose erhöhen:
python3 RCity.py -t http://teamcity.com:8111 --verbose
Du kannst Einzelbefehle direkt über die Option -c oder --command senden. Wenn du eine interaktive Shell möchtest, verwende diese Option NICHT. Sie ist nicht mit Reverse-Shells kompatibel, da die Verbindung geschlossen wird, nachdem der Befehl gesendet wurde:
python3 RCity.py -t http://teamcity.com:8111 -c id
Du kannst sicherstellen, dass keine POST-Anfragen an den TeamCity-Server gesendet werden, indem du die Option -s oder --stealth verwendest.
python3 RCity.py -t http://teamcity.com:8111 -s
Deaktiviert die RCE-Funktion – alles andere bleibt gleich
python3 RCity.py -t http://teamcity.com:8111 --no-rce
Verhindert das Sammeln der Benutzerliste; kann bei größeren Benutzerlisten zeitaufwendig sein. Überspringe damit direkt zu RCE!
python3 RCity.py -t http://teamcity.com:8111 --no-enum
Erstellung von Admin-Konten
Remote-Codeausführung
Generieren von Autorisierungs-Tokens
Aufzählen von Benutzern
Sammeln aller privaten Auth-Tokens der Benutzer
Sammeln von Serverdetails
Hier gehe ich die in diesem Projekt verwendeten Funktionen durch, um dir hoffentlich ein besseres Verständnis für diesen Exploit und die damit verbundenen Schwachstellen zu vermitteln.
Die Natur der Schwachstelle hängt sowohl mit CVE-2024-27198 als auch mit CVE-2024-27199 zusammen, da das Problem durch denselben Authentifizierungs-Bypass für REST-API-Routen in JetBrains-TeamCity-Servern entsteht. Der Impact der besagten Schwachstelle ist jedoch der Punkt, an dem sie sich unterscheiden und es interessant wird ... CVE-2024-27198 ist auf dem Papier das eigentliche Schwergewicht, da der offengelegte Impact RCE ist. Sie nutzt den Endpunkt /app/rest/debug/processes – NUR mit den Berechtigungen, die notwendigen Anfragen an diesen Endpunkt zu stellen, und zwar über ein Auth-Token. Dieser Aufruf an diesen Endpunkt unterscheidet sich zwischen Unix- und Windows-Hosts, wird aber ähnlich manipuliert. Der einzige Unterschied ist die native Shell, die für eine Anfrage angesprochen wird.
Linux - processes?exePath=/bin/sh¶ms=-c¶ms={yourRCE_HTMLEncoded}
Windows - processes?exePath=cmd.exe¶ms=/c¶ms={yourRCE_HTMLEncoded}
Nun, wie bereits erwähnt – das ist ohne Authentifizierung nicht möglich, sollte also sicher sein ... oder? Genau hier kommt der Auth-Bypass ins Spiel.
Das Umgehen der Richtlinie des TeamCity-Builds eröffnet die Möglichkeit, Anfragen an den Server zu stellen und dort unser Auth-Token zu hinterlegen, ohne technisch gesehen ein eigenes Konto zu benötigen.
Der Bypass selbst erzeugt einen alternativen Pfad zu REST-Routen, der – ohne zu sehr ins Detail zu gehen – die Kontrolle über Inhalte in einer Klasse erfordert, deren Aufgabe es ist, Anfragen zu verarbeiten, insbesondere solche, die keine 302 (Weiterleitungen) sind. Dadurch können wir die Kontrolle übernehmen, indem wir 3 notwendige Teile an unsere URL anhängen.
Ein nicht authentifizierter Endpunkt, der keine 302 auslöst, in unserem Fall /hax
Ein URL-Query-Parameter namens jsp, um die API-Routen abzufragen, zum Beispiel den Pfad users mit ?jsp=/app/rest/users
Ein beliebiger URI-Pfad, der auf .jsp endet. Dies kann erreicht werden, indem ein HTTP-Pfadparameter-Segment ;.jsp angehängt wird.
Das bedeutet, das endgültige Payload für unbefugte Anfragen an den Users-Endpunkt lautet: /hax?jsp=/app/rest/users;.jsp
Jetzt können wir Anfragen an den Users-Endpunkt stellen und unsere eigenen Benutzer hinzufügen, sogar Administratoren!
Bevor wir jedoch zu RCE übergehen können, benötigen wir ein Auth-Token als Träger für unsere RCE-Anfragen an deren REST-API. Kein Problem – jetzt, wo wir unseren Bypass haben, erstellen wir einfach eines!
Der Token-Endpunkt folgte demselben Pfadbaum wie im vorherigen Beispiel; er ist unter /app/rest/users/id:{user_id}/tokens/{token_name} zu finden. Lass uns also ein weiteres Payload erstellen, um die Authentifizierung zu umgehen und ein Token zu erzeugen!
(Wir geben dafür unseren eigenen Token-Namen an; bei diesem Skript handelt es sich um eine zufällige Erzeugung alphanumerischer ASCII-Zeichen).
/hax?jsp=/app/rest/users/id:{user_id}/tokens/{token_name};.jsp
Nachdem wir unsere POST-Anfrage gesendet haben, um unser Token zu unserem neu erstellten Benutzer hinzuzufügen, können wir nun Anfragen an die Route /app/rest/debug/processes stellen!
Es gibt nichts Besonderes beim Erstellen unserer RCE-Payloads – führe einfach eine HTML-Encodierung deiner Payloads im params-Argument durch!
Viel Spaß beim Hacken!
https://nvd.nist.gov/vuln/detail/CVE-2024-27198
https://github.com/W01fh4cker/CVE-2024-27198-RCE
Dieses Skript ist ausschließlich für Bildungszwecke bestimmt. Verwende es verantwortungsvoll und nur auf Systemen, auf die du zugreifen darfst.