De NFS à root : analyse de la machine Sloink sur HackTheBox
Lorsqu’un partage NFS mal configuré expose des répertoires système sensibles, même un compte utilisateur restreint peut devenir une passerelle vers une compromission plus profonde. C’est exactement ce qui s’est produit sur la machine Sloink de HackTheBox, où une combinaison d’exports NFS ouverts, de sauvegardes PostgreSQL exposées et d’une restriction de shell oubliée a permis à un testeur de passer d’un accès non authentifié à un contrôle total en tant que root.
La première brèche : la mauvaise configuration NFS
La reconnaissance initiale a révélé deux partages NFS accessibles à tous les utilisateurs : /home et /var/backups. Tous deux étaient exportés avec des paramètres trop permissifs, permettant aux attaquants de monter et de lire des fichiers sensibles. Parmi les données exposées figuraient des archives de sauvegarde PostgreSQL générées chaque minute ainsi que des historiques de commandes shell des utilisateurs. Un fichier a particulièrement attiré l’attention : /home/service/.psql_history, qui enregistrait une commande de connexion à l’utilisateur superutilisateur PostgreSQL via un socket Unix.
Identifiants et tunnels : franchir les barrières
Le shell de l’utilisateur service était restreint à /bin/false, bloquant l’accès direct par SSH. Cependant, l’historique .bash_history exposé confirmait des connexions régulières à PostgreSQL. En exploitant la faille d’échappement root NFS — une fonctionnalité de certains serveurs NFS permettant aux utilisateurs de sortir de leur partage désigné — les attaquants ont extrait /etc/passwd et /etc/shadow. Les hachages utilisaient l’algorithme yescrypt, ralentissant les tentatives de force brute, ce qui a recentré l’attention sur les données NFS.
Une astuce a consisté à créer un utilisateur local avec le même UID que le compte service (1337), offrant un accès au répertoire personnel restreint. Cela a révélé le chemin du socket Unix PostgreSQL (/var/run/postgresql/.s.PGSQL.5432) et confirmé l’habitude de l’utilisateur de se connecter à la base de données en tant qu’administrateur.
Exploitation de la base de données et élévation de privilèges
Sans disposer des identifiants du superutilisateur PostgreSQL, les attaquants ont pivoté vers un accès réseau. Ils ont établi un tunnel via le compte SSH pour atteindre directement le socket Unix PostgreSQL. Une fois connectés, ils ont exploité la fonctionnalité COPY FROM PROGRAM — normalement utilisée pour importer des données — afin d’exécuter des commandes arbitraires en tant qu’utilisateur postgres, obtenant ainsi une exécution de code à distance.
La phase finale a profité d’une tâche cron s’exécutant en tant que root, qui copiait périodiquement l’intégralité du répertoire de données PostgreSQL, appartenant à l’utilisateur postgres. En plaçant un binaire bash avec bit SUID dans ce répertoire, l’attaquant a attendu que la tâche cron s’exécute, transformant instantanément son accès en privilèges root.
Sloink illustre comment des mauvaises configurations en couches — notamment dans les systèmes de fichiers partagés et les services de bases de données — peuvent créer des chemins d’attaque inattendus. Des contrôles d’accès stricts sur les exports NFS et une gestion sécurisée des connexions superutilisateur PostgreSQL auraient pu empêcher cette chaîne de compromission.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.