Vérifiez l'historique : identifiants divulgués en ligne de commande
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
- Utiliser la commande intégrée history pour lire les commandes d'un utilisateur précédent
- Reconnaître que les secrets passés en argument de ligne de commande sont enregistrés et exposés
- Trier un shell fraîchement obtenu pour trouver rapidement des identifiants
- Comprendre pourquoi les options du type -p<mot de passe> sont dangereuses
Compétences testées
Prérequis
- Commandes shell de base (ls, cat)
- Notions sur l'accès aux bases de données
Comment ça marche
Quand un attaquant (ou un pentester) obtient un shell sur une machine pour la première fois, l'objectif immédiat est l'énumération : des gains faciles qui étendent l'accès. L'un des plus fiables est l'historique du shell. Chaque shell interactif enregistre les commandes tapées par un utilisateur - normalement dans ~/.bash_history - et la commande intégrée history les affiche. Les admins lancent toutes sortes de commandes sur une machine de déploiement, et de temps en temps l'une d'elles contient un secret.
Le schéma dangereux ici est un identifiant passé comme argument de ligne de commande. L'admin précédent s'est connecté à la base de données avec mysql -u billing_admin -p'...' -h db-prod, plaçant le mot de passe directement après -p. Tout ce qui figure sur la ligne de commande est enregistré dans l'historique et reste aussi visible, pendant son exécution, par quiconque peut lire la liste des processus avec ps. Ainsi, un simple shell, même non privilégié, livre le mot de passe de la base de données en clair, ce qui débloque souvent bien plus que la machine elle-même.
Le terminal de ce challenge se comporte comme un vrai shell : vous pouvez regarder autour de vous avec ls, cat et consorts, mais la clé est la commande intégrée history. La lire fait apparaître les commandes de déploiement de routine et, au milieu d'elles, la ligne mysql avec le flag.
Erreurs fréquentes
- Se contenter de lister les fichiers. Le secret n'est pas dans un fichier ici, il est dans l'historique des commandes. Lancez
history. - Survoler la ligne mysql. Le mot de passe est en ligne après
-p, lisez la commande entière, pas seulement le nom du programme. - Soumettre le nom d'utilisateur ou l'hôte. La question demande la valeur du mot de passe, la partie qui ressemble à un flag.
- Supposer qu'un shell non privilégié est inutile. L'historique et la liste des processus fuitent des secrets quel que soit le niveau de privilège.
Comment s'en protéger
La règle défensive est simple : ne jamais mettre de secrets sur la ligne de commande. Utilisez un fichier d'identifiants avec des permissions restreintes, une variable d'environnement injectée par un gestionnaire de secrets, ou des invites interactives, jamais -p<password>. Et faites tourner tout ce qui a un jour été tapé en clair sur la ligne de commande.
- Transmettez les identifiants de base de données via un fichier d'options protégé ou un gestionnaire de secrets, jamais en argument.
- Évitez les secrets dans toute commande (l'historique et
psles exposent tous les deux) ; préférez une invite interactive. - Restreignez et faites tourner les identifiants, et effacez ou désactivez l'historique sur les comptes sensibles.
