PHPGangsta - Der praktische PHP Blog

PHP Blog von PHPGangsta


OpenSSL: Heartbleed

with 5 comments

heartbleedIhr habt es wahrscheinlich schon alle mitbekommen, es klafft ein riesiges Loch in der häufig eingesetzten OpenSSL-Bibliothek. Webserver, Mailserver, Jabberserver, alles was irgendwie mit Verschlüsselung zu tun hat ist gefährdet. Ist bereits OpenSSL 1.0.1 bis 1.0.1f im Einsatz (das ist die aktuelle Version, seit 2 Jahren verfügbar) steht ein dringendes Update an auf 1.0.1g.

Nicht betroffen sind OpenSSL 1.0.0 und 0.9.8. Nicht betroffen ist auch OpenSSH (wichtiger Unterschied).

Die Lücke hat den Namen “Heartbleed” bekommen und ist unter der CVE-Nummer CVE-2014-0160 verzeichnet.

Mit Hilfe dieser Lücke können Angreifer auf “die nächsten 64KB” des Arbeitsspeichers des Prozesses zugreifen. “Die nächsten” ist aber variabel, je nachdem wo er gerade landet im Arbeitsspeicher, sodass mit einer gewissen Wahrscheinlichkeit auch der private SSL-Schlüssel zu finden ist. Dieser kann nun von außen ausgelesen werden, ohne dass es Logeinträge gibt, also völlig unsichtbar. Mit Hilfe dieses Private Keys kann der Angreifer die aufgezeichneten Trafficdaten der Vergangenheit entschlüsseln, aber auch in Echtzeit in der Zukunft den Traffic entschlüsseln. Er kann außerdem per Man-in-the-Middle anderen vorgaukeln dass sein Server gültig ist für die jeweilige Domain, und damit Phishing betreiben.

Sehr ausführliche Informationen befinden sich auf der Seite heartbleed.com.

Was ist zu tun:

  1. Herausfinden welche Software betroffen ist. Die meisten Dienste nutzen die OpenSSL Bibliothek dynamisch, greifen also auf die installierte Version des Betriebssystems zurück. Es gibt aber auch Dienste die es statisch linken, die die Biblipthek also beim Kompilieren mit in die executable reinpacken. Beide muss man finden und dann updaten. Zu nginx gibt es beispielsweise eine schöne Anleitung wie man das herausbekommt, wie das bei den anderen Programmen geht muss man individuell nachschauen: http://nginx.com/blog/nginx-and-the-heartbleed-vulnerability/
  2. Stoppe den Dienst bzw. die Dienste
  3. OpenSSL updaten auf mindestens 1.0.1g oder rekompiliere OpenSSL ohne Heartbeat support
  4. statisch gelinkte Programme separat updaten
  5. Reboot des Systems, damit alle Dienste die neue OpenSSL Version verwenden
  6. Da davon ausgegangen werden muss dass der Private Key gestohlen wurde (man sieht es in keinem Logfile), muss das Zertifikat ausgetauscht werden. Es muss also das Zertifikate “reissued” werden mit einem neuen Private Key und dann das neue Zertifikat installiert werden!
  7. Das alte Zertifikat muss revoked werden, damit es nicht für Man-in-the-Middle-Attacken genutzt werden kann.

Hier einige Beispiele, was alles betroffen sein könnte:

  • Webserver: Apache, nginx, Tomcat, Apache SPDY Modul
  • Mailserver: Exim, Postfix, Dovecot
  • Andere: Jabber, HAProxy, CouchDB, ProFTPd

Mit dem folgenden Befehl kann herausgefunden werden welche Software auf OpenSSL aufbaut:

apt-cache rdepends libssl1.0.0 | tail -n +3 | xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii lib'

Mit den folgenden Online-Tools kann man seine Webserver überprüfen. Leider gibt es noch keine Online-Tests beispielsweise für SMTP-STARTTLS oder Jabber etc, da muss man auf kleine Python oder Perl-Scripte zurückgreifen. Denn wie gesagt betrifft es nicht nur Webserver, sondern alle Dienste die irgendetwas mit SSL bzw. TLS am Hut haben.

Je nachdem wie viele Dienste, Server und Zertifikate man hat darf man also gut und gerne einige Stunden Arbeit investieren.

Da es bereits Module gibt für Metasploit, Nessus, Nmap und Co. gibt muss man davon ausgehen dass die Lücke bereits in großem Umfang ausgenutzt wird. Aktuell kann man nur empfehlen sich nirgends einzuloggen und ein paar Tage auf die noch nicht gefixten Dienste zu verzichten, wie beispielsweise Yahoo, Microsoft, flickr, web.de, stackoverflow und viele weitere. Online-Banking würde ich vielleicht auch ein paar Tage nicht nutzen, oder vorher alle Domains und Subdomains der Bank überprüfen. Und dann sollte man in naher Zukunft seine Passwörter ändern bei den wichtigen Diensten, sicher ist sicher, denn wer weiß ob Hacker diese Lücke nicht schon vor 2 Jahren gefunden haben und seitdem auf Sammeltour sind?

Nebenbei wurde ein Sicherheitspatch für WordPress veröffentlicht, der per Autoupdate auf die Systeme gekommen sein sollte (Wer hat alles noch kein Update aktiviert?). Es war wohl möglich sich an der Authentifizierung von WordPress vorbeizuschleichen. Eigentlich auch eine üble Sache, aber im Lichte des OpenSSL-Problems aktuell nebensächlich.

Written by Michael Kliewe

April 9th, 2014 at 4:34 pm

5 Responses to 'OpenSSL: Heartbleed'

