Anzeige
Inzwischen sind verschiedene Logos für Shellshock im Umlauf.
Inzwischen sind verschiedene Logos für Shellshock im Umlauf. (Bild: shellshocker.net)

Bash-Lücke: Die Hintergründe zu Shellshock

Inzwischen sind verschiedene Logos für Shellshock im Umlauf.
Inzwischen sind verschiedene Logos für Shellshock im Umlauf. (Bild: shellshocker.net)

Inzwischen wird die Bash-Sicherheitslücke Shellshock zur Verbreitung von Malware ausgenutzt. Die erste Korrektur war offenbar unvollständig. Wir haben die wichtigsten Hintergründe zu Shellshock zusammengefasst.

Sie hatte zwar zunächst keinen eingängigen Namen und kein Logo, aber die jüngste Sicherheitslücke in der Kommandozeile Bash ist nach Ansicht vieler Fachleute ebenso dramatisch einzuschätzen wie der inzwischen berühmte Heartbleed-Bug. Inzwischen wird sie fast überall als Shellshock bezeichnet, ihre offizielle ID ist CVE-2014-6271, in der CVE-Datenbank des NIST wurde die Lücke mit der maximalen Gefährlichkeit von zehn Punkten eingestuft.

Anzeige

Kern des Problems ist eine Funktionalität von Bash, bei der in beliebigen Variablen direkt Funktionen definiert werden können. Dabei ist es egal, wie die Variable heißt. Der entdeckte Fehler führt dazu, dass hinter einer solchen Funktionsdefinition weiterer Code ungeprüft ausgeführt wird, auch dann, wenn die entsprechende Funktion überhaupt nicht aufgerufen wird.

Das führt weiterhin dazu, dass das Ausnutzen der Sicherheitslücke extrem einfach ist. Bei verwundbaren Webanwendungen würde hierfür ein simpler Aufruf von Curl oder Wget mit geeigneten Parametern ausreichen.

Selbst 20 Jahre alte Versionen betroffen

Der Fehler steckt schon seit über 20 Jahren im Bash-Code. Der momentane Hauptautor von Bash, Chet Ramey, hat Patches für diverse alte Bash-Versionen veröffentlicht, auf Nachfrage sogar für die uralte Version 2.05b. Bash wird unter den meisten Linux-Systemen und unter Mac OS X als Standardshell verwendet. Die meisten BSD-Derivate nutzen andere Shells, die nicht betroffen sind. Doch auch dort ist Bash meist installiert, und es ist denkbar, dass einzelne Programme oder Skripte Bash nutzen. Debian nutzt Bash zwar als Standardshell für Nutzer, Skripte werden aber mit Dash ausgeführt, so dass Angriffe ebenfalls sehr unwahrscheinlich sind.

Die Möglichkeiten, diese Sicherheitslücke auszunutzen, sind vielfältig. Eine Analyse von RedHat listet bereits vier verschiedene Szenarien auf, in denen Shellshock zum Problem werden kann. Das größte Problem stellen CGI-Skripte auf Webservern dar. Dabei gibt es verschiedene Szenarien, in denen Bash aufgerufen werden kann. Zum einen gibt es CGI-Skripte, die direkt in Bash geschrieben sind. Zum anderen rufen verschiedene Programmiersprachen bei Systemaufrufen Bash auf.

Das zweite gefährliche Szenario sind SSH-Shells, die auf bestimmte Befehle beschränkt sind. Das nutzen vor allem Git- und CVS-Server, mittels Shellshock lassen sich derartige Begrenzungen aushebeln. Ein weiteres Szenario, das auch für Clientrechner zum Problem werden könnte: Manche DHCP-Clients rufen Bash auf und setzen dabei Variablen, die sich vom DHCP-Server kontrollieren lassen. Weiterhin kann auch der Druckerdaemon CUPS als Angriffsvektor dienen. Die Liste ist mit hoher Wahrscheinlichkeit unvollständig, es ist auf jeden Fall damit zu rechnen, dass weitere Angriffsmöglichkeiten entdeckt werden.

Ein Metasploit-Modul erlaubt bei VMWare Fusion unter Mac OS X das ausbrechen aus einer virtuellen Maschine. Die Webinterfaces der BIG-IP-Loadbalancer der Firma F5 sind offenbar ebenfalls verwundbar.

Nicht betroffen sind andere Shells. Vielfach waren Nutzer verwirrt, weil sie den in vielen Artikeln bereitgestellten Testcode ausführten und eine Meldung über eine Verwundbarkeit auch unter anderen Shells wie Dash, ZSH oder Busybox erhielten. Doch der Testcode selbst ruft Bash auf und löst erst dort die Sicherheitslücke aus. Es ist egal, aus welcher Shell man diesen aufruft.

Dass andere Shells nicht betroffen sind, dürfte viele Embedded-Geräte retten. Zwar kommt auf Routern und vielen anderen Geräten oft Linux zum Einsatz, hier werden aber meistens ressourcenschonendere Shells als Bash verwendet.

