© Liashko/Shutterstock.com
Teil 2 des Rückblicks auf Schwachstellen und Angriffe aus dem Jahr 2014

Kein Feuer, aber kräftig am Kokeln!


Noch nie war es um die Sicherheit im Internet so schlecht bestellt wie 2014. Jedenfalls gewinnt man diesen Eindruck, wenn man die ganzen Vorfälle im vergangenen Jahr betrachtet. Es gibt sogar eine Website, die laufend die Frage „Is The Internet On Fire?“ beantwortet [1]. Dass die Antwort auf diese Frage einige Male „Yes“ lautete, unterstreicht der zweite Teil unseres Securityrückblicks auf die Schwachstellen und Risiken im Jahr 2014.

In Teil 1 konstatierten wir bereits in der letzten Ausgabe, dass zwar nicht das ganze Internet in Flammen steht, es jedoch an etlichen Ecken und Enden kokelt. Ob dieser Umstand 2014 wirklich schlimmer war als in den Vorjahren, bezweifle ich. 2014 fielen die Schwachstellen und Angriffe nur mehr auf, da einige von ihnen werbewirksame Namen verpasst bekamen. Werfen wir mal einen Blick auf einige „Highlights“ des Jahres 2014. Los ging es mit dem am 7. April 2014 veröffentlichten Heartbleed-Bug in OpenSSL, der bereits im Entwickler Magazin 1.2015 vorgestellt wurde [2]. Dieser erwies sich als längerfristiges Problem, etwa, weil die Installation der Patches nach kurzer Zeit stockte. Und er war noch gar nicht richtig verdaut, da kam schon der nächste Schock.

Shellshock – Immer mehr Schwachstellen in der GNU Bash

Die eigentliche Shellshock-Schwachstelle hat die CVE-ID CVE-2014-6271 [3] und wurde am 24. September 2014 veröffentlicht [4]. Die Bash kann nicht nur Shell-Variablen, sondern auch Shell-Funktionen über das Environment an (indirekte) Child-Prozesse exportieren. Aktuelle Versionen verwenden dazu eine Environment-Variable mit dem Funktionsnamen als Namen und der mit () { beginnenden Funktionsdefinition als Variablenwert. Die Schwachstelle besteht darin, dass die Bash die Auswertung nach der Funktionsdefinition nicht beendet, sondern darauf folgende Shell-Befehle parst und ausführt. Zum Beispiel führt das Setzen der Environment-Variable VAR=() { ignored; }; /bin/id dazu, dass beim Import des Environments in den Bash-Prozess /bin/id ausgeführt wird. Der Prozess befindet sich dabei zwar in einem undefinierten Zustand – zum Beispiel kann es sein, dass die PATH-Variable noch nicht gesetzt ist und die Shell unter Umständen nach der Ausführung von ­/ bin/id abstürzt – der Schaden ist dann aber bereits eingetreten. Der ist zwar im Fall von /bin/id quasi nicht vorhanden, bei anderen Variablen wie zum Beispiel /bin/ rm -r / könnte es aber schon unschön werden – vom Öffnen einer Reverse-Shell oder der Installation einer Backdoor ganz zu s...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang