Applications, sites et API

Particuliers et entreprises

Injection de commandes système

OS command injection

Une entrée utilisateur devient une instruction exécutée par le système.

Révision éditoriale : 23 septembre 2026Comprendre : 2 min · Cas technique et détails : 4 min

Comprendre et agir

À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.

Une situation concrète

Une application transforme un nom de fichier en commande du système. Si elle mélange ce nom avec les instructions de son interpréteur, une entrée conçue à cet effet peut lui faire lancer autre chose que l’opération prévue.

Comment cela fonctionne

L’injection de commandes fait exécuter des instructions système à travers une application vulnérable. L’attaque hérite des droits du programme qui les lance. Elle peut ainsi lire des fichiers, modifier un service ou installer un autre outil. Elle diffère d’une injection SQL : la cible immédiate est ici le système ou un programme externe, pas le langage de la base de données.

Comment le piège fonctionne

Une donnée devient une commande
L’application prépare une opération système.
Le sens de l’opération est détourné
Interpréteur ou arguments mal maîtrisés.
Le serveur agit pour l’attaquant
Avec les droits de son service.

Ce que vous pouvez faire

Vos premiers réflexes

Gardez les logiciels et appareils à jour. Si un service se comporte anormalement après un envoi de fichier, signalez le contexte ; sa correction relève de l’exploitant.

Si vous êtes responsable du service ou de l’organisation

Développeurs : utilisez une bibliothèque sans interpréteur de commandes lorsque possible. Sinon, séparez et validez les arguments, avec des droits limités pour le service.

Le détail qui change toutUne idée reçue à corriger

Retirer quelques caractères spéciaux ne garantit pas qu’une commande soit construite de façon sûre.

À vous de décider

L’application ne s’exécute pas en administrateur. Une injection de commandes est-elle sans conséquence ?

Choisissez votre réponse et expliquez pourquoi avant de lire la correction.

Voir la réponse expliquée

Non. Le programme peut encore lire ses fichiers, utiliser ses secrets ou joindre d’autres services. L’impact dépend des droits dont il dispose réellement.

Analyser un cas technique

Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.

Étude de cas fictive

Une valeur fournie à l’application devient une commande système

Le défaut apparaît lorsqu’une application construit une commande système à partir d’une donnée reçue. Le shell peut interpréter certains caractères comme des opérateurs et lancer une action supplémentaire. Un nom de fichier attendu comme simple valeur devient alors une partie du langage de commande.

Dans les traces, l’exporteur crée un shell, puis un programme qui ouvre une connexion réseau. Cette succession mérite une investigation si l’exporteur n’a aucune raison métier de le faire. Les noms des processus ne suffisent pas : conserver leurs arguments, identifiants, parents et heures de création. Un même PID peut être réutilisé après la fin d’un processus.

La meilleure correction est souvent de remplacer l’appel système par la bibliothèque qui réalise directement l’opération. Lorsqu’un programme externe reste nécessaire, passer ses arguments séparément évite l’interprétation par le shell. Cela n’empêche toutefois pas qu’une valeur soit prise pour une option du programme : ses règles d’arguments et les chemins autorisés restent à vérifier.

Le compte du service fixe ensuite l’étendue du dommage. Une exécution sans privilèges d’administration peut encore lire des fichiers métier, récupérer des secrets ou contacter d’autres services. L’enquête doit suivre ces accès, et pas uniquement chercher une élévation de privilèges.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape

ClientParamètre non fiable

Service exportIdentité export

InterpréteurProcessus enfant

Ressource systèmeFichiers et réseau

Action
Demande de calcul
Client vers Service export
Trace request=r8
Action
Avant : chaîne transmise au shell
Service export vers Interpréteur
Trace p1 → p2
Action
Exécution hors fonction attendue
Interpréteur vers Ressource système
Trace p3 / connexion
Réponse
Effet indépendant du résultat HTTP
Ressource système vers Service export
Action
Même entrée après correction
Client vers Service export
Action sur place
Calcul par une bibliothèque
Service export
Trace Vérification du traitement
Réponse
Empreinte contrôlée
Service export vers Client

Comment repérer cette attaque

Indices à rechercher

Un serveur lance des interpréteurs ou programmes inattendus.
Un traitement de fichier déclenche des connexions sans rapport avec sa fonction.
Des fichiers ou tâches apparaissent sous l’identité du service.

