Check the History: Credentials Leaked on the Command Line
Le défi
Vous avez obtenu un shell sur une machine de déploiement en tant qu'utilisateur 'deploy'. L'admin précédent a été négligent en ligne de commande. Regardez autour, puis vérifiez ce qu'il a tapé - une commande fuite un identifiant. Soumettez le mot de passe de la base de données (de la forme HDNA{...}).
Ce que tu vas apprendre
- 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
Compétences testées
Prérequis
- Basic shell commands (ls, cat)
- Awareness of how databases are accessed
Comment ça marche
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.
Erreurs fréquentes
- 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.
Comment s'en protéger
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.
