Dipl.-Inform. Carsten Eilers

Es sind weitere Angriffe bekannt geworden, allerdings wurden alle erst nach Veröffentlichung der Patches und damit der Schwachstelle durchgeführt bzw. entwickelt. Zunächst gibt es zwei echte Angriffe, bei denen tatsächlich Daten ausgespäht wurden:

• Mandiant berichtet über einen gezielten Angriff auf einen SSL VPN Concentrator, bei dem laufende Sessions übernommen wurden. Die Angreifer konnten dadurch sowohl die Multifaktor-Authentifizierung des angegriffenen Unternehmens als auch die VPN-Client-Software, die sicher stellen sollte, dass nur erlaubte Clients eine Verbindung zum Netzwerk aufbauen können, unterlaufen. Der Angriff wurde durch die Analyse von IDS-Signaturen und VPN-Logfiles erkannt.
• Heise Security hat berichtet, dass Kriminell über Heartbleed im großen Maßstab auf SMS-Gateways SMS-Nachrichten ausgespäht haben. Die betroffenen Gateways können über ein Web-API aus dem Internet gesteuert werden und verwendeten eine der betroffenen OpenSSL-Versionen.

• Angriffe auf OpenVPN wurden von Fredrik Strömberg erfolgreich getestet, er konnte den privaten Schlüssel ermitteln.
• Collin R. Mulliner hat herausgefunden, dass die Schwachstelle genutzt werden kann, um auf TOR-Nodes Benutzer-Daten auszuspähen. Inzwischen wurde damit begonnen, die betroffenen Nodes zu sperren. Es gibt auch eine aktuelle Übersicht betroffener Nodes.

Angriffe erkennen ist und bleibt schwierig

Angriffe hinterlassen wie bereits mehrfach erwähnt keine Spuren auf dem Server wie zum Beispiel neu angelegte Dateien oder ähnliches. Allenfalls in Logfiles lassen sich Spuren finden. Wenn die Heartbeat-Requests denn überhaupt protokolliert werden. Daniel Wesemann hat im InfoSec Handlers Diary Blog eine Möglichkeit beschrieben, Angriffe in Logfiles zu erkennen. Dazu werden Firewall- und Webserver-Logfile verglichen. Enthält das Firewall-Logfile eine Reihe von tcp/443 (HTTPS) Verbindungen zum Webserver, die im Webserver-Logfile nicht auftauchen, handelt es sich sehr wahrscheinlich um Heartbeat- bzw. Heartbleed-Requests. Bei der Untersuchung eines Servers eines "Community College" wurden entsprechende Requests von einer IP-Adresse in Malaysia gefunden, gefolgt von Requests, die sowohl im Firewall- als auch im Webserver-Logfile auftauchten. Vermutlich hat zuerst jemand Session-Cookies ausgespäht, die dann getestet wurden.

Eine weitere Möglichkeit, Angriffe zu entdecken, wurde von Forschern des Lawrence Berkeley National Laboratory entwickelt: Heartbleed-Angriffe erkennen sie daran, dass die Antwort auf einen Heartbeat-Request größer als der Request ist. Was ebenso logisch wie nahe liegend ist, aber nicht viel hilft, wenn die Heartbeat-Requests gar nicht in den Logfiles auftauchen. Beschrieben wird das in einem Beitrag im Bits Blog der New York Times, dem zu Folge mit dieser Methode bei der Analyse des seit Ende Januar aufzeichneten Netzwerkverkehrs keine Angriffe auf die Netzwerke des Berkeley National Laboratory und des National Energy Research Scientific Computing Center festgestellt werden konnten. Wie schon geschrieben: Wenn man entsprechend ausführliche Logfiles (oder wie in diesem Fall den gesamten Netzwerkverkehr) auf Vorrat hat, lässt sich darin natürlich auch ein Heartbleed-Angriff nachweisen. Im Allgemeinen hat man diese Daten aber nicht.

Im gleichen Bit-Blog-Eintrag wird auch berichtet, dass nach Veröffentlichung der Schwachstelle Honeypots über Heartbleed angegriffen wurden. Was ja wohl kein Wunder ist, entsprechende Scans wurden ja auch von produktiv genutzten Servern gemeldet.

Gewinner der CloudFlare-Challenge verrät Details

Einer der Gewinner der CloudFlare-Challenge, bei der der private Schlüssel eines CloudFlare-Servers über Heartbleed ausgespäht werden sollte, hat Details zu seinem Vorgehen veröffentlicht. Er hat in den über die Heartbleed-Schwachstelle ausgespähten Daten nach den 128 Byte langen Primfaktoren des Modulus des privaten Schlüssels gesucht und daraus die restlichen Parameter des privaten Schlüssels berechnet. Der verwendete Code wurde inzwischen auf GitHub veröffentlicht.

Rund um Tests auf die Schwachstelle

Test-Tools nicht immer zuverlässig

Pedro Bueno weist im InfoSec Handlers Diary Blog darauf hin, dass die Test-Tools nicht immer zuverlässig arbeiten und unter Umständen eine verwundbare OpenSSL-Version nicht erkennen. Man sollte sicherheitshalber also mehrere Tools verwenden. Manuel Humberto Santander Pelaez hat deshalb beschrieben, wie nmap zur Prüfung der Schwachstelle verwendet wird.

Auf ein weiteres Problem beim Testen eines Server auf die Heartbleed-Schwachstelle weist Rob VandenBrink im InfoSec Handlers Diary Blog hin: Wenn die getestete SSL-Implementierung Fehler aufweist, kann der Test zu einem DoS führen. Das betrifft zumindest einige HP Proiliant Server.

Eine Test-App für Android

