Heartbleed: Sind andere Dienste als HTTPS betroffen?

65

Die OpenSSL-Sicherheitsanfälligkeit "Heartbleed" ( CVE-2014-0160 ) betrifft Webserver, die HTTPS bereitstellen . Andere Dienste verwenden ebenfalls OpenSSL. Sind diese Dienste auch anfällig für Heartbleed-ähnliche Datenlecks?

Ich denke insbesondere an

  • sshd
  • sicheres SMTP, IMAP usw. - Dovecot, Exim & Postfix
  • VPN-Server - OpenVPN und Freunde

Alle, zumindest auf meinen Systemen, sind mit den OpenSSL-Bibliotheken verknüpft.

security openssl heartbleed Flup
quelle
Fix für Ubuntu: apt-get update & apt-get install openssl libssl1.0.0 & service nginx restart;
Geben Sie
Verwenden Sie dieses Tool, um die anfälligen Hosts zu erkennen: github.com/titanous/heartbleeder
Homer6
1
apt-get updateSollte Ubuntu nun ohne Downgrade ausreichen, erschien der Patch gestern Abend im Haupt-Repository.
Jason C
10
Apt-Get Update ist nicht genug. update zeigt nur die neuesten Änderungen an, apt-get UPGRADE wird dann nach dem Update angewendet.
Sjakubowski
1
Ich bin sicher, das hat @JasonC gemeint, aber +1, um es explizit zu verdeutlichen.
Craig

Antworten:

40

Jeder Dienst, der OpenSSL für seine TLS- Implementierung verwendet, ist potenziell anfällig. Dies ist eine Schwachstelle in der zugrunde liegenden Cyrptography-Bibliothek, nicht in der Darstellung über einen Webserver oder ein E-Mail-Server-Paket. Sie sollten mindestens alle verknüpften Dienste als anfällig für Datenverlust betrachten .

Wie Sie sicher wissen, ist es durchaus möglich, Angriffe miteinander zu verketten. Selbst bei den einfachsten Angriffen ist es durchaus möglich, beispielsweise mit Heartbleed SSL zu gefährden, Webmail-Anmeldeinformationen zu lesen und mit Webmail-Anmeldeinformationen über einen schnellen "Sehr geehrter Helpdesk, können Sie mir ein neues Passwort für $ foo geben, liebe CEO " .

Es gibt weitere Informationen und Links in The Heartbleed Bug und in einer anderen Frage, die von einem regulären Serverfehler gepflegt wird : Heartbleed: Was ist das und welche Möglichkeiten gibt es, dies zu verringern? .

Rob Moir
quelle
3
"Dies ist eine Schwäche im zugrunde liegenden System, nicht in der Darstellung über ein übergeordnetes System wie SSL / TLS" - Nein, das ist falsch. Dies ist eine Schwachstelle bei der Implementierung der TLS-Heartbeat-Erweiterung. Wenn Sie TLS nie verwenden, sind Sie sicher. Ich stimme jedoch Ihrer Schlussfolgerung zu, dass Sie bei der Analyse der möglichen Auswirkungen verketteter Angriffe sehr vorsichtig sein müssen.
Perseiden
6
@Perseids Sie haben natürlich Recht, ich habe versucht, einen leicht verständlichen Weg zu finden, um zu sagen, dass die Leute nicht sicher sind, weil sie diese Version von Webserver X oder diese Version von SMTP-Server Y ausführen. Ich bearbeite sie das wird hoffentlich die Dinge verbessern, also danke, dass du darauf hingewiesen hast.
Rob Moir
35

Ihre SSH-Schlüssel scheinen sicher zu sein:

