Websecurity: Jahresrückblick

Von Carsten Eilers

Dieser shortcut liefert einen Rückblick auf Sicherheitslücken und Angriffe im Jahr 2014. Im ersten Kapitel stehen dabei vor allem OpenSSL, SSL und TLS im Fokus. Das zweite Kapitel befasst sich unter anderem mit den Angriffen Shellshock und Poodle sowie der Frage, wie sehr das Internet im Jahre 2014 nun tatsächlich zur Zielscheibe von Angriffen wurde.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 2. März 2015
• ISBN: 9783868025378

Buchvorschau

GmbH

1 Angriffe in OpenSSL und SSL/TLS

Noch nie war es mit der Sicherheit im Internet so schlecht bestellt wie 2014. Jedenfalls gewinnt man diesen Eindruck, wenn man die ganzen Vorfälle im vergangenen Jahr betrachtet. Inzwischen gibt es sogar eine Website, die laufend die Frage „Is The Internet On Fire?" beantwortet [1]. Ganz vorne mit dabei: OpenSSL und SSL/TLS allgemein. Wir blicken zurück.

Zwar steht nicht das ganze Internet in Flammen, aber es kokelt doch an etlichen Ecken. Leider mal wieder an vorderster Front involviert: SSL/TLS. Dass das dafür verwendete Zertifizierungssystem eher einem brennenden Kartenhaus als der nötigen stabilen Festung gleicht, mussten wir ja schon 2011/2012 zur Kenntnis nehmen [2]. 2014 waren erneut die Protokolle selbst sowie ihre Implementierungen die Quelle des Übels. Los ging es mit OpenSSL und ganz viel Herzblut.

Der Heartbleed-Bug in OpenSSL

Am 7. April 2014 wurde von OpenSSL ein Security Advisory [3] zu einer neu behobenen Schwachstelle mit der CVE-ID CVE-2014-0160 [4] veröffentlicht, die folgendermaßen beschrieben wurde: A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.

Eine parallel veröffentlichte Website [5] einiger Entdecker des Sicherheitsrisikos machte dann schnell deutlich, dass die Schwachstelle das Potenzial hat, zu einem großen Problem zu werden. Nebenbei bekam die Entdeckung im Gegensatz zu den meisten anderen sogar einen eigenen Namen: Heartbleed-Bug.

Der Heartbleed-Bug basiert auf einer fehlenden Bereichsprüfung in der Heartbeat-Funktion. Ein Angreifer kann darüber einen „buffer over-read auslösen. Als Antwort auf einen präparierten Heartbeat-Request sendet OpenSSL bis zu 64 KB Speicherinhalte an den Angreifer. Dieser Speicher kann unter anderen den privaten Schlüssel des Servers, Sessionschlüssel oder über TLS übertragene Zugangsdaten enthalten. Der Angriff kann ggf. wiederholt werden, um weitere Speicherbereiche auszulesen. Das ist schlimm, sehr schlimm. Oder wie Bruce Schneier es formuliert hat, eine Katastrophe [5]: „‘Catastrophic’ is the right word. On the scale of 1 to 10, this is an 11.

Wie funktioniert der Angriff?

Die „Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Exten­sion [6] dient dazu, eine Verbindung aufrechtzuerhalten, obwohl keine Daten übertragen werden („keep-alive). Heartbeat-Nachrichten bestehen aus zufälligen Daten und einem Feld mit der Payload-Länge. Der Kommunikationspartner muss auf einen Heartbeat-Request mit genau den gleichen Daten antworten.

Der Heartbleed-Bug besteht darin, dass die Payload-Länge nicht geprüft wird, bevor sie verwendet wird. OpenSSL reserviert entsprechend dem Wert im Längenfeld einen Puffer. Danach werden die Daten entsprechend diesem Wert aus der Eingabe in den Puffer kopiert. Gibt ein Angreifer eine größere Länge als Payload-Länge an, als die von ihm gesendete Payload tatsächlich umfasst, werden die hinter der Payload liegenden Speicherbereiche in den Puffer kopiert.

Wird zum Beispiel die Payload-Länge mit 64 KB angegeben (das ist der Maximalwert), obwohl nur 1 KB Payload gesendet wird, werden also 63 KB des vorhandenen Speichers in den Puffer kopiert – samt der zuvor darin enthaltenen und nicht überschriebenen, möglicherweise sensitiven, Daten. Nach dem Kopieren der Daten wird der gefüllte Puffer als Antwort auf den Heartbeat-Request an den Kommunikationspartner gesendet.

Der Angriff funktioniert sowohl gegen Server als auch gegen Clients, ist gegen Server aber deutlich einfacher, da der Angreifer von sich aus eine Verbindung zum Opfer aufnehmen kann. Beim Angriff auf einen Client muss der sich dafür mit einem bösartigen Server verbinden. Was im Zweifelsfall mit etwas Social Engineering oder