Details zur Bash-Sicherheitslücke Exploit-Szenarien für Shellshock

Die Shellshock getaufte Schwachstelle in der „Bourne Again Shell“ (Bash) ruft allerhand Sicherheitsexperten auf den Plan. Beim Fix, der in der vergangenen Woche herausgegeben worden war, ist Nacharbeit notwendig. Wolfang Kandek vom Sicherheitsspezialisten Qualys weiß, unter welchen Umständen gefährdete Systeme wirklich anfällig sind.

Anbieter zum Thema

FTAPI Software GmbH

Das vergangene Woche veröffentlichte Bash-Update umfasste leider nicht alle potenziellen Exploit-Vektoren. Diesem erweiterten Problem wurde die neue CVE-2014-7169 zugewiesen. In einem Github-Eintrag wurde derweil ein Exploit-Versuch dokumentiert, bei dem diese Schwachstelle zum Herunterladen von Malware ausgenutzt wird.

Die Bourne Again Shell ist der Standard-Kommandozeileninterpreter für Linux sowie zahlreiche andere Unix-Versionen und daher weithin im Einsatz. Für sich allein genommen ist Shellshock allerdings erst einmal nicht so gravierend. Schließlich handelt es sich um eine lokale Anfälligkeit – und Bash ist ein Kommandozeileninterpreter, dessen einziger Zweck darin besteht, Befehle auszuführen.

Wer nun meint, es sei alles nicht so tragisch, der irrt allerdings. Wir müssen uns ansehen, wie Bash verwendet wird. In der gewöhnlichen Form als Kommandozeileninterpreter sind die Angriffsvektoren zwar tatsächlich recht geringfügig. Jedoch wird Bash sehr oft zur Ausführung von Befehlen in einer vernetzten Konstellation verwendet. Dies eröffnet einen interessanten Angriffsvektor.

Shellshock-Angriffe in der Praxis

Man stelle sich einen Webserver vor, der eine IP-Adresse anpingen kann (mein Router zu Hause verfügt zum Beispiel über diese Funktion). Der Server wird dann höchstwahrscheinlich einfach das Executable „Ping“ mit dem Argument aufrufen, das angegeben wurde, wobei er vermutlich überprüft, ob das Argument korrekt als IP-Adresse formatiert ist.

Shellshock erlaubt es aber, beliebige Befehle auszuführen lassen, sofern ein Angreifer den Wert einer mitgegebenen Umgebungsvariablen manipulieren kann. Eine solche Manipulation ist nicht allzu schwierig. Zahlreiche Umgebungsvariablen lassen sich kontrollieren, etwa die Einstellungen für den Referrer oder den UserAgent. Szenarien, in denen ein CGI-BIN-Setup zur Ausführung von Befehlen auf dem Server verwendet wird, sind dementsprechend anfällig.

RedHat hat eine erweiterte Liste mit Konstellationen veröffentlicht, in denen Bash in einem Remote-Kontext verwendet wird. Daraus lässt sich ersehen, dass diese Sicherheitslücke das Potenzial zu einem großflächigen Problem hat, ähnlich wie Heartbleed im April. Einige der seinerzeit involvierten Sicherheitsforscher, darunter @ErrataRob, haben bereits Internet-weite Scans gestartet, um nach anfälligen Servern zu suchen:

• Apache Server, die mod_cgi oder mod_cgid aktiviert haben, sind betroffen, wenn die CGI-Skripte entweder in Bash programmiert wurden oder eigene Subshells öffnen. Solche Subshells werden in C implizit von system/popen aufgerufen, in Python von os.system/os.popen, in PHP (wenn es im CGI-Modus läuft) von system/exec und in Perl von open/system, wenn eine Shell verwendet wird (was vom Befehlsstring abhängt)

• ForceCommand wird in sshd-Konfigurationen verwendet, um entfernten Benutzern einschränkte Möglichkeiten zur Befehlsausführung zu geben. Die Sicherheitslücke kann ausgenutzt werden, um diese Einschränkungen zu umgehen und die Ausführung beliebiger Befehle zu ermöglichen. Manche Git- und Subversion-Implementierungen verwenden solche eingeschränkten Shells. Bei regulärer Verwendung ist OpenSSH dagegen nicht betroffen, weil die Benutzer bereits Shell-Zugriff haben.

• DHCP-Clients rufen Shell-Skripte zur Konfiguration des Systems mit Werten auf, die potenziell von einem bösartigen Server stammen können. Auf diese Weise könnten auf dem DHCP-Client-Rechner beliebige Befehle ausgeführt werden, in der Regel mit Root-Rechten.

• Verschiedene Daemons und SUID-/privilegierte Programme können Shell-Skripte aufrufen und dabei Umgebungsvariablen auslesen, deren Werte vom Benutzer festgelegt/manipuliert werden können, was die Ausführung beliebiger Befehle ermöglichen würde.

• Potenziell gefährdet ist auch jede andere Anwendung, die an eine Shell angehängt ist oder die mit Shell-Skripten arbeitet, die Bash als Interpreter nutzen. Shell-Skripte, die keine Variablen exportieren, sind für dieses Problem nicht anfällig, selbst wenn sie ungeprüfte Inhalte verarbeiten und in (nicht exportierten) Shell-Variablen und offenen Subshells speichern.

Achten Sie auf Bash-Patches Ihrer Anbieter und spielen Sie sie so schnell wie möglich ein. In einigen dieser Szenarien (CGI-BIN) kann eventuell eine andere Shell als schneller und leicht zu implementierender Workaround verwendet werden. Im Übrigen ist es nach momentanem Stand der Dinge nicht möglich, die Qualys-Scanner über die Bash-Sicherheitslücke auszunutzen.

* Wolfgang Kandek ist Chief Technical Officer bei Qualys.

(ID:42977732)