Es ist erwähnenswert, dass OpenSSH nicht vom OpenSSL-Fehler betroffen ist. Während OpenSSH für einige Funktionen zur Schlüsselgenerierung openssl verwendet, verwendet es nicht das TLS-Protokoll (und insbesondere nicht die TLS-Heartbeat-Erweiterung, die Heartbleed-Angriffe ermöglicht). Es besteht also kein Grund zur Sorge, dass SSH kompromittiert wird, obwohl es immer noch eine gute Idee ist, openssl auf 1.0.1g oder 1.0.2-beta2 zu aktualisieren (aber Sie müssen sich nicht darum kümmern, SSH-Schlüsselpaare zu ersetzen). - Dr. Jimbob vor 6 Stunden

Siehe: https://security.stackexchange.com/questions/55076/what-should-one-do-about-the-heartbleed-openssl-exploit

simme
quelle
Ist es nicht indirekt betroffen, wie von @RobM angegeben? Jemand liest das root-Passwort mithilfe der Heartbleed-Sicherheitsanfälligkeit aus dem Speicher, erhält den Nicht-SSH-Zugriff auf das System und stiehlt dann das SSH-Zeug.
Thomas Weller
1
Sie können mit diesem Fehler KEINE 64 KB Speicher lesen, nur 64 KB in der Nähe des Speicherorts des eingehenden Pakets. Leider werden dort in der Regel viele Goodies gespeichert, z. B. entschlüsselte HTTP-Anforderungen mit Klartextkennwörtern, privaten Schlüsseln und Bildern von Kätzchen.
Larsr
4

Zusätzlich zur Antwort von @RobM und da Sie speziell nach SMTP fragen: Es gibt bereits einen PoC zum Ausnutzen des Fehlers in SMTP: https://gist.github.com/takeshixx/10107280

Martijn
quelle
4
Insbesondere nutzt es die TLS-Verbindung, die nach dem Befehl "starttls" hergestellt wird, wenn ich den Code richtig gelesen habe.
Perseiden
3

Ja, diese Dienste können kompromittiert werden, wenn sie auf OpenSSL basieren

OpenSSL wird beispielsweise zum Schutz von E-Mail-Servern (SMTP-, POP- und IMAP-Protokolle), Chatservern (XMPP-Protokoll), virtuellen privaten Netzwerken (SSL-VPNs), Netzwerkgeräten und einer Vielzahl von clientseitiger Software verwendet.

Weitere Informationen zu Sicherheitslücken, betroffenen Betriebssystemen usw. finden Sie unter http://heartbleed.com/.

Peter
quelle
3

Alles, was mit verknüpft ist, libssl.sokann betroffen sein. Sie sollten jeden Dienst, der mit OpenSSL verknüpft ist, nach dem Upgrade neu starten.

# lsof +c 0 | grep -w DEL | awk '1 { print $1 ": " $NF }' | grep libssl | sort -u
bacula-fd: /usr/lib/libssl.so.1.0.0
php-fpm: /usr/lib/libssl.so.1.0.0
php-fpm: /usr/lib/php/modules/openssl.so
python2: /usr/lib/libssl.so.1.0.0
python2: /usr/lib/python2.7/lib-dynload/_ssl.so
python: /usr/lib/libssl.so.1.0.0
ruby-timer-thr: /usr/lib/libssl.so.1.0.0
ruby: /usr/lib/libssl.so.1.0.0

Mit freundlicher Genehmigung von Anatol Pomozov von Arch Linux Mailing-Liste .

Nowaker
quelle
2
Alles, was mit libssl verknüpft ist und TLS verwendet. Openssh verwendet openssl, verwendet jedoch kein TLS, ist also nicht betroffen.
StasM
2
@StasM Das ist, warum ich geschrieben habe, kann betroffen sein , ist nicht betroffen . Außerdem stellt der OpenSSH- Server KEINE Verbindung zu OpenSSL her. Dienstprogramme wie ssh-keygen tun dies, werden jedoch nicht vom OpenSSH- Server selbst verwendet. Was in der von mir bereitgestellten lsof-Ausgabe deutlich zu sehen ist - OpenSSH ist dort nicht aufgeführt, obwohl es auf dem Server ausgeführt wird.
Nowaker