{"id":1568,"date":"2014-09-26T10:14:31","date_gmt":"2014-09-26T08:14:31","guid":{"rendered":"https:\/\/www.psw-group.de\/blog\/?p=1568"},"modified":"2025-11-20T11:13:14","modified_gmt":"2025-11-20T10:13:14","slug":"shellshock-schwachstelle-macht-betriebssysteme-angreifbar","status":"publish","type":"post","link":"https:\/\/www.psw-group.de\/blog\/shellshock-schwachstelle-macht-betriebssysteme-angreifbar\/","title":{"rendered":"ShellShock: Schwachstelle macht Betriebssysteme angreifbar"},"content":{"rendered":"

Eine Sicherheitsl\u00fccke in der Unix-Shell Bash<\/strong> bedroht insbesondere Webserver und kann dazu ausgenutzt werden, beliebige Schadcodes aus dem Netz auszuf\u00fchren<\/strong>. Entdeckt wurde die Sicherheitsl\u00fccke vom Entwickler Stephane Chazelas. Nun handelt es sich bei Bash um die Quasi-Standard-Shell der meisten Unix-Systeme<\/strong> \u2013 und damit fast aller Linux-Distributionen sowie Mac OS. Auf anderen Unix-Systemen ist die Shell oftmals nachinstalliert worden. Kurzum: Die Schwachstelle betrifft fast jeden Nutzer!<\/strong><\/p>\n

<\/p>\n

Wie arbeitet ShellShock?<\/h2>\n

Entwickler Chazelas fand heraus, dass \u00fcber die Sicherheitsl\u00fccke ShellShock Code in Umgebungsvariablen eingef\u00fcgt werden kann, der beim Neustart einer Shell ausgef\u00fchrt wird. Bash wird auf Unix-Systemen in etlichen Situationen genutzt und so ist schwer absehbar, wo Angreifer die L\u00fccke ausnutzen und Code ausf\u00fchren. Die Bash-L\u00fccke ShellShock wurde bereits zum Verbreiten von Malware<\/a> ausgenutzt<\/strong>; die erste Schnellkorrektur seitens der Entwickler waren offenbar unvollst\u00e4ndig. Experten sch\u00e4tzen das Ausma\u00df der Sicherheitsl\u00fccke als \u00e4hnlich gravierend ein wie Heartbleed<\/a><\/strong>. Die offizielle ID der Sicherheitsl\u00fccke ist CVE-2014-6271 <\/a>\u2013 die NIST-CVE-Datenbank stuft die Sicherheitsl\u00fccke mit einer maximalen Gef\u00e4hrlichkeit<\/strong> ein.<\/p>\n

Das Kernproblem an der Sicherheitsl\u00fccke ist die Bash-Funktionalit\u00e4t, die es erlaubt, Funktionen in beliebigen Variablen zu definieren<\/strong>. Der Name der Variablen ist dabei unerheblich. So wird hinter der Definition einer Funktion ungepr\u00fcft weiterer Code ausgef\u00fchrt<\/strong> \u2013 sogar, wenn die Funktion selbst gar nicht aufgerufen wird. Diese Tatsache macht das Ausnutzen von ShellShock so einfach und damit schwerwiegend.<\/p>\n

Fehler ist 20 Jahre alt<\/h3>\n

Schon seit mehr als 20 Jahren steckt der Fehler im Bash-Code<\/strong>: Chet Ramey, momentaner Bash-Hauptautor, ver\u00f6ffentlichte Patches f\u00fcr mehrere alte Bash-Versionen<\/strong> \u2013 sogar eine f\u00fcr die antiquierte Version 2.05b<\/a>. Problematisch sind insbesondere CGI-Skripte auf Webservern, wie eine Analyse von RedHat<\/a>, die vier Angriffsszenarien mit ShellShock auflistet, zeigt. Einige CGI-Skripte sind direkt in Bash geschrieben, w\u00e4hrend diverse Programmiersprachen mit dem Systemstart Bash mit aufrufen. Auch SSH-Shells<\/strong>, die sich auf bestimmte Befehle beschr\u00e4nken, sind gef\u00e4hrlich. Solche Begrenzungen, die vor allem von Git- und DVS-Servern genutzt werden, lassen sich via ShellShock aushebeln. F\u00fcr Clientrechner kann es problematisch werden<\/strong>, wenn DHCP-Clients Bash aufrufen und dabei Variablen setzen, die \u00fcber den DHCP-Server kontrolliert werden k\u00f6nnen. Derzeit ist die Liste m\u00f6glicher Angriffsszenarien sicher noch nicht vollst\u00e4ndig, weil Bash fast \u00fcberall mitwirkt.<\/p>\n

Andere Shells sind nicht betroffen \u2013 Verwirrung gab es bei zahlreichen Nutzern, als sie Testcodes ausf\u00fchrten und Verwundbarkeitsmeldungen auch unter anderen Shells erhielten<\/strong>. Dies l\u00e4sst sich damit erkl\u00e4ren, dass der Testcode, der in zahlreichen Berichterstattungen, beispielsweise bei heise.de<\/a>, angegeben wird, Bash aufruft \u2013 unabh\u00e4ngig davon, aus welcher Shell gestartet wird. Embedded-Ger\u00e4te d\u00fcrften vielfach dadurch gerettet sein, dass keine anderen Shells betroffen<\/strong> sind. Wenngleich Linux auf etlichen Ger\u00e4ten und Routern zum Einsatz kommt, k\u00f6nnen Sie diesbez\u00fcglich beruhigt sein \u2013 in aller Regel setzt man auf Shells, die ressourcenschonender sind als Bash.<\/p>\n

Korrigierte Bash-Version fehlerhaft \u2013 experimenteller Patch<\/h3>\n

Kurz nachdem \u00fcber ShellShock berichtet wurde, twitterte Tavis Ormandy<\/a>, Entwickler bei Google, einen Beispielcode. Dieser verwirrte offenbar den Funktionsparser in der korrigierten Version. Ormandy konnte dies zwar nicht ausnutzen, aber es kam zum Vorschein, dass das eigentliche Problem in der Bash-Korrektur nicht behoben wurde<\/strong>. Noch existiert kein offizielles Bash-Update<\/strong>, aber einen experimentellen Patch; auf der Mailingsliste oss-security<\/a> zu finden. Eben dieser wird bereits f\u00fcr einige Linux-Distributionen ausgeliefert.<\/p>\n

 <\/p>\n

Auf ShellShock testen<\/h2>\n

Um zu testen, ob auch Sie von der Sicherheitsl\u00fccke ShellShock betroffen sind<\/strong>, k\u00f6nnen Sie diesen Befehl eingeben:<\/p>\n

test=\"() { echo Hello; }; echo gehackt\" bash -c \"\"<\/pre>\n
Sie sind betroffen, wenn der String „gehackt“ ausgegeben wird. Mit dem folgenden Beispiel-Bash-Code k\u00f6nnen Sie testen, ob Sie den ersten fehlerhaften Fix erhalten haben:<\/p>\n
X='() { function a a>\\' bash -c echo; [ -e echo ] && echo \"gehackt\"<\/pre>\n
Informieren Sie sich weiterf\u00fchrend \u00fcber Testtools, werden Sie unweigerlich auch \u00fcber Online-Tools<\/strong> stolpern. Diese arbeiten allerdings nicht sonderlich zuverl\u00e4ssig<\/strong>: Theoretisch k\u00f6nnte jede einzelne Datei auf Ihrem Server betroffen sein. Es gibt zahlreiche Variablen, die das Unterbringen von Code erlauben. Hinzu kommt, dass das Testen fremder Server rechtlich eine Grauzone ist, da Code auf fremden Servern ausgef\u00fchrt wird. Haben Sie Fragen zu ShellShock<\/strong>, antworten unsere Security-Experten Ihnen gerne! Stellen Sie Ihre Fragen in den Kommentaren oder nehmen Sie Kontakt zu unserem Support<\/a> auf.<\/p>\n