Check the History: Credentials Leaked on the Command Line
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
- Use the history builtin to read a previous user's commands
- Recognise that secrets passed as command-line flags are recorded and exposed
- Triage a freshly obtained shell for low-effort credential wins
- Understand why -p<password> style flags are dangerous
Habilidades testadas
Pré-requisitos
- Basic shell commands (ls, cat)
- Awareness of how databases are accessed
Como funciona
When an attacker (or a pentester) first lands a shell on a machine, the immediate goal is enumeration: cheap wins that expand access. One of the most reliable is shell history. Every interactive shell records the commands a user typed - normally in ~/.bash_history - and the history builtin prints them. Admins run all kinds of commands on a deploy box, and now and then one of them contains a secret.
The dangerous pattern here is a credential passed as a command-line flag. The previous admin connected to the database with mysql -u billing_admin -p'...' -h db-prod, putting the password directly after -p. Anything on the command line is recorded in history and is also visible, while it runs, to anyone who can read the process list with ps. So a single shell - even an unprivileged one - hands over the database password in clear text, which often unlocks far more than the box itself.
The terminal in this challenge behaves like a real shell: you can look around with ls, cat, and friends, but the win is the history builtin. Reading it surfaces the routine deploy commands and, sitting among them, the mysql line with the flag.
Erros comuns
- Only listing files. The secret is not in a file here; it is in the command history. Run
history. - Skimming past the mysql line. The password is inline after
-p- read the whole command, not just the program name. - Submitting the username or host. The question asks for the password value, the part that looks like a flag.
- Assuming an unprivileged shell is useless. History and process lists leak secrets regardless of privilege.
Como se proteger
The defensive rule is simple: never put secrets on the command line. Use a credentials file with tight permissions, an environment variable injected by a secret manager, or interactive prompts - never -p<password>. And rotate anything that has ever been typed inline.
- Pass database credentials via a protected option file or a secret manager, never as a flag.
- Avoid secrets in any command (history and
psboth expose them); prompt interactively instead. - Restrict and rotate credentials, and clear or disable history on sensitive accounts.
