Shellshock, mit welchem Schaden habe ich zu rechnen?

[alter_Bekannter]

Wenn ich das richtig verstanden habe konnten Umgewbungsvariablen geändert werden, was theoretisch ziemlich viel Schaden anrichten kann, aber sind auch andere Konten betroffen als das ursprünglich kompromitierte?

Gibt es weitere Lücken die beispielsweise Änderungen hervorrufen könnten die dann tatsächlich dazu führen könnten das beliebiger Code auch mit höheren Rechten ausgeführt wird?

Um mal ein konkretes Beispiel zu nennen, könnte der Nutzer www-data den Debian-System für den Apache anlegen irgendwie anderweitig an höhere Rechte kommen?
zB im Bezug auf die path Variable von root?

Oder war Debian von dem Apache CGI Problem sowieso nicht betroffen weil es Dash in dem Bereich verwendet?

 

[xploit]

Es gibt mittlerweile einen Patch für BASH der das Problem behebt

Einfach wie immer:

[src=bash]apt-get update && apt-get upgrade[/src]

Bzw. wenn du nur BASH updaten willlst:

[src=bash]apt-get update && apt-get install bash[/src]


Zu deiner Frage:

sind auch andere Konten betroffen als das ursprünglich kompromitierte?

könnte der Nutzer www-data anderweitig an höhere Rechte kommen?

Theoretisch ist es möglich, dass man über einen anderen Benutzer das root Passwort ändert und so Vollzugriff erhält.
Dazu braucht der Angreifer aber Zugang zu SUDO und ich denke niemand wäre dumm genug www-data das zu erlauben


Falls du testen willst ob deine BASH noch anfällig ist, führ das hier aus:

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

Für noch geneaure Testergebnisse besorg dir DIESES SKRIPT und führ es aus



Wenn du wissen willst ob dich jemand angegriffen hat, lass dir von grep helfen:

[src=bash]cat /pfad/zu/deinem/webserver/logfile.log | grep };[/src]

So sähe ein versuchter Angriff im Log aus:

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


Gruß

 

[alter_Bekannter]

Es ging weder um Anfälligkeit noch ums schließen der Lücke.
Auch nicht darum festzustellen ob ein System betroffen ist es ist definitiv nicht Teil der Fragestellung.
Auch nicht indirekt.

Es geht mir wirklich um das tatsächliche Ausmaß des potentiellen Schadens. Was könnte passieren?
Nein, www-data wurden keine zusätzlichen Rechte übertragen, wozu auch.

Daher die Frage, erlaubt die Lücke in irgendeinem bekannten Szenario das erlangen erhöhter Rechte?
Das englische Wikipedia hat sowas angedeutet aber kein Beispiel genannt.

 

[Asseon]

eine injizierte Funktion kann praktisch alles enthalten, also wenn irgendeine setuid binary, ein mit root rechten laufender Prozess oder der Kernel eine Lücke hat, kann diese theoretische ausgenutzt werden, wobei eine Kernellücke aus einem bash script auszunutzen je nach natur der lücke eher unwahrscheinlich ist.

 

[alter_Bekannter]

In anderen Worten:
Es konnte alles was www-data lesen konnte gelsen werden und wenn in /var/www(Das kann ich sicher wissen weil der Ordner leer ist) keine Änderungen vorgenommen wurden ist vermutlich nichts passiert.

 

[Kugelfisch]

Wenn ich das richtig verstanden habe konnten Umgewbungsvariablen geändert werden, was theoretisch ziemlich viel Schaden anrichten kann

Nein, das hast du missverstanden. Bash erlaubt(e) es grundsätzlich, über die `() {...}`-Syntax Funkionen in Umgebungsvariablen abzulegen, welche beim Start von bash importiert wurden, z.B. würde durch die Umgebungsvariable `FOO` in
[src=bash]FOO='(){ echo test;};' bash -c FOO[/src]
beim nachfolgenden Start von Bash eine Funktion namens `FOO` definiert (und durch den Parameter `-c FOO` aufgerufen). Das Feature in sich ist bereits nicht ungefährlich, speziell wenn man als Entwickler nicht berücksichtigt, dass eine vermeintliche Umgebungsvariable auch eine Funktion enthalten kann.

Die eigentliche Schwachstelle besteht aber darin, dass man den Funktionsparser auf verschiedenste Weise verwirren kann, so dass statt oder zusätzlich zum Definieren einer Funktion auch beliebiger Code sofort ausgeführt wird. Das klassische, erste Beispiel dafür ist
[src=bash]FOO='() { :; }; echo vulnerable' bash -c test[/src]
welches `echo vulnerable` ausführt, auch ohne dass die Umgebungsvariable `FOO` überhaupt verwendet wird.

Gefährlich wird dies dann, wenn von Aussen beeinflussbare Parameter in Umgebungsvariablen übergeben werden. Dies ist z.B. bei klassischen CGI-Skripten der Fall (wo diverse HTTP-Request-Header in Umgebungsvariablen abgelegt werden), kann aber auch z.B. Schnittstellen von Mail-Servern oder die Authentifizierungsschnittstelle von OpenVPN (auth-user-pass-verify) betreffen. Es könnten also auch andere Dienste neben dem Webserver angreifbar gewesen sein.

Ein universeller Weg, um nach dem Übernehmen eines lokalen Benutzerkontos über die Shellshock-Schwachstelle auch root-Rechte zu erlangen ist mir nicht bekannt. Üblicherweise sind einerseits die Umgebungsvariablen, welche ein suid-Binary vom Benutzer übernimmt, stark eingeschränkt (um zu verhindern, dass z.B. über LD_PRELOAD eigener Code ins Binary nachgeladen wird), andererseits wirft Bash beim Start eventuelle suid-Berechtigungen weg, um Exploits zu erschweren. Allerdings werden dadurch, dass ein Angreifer möglicherweise Zugriff auf ein lokales Benutzerkonto erlangt haben könnte, natürlich (wie bereits erwähnt wurde) alle Local-Privilege-Escalation-Schwachstellen akut.

 

[accC]

Wenn du von einem erfolgreichen Angriff deines Systems ausgehst, dann solltest du es neu aufsetzen, Passwörter und Zugangsdaten ändern.
Es kann zwar sein, dass bestimmte Daten nicht betroffen waren, aber wenn mir ein Schlüssel für eine Schließanlage abhanden gekommen ist und ich weiß nicht mehr, zu welchen Räumen er überall Zugang hatte, dann tausche ich lieber alle Schlösser aus, als später eines vergessen zu haben und darüber dann dem Einbrecher Einlass zu gewähren.

 

[alter_Bekannter]

Hab ich schon, daher war ich auch echt froh über meine "speicher nur automatisch generierte Passwörter im Klartext ab" Politik.

Die Frage war nur: "reicht das?"

Weil alle Konfig Dateien neu zu machen wär jetzt echt lästig. Aber wenn die nur gelesen werden konnten ist alles Grün, die Passwörter
sind alle automatisch generiert und gehen nur Lokal auf sehr eingeschränkte Konten.