Subscribe to comments with RSS or TrackBack to 'OpenSSL: Heartbleed'.

  1. Ich bin jetzt auch schon seit 2 Tagen dran, die entsprechenden Programme zu aktualisieren und die Gefahren abzuschätzen. Positiv ist schon mal, dass der Zugriff auf den Speicher nicht gezielt statt findet, sondern eher zufällig ist. Trotzdem ist es natürlich ein großes Problem. Generell ist es immer eine gute Idee, den Webserver nicht im Rootsystem laufen zu haben und nur mit eingeschränkten Rechten. Ausserdem ist PFS ein gutes Mittel, um wenigstens die übertragenen Daten zu sichern.

    Das Zertifikat sollte man zwar zurück ziehen, aber es nutzt nicht wirklich viel, da die meisten Browser gar nicht mehr auf die „Revokation List“ prüfen. Dieses ganze TLS System ist einfach sowas von Grund auf kaputt, dass man manchmal echt nicht weiß, wie man da noch was retten kann.

    Oliver

    9 Apr 14 at 20:24

  2. Update 11:30, 11.4.2014: Größe des maximal möglichen Speicherblocks korrigiert. Ursprünglich waren als Obergrenze die in der Originaldokumentation des Heartbleed-Bugs aufgeführten 64 KByte angegeben. Die RFCs und auch die Demo-Exploits lassen jedoch nur maximal 16 KByte zu

    http://www.heise.de/security/artikel/So-funktioniert-der-Heartbleed-Exploit-2168010.html

    Andreas

    15 Apr 14 at 10:54

  3. Nö, unser XMPP-Server ist davon nicht betroffen ;-)

  4. Ich habe noch eine unterhaltsame Anekdote.

    Und zwar hatte ich den Bug der HypoVereinsbank gemeldet (ich bin sicher andere haben das auch getan).

    Zunächst passierte nichts. Dann bekam ich eine sehr kuriose Mail vom Support: der Bug sei behoben.

    Die Zertifikate (so teilte mir die Bank auf Nachfrage mit) müssen aber nicht getauscht werden, weil “wir haben Systemarchitektur”.

    Ich habe zurückgeschrieben und bezweifelt, dass eine “Systemarchitektur” tatsächlich den Austausch der Zertifikate unnötig macht.

    Kurze Zeit nach diesem Hinweis waren die Zertifikate dann tatsächlich getauscht und ich bekam erneut Post.
    Man wolle sich korrigieren: der Austausch der Zertifikate sei unnötig, nicht wegen “Systemarchitektur” sondern wegen “Sicherheitsarchitektur”.

    Natürlich könne man mir nicht sagen welche “Sicherheitsarchitektur” das sein solle. Aus “Sicherheitsgründen”.

    Ferner schrieb mir die Bank: Meinen PIN für das Online-Banking bräuchte ich nicht zu ändern – denn dank Ihrer “Sicherheitsarchitektur” wäre alles absolut sicher.

    Ich war schwer beeindruckt. Die HypoVereinsbank kann Voodoo!
    Mit geheimer Ninja-Sicherheitsarchitektur!

    Endlich, so frohlockte ich, war die Welt wieder in Ordnung. Dank “Hypo”-Gandalf dem Vereinten. “This is not the SSL-bug you are looking for!”

    Jetzt mal ernsthaft: Übersehe ich hier etwas ganz Grundlegendes und war der Heartbleed-Bug doch nicht auf der Verschlüsselungsebene? Ich dachte immer an dieser Stelle könne keine System- oder Sicherheitsarchitektur egal welcher Art irgendwas bringen, weil all das erst nach dem Entschlüsseln der Daten passiert. Das habe ich doch schon richtig verstanden. Korrigiert mich bitte, falls ich da irgendeinen geheimen Trick übersehen habe.

    Ich dachte immer, das wäre wie bei einem Wasserrohr: wenn das Rohr ein Loch hat ist es ganz egal welchen Hokus-Pokus man hinter dem Rohr veranstaltet, das Wasser läuft trotzdem raus. Kann mich freilich irren: bin ja kein Klempner. Oder ich verstehe einfach nur keinen blassen Dunst von den geheimen Ninja-Servern der HypoVereinsbank.

    Markus

    23 Apr 14 at 18:23

  5. @Markus: Die dürfen aus naheliegenden Gründen nicht verraten was sie da für eine Architektur haben.

    ABER: ich könnte mir vorstellen dass Banken Intrusion-Detection-Systeme haben, und auch eventuell sogenannte “Network-Recorder”. Die zeichnen den kompletten Netzwerktraffic auf, sodass man darin nachträglich nach Angriffen suchen kann usw. Nur mit Hilfe solcher Geräte kann man sich anschauen ob jemand den Bug ausgenutzt hat und auch schauen ob der Private Schlüssel geklaut wurde. Da ich annehme dass Banken diese 6-stelligen Beträge ausgeben könnte es also sein dass die solch einen Network-Recorder haben, dann die letzten X Tage durchgeschaut haben und gesehen haben dass niemand den Bug ausgenutzt hat, demnach die Zertifikate bzw. Kundenpasswörter sicher sind.

    Ist nur eine Mutmaßung, aber mit einem solchen Recorder kann man feststellen ob einem der Private Key oder Kundenpasswörter abhanden gekommen sind oder nicht. Für ein paar hunderttausend Euro bekommt man solche Geräte mit 100 TB Festplatten drin, da kann man dann einige Tage oder Wochen den Traffic aufzeichen.

    Michael Kliewe

    30 Apr 14 at 12:25

Leave a Reply

You can add images to your comment by clicking here.