Dipl.-Inform. Carsten Eilers

Los ging das alles mit der Veröffentlichung einer von Stéphane Chazelas entdeckten Schwachstelle in der GNU Bourne Again Shell Bash mit der CVE-ID CVE-2014-6271. Die kurze Beschreibung der Schwachstelle, die damals noch keinen Namen hatte, klang schon relativ beängstigend:

"Stephane Chazelas discovered a vulnerability in bash, related to how environment variables are processed: trailing code in function definitions was executed, independent of the variable name.

In many common configurations, this vulnerability is exploitable over the network.

Chet Ramey, the GNU bash upstream maintainer, will soon release official upstream patches."

Eine über das Netzwerk, im schlimmsten Fall also das Internet, ausnutzbare Schwachstelle, die die Ausführung beliebiger Befehle erlaubt ist ganz, ganz schlecht. Vor allem im Vergleich zur anderen "berühmten" Schwachstelle dieses Jahres, dem Heartbleed-Bug in OpenSSL. Denn darüber können "nur" vertrauliche Informationen wie die privaten Schlüssel von SSL-Zertifikaten, Zugangsdaten und ähnliches ausgespäht werden. Und das nicht gezielt, sondern der Angreifer muss nehmen, was er gerade bekommt. Und trotzdem kam es durch die Schwachstelle zum Beispiel zu einem Angriff auf den US-Krankenhausbetreiber Community Health Systems (CHS) in Tennessee, bei dem große Datenmengen ausgespäht wurden: Die Angreifer hatten über Heartbleed die VPN-Zugangsdaten ausgespäht und dann über das VPN auf das lokale Netz von CHS zugegriffen. Wenn man jetzt bedenkt, dass über die Bash-Schwachstelle sofort beliebige Befehle ausgeführt werden können, ist das doch sehr beängstigend.

Prinzipiell sind alle Unix-artigen Systeme von der Schwachstelle betroffen. Unter anderen ist die Bash in allen Linux-Distributionen und auch Mac OS X enthalten, auf allen anderen Unixen und den *BSD-Systeme kann sie installiert werden.

Die technischen Details

Nach Ablauf der Embargo-Frist wurde eine vorab an betroffene Kreise gesendete Vorankündigung samt einiger technischer Details offiziell veröffentlicht.

Zu diesem Zeitpunkt waren vom Bash-Maintainer bereits Patches veröffentlicht worden.

Die Bash kann nicht nur Shell-Variablen, sondern auch Shell-Funktionen über das Environment an (indirekte) Child-Prozesse exportieren. Aktuelle Versionen verwenden dazu eine Environment-Variable mit dem Funktionsnamen als Namen und der mit "() {" beginnenden Funktionsdefinition als Variablenwert. Die Schwachstelle besteht darin, dass die Bash die Auswertung nach der Funktionsdefinition nicht beendet, sondern auf die Funktionsdefinition folgende Shellbefehle parst und ausführt.

Zum Beispiel führt das Setzen der Environment-Variable

  VAR=() { ignored; }; /bin/id

dazu, dass beim Import des Environments in den Bash-Prozess /bin/id ausgeführt wird. Der Prozess befindet sich dabei zwar in einem undefinierten Zustand, zum Beispiel kann es sein dass die PATH-Variable noch nicht gesetzt ist, und unter Umständen stürzt die Shell nach der Ausführung von /bin/id ab, der Schaden ist dann aber bereits eingetreten.

Mögliche Angriffsvektoren

Die große Gefahr der Schwachstelle besteht darin, dass eine Environment-Variable mit beliebigen Namen als "Träger" einer bösartigen Funktionsdefinition mit angehängten Befehlen dienen kann. Als erster Haupt-Angriffsvektor wurden HTTP-Requests an CGI-Skripte identifiziert.

Ein HTTP-Request sieht typischerweise so aus:

GET /path?query-parameter-name=query-parameter-wert HTTP/1.1
Host: www.demo.example
Custom: custom-header-wert

Die CGI-Spezifikation speichert alle Teile der Anfrage in Environment-Variablen. Im Fall des Apache httpd kann der "Magic String" "() {" in folgenden Feldern auftreten:

• Host ("www.demo.example", als Environment-Variable REMOTE_HOST)
• Header-Werten ("custom-header-wert", im Beispiel als HTTP_CUSTOM)
• Server-Protokoll ("HTTP/1.1", als SERVER_PROTOCOL)

Außerdem gibt es noch eine ganze Reihe weiterer möglicher Angriffspunkte, da viele weitere vom Benutzer manipulierbare Parameter ebenfalls in Environment-Variablen gespeichert werden.

Wird das CGI-Skript mit der Bash verarbeitet, wird das Environment importiert, die über den Header eingeschleuste Funktionsdefinition ausgewertet und die angehängten Befehle ausgeführt.

Weitere mögliche Angriffsvektoren sind

• OpenSSH (durch die AcceptEnv Variablen, TERM oder SSH_ORIGINAL_COMMAND),
• Git- und Subversion-Installationen, die den sshd mit ForceCommand verwenden
• Apache-Server mit mod_cgi oder mod_cgid, die für die Bash geschriebenen CGI-Skripte verwenden oder Subshells erzeugen. Subshells werden implizit von system/popen in C, os.system/os.popen in Python, system/exec in PHP (im CGI-Modus) und bei Verwendung einer Shell von open/system in Perl verwendet.
  Mit mod_php ausgeführte PHP-Skripte sind dagegen nicht betroffen.
