Heartbleed – wenn das Herz blutet

Heartbleed und dessen Folgen verstehen - bei uns hands-on!

Heartbleed - insign hands-on-Demo-Server

Heartbleed hands-on auf dem von uns eingerichteten Demo-Server erleben!

Gestern war “Tag der offenen Tür” im Internet. Was ist geschehen?

Eine ungewöhnlich krasse Sicherheitslücke in der vielfach verwendeten Open-SSL Library sorgte sofort nach Bekanntwerden für heftige Schweissausbrüche in der Branche. Ab dem frühen Morgen waren die Systemadministratoren auf Hochtouren am Server aktualisieren und neue SSL-Schlüssel generieren.

Das Sicherheitsleck – Heartbleed genannt, weil es sich im Code für eine TLS Heartbeat-Funktion befindet – hat sogar seine eigene Website: www.heartbleed.com.

Heartbleed stiess ein Guckloch zu Programmcode, E-Mails, Logins, Passwörtern, Session-Cookies und vielem mehr auf.

Heartbleed-Logo zum insign Sicherheits-Bericht von CTO Martin BachmannMit Heartbleed besitzt ein Angreifer quasi ein unsichtbares “Guckloch” in den angegriffenen Server: Dieser liefert dabei wahllos 64 Kilobyte Daten (rund 10 A4-Seiten Text) aus seinem Speicher an den Angreifer. In diesen Daten kann nun alles enthalten sein, womit sich der Server bei seiner Arbeit so beschäftigt: Programmcode, E-Mails, Benutzer-Logins, Benutzer-Passwörter, Datenbank-Passwörter, authentifizierte Session-Cookies, Formular- und Transaktionsdaten etc.

Besonders pikant dabei: Die Passwörter sind im RAM durchaus unverschlüsselt – diese werden in den meisten Fällen erst beim Speichern in der Datenbank verschlüsselt.

Unsichtbar ist dieses Guckloch, weil es keinerlei Log-Einträge darüber gibt, ob und wie oft jemand hindurch geschaut hat.

SSL-Traffic entschlüsseln – auch rückwirkend

Ein weiteres Szenario: Gelingt es dem Angreifer, den servereigenen privaten TLS-Schlüssel ausfindig zu machen, so kann er jeglichen SSL- rsp. TLS-geschützten Datenverkehr entschlüsseln. In den meisten Fällen (ausser wenn der Server Forward Secrecy verwendet) auch bereits früher abgespeicherten Datenverkehr. Und aus Snowdens Dokumenten wissen wir, wer unsere SSL-verschlüsselten Daten en masse abspeichert in der Hoffnung (oder eher zutreffenden Annahme), diesen irgendwann entschlüsseln zu können.

Betroffen von Heartbleed ist wirklich das halbe Internet: DirectNet der CS (Credit Suisse), die Online-Banking-Seiten verschiedener Kantonalbanken, Yahoo, Twitter etc. – alle sitzen im selben Boot. Die meisten Server wurden wohl in den letzten 24 Stunden gepatcht – trotzdem kann niemand sagen, wo wieviel Daten abgezweigt wurden.

Es sind alle betroffen.
Und ganz sicher auch Sie.

Ein Massen-Test der Alexa Top 10’000 Websites gibt einen Eindruck vom Umfang des Lecks (der Test wurde gestern Nachmittag gemacht – bis dahin wurden bereits viele Server aktualisiert und abgesichert).

Mit dem Heartbleed-Test können Sie die von Ihnen verwendeten Server leicht selber testen – falls diese immer noch nicht abgesichert wurden, sollten Sie energisch reagieren und Logins vermeiden.

Tag der offenen Tür im Netz

Selbstverständlich kursierten im Netz sogleich mehrere Exploits, mit welchen die bekannt gewordene Lücke genutzt werden kann. Und dies wurde auch gemacht! Ein genervter Sysadmin hat im Netz gestern treffend gepostet:

