Pivotando por Três Hosts para Recuperar um Token do Cofre e a Flag
O desafio
Você tem um ponto de apoio no web01 dentro de uma rede interna. Um cofre de segredos está em algum lugar na mesma sub-rede, mas você não consegue alcançá-lo diretamente. Escaneie a rede, pivote pelo host intermediário com a chave que encontrar, recupere o token do cofre e leia a flag que o cofre retorna.
O que você vai aprender
- Mapear uma sub-rede interna com nmap para encontrar hosts e portas acessíveis
- Identificar e reutilizar uma chave privada SSH vazada para pivotar para outro host
- Recuperar um token de serviço a partir das notas de deploy e do histórico de um host
- Autenticar em uma API HTTP com um header de token para ler um segredo
- Explicar por que a segmentação de rede sozinha falha quando chaves e tokens vazam
Habilidades testadas
Pré-requisitos
- Familiaridade com ssh, nmap, curl e comandos básicos de shell
- Entender como uma chave privada SSH autentica um login
- Saber que um token de API é passado em um header da requisição
Como funciona
Redes internas reais são em camadas. O host onde você chega primeiro raramente é o host que guarda o prêmio - ele é um trampolim. Aqui o web01 fica na DMZ e consegue falar com a camada de aplicação, mas o cofre de segredos no vault03 só aceita requisições que já carregam um token válido, e esse token deveria viver na camada de aplicação, nunca no node web. O desafio é ir de onde você está até onde o segredo está.
O primeiro movimento é o reconhecimento. O nmap no segmento 10.0.0.0/24 revela três hosts ativos: seu ponto de apoio, o app02 com SSH aberto na 22, e o vault03 com a API do cofre na 8200. Atacar o cofre diretamente retorna 403 missing client token - você consegue alcançá-lo na rede, mas não tem credencial. O caminho a seguir é o host intermediário, e a chave para ele está no disco: uma chave privada de deploy em /var/www/deploy/.ssh/id_rsa que autentica como deploy@app02.
Depois de pivotar com ssh -i, a camada de aplicação entrega a peça que faltava. O runbook de deploy no app02 documenta a chamada exata da API, token incluído: curl -H "X-Vault-Token: s.7Hk2mQ9pZ" http://10.0.0.30:8200/v1/secret/data/flag. O histórico do shell confirma que o operador executou da mesma forma. Repetir essa requisição de dentro da camada de aplicação retorna a flag. Todo o exercício é uma cadeia - escanear, pivotar, roubar o token, autenticar - onde cada elo só fica acessível depois do anterior.
Erros comuns
- Tentar fazer curl no cofre a partir do web01. O cofre responde
403 missing client tokenali - você precisa do token, e o token nunca fica no node web. - Pular o escaneamento de rede. Sem o
nmapvocê não sabe que o app02 tem SSH aberto nem que o vault03 sequer existe; chutar desperdiça todo o exercício. - Ignorar a chave SSH no disco. A chave de deploy em
/var/www/deploy/.ssh/id_rsaé o único caminho para o app02 - o pivô é obrigatório, não opcional. - Esquecer o header do token. Um
curlsimples para o cofre ainda falha no app02; a requisição precisa carregarX-Vault-Tokenpara ser autorizada.
Como se proteger
A segmentação atrasou o atacante, mas não o impediu, porque as chaves e tokens que atravessam os segmentos ficaram legíveis. As correções reforçam cada elo da cadeia:
- Nunca armazene uma chave privada SSH de longa duração em um diretório web legível por qualquer um - emita credenciais SSH de curta duração, baseadas em certificado, restritas a um único jump host.
- Mantenha tokens do cofre fora das notas de deploy e do histórico do shell - injete-os em tempo de execução e use TTLs curtos para que um token vazado expire rapidamente.
- Restrinja o cofre para aceitar tokens apenas de identidades de cliente aprovadas, não de qualquer um na sub-rede que tenha a string.
- Monitore SSH lateral e leituras incomuns no cofre para que um pivô da DMZ até a camada de aplicação dispare um alerta.
Trate qualquer token encontrado em disco ou no histórico como comprometido: revogue-o, rotacione a chave de deploy e revise o que aquela identidade conseguia alcançar.