Trend Micro hat für Android den Trend Micro Heartbleed Detector zum Erkennen von Heartbleed-Gefahren veröffentlicht. Die App testet, ob die Android-Version des Smartphones von der Schwachstelle betroffen ist, ob eine installierte App eine betroffene OpenSSL-Version enthält und ob eine App sich mit einem betroffenen Server verbindet. Die Android-Versionsnummer sollte jeder auch ohne App prüfen können (nur Version 4.1.1 ist von der Schwachstelle betroffen), die Prüfung der Apps ist aber sehr hilfreich.

"Reverse" Heartbleed und ein Test-Tool dafür

Meldium hat sich mit dem "umgekehrten" Heartbleed auseinander gesetzt: Angriffen auf Clients. Auch ein entsprechender Online-Test wurde veröffentlicht. Während man bei Clients zuerst an klassische Clients wie Webbrowser und HTTP(S)-APIs nutzende Apps denkt, droht auch weiteren Clients Gefahr durch die Heartbleed-Schwachstelle: Allen Anwendungen, denen URLs zur Auswertung übergeben werden können, wie zum Beispiel

• der Vorschau-Funktion von Social Networks für darüber verbreitete Links,
• Thumbnail-Generatoren für Bilder, oder
• Protokollen wie OpenID oder WebFinger, die es wenig vertrauenswürdigen Benutzern erlauben, vertrauenswürdige Server zu selbst gewählten URL weiterzuleiten.

Natürlich nur dann, wenn auf dem Client eine verwundbare Version von OpenSSL läuft. Meldium hat das Test-Tool vor der Veröffentlichung getestet und dabei unter anderen eine Schwachstelle in einem nicht genannten Social Network gefunden: Ein Programm des Social Networks rief den übergebenen URL auf, um eine Vorschau zu erzeugen. Dabei wurde über die Heartbleed-Schwachstelle Speicher des Social Networks ausgelesen, der unter anderem die Ergebnisse interner API-Aufruf und Python Source-Code enthielt.

Die Schwächen des CVSS Base Score

Der zur Einstufung der Gefährlichkeit einer Schwachstelle verwendete Common Vulnerability Scoring System (CVSS) Base Score zeigt mal wieder eine altbekannte Schwäche auf: Er kann nicht alle möglichen Fälle korrekt abdecken. Was dazu führt, dass der Score für die Heartbleed-Schwachstelle nur eine relativ harmlose 5.0 ist, wie Eric Maurice in Oracles Software Security Assurance Blog bemerkt. Zwar kann die Schwachstelle ohne Authentifizierung aus der Ferne ausgenutzt werden, was sie ziemlich gefährlich macht. Die offizielle Folge eines Angriff ist aber nur die Kompromittierung weniger Daten, was den Score wieder nach unten zieht. Dass diese Daten extrem gefährlich sein können, findet keine Berücksichtigung. Wer sich also nur auf dem CVSS Score verlässt, hält diese Schwachstelle für viel harmloser als sie tatsächlich ist.

Der OpenSSL-Sourcecode im Blick

Das Unternehmen "OOO "Program Verification Systems"" hat mit seinem Tool PVS-Studio eine statische Codeanalyse der OpenSSL-Sourcecodes durchgeführt und keine schwerwiegenden Fehler gefunden. Was noch nicht viel bedeutet, denn zum Beispiel der Heartbleed-Fehler lässt sich durch eine statische Analyse gar nicht finden. Aber es ist doch etwas beruhigend, dass keine durch eine statische Analyse auffindbare Fehler vorhanden sind.

Die OpenBSD-Entwickler sind dabei, den OpenSSL-Sourcecode auszumisten. Das Ergebnis ist ein Fork, der auf den Namen LibreSSL getauft wurde. Das Ganze wird auf der Website OpenSSL Valhalla Rampage protokolliert und kommentiert. Diese Website stammt aber nicht von den OpenBSD-Entwicklern.

Spam und Phishing mit Heartbleed als Köder

Trend Micro berichtet über Spam-Mails, die die Heartbleed-Schwachstelle als Köder nutzen, um die Mailempfänger auf die Webseiten der Cyberkriminellen zu locken. Und Symantec meldet Phishing-Mails mit der Heartbleed-Schwachstelle als Köder. Die Empfänger sollen ihre Daten aktualisieren - die dann natürlich lediglich in der Datenbank der Phisher landen. Was ja auch eine Art "Aktualisierung" ist: Von "nicht vorhanden" zu "vollständige Daten abgephisht".

Weitere interessante Links

• Zunächst etwas Eigenwerbung: Auf JAXenter.de sind nach der Einführung zwei weitere Texte von mir zur Heartbleed-Schwachstelle erschienen: Was Unternehmen und Privatpersonen über Heartbleed wissen müssen - und wie Sie jetzt reagieren sollten.
• Robert Graham hat auf GitHub ein Tool veröffentlicht, dass über die Heartbleed-Schwachstelle Daten ausspähen kann: heartleech. Er hat das Tool unter anderen am Server der CloudFlare-Challenge getestet und seine Ergebnisse zusammengefasst. In den über 100 GB heruntergeladenen Daten hat er den privaten Schlüssel zuerst falsch gesucht, ist dann aber fündig geworden.
• Ben Grubb vom Sidney Morning Herald hat eine "Heartbleed disclosure timeline: who knew what and when" zusammengestellt (Stand der Entwicklung ist der 15.4.)
• Vom SANS Institute gibt es eine Sonderausgabe des monatlichen OUCH!-Newsletters: "Heartbleed - Why Do I Care?" (PDF)

Apple fixt Triple-Handshake-Schwachstelle

Und dann noch eine kleine Randnotiz: Apple hat die Triple-Handshake-Schwachstelle sowohl in Mac OS X als auch in iOS behoben.

Carsten Eilers