Willkommen in der Welt danachHerzblut. Wir haben unsere Server gepatcht und ersetzen unsere SSL-Zertifikate. Aber nur weil unsere Server repariert sind, heißt das nicht, dass der Rest des Internets repariert ist. Wir haben Mitarbeiter, und sie nutzen das Internet, um Geheimnisse wie Kreditkartennummern und Anmeldeinformationen auszutauschen. Sie suchen bei uns Rat.
Wir können unseren Kunden empfehlen,eine Heartbleed-Testseiteum zu sehen, ob die Site, die sie besuchen möchten, die Sicherheitslücke aufweist. Wenn eine Site positiv ausgibt, tauschen Sie keine Geheimnisse mit ihr aus. Aber wenn eine SitenichtWenn das Ergebnis für Heartnet positiv ist, kann die Situation wie folgt aussehen:
- Die Site hatte nie diese Sicherheitslücke (gut)
- Die Site hatte die Sicherheitslücke und hat sie behoben, verwendet aber immer noch das möglicherweise kompromittierte SSL-Zertifikat (fehlerhaft).
- Die Site hatte die Sicherheitslücke und hat sie behoben und das SSL-Zertifikat neu generiert, jedoch ohne die Schlüssel neu zu generieren (fehlerhaft).
- Die Site hatte die Sicherheitslücke, hat sie behoben, Schlüssel neu generiert und das SSL-Zertifikat ersetzt. (gut)
Gibt es eine Möglichkeit, unseren Mitarbeitern vor der Eingabe ihrer Kreditkartennummer in das Formular mitzuteilen,GutSzenarien aus derschlechtEinsen?
Wie weisen wir unsere Mitarbeiter an, ihre Gefährdung durch von Heartbleed kompromittierte Server zu minimieren?
Antwort1
Im Wesentlichen: Nein, es gibt keine Möglichkeit, gute von schlechten Szenarios zu unterscheiden, da Ihre Benutzer keine vollständige Übersicht über die Systeme haben, die sie verwenden.
Das Ausmaß des durch den Bug verursachten Schadens ist noch weitgehend unbekannt. Der größte Teil des Schadens wurde möglicherweise in der Vergangenheit angerichtet und wird das Internet noch lange beeinträchtigen. Wir wissen einfach nicht, welche Geheimnisse gestohlen wurden, wann und von wem.
Beispiel: Das OpenSSL-Herz von Google blutet etwa ein Jahr lang. Unbekannte Angreifer durchsuchen die Server und suchen nach interessanten Geheimnissen – auch hier können wir nicht wissen, ob sie das getan haben oder nicht –, bis sie ein Konto finden, das jemandem mit autorisiertem Zugriff auf ein anderes System gehört, beispielsweise Twitter.com oder AnyBank.co.uk oder dev.redhat.com. Mit Zugriff auf solche Konten könnten sie möglicherweise weiter graben, sich Zugang zu anderen Systemen verschaffen, anderen Schaden anrichten (sichtbar oder nicht) und weitere Konten kompromittieren – ohne dass jemand den Ursprung des Einbruchs vermutet. Zu diesem Zeitpunkt sind Sie bereits weit von den blutenden OpenSSL-Servern entfernt, und dies ist eine der schlimmeren Folgen von Heartbleed. Hinzu kommt das Risiko, dass die privaten Schlüssel der Server kompromittiert werden.
Es dauert lange, Vertrauen aufzubauen, und es kann schnell wieder verloren gehen. Ich sage nicht, dass wir vorher keine Vertrauensprobleme im Internet hatten, aber Heartbleed hat definitiv nicht geholfen. Die Behebung des Schadens wird lange dauern, und das zu verstehen, ist Teil des Verständnisses, wie Sie sich selbst und Ihre Mitarbeiter/Kunden/Chefs usw. schützen können – und wie nicht. Es gibt einige Dinge, die Sie kontrollieren können, um Ihre Gefährdung durch die Sicherheitslücke zu begrenzen, und es gibt Dinge, die Sie nicht kontrollieren können – aber sie werden Sie trotzdem betreffen. Sie können zum Beispiel nicht kontrollieren, wie alle anderen auf diese Sicherheitslücke reagieren – die NSA hat den Bug angeblich entdeckt, aber geschwiegen. Das war ziemlich schlimm für den Rest von uns, aber wir hatten keine Möglichkeit, uns davor zu schützen.
Als Internetnutzer können und sollten Sie:
- Verstehenwie schlimmder Fehler ist
- Antworten Sie NICHT auf Links in E-Mails, die Sie zum Zurücksetzen Ihres Passworts auffordern, und folgen Sie diesen nicht. Gehen Sie stattdessen direkt auf die Website des Unternehmens/der Organisation und setzen Sie Ihr Passwort aktiv zurück. In solchen Fällen gehen Betrüger gerne zum Phishing über.
- Überprüfen Sie Ihr Android-Telefon auf Heartbleed. Es gibt eineAppvon Lookout Mobile Security, das Ihre OpenSSL-Version überprüft.
Überprüfen Sie die von Ihnen besuchten Websites auf Heartbleed (unvollständige Checkliste):
Verwendet der Server OpenSSL?
- NEIN: Sie sind nicht direkt (von diesem Fehler) betroffen. Verwenden Sie die Site weiterhin, aber ändern Sie Ihr Passwort, falls ein anderer Server, der direkt oder indirekt von dem Fehler betroffen ist, Zugriff auf Ihr Passwort hatte. Dies setzt natürlich voraus, dass alle derartigen Server in diesem Netzwerk gepatcht wurden, neue Zertifikate ausgestellt wurden usw.
- Ja: Gehen Sie zu 2.
Befindet sich auf dem Server eine Heartbleed-freie Version von OpenSSL? Stellen Sie sicher, dass Ihr Heartbleed-Check-Tool tatsächlich nach der Sicherheitslücke sucht und nicht nach dem HTTP-Header oder einem anderen „Indikator“.
- NEIN: Geben Sie keine Geheimnisse an die Site weiter, aber senden Sie, wenn möglich, eine Notiz an den Webmaster.
- Ja: Gehen Sie zu 3.
Gab es bei einer früheren Version von OpenSSL Heartbleed?
- NEIN: Einige Administratoren haben nicht auf die neueste OpenSSL-Version aktualisiert, da diese nicht lange genug im Feld getestet wurde. Ihre Server waren nie anfällig für diesen Fehler, aber aus den oben genannten Gründen ist es möglicherweise trotzdem besser, Ihr Passwort zu ändern.
- Ja: Der Server war anfällig und es ist möglich, dass alle Daten im Arbeitsspeicher zwischen dem Zeitpunkt des Upgrades auf die anfällige Version und dem Zeitpunkt der Offenlegung (bis zu zwei oder sogar drei Jahre) kompromittiert wurden.
Hier kommen wir wieder zum Thema Vertrauen: Wenn Sie das Vertrauen einer Person verlieren, ist das eine schlechte Sache. Besonders, wenn es sich bei dieser Person um Ihren Benutzer/Kunden/Chef handelt. Um ihr Vertrauen zurückzugewinnen, müssen Sie wieder von vorne beginnen und sich für einen Dialog öffnen.
Um den Einstieg zu erleichtern, kann ein Webadministrator Folgendes veröffentlichen:
- Frühere OpenSSL-Version(en) (anfällig/nicht anfällig)
- Aktuelle Version und Aktualisierungsdatum
Und wenn die vorherige Version von OpenSSL anfällig war:
- Wann das aktuelle SSL-Zertifikat generiert wurde
- Detaillierte Beschreibung, wie das alte Zertifikat widerrufen wurde
- Gewährleistung, dass für das neue Zertifikat ein neues Geheimnis verwendet wurde
- Vorschläge für Benutzer basierend auf den oben genannten Informationen
Als Benutzer haben Sie das Recht, diese Informationen anzufordern, und das sollten Sie im Interesse aller Benutzer des Dienstes auch tun. Dies würde die Sichtbarkeit für die Sicherheitsgemeinschaft erhöhen und es Benutzern erleichtern, ihre Gefährdung durch kompromittierte Server zu minimieren.