Reaktionen auf den Heartbleed Bug


25. April 2014, von in IT

Die News-Seite heise Security berichtete am 08.04.2014 als eines der ersten Newsportale vom Heartbleed Bug in der OpenSSL Bibliothek.

Die Meldungen über diese kritische Schwachstelle veranlassten auch uns zu schnellem Handeln. Dieser Artikel berichtet im Nachgang darüber, wie wir dabei vorgegangen sind und was zu tun war.

Die größte Gefahr für unsere Webserver und Dienste bestand darin, dass es durch den Heartbleed Bug möglich war, sicherheitskritische Informationen aus einem verwundbaren Server auszulesen. Zu diesen Informationen zählt z.B. auch der Private-Key des Webservers, welcher für die SSL Verschlüsselung der Daten benötigt wird, welche Client und Server miteinander austauschen. Gelangt ein Angreifer in Besitz dieses Private-Key, kann er mit dessen Hilfe die Kommunikation entschlüsseln und die übermittelten Daten im Klartext lesen.

Während die Schwachstelle in OpenSSL gepatched wurde und die verschiedenen Linux Distributionen begannen aktualisierte Pakete für Updates bereitzustellen, reagierte auch der Hersteller unserer Firewall-UTM-Lösung auf die Schwachstelle. Während unsere Firewall selbst nicht von dem Bug betroffen ist, wurden für das integrierte Intrusion Prevention System (IPS) neue Signaturen veröffentlicht, welche ein Ausnutzen der Schwachstelle bereits ab dem 10.04.14 verhindern konnten. Und tatsächlich zeigt uns das Log, dass täglich mehrere Versuche blockiert wurden die Verwundbarkeit durch den Heartbleed Bug auszunutzen.

Eine Firewall-UTM-Lösung stellt in modernen Netzwerken jedoch nur die erste Verteidigungslinie vor Angriffen und Bedrohungen aus dem Internet dar. Daher wurden kurz nach der Veröffentlichung des OpenSSL-Patch die betroffenen Systeme aktualisiert, so dass sich die Schwachstelle selbst ohne vorgeschaltetes IPS nicht mehr ausnutzen lässt.

Diese beiden Maßnahmen schützen unsere Systeme nun also davor, dass der Heartbleed Bug zukünftig nicht mehr ausgenutzt werden kann, um unsere Systeme zu kompromittieren. Doch was ist, wenn der Bug bereits vor Veröffentlichung der Schwachstelle ausgenutzt wurde? Denn es ist nicht auszuschließen, dass der Private-Key eines Servers bereits Tage, Wochen oder sogar Monate vorher entwendet werden konnte. Und mit diesem Key wäre es weiterhin möglich, die eigentlich verschlüsselte Übertragung zu entschlüsseln und mitzulesen.

Um auch diesem Risiko zu begegnen, bietet GeoTrust seinen Kunden derzeit an, aktuell gültige SSL Zertifikate kostenlos zu erneuern. Hierzu werden auf den entsprechenden Servern mittels des Kommandozeilenprogramms openssl neue *.key und *.csr Dateien für eine erneute Zertifikatsanforderung generiert. Die CSR-Dateien werden dabei an GeoTrust übermittelt, damit uns neue SSL Zertifikate ausgestellt werden können.

Bevor GeoTrust die neuen Zertifikate ausstellt, erfolgt der sogenannte Verification Call. GeoTrust ermittelt hierbei eine Telefonnummer, zu dem in der Zertifikatsanforderung angegebenen Organisationsnamen. Diese Nummer wird angeblich einem öffentlichen Telefonbuch oder Adressverzeichnis entnommen. Ob dies stimmt, oder man einfach die im Kundencenter hinterlegte Telefonnummer verwendet, können wir nicht überprüfen und lassen wir mal dahingestellt. Unter dieser Nummer wird nun versucht, die im GeoTrust Kundencenter hinterlegte Person zu erreichen und die Richtigkeit der Zertifikatsanfrage zu verifizieren.

Über den Ablauf der Verification Calls mussten wir ein wenig schmunzeln. Denn es war nur wichtig, dass man bestätigte, die gewünschte Person zu sein und alle weiteren Fragen mit JA zu beantworten. Die nötigen Informationen wurden einem dabei schon in den Mund gelegt. Inwieweit dies nun zur Sicherheit beträgt, lassen wir ebenfalls mal dahingestellt.

2-3 Tage später wurden die neuen SSL Zertifikate per E-Mail zugestellt. Jetzt begann ein kleiner Hackathon, um diese in das für den jeweiligen Server kompatible Format zu konvertieren und auf allen betroffenen Servern auszutauschen.

Bereits bei fünf SSL Zertifikaten und ca. einem Dutzend Webservern ist dies ein ganz schöner Aufwand. Ich möchte gar nicht wissen, was die Admins großer Unternehmen mit einem Dutzend SSL Zertifikaten und mehreren Dutzend Webservern in den letzten Tagen leisten mussten.

Sind die neu ausgestellten Zertifikate überall installiert, können die alten über die CA widerrufen werden. Sie verlieren damit ihre Gültigkeit und sollten von den verschiedenen Webbrowsern nicht mehr akzeptiert werden. Ob dem wirklich so ist, hängt jedoch auch davon ab, wie häufig die Browser die Sperrlisten der Root-CAs abrufen.

Mit dem Abschluss der genannten Maßnahmen ist die Kommunikation zwischen Server und Client, sowie unsere Server selbst wieder sicher. Zumindest bist der nächste Horror-Bug bekannt wird.

Schreiben Sie einen Kommentar

Ihre E-Mail Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert