Abo
  • Services:
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...



Anzeige

Stellenmarkt
  1. Hornbach-Baumarkt-AG, Großraum Mannheim/Karlsruhe
  2. Stadtwerke München GmbH, München
  3. Kurz Industrie-Elektronik GmbH, Remshalden
  4. Kaasa Health GmbH, Düsseldorf


Anzeige
Top-Angebote
  1. beim Kauf eines 6- oder 8-Core FX Prozessors
  2. (u. a. G700s 54,90€, G930 74,90€)
  3. 24,99€ inkl. Versand (PC), Konsole ab 29,99€

Folgen Sie uns
       

Anzeige
Whitepaper
  1. Kritische Bereiche der IT-Sicherheit in Unternehmen
  2. Tipps für IT-Engagement in Fernost
  3. Potenzialanalyse für eine effiziente DMS- und ECM-Strategie


  1. Galaxy Note 7 im Test

    Schaut dir in die Augen, Kleine/r/s!

  2. Terrorbekämpfung

    Denn sie wissen nicht, wen sie scannen

  3. Neuer Akku

    Tesla lässt fliegen

  4. FBI

    Russland soll die New York Times attackiert haben

  5. Smach Z ausprobiert

    So wird das nichts

  6. Parrot Disco

    Schnelle Flugzeugdrohne mit Brillen-Bildübertragung

  7. Marsrover

    China veröffentlicht Pläne für eigenen Marsrover

  8. Android 7.0

    Google verteilt erste Factory-Images, Sony nennt Update-Plan

  9. Denza 400

    Chinesische Mercedes-B-Klasse fährt 400 km elektrisch

  10. Microsoft

    Office für Mac 2016 auf 64 Bit aufgerüstet



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
8K- und VR-Bilder in Rio 2016: Wenn Olympia zur virtuellen Realität wird
8K- und VR-Bilder in Rio 2016
Wenn Olympia zur virtuellen Realität wird
  1. 400 MBit/s Telefónica und Huawei starten erstes deutsches 4.5G-Netz
  2. Medienanstalten Analoge TV-Verbreitung bindet hohe Netzkapazitäten
  3. Mehr Programme Vodafone Kabel muss Preise für HD-Einspeisung senken

Lernroboter-Test: Besser Technik lernen mit drei Freunden
Lernroboter-Test
Besser Technik lernen mit drei Freunden
  1. Künstliche Muskeln Skelettroboter klappert mit den Zähnen
  2. Cyborg Ein Roboter mit Herz
  3. Pleurobot Bewegungen verstehen mit einem Robo-Salamander

Mobilfunk: Eine Woche in Deutschland im Funkloch
Mobilfunk
Eine Woche in Deutschland im Funkloch
  1. Netzwerk Mehrere regionale Mobilfunkausfälle bei Vodafone
  2. Hutchison 3 Google-Mobilfunk Project Fi soll zwanzigmal schneller werden
  3. RWTH Ericsson startet 5G-Machbarkeitsnetz in Aachen

  1. Re: Konzept schlecht

    gettingbetter | 12:12

  2. Re: Konkurrenz für Supersportwagen?

    PiranhA | 12:12

  3. Re: Reichweite Autobahn

    Berner Rösti | 12:11

  4. Update OTA für Ungeduldige :-)

    Iglst | 12:11

  5. Re: Beschleunigung ist aber auch das einzige...

    JackIsBlack | 12:10


  1. 12:16

  2. 12:14

  3. 11:08

  4. 10:53

  5. 10:00

  6. 09:45

  7. 09:14

  8. 09:06


  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