Applications, sites et API

Particuliers et entreprises

Injection de commandes système

OS command injection

Une application traite une donnée reçue comme une commande du système.

Révision éditoriale : 29 octobre 2026Comprendre : 2 min · Cas technique et détails : 5 min

Comprendre et agir

Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.

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

Une injection de commandes permet à un attaquant de faire exécuter des instructions au système à travers une application vulnérable. Ces instructions disposent des droits du programme qui les lance. Elles peuvent lire des fichiers, modifier un service ou installer un outil. Ici, l’attaque vise le système ou un programme externe ; dans une injection SQL, elle vise les instructions destinées à 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

Utilisez, si possible, une bibliothèque qui évite l’interpréteur de commandes. Si un programme externe est nécessaire, séparez et validez ses arguments et limitez les droits du service.

Un point à vérifierUne idée reçue à corriger

Enlever quelques caractères spéciaux ne suffit pas à garantir qu’une commande soit construite sans danger.

À vous de décider

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

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

Non. Même sans être administrateur, le programme peut lire ses fichiers, utiliser ses secrets ou contacter d’autres services. Ses droits réels déterminent les conséquences.

Analyser un cas technique

Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».

Étude de cas fictive

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

L’application construit ici une commande système avec une donnée reçue. Un nom de fichier, qui devait rester une simple valeur, est interprété par le shell comme une partie de la commande. Certains caractères peuvent alors déclencher une action supplémentaire.

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.

Quelles informations comparer

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.

Ce que ces indices ne permettent pas de conclure

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

L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.

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 ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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

Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.

Lire les extraits commentés (reconstitution fictive)

Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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

Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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 comprendre votre situation et trouver de l’aide : 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