Die "HeartBleed"-Schwachstelle in OpenSSL (CVE-2014-0160)

Informationen zur "HeartBleed"-Schwachstelle in manchen Versionen der Krypto-Bibliothek OpenSSL und zu den betroffenen Systemen und Auswirkungen am Fachbereich Mathematik und Informatik

Was ist "HeartBleed"?

"Heartbleed" ist eine Schwachstelle in der verbreiteten Krypto- und SSL-Bibliothek "OpenSSL". Sie wurde am 8. April öffentlich bekannt und bestand seit der OpenSSL-Version 1.0.1 von Anfang 2012. Viele Internet-Diensteanbieter, insbesondere viele Betreiber von Webservern, verwenden OpenSSL, um die Kommunikation ihrer Nutzer mit ihren Servern zu schützen. Die "Heartbleed"-Schwachstelle ermöglicht es, bei bestehender SSL-Verbindung Daten aus dem Speicherbereich des Prozesses auf der Gegenseite der Verbindung auszulesen. Das können bei einem Webserver auch Nutzerdaten sein, die eigentlich verschlüsselt übermittelt wurden - auch Daten anderer Nutzer dieses Webservers wie z.B. deren Anmelde-Passworte für diesen Webserver. Weiterhin können u.U. die geheimen SSL-Schlüssel betroffener Webserver von einem Angreifer ausgelesen und dann damit der gesamte verschlüsselte Datenverkehr von und zu diesem Server entschlüsselt werden. Auch kann sich ein Angreifer mit diesen Server-Schlüsseln als der authentische Server ausgeben ("Man in the middle"-Angriff) und so unbefugt und unbemerkt an weitere Informationen gelangen.

Von der Schwachstelle sind bzw. waren aufgrund der großen Verbreitung der OpenSSL-Software viele Webserver-Betreiber und Anbieter von Internetdiensten betroffen.

Von der Schwachstelle betroffene Systeme am FB Mathematik und Informatik

Folgende Infrastruktur-Server des Fachbereichs waren von der Heartbleed-Schwachstelle betroffen:

• www.mi.fu-berlin.de
• www.inf.fu-berlin.de
• www.math.fu-berlin.de
• portal.mi.fu-berlin.de
• svn.imp.fu-berlin.de
• wiki.mi.fu-berlin.de
• page.mi.fu-berlin.de
• msdnaa.imp.fu-berlin.de
• moodle.imp.fu-berlin.de
• trac.imp.fu-berlin.de
• www.allegro.imp.fu-berlin.de

Darüber hinaus waren folgende Webserver

• www.mathekalender.de
• www.math-berlin.de
• facingscience.mi.fu-berlin.de
• mathlife.mi.fu-berlin.de
• pharmacometrics.mi.fu-berlin.de
• plat-forms.org
• syzygies.math.fu-berlin.de
• wiki.plat-forms.org
• www.adleaks.org
• www.ecmath.de
• www.reviewqualitycollector.org
• www.scadacs.org

sowie einige interne bzw. Test-Server betroffen.

Weiterhin betroffene Rechner:

• zentral verwaltete Linux-Arbeitsplatzrechner (mit dem nächtlichen Update vom 8. auf den 9. April wurde auf diesen Rechnern die betroffene OpenSSL-Version durch die korrigierte Version ersetzt)
• selbstverwaltete Linux-Rechner, auf denen OpenSSL >= 1.0.0 und < 1.0.1g verwendet wurde/wird

Nicht betroffen sind

• alle Windows-Betriebssysteme von Microsoft (enthält eigene SSL-Implementierung von Microsoft)
• alle Versionen von Apples OS X (enthält OpenSSL 0.9.8)
• Debian Linux "Squeeze" mit den Standard-Paketen (enthält OpenSSL 0.9.8)
• Mobil-Betriebssystem iOS (alle Versionen)
• Mobil-Betriebssystem Anrdoid (bis auf die betroffene Version Android 4.1.1 )

Einschätzung des Risikos

Zeitfenster für Angriffe