• DHCP-Clients, die Shellskripte zur Konfiguration verwenden und dabei Parameter von einem möglicherweise bösartigen Server übernehmen
• Verschiedene Daemons und SUID/privilegierte Programme, die Shell-Skripte mit von einem Angreifer manipulierbaren Environment-Variablen ausführen.
• Jedes Programm, dass unter einer Shell läuft oder Shell-Skripte mit der Bash als Interpreter ausführt.
  Nicht betroffen sind Shell-Skripte, die keine Variablen exportieren.
• Unter Linux-Systemen, in denen /bin/sh ein symbolischer Link zu /bin/bash ist, kann jeder Aufruf von popen()/system() innerhalb einer Webanwendung gefährlich sein, da über die HTTP-Header die HTTP_*-Variablen des Environments gesetzt werden.

Unter Mac OS X erlaubt die Schwachstelle das Erlangen von root-Rechten (Privilegieneskalation).

Der Patch reicht nicht aus

Im Laufe des Tages wurde festgestellt, dass der Patch die Schwachstelle nicht vollständig behebt. Die sich dadurch ergebende neue Schwachstelle erhielt die CVE-ID CVE-2014-7169.

RedHat hat einen Test veröffentlicht, mit dem geprüft werden kann, ob ein System von einer der Schwachstellen betroffen ist.

Wie viele Server sind betroffen?

Robert Graham von Errata Security hat im Internet einen Scan nach angreifbaren Servern gestartet. Sein Skript sendet dazu Requests an die Server, die als Cookie-, Host- und Referer-Header den Wert

() { :; }; ping -c 3 IP-Adresse

enthalten. Ist ein Server von der ShellShock-Schwachstelle betroffen und landet einer der Header in einer Bash, wird ein Ping an die IP-Adresse gesendet. Das ist die Adresse von Grahams Server, wo ein Skript die eintreffenden Pings zählt. Leider enthielt das einen Fehler und hörte ziemlich früh auf zu zählen. Bis zum Auftritt des Fehlers wurden 3.000 auf Port 80 betroffene Systeme gezählt.

Mal abgesehen davon, dass nur die ersten 3.000 Server überhaupt gezählt wurden, erfasst der Test bei weitem nicht alle betroffenen Server. Denn es werden nur die Server als betroffen erkannt, die zufällig auf der Root-Seite einen oder mehrere der drei getesteten HTTP-Header mit einem Bash-Skript verarbeiten, und die auch bei nicht korrekt gesetzten Host-Feld korrekt antworten (was laut Robert Graham nur 1 von 50 Servern macht). Es gibt mit Sicherheit noch sehr viele weitere Server, in denen tiefer in der Webanwendung versteckte Skripte und andere Parameter betroffen sind. Robert Graham nennt als Beispiel dafür das Skript /cgi-sys/defaultwebpage.cgi von CPanel.

Robert Graham hält die Schwachstelle für "wormable", also von einem Wurm ausnutzbar. Und ich fürchte, da hat er recht. Alles, was ein Cyberkrimineller tun muss, ist eine Liste betroffener Skripte und Parameter erstellen, und schon kann ein Wurm sich auf den Weg machen und von jeden infizierten Rechner aus nach weiteren angreifbaren Rechnern suchen. Er muss dann ja nur noch pro Server die Liste mit angreifbaren Skripten etc. durch gehen. Übrigens wetten laut Mikko Hypponen von F-Secure Teilnehmer der Virus Bulletin 2014 Conference darauf, wann ein Wurm auftaucht. Wohlgemerkt: Wann - nicht ob.

Inzwischen verwenden Cyberkriminelle Robert Grahams Testcode zur Verbreitung von Schadsoftware. Die von ihm bei seinem Scan entdeckten Server dürften also inzwischen kompromittiert sein, sofern sie nicht in der Zwischenzeit gepatcht wurden.

Die Schwachstelle von Welt hat heutzutage einen Namen!

Irgendwann im Laufe dieses ersten Tages hat jemand den Namen ShellShock geprägt. Wer, wieso, weshalb, warum weiß ich nicht. Aber seit Heartbleed kommt eine Schwachstelle, die etwas auf sich hält, nicht mehr ohne Namen aus. Und ohne Logo, aber dafür war es noch zu früh.

Und damit geht der erste Tag auch zu Ende. Aber Sie wissen ja: Schlimmer geht immer. Hier erfahren Sie, was am 25. September rund um ShellShock passiert ist.

Carsten Eilers

---

Übersicht über alle Artikel zum Thema

Alles, was Sie über ShellShock wissen müssen

ShellShock - Die Schwachstellen und Angriffsvektoren

ShellShock - Die Angriffe

ShellShock - Chronologie und Details: Tag 1 - Der 24. September 2014

ShellShock - Chronologie und Details: Tag 2 - Der 25. September 2014

ShellShock - Chronologie und Details: Tag 3 - Der 26. September 2014

ShellShock - Chronologie und Details: Tag 4 - Der 27. September 2014

ShellShock - Chronologie und Details: Tag 6 - Der 29. September 2014

ShellShock - Chronologie und Details: Tag 8 - Der 1. Oktober 2014