Verifique o Histórico: Credenciais Vazadas na Linha de Comando
O desafio
Você conseguiu um shell numa máquina de deploy como usuário 'deploy'. O admin anterior foi descuidado na linha de comando. Olhe ao redor, depois verifique o que ele digitou - um comando vaza uma credencial. Envie a senha do banco de dados (no formato HDNA{...}).
O que você vai aprender
- Usar o comando interno history para ler os comandos de um usuário anterior
- Reconhecer que segredos passados como flags na linha de comando ficam registrados e expostos
- Triar um shell recém-obtido em busca de credenciais fáceis de encontrar
- Entender por que flags no estilo -p<senha> são perigosas
Habilidades testadas
Pré-requisitos
- Comandos básicos de shell (ls, cat)
- Noção de como bancos de dados são acessados
Como funciona
Quando um atacante (ou um pentester) obtém um shell numa máquina pela primeira vez, o objetivo imediato é a enumeração: vitórias fáceis que ampliam o acesso. Uma das mais confiáveis é o histórico do shell. Todo shell interativo registra os comandos digitados por um usuário, normalmente em ~/.bash_history, e o comando interno history os exibe. Admins rodam todo tipo de comando numa máquina de deploy, e de vez em quando um deles contém um segredo.
O padrão perigoso aqui é uma credencial passada como flag na linha de comando. O admin anterior se conectou ao banco de dados com mysql -u billing_admin -p'...' -h db-prod, colocando a senha diretamente após -p. Qualquer coisa na linha de comando é registrada no histórico e também fica visível, enquanto o comando roda, para quem conseguir ler a lista de processos com ps. Assim, um único shell, mesmo sem privilégios, entrega a senha do banco de dados em texto aberto, o que geralmente destrava muito mais do que a própria máquina.
O terminal deste desafio se comporta como um shell real: você pode olhar ao redor com ls, cat e afins, mas a solução está no comando interno history. Ao lê-lo, aparecem os comandos de deploy de rotina e, entre eles, a linha do mysql com a flag.
Erros comuns
- Apenas listar arquivos. O segredo aqui não está num arquivo; está no histórico de comandos. Rode
history. - Passar batido pela linha do mysql. A senha está inline logo após
-p, leia o comando inteiro, não só o nome do programa. - Enviar o usuário ou o host. A pergunta pede o valor da senha, a parte que parece uma flag.
- Supor que um shell sem privilégios é inútil. O histórico e a lista de processos vazam segredos independentemente do nível de privilégio.
Como se proteger
A regra defensiva é simples: nunca coloque segredos na linha de comando. Use um arquivo de credenciais com permissões restritas, uma variável de ambiente injetada por um gerenciador de segredos, ou prompts interativos, nunca -p<senha>. E rotacione tudo que já foi digitado inline.
- Passe as credenciais do banco de dados via um arquivo de opções protegido ou um gerenciador de segredos, nunca como flag.
- Evite segredos em qualquer comando (histórico e
psexpõem ambos); use prompts interativos em vez disso. - Restrinja e rotacione as credenciais, e limpe ou desative o histórico em contas sensíveis.