Anfang August 2012 wurden erste Server am Fachbereich auf die Debian/Linux-Version "Wheezy" und damit auf die von der Schwachstelle betroffene OpenSSL-Version umgestellt. Die Schwachstelle wurde am Abend des 7. April bekannt. Bis zum späten Vormittag des 8. April wurde die OpenSSL-Version mit der Schwachstelle auf den betroffenen zentral verwalteten FB-Servern durch die korrigierte OpenSSL-Version ersetzt. Auf den meisten betroffenen Servern wurde bis zum Abend des 10. April, auf den übrigen Servern bis zum 11. April, das SSL-Schlüsselpaar und das SSL-Zertifikat erneuert. Der Zeitraum zwischen dem öffentlichen Bekanntwerden der Schwachstelle und ihrer Schließung auf den Fachbereichs-Servern betrug aufgrund der schnellen Reaktion der IT-Dienst-Mitarbeiter nur wenige Stunden. Ab Dienstagmittag, 8.4., konnte die Schwachstelle auf den FB-Servern nicht mehr ausgenutzt werden. Inwiefern die Schwachstelle in Hacker-Kreisen bereits vor dem 8. April bekannt gewesen ist - und eventuell auch ausgenutzt wurde -, lässt sich nicht sagen.

Durchführbarkeit des Angriffs

Der Angriff ist leider, wie mittlerweile in einem öffentlichen "Wettbewerb" der Firma CloudFlare nachgewiesen wurde, praktikabel. Da er zudem keine Spuren hinterlässt, kann auch im Nachhinein nicht (anhand von Server-Logfiles o.ä.) festgestellt oder ausgeschlossen werden, ob/dass ein Angriff stattgefunden hat.

Gefährdete Daten

Durch den Angriff können Angreifer in erster Linie Schlüssel der betroffenen Webserver sowie Nutzerdaten aus dem Kontext des jeweiligen Webservers in die Hände gefallen sein. Auf einem Teil der am Fachbereich betroffenen Server könnten unter den Nutzerdaten auch FU-Accountnamen und -Passworte sein. Mit den Server-Schlüsseln ist es möglich, mitgeschnittene eigentlich verschlüsselte Verbindungen nachträglich zu entschlüsseln und so an die übertragenen Daten zu gelangen, die eigentlich dank SSL vertraulich bleiben sollten. Sofern FU-Passworte erbeutet worden sein sollten, kann mit diesen - solange sie nicht geändert wurden - auf weitere FU-Dienste und die dort zugänglichen Daten zugegriffen werden.

Empfohlene Reaktion

• Ändern Sie vorsorglich Ihr FU-Passwort! Der Passwortwechsel sollte über das Portal der ZEDAT erfolgen.
• Nutzer von zentralverwalteten Linux-Arbeitsplatzrechnern: Booten Sie, falls nach dem 8. April noch nicht geschehen, Ihren Arbeitsplatzrechner neu. Damit gehen Sie sicher, dass alle Anwendungen auf dem Rechner definitiv die neue OpenSSL-Version verwenden, die die Schwachstelle nicht mehr enthält.
• Betreiber von selbstverwalteten Linux-Rechnern :
  • Prüfen Sie, ob auf Ihrem Rechner entweder OpenSSL in einer Version < 1.0 oder >= 1.0.1g installiert ist. Diese sind nicht von der Schwachstelle betroffen. Wenn eine andere OpenSSL-Version auf Ihrem Rechner installiert ist: Aktualisieren Sie sie auf OpenSSL 1.0.1g oder neuer!
• Betreiber von selbstverwalteten SSL-Servern (Webserver und andere SSL-geschützte Dienste), sofern diese SSL/TLS anbieten und dafür OpenSSL nutzen:
  1. ggf. Updaten auf nicht mehr anfällige Version der Software bzw. von OpenSSL
  2. erst nach Schritt 1: Erneuern des SSL-Schlüsselpaares für den Server
  3. Erzeugen/Besorgen eines neuen SSL-Zertifikates zum neuen Schlüsselpaar
  4. Sperren des alten SSL-Zertifikates

Weiterführende Informationen

• "Extrablatt" der ZEDAT zu "Heartbleed"
• "Hinweis der OpenSSL-Entwickler zu "Heartbleed"
• "Heartbleed"-Infoseite der Entdecker (Codenomicon)
• "Heartbleed" bei Heise Online
• "Heartbleed"-Infoseite der Bundesamtes für Sicherheit in der Informationstechnik (BSI)