Was ist Command Injection?

Eine Command-Injection-Schwachstelle entsteht, wenn eine Anwendung nicht vertrauenswürdige Eingaben in einen Betriebssystembefehl einsetzt. Angreifer ergänzen Shell-Steuerzeichen oder Argumente und lassen das System Befehle ausführen, die der Entwickler nie vorgesehen hat. Abhängig vom Dienstkonto können sie Dateien lesen, Daten verändern oder den Server vollständig übernehmen.

Der Fehler findet sich häufig in Funktionen, die externe Werkzeuge aufrufen: Bildkonvertierung, Archivverarbeitung, Netzwerkdiagnose oder administrative Skripte. Command Injection steht in engem Zusammenhang mit Remote Code Execution, ist aber nur ein konkreter Weg zur Ausführung von Code.

Wie lässt sich Command Injection verhindern?

• - Shell-Befehle vermeiden, wenn eine Bibliothek oder eng begrenzte API dieselbe Aufgabe erfüllt.
• - Argumente über sichere Prozess-APIs übergeben, statt einen Befehlsstring zusammenzubauen.
• - Eingaben mit einer strengen Positivliste prüfen und unerwartete Optionen oder Steuerzeichen ablehnen.
• - Die Anwendung mit minimalen Betriebssystemrechten ausführen und riskante Verarbeitung isolieren.

Codebeispiel: Shell-String oder sichere Prozessargumente

Verwundbar:

$host = $_POST['host'];
$result = shell_exec('ping -c 1 ' . $host);

Sicherer Ansatz mit Symfony Process:

$host = filter_var($_POST['host'], FILTER_VALIDATE_IP);
if ($host === false) {
    throw new InvalidArgumentException('Ungültige IP-Adresse');
}

$process = new Process(['/bin/ping', '-c', '1', $host]);
$process->setTimeout(3);
$process->run();

Das Argument-Array umgeht die Shell. Die Typprüfung verhindert zusätzlich Options-Injection, beispielsweise Werte, die mit einem Bindestrich beginnen. Wo möglich ist eine Netzwerkbibliothek noch besser als der Aufruf eines Betriebssystemprogramms.

Warum reicht Escaping allein häufig nicht aus?

Escaping-Regeln unterscheiden sich je nach Shell, Betriebssystem und Argumentkontext. Ein Filter, der nur einige bekannte Zeichen sperrt, ist deshalb schnell unvollständig. Die Shell vollständig aus dem Datenpfad zu entfernen ist deutlich robuster.

Wie läuft ein Angriff typischerweise ab?

1. Der Angreifer findet einen Parameter, der erkennbar an ein Systemwerkzeug übergeben wird, etwa eine IP-Adresse für einen Ping oder einen Dateinamen für eine Konvertierung.
2. Mit ungefährlichen Sonderzeichen, zusätzlichen Optionen oder Zeitverzögerungen prüft er, ob die Eingabe die Befehlsstruktur beeinflusst.
3. Nach einem erfolgreichen Nachweis untersucht er Rechte, erreichbare Dateien, Umgebungsvariablen und Netzwerkverbindungen des Prozesses.
4. Gestohlene Zugangsdaten oder eine nachgeladene Reverse Shell können den ersten Fehler zu einer dauerhaften Systemübernahme erweitern.

Command Injection oder Argument Injection?

Bei einer klassischen Command Injection fügt der Angreifer neue Befehle oder Shell-Konstrukte ein. Bei einer Argument Injection bleibt das aufgerufene Programm gleich, erhält aber zusätzliche Optionen. Auch das kann kritisch sein: Manche Werkzeuge lesen mit einer Option beliebige Dateien, schreiben Ausgaben an frei wählbare Orte oder stellen Netzwerkverbindungen her. Eine Prozess-API ohne Shell verhindert Shell-Steuerzeichen, aber nicht automatisch gefährliche Programmargumente. Deshalb müssen auch erlaubte Optionen und Werte begrenzt werden.

Wie wird die Schwachstelle getestet und erkannt?

Ein Test betrachtet Query-Parameter, Formulare, JSON, Header und gespeicherte Werte, die später in Jobs verarbeitet werden. Zeitbasierte Nachweise oder kontrollierte DNS-Anfragen sind häufig sicherer als Befehle, die Dateien verändern. Im Code sind String-Verkettungen rund um Funktionen wie exec, system oder Prozess-Builder besonders relevant. Im Betrieb weisen unerwartete Kindprozesse, auffällige Kommandozeilen und ausgehende Verbindungen eines Webservers auf Missbrauch hin.

Welche Folgen sind realistisch?

Der unmittelbare Zugriff entspricht zunächst den Rechten des betroffenen Prozesses. Bereits ein niedrig privilegierter Webserver liest aber häufig Anwendungskonfigurationen, API-Schlüssel und Datenbankzugänge. Root-Prozesse, eingebundene Docker-Sockets oder weitreichende Cloud-Rollen erhöhen den Schaden erheblich. Least Privilege, isolierte Worker und restriktive ausgehende Verbindungen begrenzen die Reichweite, während die unsichere Befehlsausführung im Code behoben werden muss.