O Token Nomeia o Host: Recon a Partir de um JWT de Serviço Capturado
O desafio
Você capturou um JWT de serviço para serviço numa rede interna. Ele deveria ser opaco, mas o payload de um JWT é apenas base64 e decodifica sem nenhuma chave. Uma de suas claims nomeia discretamente um sistema interno com o qual o serviço pode falar. Decodifique o payload na bancada e envie esse nome de host interno.
O que você vai aprender
- Entender que o payload de um JWT decodifica para claims em texto puro sem precisar de chave
- Identificar as claims iss, aud e scope em um token de serviço
- Extrair um hostname interno da claim audience
- Explicar como tokens capturados vazam inteligência sobre o ambiente
- Reconhecer por que tokens de serviço devem ter vida curta e ser enviados por canais criptografados
Habilidades testadas
Pré-requisitos
- Um JWT é composto por três partes em base64url: header, payload e signature
- Claims padrão como iss e aud carregam o emissor e o destinatário (audience)
Como funciona
Autenticação serviço a serviço costuma usar JWTs e, como qualquer JWT, o payload é codificado em base64url, não criptografado. Qualquer pessoa que capture o token (farejando tráfego interno, lendo um log ou extraindo-o de uma configuração) pode decodificar as claims instantaneamente, sem precisar de chave.
Decodificar esse token resulta em {"iss":"auth.acme","aud":"vault.internal.acme","scope":"read"}. Claims padrão são uma mina de ouro para recon: iss (issuer) nomeia o servidor de autenticação, scope sugere o que o portador pode fazer, e aud (audience) nomeia o serviço para o qual o token se destina. Aqui a audience é vault.internal.acme, um hostname interno que um atacante externo não teria outra forma de descobrir. Essa única string revela que existe um cofre de segredos, como ele se chama e que existe um caminho até ele na rede.
Nenhuma falsificação é necessária para esse tipo de vazamento. O valor de um token capturado está em parte no acesso que ele concede e em parte na inteligência que ele carrega: hostnames, endpoints, ids de conta e escopos que mapeiam o ambiente para o próximo movimento.
Erros comuns
- Tratar o token como criptografado. É base64, decodifique diretamente, sem precisar de chave ou quebra.
- Ler o issuer em vez da audience.
isséauth.acme; o host interno que você quer é a claimaud. - Adicionar um esquema ou caminho. A resposta é o hostname puro
vault.internal.acme, não uma URL. - Tentar forjar o token. Esta é uma tarefa de recon somente leitura; nada precisa ser alterado.
Como se proteger
Assuma que qualquer claim em um token de serviço pode ser lida por quem o interceptar e minimize o que ele revela.
- Transmita tokens apenas por TLS, para que não possam ser capturados diretamente do tráfego de rede.
- Mantenha tokens de serviço com vida curta e escopo restrito, para que um token capturado se torne inútil rapidamente.
- Evite colocar hostnames internos sensíveis ou pistas de topologia em claims onde um identificador opaco seria suficiente.
- Monitore tokens usados a partir de origens inesperadas, o que pode indicar uma captura e reprodução (replay).