Pivot vers la base de données : mouvement latéral SSH depuis un serveur web
Le défi
Vous avez un shell sur web01, le serveur web public. La base de données est sur une autre machine, joignable seulement depuis l'intérieur. Trouvez le passage, rebondissez dessus et lisez le secret que la base cache.
Ce que tu vas apprendre
- Comprendre qu'un point d'ancrage sur un serveur web public est rarement l'objectif - les vraies données se trouvent sur des hôtes internes segmentés vers lesquels il faut pivoter.
- Lire une configuration client SSH (~/.ssh/config) pour découvrir l'hôte suivant, l'utilisateur avec lequel se connecter et la clé privée exacte qui vous authentifie.
- Utiliser une clé privée découverte pour s'authentifier sur un hôte interne sans mot de passe, la clé elle-même remplaçant le mot de passe.
- Comprendre pourquoi les sauvegardes de base de données (sorties de mysqldump) constituent un butin de grande valeur, contenant souvent en clair des secrets que la base de données en production protège.
- Cartographier un réseau interne à partir d'artefacts déjà présents sur la machine : entrées de /etc/hosts, fichiers de configuration de l'application et entrées de known_hosts.
Compétences testées
Prérequis
- Être à l'aise dans un shell Unix (cd, ls, cat) et savoir lire les dotfiles d'un répertoire personnel.
- Connaissance de base du fonctionnement de l'authentification SSH par clé (clé privée côté client, clé publique côté serveur).
Comment ça marche
Le mouvement latéral est l'étape qui suit la première intrusion. On atterrit rarement à l'endroit où se trouvent les données de valeur. Ici, vous démarrez en tant que www-data sur web01, un serveur web exposé publiquement. La base de données est délibérément placée sur une machine séparée qui n'accepte les connexions que depuis l'intérieur du réseau, ce qui la rend invisible depuis l'extérieur. Tout l'enjeu consiste à trouver le pont que les opérateurs de l'application ont déjà construit entre les deux machines.
Erreurs fréquentes
- Traiter le serveur web comme la destination finale. Le flag ne se trouve jamais sur
web01- s'arrêter là et grepper la racine web à la recherche d'un secret gaspille tout le temps imparti. - Ignorer le répertoire
~/.ssh. La configuration client, la clé privée et l'entrée known_hosts vous donnent ensemble l'hôte, l'utilisateur et le moyen de vous connecter - les ignorer revient à deviner des IP et des noms d'utilisateur au hasard. - Essayer de forcer un mot de passe ou d'en fournir un à
ssh. Avec une clé de déploiement en place, aucun mot de passe n'existe : la clé est l'identifiant. - Oublier que la base de données elle-même peut rester verrouillée pendant que sa sauvegarde révèle tout. Après le pivot, le butin se trouve dans un fichier de dump en texte clair, pas derrière une connexion à la base de données en production.
Comment s'en protéger
La cause profonde est une clé privée présente sur un hôte accessible et exposé sur Internet. Une clé sur web01 est un pivot qui n'attend qu'à se produire : quiconque y prend pied hérite d'un accès sans mot de passe directement vers la machine de base de données. Les clés utilisées pour le déploiement ne devraient jamais résider sur les serveurs que les attaquants atteignent en premier : émettez-les depuis un pipeline de déploiement contrôlé, donnez à chacune la portée la plus restreinte possible (une commande forcée, un seul hôte, pas de shell interactif) et faites-les tourner selon un calendrier régulier.
Le second échec consiste à traiter une sauvegarde de base de données comme moins sensible que la base elle-même. Le dump contenait des secrets en clair que la base en production aurait protégés. Les sauvegardes méritent les mêmes contrôles que les données de production.
- Segmentez la base de données pour que seul un compte de service applicatif, et non un administrateur interactif, puisse y accéder, et appliquez cette limite au niveau réseau, pas seulement par convention.
- Restreignez la portée des clés SSH avec les directives
command=etfrom=dans authorized_keys ; préférez des certificats de courte durée aux clés privées de longue durée. - Chiffrez les sauvegardes au repos, stockez-les hors de l'hôte de base de données et limitez qui peut les lire.
- Ne jamais commiter ni déployer de clés privées avec le code applicatif ou dans la racine web.