ShellShock: Wie viele Systeme sind von der Bash-Sicherheitslücke betroffen?

Die Bash-Sicherheitslücke ShellShock sorgt derzeit in Unternehmen für große Verunsicherung. Aber wie viele Systeme sind davon überhaupt betroffen?

Genauso wie die Heartbleed-Lücke vor einigen Monaten hat auch die inzwischen als ShellShock bekannt gewordene Sicherheitslücke in der Unix-Shell Bash (Bourne-again Shell) unzählige Unternehmen veranlasst, Warnungen und Patches für Bash-Exploits zu veröffentlichen. Anders als bei Heartbleed ist die Bash-Sicherheitslücke dabei vor allem genau deshalb so kritisch, weil sich nicht genau sagen lässt, welche oder wie viele Systeme tatsächlich betroffen sind.

Die ShellShock-Anfälligkeit, offiziell unter der Bezeichnung CVE-2014-6271 bekannt, wird auch bereits aktiv ausgenutzt. Auf Twitter postete ein Security-Forscher einen Link zu einem GitHub-Repository, auf dem entsprechender Schadcode für die Bash-Sicherheitslücke gehostet wird. Zudem veröffentlichte das Australia Computer Emergency Response Team (AusCERT) Berichte über entsprechende Angriffe.

Die Sicherheitslücke in der Bash-Kommandozeile entstehe, so Huzaifa Sidhpurwala von Red Hat in einem Blog-Beitrag, durch die Möglichkeit, speziell erstellte Umgebungsvariablen ungeprüft ausführen zu können. Kurz gesagt erlaubt Bash ganz einfach bestimmte Befehle, indem der Code dafür an das Ende einer Funktion angefügt wird.

Angreifer können die Bash-Sicherheitslücke auf diese Weise sehr einfach ausnutzen, indem eigener Code an eine Funktion angehängt wird, um so die vollständige Kontrolle über ein System zu erlangen. Aus diesem Grund hat die National Vulnerability Database auch entscheiden, die Sicherheitslücke gemäß dem Common Vulnerability Scoring System (CVSS) mit dem Höchstwert 10 zu bewerten.

Mehr noch als die Schwere dieser Lücke, so Security-Experten, sei vor allem die potenzielle Verbreitung das eigentliche Problem – selbst im Vergleich zum Heartbleed-Bug, der Millionen Systeme betrifft, die eine anfällige OpenSSL-Version im Einsatz haben.

Bash-Sicherheitslücke reicht weit über Unix-Systeme hinaus

Bash ist zwar eine Unix-Kommandozeile, die sowohl in den meisten Linux-Distributionen als auch in Apples Mac OS verwendet wird, aber das Problem lässt sich damit leider nicht eingrenzen. Robert Graham zum Beispiel, CEO von Errata Security, hat Unternehmen in einem Blog-Beitrag dazu aufgefordert, nach alten Apache-Versionen, Video-Kameras oder auch IoT-Geräten (Internet of Things) zu suchen, die eine anfällige Bash-Version nutzen – und das wären im Grunde genommen alle Versionen von Bash der letzten zwei Jahrzehnte.

Troy Hunt, ein anderer Security-Experte, schreibt auf seinem Blog, dass die Bash-Sicherheitslücke durchaus auch Windows-Systeme angreifbar machen kann, da sich selbst in den meisten Windows-Architekturen Nicht-Microsoft-Komponenten befinden, die durchaus angreifbar sein können.

Nicht alle betroffenen Systeme sind gleichermaßen angreifbar

Wolfgang Kandek, CTO von Qualys, gibt zu bedenken, dass ShellShock so lange schon existiert und so lange unentdeckt blieb, dass davon wohl sogar mehr als doppelt so viele Systeme betroffen sein dürften als noch bei Heartbleed. Trotzdem heißt das allerdings nicht, dass auch alle von der Bash-Sicherheitslücke betroffenen Systeme auch tatsächlich angegriffen werden können. So ist die Sicherheitslücke zum Beispiel nur für die Angreifer interessant, die sie aus der Ferne ausnutzen. Wenn man bereits Zugriff auf ein System hat, ist die Sicherheitslücke dagegen uninteressant.

ShellShock kann durchaus auch wurmartigen Charakter annehmen und ausführbaren Schadcode von einem System auf weitere verteilen.

Laut Kandek dürfte eine der offensichtlichsten Angriffsvarianten über einen Web-Server ablaufen, der die Ausführung von CGI-Code erlaubt, eine veraltete Funktion, die die meisten Webseiten heute nicht mehr erlauben. Aber selbst wenn dieser Exploit ausgenutzt werden kann: Angreifer bräuchten einen weiteren erfolgreichen Exploit, um auf dem angegriffenen System Root-Zugriff zu erlangen. Für diesen Fall wäre also ein Zero-Day-Exploit oder ähnliches nötig, um ein aktuell gehaltenes System erfolgreich anzugreifen.

Ältere Systeme aber, die bereits für ihre Anfälligkeit bekannt sind, können laut Kandek durchaus übernommen werden, um dort beispielsweise eigenen Code auszuführen oder den Arbeitsspeicher nach sensiblen Daten abzusuchen. In dieser Hinsicht ist ShellShock laut Kandek kritischer als Heartbleed. ShellShock kann durchaus auch wurmartigen Charakter annehmen und ausführbaren Schadcode von einem System auf weitere verteilen wie einst Vobfus und Beebone.

Kasper Lindgaard, Research Director bei Secunia, stimmt mit Kandek darin überein, dass CGI-Module eines Webservers der wahrscheinlichste Angriffsvektor sein dürften, um die Bash-Sicherheitslücke auszunutzen. Um die Einfachheit zu beschreiben, mit der Schadcode auf ein verwundbares System geladen werden kann, verweist er auf Forschung von Errata-CEO Robert Graham, der darin „Ping“-Befehle über CGI-Variablen ausgeliefert hat.

Graham hat alleine über Port 80 um die 3.000 verwundbare Systeme gefunden, merkte dabei aber an, dass sein Scan nichts darüber aussagt, wo genau der Bug besteht. Die Resultate zeigen trotzdem, wie weitverbreitet die ShellShock-Lücke ist und dass wohl noch lange nicht abzusehen ist, wo überall eine Gefahr lauert. Ein durchaus beunruhigender Gedanke, wenn man an die potenzielle Übernahme eines kompletten Systems denkt.

„Es gibt eine ganze Reihe unterschiedlicher Angriffsvektoren, und bisher sind die wenigsten bekannt“, so Lindgaard. „ShellShock mag nicht so viele Nutzer betreffen wie Heartbleed, die Auswirkungen sind aber weitaus kritischer.

Unternehmen gegen ShellShock absichern

Die große öffentliche Aufmerksamkeit, die durch die Bash-Sicherheitslücke entstanden ist, hat zu vielen Patches betroffener Anbieter geführt, darunter zum Beispiel CentOS, Debian, Ubuntu oder Red Hat. Aber die Lücke ist nicht so einfach zu schließen, was man auch daran sieht, dass Red Hat nach dem ersten Patch einen zweiten nachschieben musste, weil der erste nicht ausreichte.

Für Lindgaard sind Red Hat und die anderen Anbieter kalt überrascht worden und konnten deshalb in der Kürze der Zeit einfach nicht alle Angriffsvektoren auf einmal abdecken. Unternehmen könnten daher einfach abwarten, bis alle betroffenen Systeme aktualisiert wurden. Lindgaard rät in diesem Fall daher dazu, eine komplette Risikoanalyse durchzuführen, um genau festzustellen, wo überall Anfälligkeiten bestehen.

Nach dieser kompletten Systemanalyse, so Lindgaard und Kandek übereinstimmend, könnten Unternehmen abhängig von Kompatibilität und Funktionalität relativ einfach Bash gegen eine alternative Kommandozeile austauschen. Alleine in Linux gibt es drei Alternativen.

Daniel Ingevaldson, CTO von Easy Solutions, stimmt zwar prinzipiell zu, dass das Aktualisieren mit Patches der ideale Weg wäre, die Sicherheitslücke zu schließen. Allerdings sollten Unternehmen auch nicht zu lange warten, vor allem dann, wenn Anbieter möglicherweise gar kein Update mehr veröffentlichen werden.

In diesem Fall rät er IT-Abteilungen, Log-Vorgänge zu überwachen, da ein Exploit-Versuch dann per URL oder HTTP-Header erfolgen würde und somit recht einfach zu beobachten sei. Im Gegensatz dazu sei ein Heartbleed-Exploit weitaus schwieriger zu entdecken. Diese einfache Möglichkeit, Bash-Exploits zu entdecken, sei laut Ingevaldson möglicherweise der einzige Silberstreifen am Horizont.

Folgen Sie SearchSecurity.de auch auf Facebook, Twitter und Google+!

Artikel wurde zuletzt im September 2014 aktualisiert

Erfahren Sie mehr über Anwendungs- und Plattformsicherheit

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close