Heartbleed-Schwachstelle: Was Sie wissen müssen

Am 7. April 2014 wurde eine schwere Sicherheitslücke namens "Heartbleed" bekannt gegeben. Heartbleed ist eine Sicherheitslücke in der OpenSSL 1.0.1-Serie software , die in der NIST-Ankündigung CVE-2014-0160 beschrieben wird. Kurz gesagt, ermöglicht diese Schwachstelle Hackern den Zugriff auf Teile des Speichers eines anfälligen Systems, was zur potenziellen Preisgabe von Passwörtern, sensiblen Daten und privaten Zertifikatsschlüsseln auf den betroffenen Systemen führt. Heartbleed erreicht dies, indem es eine Schwachstelle in der "TLS Heartbeat Extension" ausnutzt, die den Serverspeicher offenlegt. Noch schlimmer ist, dass dieser Heartbeat-Angriff ohne das Wissen des Opfers wiederholt werden kann und der Angreifer bei jeder Wiederholung einen weiteren 64k-Snapshot des Speichers preisgibt. Diese sehr schwerwiegende Sicherheitslücke macht die sensibelsten Daten der betroffenen Systeme zugänglich.

The good news: the vulnerability has a patch. However, the widespread adoption of the OpenSSL 1.0.1 series software, coupled with the two years that this vulnerability has existed, means that the risks attributable to Heartbleed are enormous. Current estimates predict that over 500,000 systems may be vulnerable. Specifically, the Heartbleed vulnerability affects those systems that use OpenSSL 1.0.1 (a-f). Unfortunately, since this software is so widely implemented, many popular OS platforms are affected and thus vulnerable. I would suggest visiting the CERT Web Site for a more list of affected platforms. It is worth mentioning that this is a developing story, and as such, the list of affected platforms is likely to change.

Es ist wichtig zu verstehen, dass diese Sicherheitslücke nicht nur auf Webserver beschränkt ist. Angesichts der Popularität von OpenSSL, des heutigen Trends zum "Internet der Dinge" und der Tatsache, dass viele moderne Geräte jetzt mit SSL geschützten Web-Konfigurationsschnittstellen ausgeliefert werden, ist der Umfang der potenziell angreifbaren Geräte immens. Von Netzwerk-Routern bis hin zu industriellen Steuerungssystemen kann alles angreifbar sein.

Die Bestimmung des Ausmaßes der Gefährdung durch diese Schwachstelle kann für ein großes Unternehmen eine nicht triviale Herausforderung darstellen. Zur Ermittlung der Schwachstelle gehört zweifellos eine Überprüfung der betroffenen Unternehmensplattformen und der auf diesen Systemen verwendeten OpenSSL-Versionen. Wenn Sie die neueste Version von OpenSSL verwenden, gibt es darüber hinaus skriptbasierte Methoden, mit denen ein System interaktiv abgefragt werden kann, um seine Schwachstelle zu ermitteln, wie z. B. die folgende Zeile command :

echo -e "quit\n" | openssl s_client -connect 192.168.1.1:443 -tlsextdebug 2>&1 | grep 'server extension "heartbeat" (id=15)' || echo safe

Schließlich gibt es Online-Seiten, die bei Angabe eines DNS -Hosts und -Ports auf die Heartbleed-Schwachstelle prüfen können.

Wenn man feststellt, dass die eigene Website oder der eigene Server verwundbar ist, was dann? Was ist die beste Vorgehensweise?

If a server is determined to be vulnerable, then to be completely safe, one must assume that all sensitive data that may have ever been in the memory of that system has been compromised. It’s important to remember that this vulnerability has been a part of the OpenSSL code base for over 2 years. And given the untraceable nature of this exposure, there is no sure way to determine the extent of any attack, therefore all data on affected systems should be suspect.

• Alle betroffenen Konten sollten ihre Passwörter zurücksetzen lassen.
• Alle anfälligen Systemzertifikate mit privaten Schlüsseln, die nicht durch ein HSM oder eine kryptografische hardware geschützt sind, sollten widerrufen und durch Zertifikate mit neuen Schlüsseln ersetzt werden.
• Alle sensiblen Daten müssten auf ihre Gefährdung hin überprüft werden.

It’s also important to understand that this is not a compromise of PKI, SSL, TLS or X.509 certificates. Heartbleed is more of an exploit of the systems that use PKI. And as such, any new certificates that are required to re-key vulnerable systems, would be subject to the original certificate requirements that were used to create the original certificates. That said, CSS always suggests that during any certificate re-keying or re-enrollment event, an analysis of the key size, hash algorithm, and chaining requirements be performed as a part the overall certificate enrollment process.Another Heartbleed read.Contact us.