CVE-2024-27198

Falha de bypass de autenticação no componente web do TeamCity On-Premises que permite a um atacante não autenticado, com simples acesso de rede à instância, executar ações administrativas — incluindo criar uma nova conta de admin. É crítica de fato: sem pré-condição de credencial, sem interação do usuário, e virou alvo de exploração em massa dias após a divulgação, incluindo uso por grupos ligados a estados-nação e por operadores de ransomware.

A CISA classifica a falha como CWE-288 (Authorization Bypass Through User-Controlled Key / bypass de autenticação por caminho alternativo). O problema está no componente web do TeamCity On-Premises: o filtro que decide se uma requisição precisa de autenticação compara o caminho da URL contra uma lista de rotas protegidas, mas essa comparação não é equivalente à forma como o servlet container e o roteador interno do TeamCity efetivamente resolvem e despachar o caminho. Isso abre espaço para um atacante manipular o path da requisição de forma que o filtro de autenticação classifique a chamada como não protegida, enquanto o backend a trata como uma rota administrativa válida (endpoints REST, diagnóstico, gestão de usuários).

Essa classe de bug — divergência entre a normalização de path usada no controle de acesso e a usada no roteamento real — é a mesma família de problema que já havia aparecido em CVE-2023-42793, também no TeamCity. O atacante não precisa de nenhuma credencial nem de configuração não padrão: a falha existe no comportamento padrão do produto instalado.

A JetBrains também corrigiu, na mesma leva de 2023.11.4, a CVE-2024-27199 (path traversal não autenticado). As duas foram divulgadas e corrigidas juntas, e relatos de exploração no mundo real mostram atacantes encadeando as duas: usando o bypass de autenticação para alcançar endpoints administrativos e, com isso, criar contas de admin ou plantar configurações de build maliciosas que executam código no servidor.

Vetor é rede: qualquer atacante com acesso HTTP/HTTPS à interface web do TeamCity On-Premises pode tentar o bypass, sem autenticação prévia e sem interação do usuário-vítima (AV:N/AC:L/PR:N/UI:N no vetor CVSS confirma isso). Não há exigência de configuração especial do TeamCity — a instância vulnerável na versão default já está exposta.

Na prática, o abuso relatado consiste em usar o caminho manipulado para acionar endpoints REST administrativos — tipicamente criação de usuário — e assim obter uma conta com privilégio de administrador dentro do TeamCity. A partir daí, o atacante tem controle total sobre pipelines de build: pode criar/alterar build steps, o que na maioria dos ambientes de CI/CD equivale a execução arbitrária de código no servidor de build e, dependendo da topologia, nos agentes conectados e nos artefatos publicados a jusante — um vetor clássico de comprometimento de cadeia de suprimentos de software.

A exploração em massa começou muito rapidamente após a divulgação (Dark Reading e outros veículos documentaram isso na semana seguinte ao patch), com atores variados — de oportunistas criando contas administrativas em instâncias expostas até grupos associados a operações de estado e a ransomware usando o acesso para movimento lateral e persistência. A entrada no catálogo KEV da CISA, com prazo de correção de 2024-03-28 para agências federais dos EUA, reflete essa exploração ativa confirmada, não apenas risco teórico.

A correção é atualizar o TeamCity On-Premises para a versão 2023.11.4 ou posterior — é a única mitigação com efeito comprovado contra o mecanismo da falha. TeamCity Cloud (SaaS) não é afetado porque a JetBrains já opera a versão corrigida no lado servidor.

Para ambientes que não conseguem migrar imediatamente para o build 2023.11.4, a JetBrains publicou, junto com o advisory, um patch de segurança específico para essa vulnerabilidade que pode ser aplicado sem fazer o upgrade completo da versão principal — indicado para quem está em versões LTS mais antigas e precisa de uma janela de mitigação. Isso reduz o risco de quebra de compatibilidade do upgrade completo, mas não substitui a atualização eventual: correções pontuais tendem a cobrir só o vetor conhecido no momento, não a superfície inteira revisada em um release completo.

Restringir o acesso de rede à interface administrativa do TeamCity (não expor a porta HTTP/HTTPS do servidor diretamente à internet, colocando-a atrás de VPN ou allowlist de IP) reduz a superfície de ataque, mas não é substituto do patch — a falha está na lógica de autenticação da aplicação, não em algo que um controle de rede corrija estruturalmente contra um atacante já dentro do perímetro. Monitorar contas de administrador criadas fora do fluxo normal de provisionamento é útil como detecção, não como prevenção.

Procure por criação de contas de usuário com papel administrativo fora do processo normal de onboarding — timestamps de criação sem correlação com atividade humana esperada, nomes de usuário genéricos ou automatizados. Nos logs de acesso web do TeamCity, requisições a endpoints REST administrativos ou de diagnóstico com paths anômalos (variações, sufixos ou caracteres extras que não correspondem ao uso normal da aplicação) são o indício mais direto de tentativa de bypass, mas exigem baseline do tráfego normal da instância para diferenciar ruído de tentativa real.

Como indicador pós-exploração, revise build configurations e build steps recém-criados ou alterados por contas suspeitas, e artefatos de build inesperados — sinal de que o acesso administrativo obtido via bypass foi usado para inserir execução de código na pipeline. Não há uma assinatura única e confiável publicada que cubra todas as variações de exploração observadas; a presença de módulo Metasploit, template Nuclei e PoC pública indica múltiplas variantes de payload circulando, o que torna detecção baseada só em assinatura de rede pouco confiável isoladamente.