Repérer les processus enfants d’un service qui lancent un interpréteur ou contactent une destination inattendue pendant un traitement applicatif.

Éléments à croiser

Assembler d’abord les lignes auditd portant le même numéro d’événement. Reconstituer ensuite les processus sur le même hôte et la même période, puis seulement les rattacher au job applicatif.

Limites de l’interprétation

Un interpréteur peut être utilisé légitimement par un traitement. La filiation, les paramètres autorisés et la connexion sortante doivent être confrontés au fonctionnement attendu.

Comment réagir

Fermer la fonction vulnérable et conserver la requête ainsi que l’arbre des processus, en masquant les secrets. Isoler le service selon les conséquences observées. Rechercher les fichiers, accès et tâches créés, puis reconstruire l’environnement si son intégrité ne peut pas être établie. Renouveler les secrets qu’il pouvait lire.

Vérifier la correction

Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.

Les données reçues ne doivent jamais être interprétées par un shell.
Les noms commençant par un marqueur d’option et les chemins inattendus doivent être traités explicitement.
Le traitement corrigé doit produire le résultat attendu avec les droits minimaux.

À vous de raisonner

Le shell a été supprimé et les arguments sont transmis séparément. Pourquoi faut-il encore tester les noms de fichiers commençant par un marqueur d’option ?

Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Le programme appelé peut interpréter une telle valeur comme une option, même sans shell. Vérifiez les règles d’arguments, les chemins acceptés et les droits du service. La séparation des arguments ferme un mécanisme d’injection ; elle ne valide pas automatiquement tous les usages du programme.

Consulter les détails techniques

Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.

Lire les extraits commentés — reconstitution fictive

Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.

guid: Identifiant inventé pour suivre les processus du cas Linux. Ce n’est pas un champ natif auditd ; ne pas y chercher le ProcessGuid de Sysmon Windows.

Arbre causal à examiner

Journal

Événements normalisés fictifs. Les identifiants guid servent ici à suivre les processus Linux ; ils ne sont pas des champs natifs auditd. Les commandes ont été expurgées.

11:02:00Z process host=api-1 guid=p1 image=/srv/exporter user=export
11:02:04Z process host=api-1 guid=p2 parent=p1 image=/bin/sh request=r8
11:02:04Z process host=api-1 guid=p3 parent=p2 image=/usr/bin/curl
11:02:05Z network host=api-1 guid=p3 dst=198.51.100.19:443
11:02:05Z app     host=api-1 request=r8 operation=checksum status=200

Préparer une collecte dans votre environnement

Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.

Linux — auditd
Où les trouver
Sur le serveur concerné, dans le fichier log_file d’auditd, généralement /var/log/audit/audit.log. Les enregistrements SYSCALL, EXECVE et PATH d’un même événement partagent le numéro dans msg=audit(...).
Quoi relever
Rapprocher les événements d’exécution : exe, pid, ppid, uid/auid et arguments EXECVE. Rechercher une filiation inattendue service web → interpréteur de commandes → programme réseau.
Accès et prérequis
Service actif et règles d’audit adaptées avant les faits. Linux n’enregistre pas automatiquement toutes les exécutions et lectures ; les arguments et chemins collectés peuvent être sensibles.
Documentation : Linux — auditd
Service concerné — audit et historique à vérifier
Où les trouver
Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
Quoi relever
Retrouver la requête d’export et le worker qui l’a traitée. Le lien entre identifiant HTTP, tâche et processus doit être prévu par le service ; il n’est pas fourni automatiquement par auditd.
Accès et prérequis
Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Documentation : Service concerné — audit et historique à vérifier

Si vous pensez être concerné

Si vous utilisez le service

Gardez les logiciels et appareils à jour. Si un service se comporte anormalement après un envoi de fichier, signalez le contexte ; sa correction relève de l’exploitant.

Pour l’équipe qui exploite le service

Bloquez le traitement vulnérable et préservez les traces d’exécution.
Évaluez les fichiers, secrets et réseaux accessibles au processus.
Recherchez une persistance avant la remise en service.

Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir

OWASP — OS Command Injection Defense — cheatsheetseries.owasp.org
Python — subprocess, sécurité — docs.python.org