WICHTIG: "ShellShock"-Exploit! Gefährlicher als Heartbleed!

kk · 25. September 2014

Hallo,

vielleicht haben Sie bereits von der Sicherheitslücke in der Bourne Again Shell (kurz bash) gehört. Diese Lücke ist absolut kritisch. Wir haben in ersten Tests erfolgreich auch über PHP-Scripte, die via suPHP ausgeführt werden und die shell_exec-Funktion (bzw. Backticks) aufrufen, in eigene Testsysteme "einsteigen" können. Der eigentliche "Exploit" besteht quasi nur aus einem einzigen, spziell präparierten HTTP-Aufruf!

Im Gegensatz zu Heartbleed, welches ein mittel-/langfristiges Ausspähen verschlüsselter Daten ermöglichte, gibt es mit ShellShock einen sofortigen, unmittelbaren Serverzugriff! Potenziell verwundbare PHP-Scripte lassen sich mittels Suchmaschinen schnell finden.

Für PHP Wheezy wurde am 25.09. gegen 01:00 ein erstes Patch bereitgestellt; mit dem nun vorliegenden zweiten Patch (23:18) sollte die Lücke vollständig geschlossen sein. Für Debian Squeeze dürfte via LTS in Kürze auch ein weiteres Update erfolgen.

Für ältere Linux-Systeme gibt es nur zwei Möglichkeiten: manuell bash neu compilieren, oder mittels LD_PRELOAD-Trick einen Workaround installieren. Eine ausführliche Beschreibung haben wir in unserer Wissensdatenbank bereitgestellt: http://www.liveconfig.com/de/kb/23

Bitte nehmen Sie diese Sicherheitslücke sehr ernst! Aktualisieren Sie umgehend Ihre Server, oder installieren Sie das in KB#23 beschriebene Workaround. Nach Medienberichten existieren bereits die ersten automatisch verbreitenden Würmer.

Viele Grüße

-Klaus Keppler

ap24 · 26. September 2014

Mit Ihrer Anleitung habe ich nun mein System "verschrottet":

Code

/bin/sh: X: line 1: syntax error near unexpected token `='
/bin/sh: X: line 1: `'
/bin/sh: error importing function definition for `X'
/test.sh: line 1: syntax error near unexpected token `newline'
/test.sh: line 1: `#!/bin/sh'

kk · 26. September 2014

Sie haben nichts verschrottet
Falls Sie die SSH-Session noch offen haben, geben Sie einfach "unset X" ein.
Oder melden Sie sich ab und wieder an.

TCRserver · 26. September 2014

Hallo Herr Keppler,
in Ihrer Anleitung KB#23 sind zwei kleine Fehler enthalten:

Im Prüfstring ist ein kleiner Typo enthalten:

Zitat
Code
$ [B]LC[/B]_PRELOAD=./bash_ld_preload.so bash -c "echo Test"
[QUOTE]

Richtig:
Code
$ [B]LD[/B]_PRELOAD=./bash_ld_preload.so bash -c "echo Test"
[QUOTE]
Wenn dagegen alles passt, dann verschieben Sie das Binary nach /usr/lib:
Code
$ mv bash_ld_preload.so /usr/bin
Alles anzeigen

Da sollte der Code Teil geändert werden in:

Code

$ mv bash_ld_preload.so /usr/lib

Danke für das bereitstellen der fertig compilierten Pakete und den Sicherheitshinweis an die Community!

Nosxxx · 26. September 2014

Soweit ich das gesehen habe dürfte bei Debian 7 der fix (das Update) nun funktionieren

kk · 26. September 2014

Zitat von TCRserver

Hallo Herr Keppler,
in Ihrer Anleitung KB#23 sind zwei kleine Fehler enthalten:

Danke für den Hinweis! War gestern ein langer Tag... Die Anleitung wurde entsprechend korrigiert.

andreas · 26. September 2014

@Herr Keppler,

vielen Dank für das kurzfristige bereitstellen des Workaround.

Andreas

bash · 26. September 2014

Test ob ihr von CVE-2014-6271 betroffen seid:

Code

env var='() { ignore this;}; echo vulnerable' bash -c /bin/true

Gibt er hier "vulnerable" aus, seid ihr betroffen

Test ob ihr von CVE-2014-7169 betroffen seid (automatisch wenn CVE-2014-6271 möglich ist):

Code

env X='() { (a)=>\' bash -c "echo date"; cat echo

Gibt er hier ein Datum und nicht "date" aus, seid ihr betroffen.

Ist vieleicht für viele mal ganz hilfreich...

Sven_67 · 28. September 2014

Zitat von bash

Ist vieleicht für viele mal ganz hilfreich...

Vor allem für die, die sich schon immer mal als Hacker versuchen wollten.....tolle Wurst, hier ne Anleitung einzustellen, wie man Erfolg haben könnte.

kk · 28. September 2014

Zitat von Sven_67

tolle Wurst, hier ne Anleitung einzustellen, wie man Erfolg haben könnte.

Eventuell haben Sie die Lücke oder den o.g. Befehl nicht verstanden. Der vom Nutzer "bash" genannte Befehl zeigt tatsächlich nur, ob die eigene bash-Version noch verwundbar ist. Richtigen Exploit-Code gibt es inklusive Backdoor und notwendigem HTTP-Request schlüsselfertig bei GitHub, selbst große IT-Newsmagazine verlinken sogar schon direkt darauf.

Und: man muss kein besonders großer Hacker sein, um diese Lücke erfoglreich ausnutzen zu können. Das ist ja das Schlimme daran...

synergix · 28. September 2014

Guten Morgen zusammen,

erstmal vielen Dank Herr Kuppler, das Sie in aller Deutlichkeit auf diese Lücke aufmerksam gemacht haben. Selbst in renommierten IT Magazinen geht das zum Teil ja etwas unter.

Mein Tip: Mit folgendem Befehl die Verwundbarkeit testen:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Wenn:
vulnerable
this is a test

ausgegeben wird, ist das System betroffen.

Und das einfachste ist in diesem Fall, ein Update des Systems durchzuführen. Debian und RedHat basiert Systeme bekommen seit gestern ja schon die zweite Aktualisierung verpasst. Damit hat man dann erst mal Ruhe.

An die, die sich hier aufregen: Etwas lockerer bitte. Und erstmal in Ruhe prüfen, was passiert, bzw. was nicht, bevor hier gemeckert wird.

CL

Jetzt mitmachen!