Pivot to the Database: SSH Lateral Movement from a Web Server
Le défi
Vous avez un shell sur web01, le serveur web public. La base de donnees est sur une autre machine, joignable seulement depuis l'interieur. Trouvez le passage, rebondissez dessus et lisez le secret que la base cache.
Ce que tu vas apprendre
- Recognize that a foothold on a public web server is rarely the goal - the real data lives on segmented internal hosts you must pivot toward.
- Read an SSH client config (~/.ssh/config) to discover the next host, the user to log in as, and the exact private key that authenticates you.
- Use a discovered private key to authenticate to an internal host without a password, since the key itself replaces the password.
- Understand why database backups (mysqldump output) are high-value loot that often contain plaintext secrets the live database protects.
- Map an internal network from artifacts already on the box: /etc/hosts entries, app config files, and known_hosts records.
Compétences testées
Prérequis
- Comfort moving around a Unix shell (cd, ls, cat) and reading dotfiles in a home directory.
- Basic familiarity with how SSH key-based authentication works (private key on the client, public key on the server).
Comment ça marche
Lateral movement is the step after the first break-in. You rarely land where the valuable data sits. Here you start as www-data on web01, a public-facing web server. The database is deliberately placed on a separate box that only accepts connections from inside the network, so it is invisible from the outside. The whole challenge is finding the bridge that the application's own operators already built between the two machines.
Erreurs fréquentes
- Treating the web server as the destination. The flag is never on
web01- stopping there and grepping the web root for a secret wastes the whole budget. - Ignoring the
~/.sshdirectory. The client config, the private key, and the known_hosts entry together hand you the host, the user, and the means to log in - skipping them leaves you guessing IPs and usernames. - Trying to brute-force a password or supply one to
ssh. With a deploy key in place, no password exists - the key is the credential. - Forgetting that the database itself can stay locked while its backup leaks everything. After pivoting, the loot is in a plain-text dump file, not behind a live database login.
Comment s'en protéger
The root cause is a private key sitting on a reachable, internet-facing host. A key on web01 is a pivot waiting to happen: anyone who lands there inherits a passwordless route straight onto the database box. Keys used for deployment should never live on the servers attackers reach first - issue them from a controlled deploy pipeline, give each one the narrowest possible scope (a forced command, a single host, no interactive shell), and rotate them on a schedule.
The second failure is treating a database backup as less sensitive than the database. The dump contained secrets in clear text that the running database would have guarded. Backups deserve the same controls as production data.
- Segment the database so only an application service account - not an interactive admin user - can reach it, and enforce that boundary at the network layer, not just by convention.
- Scope SSH keys with
command=andfrom=restrictions in authorized_keys; prefer short-lived certificates over long-lived private keys. - Encrypt backups at rest, store them off the database host, and restrict who can read them.
- Never commit or deploy private keys alongside application code or web roots.