„Judging by the active attempts being reported in the DMZ, the best thing now is STOPPING THE FRIKKIN SERVER ASAP. Sessions are being hijacked, passwords leaked, confidential business data revealed.“

Ein praktisches Beispiel

Die Bedeutung dieses Lecks kann kaum überbewertet werden. Viele sind allerdings bereits etwas immun ob der inflationären Sicherheitswarnungen der letzten Zeit. Um die Tragweite dieses Lecks wirklich wahrzunehmen, muss man, so finde ich, Heartbleed ausprobiert haben. Dies haben wir getan.

Mittels eines im Netz kursierenden Exploit-Scripts (ssltest.py) konnten wir auf einem eigenen Test-Server mühelos Daten aus dem RAM extrahieren. Darunter waren unverschlüsselte Passwörter, Source Code, und insbesondere Session-Cookies zu finden.

01c0: 53 53 49 44 3D 6D 75 65 66 62 68 6F 68 38 65 61 SSID=muefbhoh8ea
01d0: 36 35 62 75 63 65 67 65 35 6B 65 33 67 38 34 0D 65bucege5ke3g84.
01e0: 0A 0D 0A 72 21 FC 71 4C 9C E0 86 C9 2C A8 8C 77 ...r!.qL....,..w

Mithilfe eines geklauten Session-Cookies kann nun problemlos die Session des anderen Benutzers übernommen werden – man ist angemeldet als dieser Benutzer (bekannt als Session Hijacking). Man stelle sich vor, was passiert, wenn der Angreifer die Session eines Admins in die Finger bekommt – oder auch “nur” die Session eines Webmail-Benutzers.

Unser Heartbleed Demo-Server

Wer dies nun selber und legal ausprobieren möchte, der kann dies auf unserem Heartbleed Demo-Server tun. Darauf findet sich ein Link, welcher den Angriff auf sich selbst mit dem genannten Tool ausführt und den Memory-Dump ausgibt. Zugegeben: Darauf läuft wenig, darum findet man nicht viel im RAM – aber eine aktive Session-ID für ein Session Hijacking ist mit ein paar Reloads schnell gefunden.

Bis hierhin – und nicht weiter
Natürlich ist es jedem selbst überlassen, ob er das genannte Script (was selber gesucht werden muss) selbst ausprobieren will. Unseren Demo-Server stellen wir explizt zur Verfügung, denn selbstverständlich ist jeglicher Angriff auf einen fremden Server eine illegale Handlung.

Fazit

In den nächsten Tagen wird sich zeigen, wie gross der Schaden des “Tags der offenen Tür” im Internet gewesen ist. Was wohl unbekannt bleibt ist, wer die Lücke vor der Veröffentlichung von Heartbleed genutzt hat und welche Daten mitgeschnitten wurden. Über Fälle wie die zig Millionen gehackter E-Mail-Accounts darf man sich aber nicht wundern – mit Heartbleed (oder einer vergleichbaren Sicherheitslücke) geht das ganz einfach.

Was klar ist:

  • Der Angriff ist effizient und (entgegen dem, was in der Presse oft behauptet wurde) sehr einfach durchzuführen.
  • Sie sollten in ein paar Tagen Ihre im Web verwendeten Passwörter ändern. Unbedingt. Diese standen am Tag der offenen Tür (und natürlich schon vorher) quasi offen und unverschlüsselt im Netz.
  • C sollte als Programmiersprache für wichtige Komponenten verboten werden. Programmierer sollten nicht Memory Management selber betreiben müssen, sonst sind Buffer Overflows und Memory Leaks quasi vorprogrammiert.

Kein Scherz, ändern Sie Ihre Passworte.

Von Martin BachmannMartin Bachmann auf FacebookMartin Bachmann auf Google+Martin Bachmann auf Twitter Autoren-Webseite anschauen

Mitgründer und CTO @insigngmbh, Initiant von @android_schweiz, Android Evangelist und jetzt auch Papi.

Kommentare (0)

Kommentar verfassen