Login
Login-Name Passwort


 
Newsletter
Werbung

Do, 29. Oktober 2015, 15:00

Shell Command Injection – Wie fremder Text in das Terminal gelangt

Man möchte sicher nicht, dass ein Fremder einen Befehl in das Terminal eingibt. Und doch kann es genau dazu kommen, wenn Skripte auf dem System Sicherheitslücken aufweisen, die es einem Angreifer erlauben, beliebigen Schadcode auszuführen. Eine dieser Sicherheitslücken ist die sogenannte »Shell Command Injection« oder auch »Shell Injection«, über die in diesem Artikel informiert werden soll.

Angriffsszenario

Es geht um Text. Nichts anderes als Text. Klingt langweilig? Nein, keinesfalls. Den Weg des Textes vom Angreifer zum Kommandozeileninterpreter, der Shell, dem Terminal oder der Konsole zu verfolgen ist eine mitunter spannende Angelegenheit, die man am besten gleich einmal an einem Beispiel ausprobiert, anstatt lange zu theoretisieren.

Man versetze sich in die Rolle des Angreifers, der ein Kommando auf einen PC einschleusen will. Ein E-Mailprogramm soll in diesem Szenario eine Sicherheitslücke aufweisen, die ausgenutzt wird. Angenommen, das E-Mailprogramm wäre in Python geschrieben und verwendet zur Dateivorschau von Anhängen das dazu vorgesehene Standard-Pythonmodul »MailCap«.

Hinweis: Da ein vollständiger Quellcode eines E-Mailprogramms diesen Artikel sprengen würde, wird in dem unten stehenden Beispiel der Dateiname DATEINAME fest einprogrammiert. Normalerweise käme der Dateiname über den Angreifer in das Programm. Ein Abschnitt des Python-Mailprogramms sähe somit in dem stark vereinfachten Beispiel so aus:

import mailcap, os
d=mailcap.getcaps()
DATEINAME="';ls;#';ls;#.mp4"
cmd,m=mailcap.findmatch(d, "audio/mpeg4", filename=DATEINAME)
os.system(cmd)

Hinweis: Das harmlose Kommando ls dient in diesem Beispiel als Platzhalter für das bösartige Kommando des Angreifers. Das Semikolon ; trennt zwei Befehle voneinander, das Rautezeichen # kommentiert den hinteren Teil aus.

Erklärung der Lücke

Das Pythonmodul mailcap sucht hier mit getcaps() nach einem Programm zur Dateivorschau für die mp4-Datei in DATEINAME. Es liefert in cmd ein Kommando zurück, das man mit os.system(cmd) an die Shell gibt, um das zum Dateityp passende Anzeigeprogramm zu starten.

So weit, so gut. Wo ist nun das Problem, wird man sich fragen? Sieht doch alles ganz normal aus bis vielleicht auf den merkwürdigen Dateinamen ';ls;#';ls;#.mp4. Schaut man sich die Sache genauer an, so erkennt man bald, dass hier der DATEINAME einfach mit einem anderen Text zusammenkopiert wird.

Es wird mit mailcap.findmatch() zunächst geschaut, wie das Kommando zum Ansehen einer mp4-Datei lautet. Das könnte dann je nach verwendeter Linux Distribution entweder vlc '%s' oder aber vlc %s lauten. (VLC wird hier beispielhaft als Viewer benutzt. Auf manchen System ist es mplayer, Totem oder ein ganz anderes Programm.)

Nun wird DATEINAME anstelle von %s eingesetzt, was zu einer der beiden Kommandozeilen in der Variable cmd führt:

> print cmd
vlc '';ls;#';ls;#.mp4'  # Variante 1
vlc ';ls;#';ls;#.mp4    # Variante 2

Unabhängig davon, welche der beiden Kommandozeilen zum Tragen kommt, wenn dieser »blind« zusammenkopierte Text mit os.system(cmd) auf eine Kommandozeile gerät, so wird nicht nur VLC ausgeführt, sondern ungewollt auch noch das aktuelle Verzeichnis mit ls ausgegeben.

Dass VLC dabei eine Fehlermeldung ausgibt, ist dem Angreifer hierbei gleichgültig, denn es wurde von ihm bereits erfolgreich das Kommando ls in die Shell injiziert.

Hinweis: Wer das (in dem Fall harmlose) Verhalten testen möchte, kann entweder mittels python eine Python-Konsole öffnen und den Code ausführen oder speichert den Code in einer Datei und ruft diese per python shell_code_injection_1.py auf. Nach dem Schließen von VLC sieht man die Ausgabe des aktuellen Verzeichnisses in der Shell.

Dies war es, was hier zu beweisen war. Indem der Dateiname vom Angreifer einfach entsprechend präpariert wurde, kann ein beliebiges Kommando beim E-Mailempfänger ausgeführt werden, obwohl sich dieser die angehängte Datei doch nur hat ansehen wollen. Der Inhalt der Datei spielt hierbei keine Rolle, es ist der Text des Dateinamens der den Schadcode enthält.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung