Shellshock Test

[Avalox]

Als Kopie von

http://seeseekey.net/blog


Möchte man Testen ob man vom Shellshock-Fehler betroffen ist, gibt man auf der Konsole folgendes ein:


env x="() { :;} ; echo Anfällig für Shellshock" /bin/sh -c "echo Shellshock-Test"


Wenn man betroffen ist gibt diese Kommandozeile:

Anfällig für Shellshock
Shellshock-Test

aus. Ist man nicht betroffen erhält man folgende Ausgabe:

Shellshock-Test

Versuche Shellshock von Außen zu nutzen kann man feststellen indem man seine
Logdateien nach diesem Beispiel:


cat logfile.log | grep };


abgrast. Bei einem Webserver Log könnte das ganze dann z.B. so aussehen:

192.168.1.15 - - [27/Sep/2014:19:32:19 +0200] "GET / HTTP/1.1" 200 18804 "-" "() { foo;};echo;/bin/cat /etc/passwd"

[lumines]

Wegen Shellshock habe ich mal auf allen meinen Debian-Kisten (stable) unattended-upgrades (https://wiki.debian.org/UnattendedUpgrades) eingerichtet. Per Default werden nur Pakete aus dem Security-Repo automatisch aktualisiert, was mir eigentlich auch als ganz sinnvoll erscheint.

Mit checkrestart aus dem Paket debian-goodies (https://packages.debian.org/wheezy/debian-goodies) kann man übrigens überprüfen, ob noch alte Libraries nach einem Upgrade geladen sind und welche Dienste man neu starten muss. Für einen Server, den man selten komplett hoch und runterfährt, ist das eine ziemlich praktische Sache.

[Lokadamus]

Es wurden noch 5 weitere Probleme in Bash gefunden, die teilweise schon behoben sind.
http://www.golem.de/news/shellshock-immer-mehr-luecken-in-bash-1409-109483.html <-- Ganz am Ende ein kleines Script zum Testen, ob da noch eine Lücke aktiv ist

http://www.heise.de/newsticker/meldung/ShellShock-Teil-3-Noch-drei-Sicherheitsprobleme-bei-der-Bash-2404788.html

[Crushinator]

Bei mir hat man die Lücke laut Apache-Logs noch in der Nacht zum 24.09. versucht, auszunutzen. Zum Glück war nirgendwo cgi zugelassen, so dass nichts passiert ist.

Dafür war tags darauf einer der Server nach dem Patchen und dem anschließendem Reboot wegen eines noch unbekannten Hardware-Schadens nicht mehr zum Leben zu erwecken. Tod durch (Shell)Schock? ;D

[PHuV]

Die Cygwin-Tools haben auch dieses Problem.

[BBig]

https://shellshocker.net/

[anddill]

Bei mir hat man die Lücke laut Apache-Logs noch in der Nacht zum 24.09. versucht, auszunutzen. Zum Glück war nirgendwo cgi zugelassen, so dass nichts passiert ist.

Dafür war tags darauf einer der Server nach dem Patchen und dem anschließendem Reboot wegen eines noch unbekannten Hardware-Schadens nicht mehr zum Leben zu erwecken. Tod durch (Shell)Schock? ;D

Hmm, ich hab meinen Reste-PC den ich auf Arbei nutze nach einem Hardwareschaden (Ausfall des SATA-Controllers) mit Suse 13.2 Beta neu aufgesetzt. Dann hab ich ihn auf Arbeit geschleppt und die IP und den Proxy dort eingerichtet. Netz ging einwandfrei.
Dann kam ein Update für die Bash, welches ich installiert habe. Heute mach ich die Kiste an, und nach 2min ist die Netzverbindung weg. Nun, Internet ist bei uns häufiger weg, also hab ich die Kiste erst mal stehen gelassen und hab was sinnvolles gemacht.
INet kam aber nicht wieder, dann hab ich gemerkt dass der Drucker im Nachbarzimmer auch nicht mehr da war.
Reboot -> geht wieder. Für 1min, dann ist das Netzwerk wieder ein schwarzes Loch.
Ob da irgendwelche hastig geklöppelten Patches was zerschossen haben? Wenn das selbe einem Server passiert ist der ja auch "aus der Welt gefallen".

[lumines]

Halte ich für eher unwahrscheinlich. Die Leute, die das maintainen, machen das bestimmt nicht seit gestern und wer die Bash bei OpenSUSE betreut, wird sicher auch etwas mehr Erfahrung haben. Ich mein, kann theoretisch vorkommen, aber das wird bei den Patches nicht wahrscheinlicher gewesen sein als sonst.

[anddill]

Ob der da auch so nen beknackten Proxy hat und eine feste IP ohne DHCP oder sonstiges?
Werd die Kiste morgen mal wieder mit nach Hause nehmen, mal schauen was hier am DHCP passiert.
Fand das nur interessant, weil Crushi was von Hardwareschaden schrieb, und ich hab auch schon drüber nachgedacht ob nicht einfach der Phy verreckt ist bzw. am verrecken ist.

ps: Meine Ahnung von Linux beschränkt sich leider nur auf das was die GUI mir zeigt und eine handvoll Konsolenkommandos.

grml...
Warum muss man den ganzen Mist an mindestens 4 Stellen eintragen? Und warum ging es vor dem Update? Und warum geht es jetzt wieder?
Fragen...Fragen...Fragen...

[sei laut]

Naja, das Bash-Update sind wenige Zeilen Code. Das hat eigentlich keine so gravierenden Folgen. Vorallem ist es Bash, das ist nicht der Kernel, kein Treiber. Für das System ansich völlig harmlos - höchstens irgendwelche Scripte könnten eben Probleme machen, wenn das Update unsauber wäre.
(aber die meisten Linux-Kommandozeilenprogramme sind eh in C und unbeeindruckt davon)

Aber ich nutze nur Debian oder Debian-Derivate, kann das Suse Update nicht beurteilen.

[Crushinator]

[...] Reste-PC [...] Reboot -> geht wieder. Für 1min, dann ist das Netzwerk wieder ein schwarzes Loch.
Ob da irgendwelche hastig geklöppelten Patches was zerschossen haben? Wenn das selbe einem Server passiert ist der ja auch "aus der Welt gefallen".

Das kann IMHO unmöglich mit dem bash-Update zusammenhängen. Mein betroffener Server (FreeBSD) gab beim Booten "keinen Ton" mehr von sich, ist also HW-tot. Bei der Sichtprüfung ist auf dem Mainboard nichts negatives aufgefallen. Vielleicht ist im Netzteil was geplatzt? (Er hatte zu dem Zeitpunkt eine Uptime von 412 Tagen)

Jedenfalls wurden seine HDDs danach samt Raid-Controller in ein baugleiches System gesteckt, ohne jeglichen Probleme hochgefahren und wieder ins Produktivsystem eingebunden.

[Gast]

Habe jetzt mal folgendes in die Konsole eingegeben (aus der oben verlinkten Seite shellshocker.net):

curl https://shellshocker.net/shellshock_test.sh | bash

Spuckt nur "not vulnerable" aus.
Kann man sicher sein, dass alles i.O. ist?

[PHuV]

Die aktuellen Cygwin-Tools sind schon gefixt. :up:

[Grumbart]

@ Gast

hier noch Informationen.
https://access.redhat.com/articles/1200223

Hast Du noch ein paar Details zu Deinem System?

Aber ich nutze nur Debian oder Debian-Derivate
das.

@ andill auch wenn ich SuSE nicht mag, das ist sicher kein Fehler des Bash Fixes.
Gerade das Fixen dieser Sicherheitslücke ist quasi vorbildlich.

[Gast]

@Grumbart:

Hallo, ist ein Xubuntu 14.04 auf normaler Heim-HW also kein Server o.ä.

Das erwähnte Konsolenkommando ergibt nach dem Testen - wie erwähnt - überall "not vulnerable" bis auf diese Zeile:

bash: shellshocker: Kommando nicht gefunden.

[Gast]

Achso, letztes Bashupdate war laut History am 26.9.
Das System wird btw täglich geupdated (falls Updates vorhanden).

[Godmode]

Patch OSX das eigentlich silent? Vor ein paar Tagen war die Lücke noch da, jetzt ist sie zu, obwohl ich keine Updates installiert habe?

[Grumbart]

@ Gast
http://packages.ubuntu.com/trusty/bash
Version: Paket: bash (4.3-7ubuntu1.4) [security]

also mach mal in einem xterm
# dpkg | grep -i bash

Das Bash Paket sollte in der Version "(4.3-7ubuntu1.4)" vorliegen
Klick (http://changelogs.ubuntu.com/changelogs/pool/main/b/bash/bash_4.3-7ubuntu1.4/changelog) 26.09 für den Fix passt auch

[Lokadamus]

Patch OSX das eigentlich silent? Vor ein paar Tagen war die Lücke noch da, jetzt ist sie zu, obwohl ich keine Updates installiert habe?Beißt sich irgendwie mit der Meldung.
http://www.heise.de/newsticker/meldung/Mac-OS-X-Bash-Update-gegen-ShellShock-2405325.html

[Gast]

@Grumbart:
Habs mal nach Deiner Anleitung gecheckt. Ist auf jeden Fall die 4.3-7ubuntu1.4 Version.
Danke nochmal für die Infos.

Gruß

[Godmode]

Beißt sich irgendwie mit der Meldung.
http://www.heise.de/newsticker/meldung/Mac-OS-X-Bash-Update-gegen-ShellShock-2405325.html

Eventuell liegt es daran, dass ich schon 10.10 verwende.

[sei laut]

Die Bash Update Orgie geht übrigens weiter.. wer hätte es gedacht:
http://blog.fefe.de/?ts=aac86212

[nalye]

Ähm, Patch #30 ist ja schon "alt"
Sun Oct 5 2014: 9:57pm EST

//Edith meint: Auf meinem OS X 10.9.5 musste ich alle Patches selbst einspielen, da kam irgendwann mal was per Autoupdate, aber das ist schon eine Weile her

//Noch Edit:

http://blog.malwaremustdie.org/2014/10/mmd-0029-2015-warning-of-mayhem.html
Momentan geht das Ding ganz gut rum. Es wird primär versucht, einen dDoS-Bot zu installieren. Die Access-Logfiles sollte man periodisch nach "{" durchsuchen, falls die Kiste verwundbar ist.