Doppelte Sicherheitslücke

Wenige Stunden nach den ersten Berichten über die Sicherheitslücke postete der Google-Entwickler Tavis Ormandy auf Twitter einen Beispielcode, der auch den Funktionsparser der korrigierten Bash-Version zu verwirren schien. Zwar gelang es Ormandy nicht, dies für eine Sicherheitslücke auszunutzen, trotzdem war offensichtlich, dass das Problem nur unvollständig behoben war. Inzwischen wurde auf der Mailingliste oss-security ein experimenteller Patch gepostet. Ein offizielles Bash-Update gibt es noch nicht, einige Linux-Distributionen liefern aber bereits Pakete mit dem experimentellen Patch aus. Diese erneute Lücke hat inzwischen die ID CVE-2014-7169 erhalten.

Das Vorhandensein der Möglichkeit, bei dem Funktionen direkt in Variablen definiert werden können, finden viele generell problematisch. Allerdings gibt es wohl zahlreiche Bash-Skripte, die die entsprechende Funktion nutzen. Würde man es komplett entfernen, würden wohl einige ältere Skripte nicht mehr funktionieren. Andreas Bogk hat einen Patch erstellt, der die komplette Funktionalität aus Bash entfernt.

Erste Malware aufgetaucht

Auf Github wurden heute Teile eines Logfiles veröffentlicht, die offensichtlich den Versuch eines Angriffs darstellen. Ein HTTP-Request setzte die Cookie-Variable, die Host-Variable und die Referrer-Variable auf einen Exploit-Code zur Ausnutzung von Shellshock. Der Code lädt per wget eine Datei von einem Server herunter und führt diese aus. Die Datei hat den Namen nginx, es handelt sich aber nur um eine Tarnung, mit dem Webserver nginx hat sie nichts zu tun. Es handelt sich dabei um eine Malware, die anschließend versucht, weitere Server mit Sicherheitslücken in Telnet oder Busybox zu finden. Bisher erkennen nur wenige Antiviren-Programme diese Malware. Der Server, der die Malware ausliefert, war zum Zeitpunkt dieses Artikels nach wie vor online.

Ein weiterer Angriff versucht offenbar ein Perlskript, welches als Shellbot.B bekannt ist, mit dem Dateinamen "jur" zu installieren.

In den Logfiles von Webservern findet man inzwischen verschiedene Versuche, die Lücke auszunutzen, die meisten sind aber nur Tests. Einen größeren Scan hat der Sicherheitsforscher Robert Graham durchgeführt. Beim ersten Scan fand Graham nur 3.000 verwundbare Hosts, doch das hing wohl mit einem Fehler in seinem Scanscript zusammen.

Serveradministratoren können ihre Logs nach derartigen Einträgen durchsuchen, typisch ist die Zeichenkette "};", die in fast allen Beispielcodes enthalten ist und sonst in Webserver-Logs üblicherweise nicht auftaucht. Ein typischer Logeintrag, der versucht, die Sicherheitslücke testweise auszunutzen, sieht beispielsweise so aus (die IP-Adressen von Host und Ziel wurden entfernt):

0.0.0.0 - - [25/Sep/2014:11:32:29 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 1689 "-" "() { :;}; /bin/ping -c 1 0.0.0.0"

Testen

Ob man von der ursprünglichen Sicherheitslücke betroffen ist, lässt sich mit einem einfachen Befehl testen:

test="() { echo Hello; }; echo gehackt" bash -c ""

Wird anschließend der String "gehackt" ausgegeben, ist man betroffen. Ein Beispiel, um zu testen, ob man nur den unvollständigen ersten Fix erhalten hat, ist folgender Bash-Code:

X='() { function a a>\' bash -c echo; [ -e echo ] && echo "gehackt"

Es gibt inzwischen auch verschiedene Tools, um über das Netz zu prüfen, ob eine Webseite betroffen ist. Diese sind allerdings meist nicht zuverlässig, da theoretisch jede einzelne Datei auf dem Server betroffen sein könnte und es zahlreiche verschiedene Variablen gibt, in denen man Code unterbringen kann. Das Testen von fremden Servern ist möglicherweise illegal, da man in dem Fall Code auf fremden Servern ausführt.

Das Internet brennt

Es ist wohl nur Zufall, dass fast zeitgleich zu Shellshock eine bösartige Lücke in der RSA-Verifizierung von Firefox und Chrome entdeckt und die Webseite von jQuery zweimal hintereinander gehackt wurde. Doch die Häufung der Ereignisse wirft gewiss ein bezeichnendes Bild auf den allgemeinen Zustand der IT-Sicherheit. Für weitere Spekulationen sorgte eine Ankündigung von Amazon, sämtliche EC2-Server zu rebooten. Manche vermuten, dass der Hintergrund eine weitere, noch nicht bekannte gravierende Sicherheitslücke ist - möglicherweise im Linux-Kernel.

Nachtrag vom 26. September 2014, 11:49 Uhr

Entwickler von Redhat haben inzwischen zwei weitere mögliche Sicherheitslücken im Funktionsparser von Bash gefunden. Es handelt sich dabei um Zugriffe auf falsche Speicherbereiche, die die IDs CVE-2014-7186 und CVE-2014-7187 erhalten haben. Wie gravierend diese neuen Lücken sind, und ob sie sich leicht ausnutzen lassen, ist im Moment schwer abschätzbar. Patches sind von Redhat auf der Mailingliste oss-security gepostet worden.


eye home zur Startseite
Ass Bestos 12. Dez 2014

immer diese leute aus dem computerBILD forum.

PeterMeter 22. Okt 2014

habe auch diverse logs mit dem wget bla bla, nur mich verunsichert immer das mal 403er...

GodsBoss 28. Sep 2014

Wenn PHP über CGI aufgerufen wird und die Bash nicht gepatcht ist, reicht ein Aufruf von...

Reuti 28. Sep 2014

Was ich mich frage: warum benötigt man dort vererbte Funktionen? Aus anderen Gründen habe...

MasterBlupperer 27. Sep 2014

Ich würde nicht unbedingt Bash gegen die Version von HomeBrew/MacPorts tauschen, da dies...

Kommentieren



Anzeige

  1. Teamleiter Software-Entwicklung (m/w)
    GIGATRONIK Köln GmbH, Köln
  2. Koordinator/in für ?-ffentlichkeitsarbeit und IT
    Ludwig-Maximilians-Universität (LMU) München, München
  3. Software Architekt/in Embedded Systems - Navigation
    Daimler AG, Sindelfingen
  4. Edi Specialist (m/w)
    MISUMI Europa GmbH, Schwalbach (Taunus)

Detailsuche



Anzeige
Top-Angebote
  1. NEU: Bud Spencer & Terence Hill - Monster-Box Reloaded [20 DVDs]
    64,90€
  2. NEU: 4 Blu-rays für 30 EUR
    (u. a. Der große Gatsby, Mad Max, Black Mass, San Andreas)
  3. NEU: Blu-rays zum Sonderpreis

Weitere Angebote


Folgen Sie uns
       


  1. Microsoft

    Xbox One macht nicht mehr fit

  2. Google Earth

    Googles Satellitenkarte wird schärfer

  3. Brexit-Entscheidung

    4Chan manipuliert Petition mit vatikanischen IPs und Bots

  4. Twitch

    Geldregen im Streamer-Chat

  5. Streaming

    Amazon Video erhält erstes Dolby-Vision-Material

  6. Windows 10

    Microsoft zahlt Entschädigung für nicht gewolltes Upgrade

  7. Nexar

    Smartphone erstellt automatisch Profile von Autofahrern

  8. Pikes Peak

    Eiswürfelgekühlter Tesla Model S bricht Rennrekord

  9. Betriebssystem

    Noch einen Monat Gratis-Upgrade auf Windows 10

  10. Anki Cozmo

    Kleiner Roboter als eigensinniger Spielkamerad



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Prozessor: Den einen Core M gibt es nicht
Prozessor
Den einen Core M gibt es nicht
  1. Elitebook 1030 G1 HPs Core-M-Notebook soll 13 Stunden durchhalten

IT und Energiewende: Fragen und Antworten zu intelligenten Stromzählern
IT und Energiewende
Fragen und Antworten zu intelligenten Stromzählern
  1. Smart Meter Bundestag verordnet allen Haushalten moderne Stromzähler
  2. Intelligente Stromzähler Besitzern von Solaranlagen droht ebenfalls Zwangsanschluss
  3. Smart-Meter-Gateway-Anhörung Stromsparen geht auch anders

Mikko Hypponen: "Microsoft ist nicht mehr scheiße"
Mikko Hypponen
"Microsoft ist nicht mehr scheiße"

  1. Re: Mal schauen wann die Trojaner- Entwickler das...

    Herr Unterfahren | 11:23

  2. Re: Immer noch zu groß

    Trollfeeder | 11:22

  3. Wieso nicht mit Bitcoin/Changetip?

    Bill Carson | 11:22

  4. Rechenzeit: 42 Millionen Fussballfeldumrundungen

    S-Talker | 11:21

  5. Missverständlich

    ffrhh | 11:19


  1. 11:31

  2. 10:58

  3. 10:54

  4. 10:27

  5. 10:19

  6. 08:53

  7. 08:15

  8. 08:03


  1. Themen
  2. A
  3. B
  4. C
  5. D
  6. E
  7. F
  8. G
  9. H
  10. I
  11. J
  12. K
  13. L
  14. M
  15. N
  16. O
  17. P
  18. Q
  19. R
  20. S
  21. T
  22. U
  23. V
  24. W
  25. X
  26. Y
  27. Z
  28. #
 
    •  / 
    Zum Artikel