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. Schwarz IT Infrastructure & Operations Services GmbH & Co. KG, Neckarsulm
  2. Robert Bosch Starter Motors Generators GmbH, Schwieberdingen
  3. Ashampoo Systems GmbH & Co. KG, Oldenburg
  4. Osmo Holz und Color GmbH & Co. KG, Göttingen


Anzeige
Blu-ray-Angebote
  1. (u. a. Apollo 13, Insidious, Horns, King Kong, E.T. The Untouchables, Der Sternwanderer)
  2. (u. a. Die große Bud Spencer-Box Blu-ray 16,97€, Club der roten Bänder 1. Staffel Blu-ray 14...
  3. (u. a. London Has Fallen, The Imitation Game, Lone Survivor, Olympus Has Fallen)

Folgen Sie uns
       

Anzeige
Whitepaper
  1. Praxiseinsatz, Nutzen und Grenzen von Hadoop und Data Lakes
  2. Mit digitalen Workflows Geschäftsprozesse agiler machen
  3. Kritische Bereiche der IT-Sicherheit in Unternehmen


  1. Streaming

    Netflix-Nutzer wollen keine Topfilme

  2. Star Wars Rogue One VR Angespielt

    "S-Flügel in Angriffsposition!"

  3. Kaufberatung

    Die richtige CPU und Grafikkarte

  4. Android

    Google kann Größe von App-Updates weiter verringern

  5. Exilim EX-FR 110H

    Casio stellt Actionkamera für die Nacht vor

  6. Webmailer

    Mit einer Mail Code in Roundcube ausführen

  7. A1 Telekom Austria

    Im kommenden Jahr hohe Datenraten mit LTE

  8. Pebble am Ende

    Pebble Time 2 und Core wegen Übernahme gecancelt

  9. Handheld

    Nintendo zahlt bis zu 20.000 US-Dollar für 3DS-Hacks

  10. Großbatterien

    Sechs 15-Megawatt-Anlagen sollen deutsches Stromnetz sichern



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Gigaset Mobile Dock im Test: Das Smartphone wird DECT-fähig
Gigaset Mobile Dock im Test
Das Smartphone wird DECT-fähig

Civilization: Das Spiel mit der Geschichte
Civilization
Das Spiel mit der Geschichte
  1. Civilization 6 Globale Strategie mit DirectX 12
  2. Take 2 GTA 5 saust über die 70-Millionen-Marke
  3. Civilization 6 im Test Nachhilfestunde(n) beim Städtebau

Oculus Touch im Test: Tolle Tracking-Controller für begrenzte Roomscale-Erfahrung
Oculus Touch im Test
Tolle Tracking-Controller für begrenzte Roomscale-Erfahrung
  1. Microsoft Oculus Rift bekommt Kinomodus für Xbox One
  2. Gestensteuerung Oculus Touch erscheint im Dezember für 200 Euro
  3. Facebook Oculus zeigt drahtloses VR-Headset mit integriertem Tracking

  1. Re: Bei den heutigen Kinopreisen

    peterbarker | 13:28

  2. Re: Das war mein Kündigungsgrund

    MrTuscani | 13:28

  3. Nachvollziehbare Argumentation

    IncredibleAlk | 13:27

  4. Re: 2 Wochen vor Kino erstmal die Raubkopier...

    SjeldneJordartar | 13:26

  5. Re: Welche Nummer?

    chefin | 13:25


  1. 13:10

  2. 12:25

  3. 11:59

  4. 11:44

  5. 11:38

  6. 11:05

  7. 10:53

  8. 10:23


  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