it-swarm.com.de

Was sollte ein Website-Betreiber gegen den Heartbleed OpenSSL-Exploit tun?

CVE-2014-016

http://heartbleed.com

Dies soll eine kanonische Frage zum Umgang mit dem Heartbeat-Exploit sein.

Ich verwende einen Apache-Webserver mit OpenSSL sowie einige andere Dienstprogramme, die auf OpenSSL (als Client) basieren. Was soll ich tun, um die Risiken zu mindern?



(Obligatory XKCD

 I looked at some of the data dumps
 from vulnerable sites,
 and it was ... bad.
 I saw emails, passwords, password hints.
 SSL keys and session cookies.
 Important servers
 brimming with visitor IPs.
 Attack ships on fire off 
 the shoulder of Orion,
 c-beams glittering in the dark
 near the Tannhäuser Gate.
 I should probably patch OpenSSL.

Bildnachweis: XKCD .

113
Deer Hunter

Es gibt mehr zu berücksichtigen als nur neue Zertifikate (oder vielmehr neue Schlüsselpaare) für jeden betroffenen Server. Es bedeutet auch:

  • Patchen betroffener Systeme auf OpenSSL 1.0.1g
  • Widerruf der alten Schlüsselpaare, die gerade abgelöst wurden
  • Alle Passwörter ändern
  • Ungültigmachen aller Sitzungsschlüssel und Cookies
  • Auswertung des tatsächlichen Inhalts, der von den anfälligen Servern verarbeitet wird, die möglicherweise durchgesickert sind, und entsprechende Reaktion.
  • Auswertung aller anderen Informationen, die aufgedeckt werden könnten, wie Speicheradressen und Sicherheitsmaßnahmen

Neel Mehta (der Google-Sicherheitsingenieur, der zuerst gemeldet den Fehler) hat getwittert :

Heap-Zuweisungsmuster machen eine Belichtung mit privaten Schlüsseln für #heartbleed #dontpanic unwahrscheinlich.

Tomas Rzepka (wahrscheinlich von der schwedischen Sicherheitsfirma Certezza ) antwortete mit dem, was sie tun mussten, um Schlüssel wiederherzustellen:

Wir können den privaten Schlüssel erfolgreich auf FreeBSD extrahieren, nachdem wir Apache neu gestartet und die erste Anfrage mit ssltest.py gestellt haben

Der Diebstahl von privaten Schlüsseln wurde auch von CloudFlare Challenge demonstriert.

Und Twitter-Benutzer makomk mischte sich ein mit :

Ich habe es von Apache auf Gentoo als Hauptfaktor für Binärdateien wiederhergestellt, aber Ihre Demo ist viel klarer ... Es hat eine niedrige Erfolgsrate, mehr Versuche mit derselben Verbindung helfen nicht, das erneute Verbinden kann, ein Neustart hat wahrscheinlich gewonnen 't ... Jemand mit anständigen Fähigkeiten zur Ausbeutung von Haufen könnte wahrscheinlich die Zuverlässigkeit verbessern. Ich versuche es nicht wirklich so sehr.


Ich habe die obigen Punkte von heartbleed.com (Hervorhebung von mir) zusammengefasst:

Was ist durchgesickertes Primärschlüsselmaterial und wie kann es wiederhergestellt werden?

Dies sind die Kronjuwelen die Verschlüsselungsschlüssel selbst . Durchgesickerte geheime Schlüssel ermöglichen es dem Angreifer, den vergangenen und zukünftigen Datenverkehr zu den geschützten Diensten zu entschlüsseln und sich nach Belieben als Dienst auszugeben. Jeder durch die Verschlüsselung und die Signaturen in den X.509-Zertifikaten gewährte Schutz kann umgangen werden. Die Wiederherstellung nach diesem Leck erfordert das Patchen der Sicherheitsanfälligkeit, das Widerrufen der gefährdeten Schlüssel sowie das erneute Ausgeben und Verteilen neuer Schlüssel. Selbst wenn Sie dies alles tun, bleibt der vom Angreifer in der Vergangenheit abgefangene Datenverkehr immer noch anfällig für Entschlüsselung. All dies muss von den Eigentümern der Dienste durchgeführt werden.

Was ist durchgesickertes Sekundärschlüsselmaterial und wie kann es wiederhergestellt werden?

Dies sind beispielsweise die Benutzeranmeldeinformationen (Benutzernamen und Kennwörter) , die in den anfälligen Diensten verwendet werden. Für die Wiederherstellung nach diesen Lecks müssen die Eigentümer des Dienstes zuerst das Vertrauen in den Dienst gemäß den oben beschriebenen Schritten wiederherstellen. Danach können Benutzer beginnen, ihre Passwörter und möglichen Verschlüsselungsschlüssel gemäß den Anweisungen der Eigentümer der Dienste zu ändern, die kompromittiert wurden. Alle Sitzungsschlüssel und Sitzungscookies sollten ungültig sein und als gefährdet gelten.

Was ist durchgesickerter geschützter Inhalt und wie kann er wiederhergestellt werden?

Dies ist der tatsächliche Inhalt, der von den anfälligen Diensten verarbeitet wird . Es kann sich um persönliche oder finanzielle Details, private Kommunikation wie E-Mails oder Sofortnachrichten, Dokumente oder alles handeln, was durch Verschlüsselung geschützt werden sollte. Nur Eigentümer der Dienste können die Wahrscheinlichkeit des Durchsickerns abschätzen und sollten ihre Benutzer entsprechend benachrichtigen. Das Wichtigste ist, das Vertrauen in das Primär- und Sekundärschlüsselmaterial wie oben beschrieben wiederherzustellen. Nur so können die gefährdeten Dienste in Zukunft sicher genutzt werden.

Was sind durchgesickerte Sicherheiten und wie kann sie wiederhergestellt werden?

Durchgesickerte Sicherheiten sind andere Details, die dem Angreifer im durchgesickerten Speicherinhalt ausgesetzt wurden . Diese können technische Details wie Speicheradressen und Sicherheitsmaßnahmen wie Kanarienvögel zum Schutz vor Überlaufangriffen enthalten. Diese haben nur einen zeitgemäßen Wert und verlieren ihren Wert für den Angreifer, wenn OpenSSL auf eine feste Version aktualisiert wurde.

64
scuzzy-delta

Direkt kopiert von OpenSSL-Site

OpenSSL Security Advisory [07. April 2014]

TLS-Heartbeat-Leseüberschreitung (CVE-2014-0160)

Eine Überprüfung fehlender Grenzen bei der Behandlung der TLS-Heartbeat-Erweiterung kann verwendet werden, um einem verbundenen Client oder Server bis zu 64 KB Speicher anzuzeigen.

Es sind nur die Versionen 1.0.1 und 1.0.2-Beta von OpenSSL betroffen, einschließlich 1.0.1f und 1.0.2-Beta1.

Vielen Dank an Neel Mehta von Google Security für die Entdeckung dieses Fehlers und an Adam Langley und Bodo Moeller für die Vorbereitung des Fixes.

Betroffene Benutzer sollten auf OpenSSL 1.0.1g aktualisieren. Benutzer, die nicht sofort aktualisieren können, können OpenSSL alternativ mit -DOPENSSL_NO_HEARTBEATS neu kompilieren.

1.0.2 wird in 1.0.2-beta2 behoben.


  • Überprüfen Sie, ob Sie die genannten Versionen von OpenSSL verwenden, wenn ja, patchen Sie sie auf 1.0.1g (indem Sie sie aus Quelle kompilieren und das Paket mit zB [~ # ~] fpm [umschließen). ~ # ~] ).

  • (Hinzufügung durch atk) Ersetzen Sie anschließend Ihre exponierten Zertifikate und widerrufen Sie sie.

  • (Ergänzung durch dr.jimbob) Es sei darauf hingewiesen, dass OpenSSH nicht vom OpenSSL-Fehler betroffen ist. Während OpenSSH openssl für einige Funktionen zur Schlüsselgenerierung verwendet verwendet nicht das TLS-Protokoll (und insbesondere die TLS-Heartbeat-Erweiterung, die Heartbleed angreift). Sie müssen sich also keine Sorgen machen, dass SSH kompromittiert wird, obwohl es immer noch eine gute Idee ist, openssl auf 1.0.1g oder 1.0.2-beta2 zu aktualisieren (Sie müssen sich jedoch keine Gedanken über das Ersetzen von SSH-Schlüsselpaaren machen).

    • (OrangeDog): @drjimbob, es sei denn, Ihre SSH-Schlüssel befinden sich im Speicher eines Prozesses, der OpenSSLs TLS verwendet. Unwahrscheinlich aber möglich.
  • (Ergänzung durch Deer Hunter): Gemessen an den aktiven Versuchen, die im DMZ gemeldet werden, ist das Beste jetzt STOPPING DER FRIKKIN-SERVER SO SCHNELL WIE MÖGLICH . Sitzungen werden entführt, Passwörter durchgesickert und vertrauliche Geschäftsdaten enthüllt.

  • (Ein zusätzliches bisschen mit freundlicher Genehmigung von EFF.org ): "Um zu einer genaueren Schlussfolgerung über die Geschichte von Heartbleed zu gelangen, ist es für die Netzwerkgemeinschaft am besten, zu versuchen, die Ergebnisse von Koeman zu replizieren. Alle Netzwerkbetreiber, die über umfangreiches TLS verfügen -Layer-Verkehrsprotokolle können nach böswilligen Herzschlägen suchen, die am häufigsten eine TCP Nutzlast von 18 03 02 00 03 01 40 00 oder 18 03 01 00 03 01 40 00 haben, obwohl die 0x4000 bei Das Ende kann durch niedrigere Zahlen ersetzt werden, insbesondere bei Implementierungen, bei denen versucht wird, mehrere Malloc-Chunk-Bins zu lesen. "Kurz gesagt, wenn Sie detaillierte TLS-Protokolle führen (für die Mehrheit der Betreiber dort draußen wahrscheinlich nicht wahrscheinlich), suchen Sie nach früheren Ausnutzungsversuchen ( und teile was du hast).


Verwandte Fragen und Antworten zu ServerFault:

https://serverfault.com/questions/587338/does-heartbleed-affect-aws-elastic-load-balancer

https://serverfault.com/questions/587329/heartbleed-what-is-it-and-what-are-options-to-mitigate-it

https://serverfault.com/questions/587348/best-method-to-update-ubuntu-13-10-to-path-the-heartbleed-bug

https://serverfault.com/questions/587324/heartbleed-how-to-reliably-and-portably-check-the-openssl-version

Eine gut geschriebene Zusammenfassung bei AskUbuntu: https://askubuntu.com/a/444905

Eine umfassende Frage und Antwort bei Unix & Linux SE: https://unix.stackexchange.com/questions/123711/how-do-i-recover-from-the-heartbleed-bug-in-openssl

Wenn Sie zufällig einen Server unter Mac OS X ausführen: https://Apple.stackexchange.com/questions/126916/what-versions-of-os-x-are-affected-by-heartbleed =

Abrufen eines privaten SSL-Schlüssels mithilfe von Heart Bleed: http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed Ja, es ist möglich!

21
hoa

[bearbeitet]

Ich habe ein Tool erstellt, um den Status Ihres SSL zu überprüfen und festzustellen, ob der Heartbeat aktiviert und anfällig ist. Tool unter: http://rehmann.co/projects/heartbeat/

Es gibt noch eine unter http://filippo.io/Heartbleed/

Wenn Sie anfällig sind, aktualisieren Sie bitte Ihre OpenSSL-Pakete und erneuern Sie Ihre Zertifikate!

9
Luke Rehmann

Jspenguin hat ein Offline-Tool geschrieben, um zu überprüfen, ob ein Server den Fehler aufweist. Laden Sie es herunter, prüfen Sie es und führen Sie es aus.

Ich habe auch ssl-heartbleed-check.pl (auch ein Offline-Tool) geschrieben, um zu überprüfen, ob die von Ihrem Perl-Stack verwendete OpenSSL (die auf * n * x häufig die vom Ganzen verwendete openssl ist) System) betroffen ist. Auf diese Weise können Sie feststellen, ob Sie auf der Clientseite betroffen sind.

Nmap 6.45 enthält ein ssl-heartbleed Skript. ssl-heartbleed.nse kann auch zusammen mit nmap ≥6.25 verwendet werden.

3
dolmen

Beachten Sie, dass, wenn Sie einen Cloud-basierten Anbieter oder ein Content-Distributionsnetzwerk verwenden und diese anfällig sind, der undichte Inhalt Ihrer Website mit dem Inhalt aller anderen Websites gemischt wird, die diesen Anbieter verwenden. Ich habe gerade habe das gerade mit Incapsula gesehen , wo der Inhalt einer Bank-Website entlang der Kryptowährungs-Website durchgesickert ist. Sie sind jetzt zum Glück behoben.

3
kravietz