it-swarm.com.de

Heartbleed: Was ist das und welche Möglichkeiten gibt es, um es zu mildern?

Dies ist eine kanonische Frage zum Verständnis und zur Behebung des Heartbleed-Sicherheitsproblems.

Was genau ist CVE-2014-0160 AKA "Heartbleed"? Was ist die Ursache, welche Betriebssysteme und Versionen von OpenSSL sind anfällig, was sind die Symptome, gibt es Methoden, um einen erfolgreichen Exploit zu erkennen?

Wie kann ich überprüfen, ob mein System betroffen ist? Wie kann diese Sicherheitsanfälligkeit verringert werden? Sollte ich mir Sorgen machen, dass meine Schlüssel oder andere private Daten kompromittiert wurden? Welche anderen Nebenwirkungen sollte ich befürchten?

203
Jacob

Stellen Sie zunächst sicher, dass Sie verstehen, ob diese Sicherheitsanfälligkeit tatsächlich auf Sie zutrifft, bevor Sie ausflippen. Wenn Sie einen Server haben, aber noch nie Anwendungen mit TLS hatten, ist dies für Sie keine Aufgabe mit hoher Priorität. Wenn Sie andererseits schon einmal TLS-fähige Anwendungen hatten, dann sind Sie hier genau richtig. Weiter lesen:

Was genau ist CVE-2014-0160 alias "Heartbleed"?

Es ist ein großes Durcheinander, das ist es. Kurz gesagt, in den OpenSSL-Versionen 1.0.1 bis 1.0.1f wurde eine aus der Ferne ausnutzbare Sicherheitsanfälligkeit entdeckt, durch die ein Angreifer bestimmte Teile des Systemspeichers lesen kann. Diese Teile enthalten vertrauliche Daten wie private Schlüssel, vorinstallierte Schlüssel, Kennwörter und hochwertige Unternehmensdaten.

Der Fehler wurde unabhängig von Neel Mehta von Google Security (21. März 2014) und dem finnischen IT-Sicherheitstestunternehmen Codenomicon (2. April 2014) entdeckt.

Was ist die Ursache?

Nun, fehlerhafter Code in OpenSSL. hier ist das Commit, das die Sicherheitsanfälligkeit eingeführt hat, und hier ist das Commit, das die Sicherheitsanfälligkeit behoben hat. Der Fehler trat im Dezember 2011 auf und wurde heute, am 7. April 2014, behoben.

Der Fehler kann auch als Symptom eines größeren Problems angesehen werden. Die beiden damit verbundenen Probleme sind (1) welcher Prozess vorhanden ist, um sicherzustellen, dass fehlerhafter Code nicht in eine Codebasis eingeführt wird, und (2) warum die Protokolle und Erweiterungen so komplex und schwer zu testen sind. Punkt (1) ist ein Governance- und Prozessproblem bei OpenSSL und vielen anderen Projekten. Viele Entwickler widersetzen sich einfach Praktiken wie Codeüberprüfungen, Analysen und Scannen. Punkt (2) wird in der TLS-Arbeitsgruppe der IETF erörtert. Siehe Heartbleed/Protokollkomplexität .

Wurde der fehlerhafte Code böswillig eingefügt?

Ich werde nicht darüber spekulieren, ob dies wirklich ein Fehler war oder möglicherweise ein bisschen Code, der für einen schlechten Schauspieler eingegeben wurde. Die Person, die den Code für OpenSSL entwickelt hat, gibt jedoch an, dass er versehentlich war. Siehe Mann, der eine schwerwiegende 'Heartbleed'-Sicherheitslücke eingeführt hat, bestreitet, sie absichtlich eingefügt zu haben .

Welche Betriebssysteme und Versionen von OpenSSL sind anfällig?

Wie oben erwähnt, jedes Betriebssystem oder jede Anwendung, die mit OpenSSL 1.0.1 bis 1.0.1f verknüpft ist.

Was sind die Symptome, gibt es Methoden, um einen erfolgreichen Exploit zu erkennen?

Dies ist der beängstigende Teil. Soweit wir wissen, ist nicht bekannt, ob diese Sicherheitsanfälligkeit ausgenutzt wurde oder nicht. Es ist theoretisch möglich, dass bald IDS-Signaturen veröffentlicht werden, die diesen Exploit erkennen können, aber zum jetzigen Zeitpunkt sind diese nicht verfügbar.

Es gibt Hinweise darauf, dass Heartbleed bereits im November 2013 in freier Wildbahn aktiv ausgebeutet wurde. Siehe EFFs Wild at Heart: Haben Geheimdienste im November 2013 Heartbleed eingesetzt? Und Bloomberg berichtet, dass NSA hatte den Exploit kurz nach Einführung der Sicherheitsanfälligkeit bewaffnet. Siehe NSA soll Heartbleed Bug for Intelligence jahrelang ausnutzen . Die US-Geheimdienstgemeinschaft bestreitet jedoch Bloombergs Behauptungen. Siehe IC ON THE RECORD .

Wie kann ich überprüfen, ob mein System betroffen ist?

Wenn Sie OpenSSL auf Ihrem System verwalten, können Sie einfach openssl version Ausgeben:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Wenn die Distribution verwaltet OpenSSL, dann können Sie wahrscheinlich die Version von OpenSSL aufgrund von Back-Patches mit dem Befehl openssl oder den Paketinformationen (z. B. apt-get, dpkg, yum oder rpm). Der von den meisten (allen?) Distributionen verwendete Back-Patching-Prozess verwendet nur die Basisversionsnummer (z. B. "1.0.1e"). und enthält nicht eine effektive Sicherheitsversion (zum Beispiel "1.0.1g").

Es gibt eine offene Frage zu Super User, um die effektive Sicherheitsversion für OpenSSL und andere Pakete zu ermitteln, wenn Pakete zurückgepatcht werden. Leider gibt es keine nützlichen Antworten (außer auf der Website der Distribution). Siehe Bestimmen der effektiven Sicherheitsversion bei Backpatching ?.

Als Faustregel gilt: Wenn Sie jemals eine der betroffenen Versionen installiert und Programme oder Dienste ausgeführt haben, die mit OpenSSL für TLS-Unterstützung verknüpft sind, sind Sie anfällig.

Wo finde ich ein Programm zum Testen der Sicherheitsanfälligkeit?

Innerhalb weniger Stunden nach der Ankündigung von Heartbleed hatten mehrere Personen im Internet öffentlich zugängliche Webanwendungen veröffentlicht, mit denen angeblich ein Server auf das Vorhandensein dieser Sicherheitsanfälligkeit überprüft werden konnte. Zum jetzigen Zeitpunkt habe ich noch keine geprüft, daher werde ich ihre Bewerbungen nicht weiter veröffentlichen. Sie können mit Hilfe Ihrer bevorzugten Suchmaschine relativ leicht gefunden werden.

Wie wird diese Sicherheitsanfälligkeit gemindert?

Aktualisieren Sie auf eine nicht anfällige Version und setzen Sie anfällige Daten zurück oder sichern Sie sie erneut. Wie auf der Website Heartbleed angegeben, sind die entsprechenden Antwortschritte im Großen und Ganzen:

  1. Patch anfällige Systeme.
  2. Generieren Sie neue private Schlüssel neu.
  3. Senden Sie neue CSR an Ihre Zertifizierungsstelle.
  4. Erhalten und installieren Sie ein neues signiertes Zertifikat.
  5. Ungültige Sitzungsschlüssel und Cookies
  6. Setzen Sie Passwörter und gemeinsame Geheimnisse zurück
  7. Alte Zertifikate widerrufen.

Eine detailliertere Analyse und Antwort finden Sie unter Was sollte ein Website-Betreiber gegen den Heartbleed OpenSSL-Exploit tun? auf dem Security Stack Exchange.

Sollte ich mir Sorgen machen, dass meine Schlüssel oder andere private Daten kompromittiert wurden? Welche anderen Nebenwirkungen sollte ich befürchten?

Absolut. Systemadministratoren müssen annehmen, dass ihre Server, die anfällige OpenSSL-Versionen verwendet haben, tatsächlich kompromittiert sind und entsprechend reagieren.

Kurz nachdem die Sicherheitsanfälligkeit bekannt wurde, bot Cloudfare eine Herausforderung an, um festzustellen, ob der private Schlüssel eines Servers in der Praxis wiederhergestellt werden kann. Die Herausforderung wurde unabhängig von Fedor Indutny und Ilkka Mattila gewonnen. Siehe The Heartbleed Challenge .

Wo finde ich weitere Informationen?

Link Dump, für diejenigen, die mehr Details suchen:


Eine ziemlich detaillierte Zeitleiste der Offenlegungsereignisse finden Sie unter Heartbleed-Offenlegungszeitleiste: Wer wusste was und wann .


Wenn Sie ein Programmierer sind und an verschiedenen Programmiertricks interessiert sind, z. B. dem Erkennen eines Heartbleed-Angriffs durch den Rückruf von OpenSSL msg_cb, Siehe OpenSSLs Security Advisory 2014047 .

116
EEAA

Eine einfache Erklärung des Fehlers von XKCD:

(XKCD 1354

43
200_success

Ubuntu 12.04, 12.10 und 13.10

Ubuntu hat SN-2165-1 ausgegeben, das besagt, dass aktualisierte Pakete jetzt in den Archiven verfügbar sind. Führen Sie die folgenden zwei Befehle aus, um das Update zu erhalten.

Sudo apt-get update
Sudo apt-get upgrade

Ubuntu 14.04

Ich habe ein Debian-Paket mit der neuen Version (1.0.1g) auf eine PPA hochgeladen, die ich für diesen Zweck eingerichtet habe. Diese drei Befehle fügen meinem System meine PPA hinzu, aktualisieren die Liste der verfügbaren Pakete und aktualisieren alles:

Sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
Sudo apt-get update
Sudo apt-get upgrade

Hinweis: Die PPA bietet auch Pakete für Ubuntu 12.04 und 13.10, nur für den Fall, dass Sie die neue Version (1.0.1g) lieber ausführen möchten, anstatt nur die gepatchten Versionen in den Archiven zu verwenden.

Ubuntu 10.04

Dies ist eine LTS-Version. Die Serverversion wird weiterhin unterstützt und erhält Sicherheitsupdates. Die Heartbleed-Sicherheitsanfälligkeit hatte jedoch keine Auswirkungen auf das openssl-Paket einer Standardinstallation von Ubuntu 10.04, da die Version unter 1.0.1 liegt.

Die Desktop-Version hat das Ende ihrer Lebensdauer erreicht und muss aktualisiert/neu installiert werden.

Ubuntu 13.04 und andere veraltete Versionen

Ubuntu 13.04 hatte einen sehr kurzen Support-Zyklus, den Sie vielleicht nicht erwarten. Es hat bereits das Ende seiner Lebensdauer erreicht und erhält keine Sicherheitsupdates mehr. Es sollte lange aktualisiert worden sein. Wenn es immer noch von jemandem verwendet wird, aktualisieren Sie es jetzt entweder von Grund auf neu oder es kann zerstörungsfrei auf 13.10 aktualisiert werden. Gehen Sie dazu folgendermaßen vor: http://www.tecmint.com/upgrade-ubuntu-13-04 -raring-ringtail-to-ubuntu-13-10-saucy-salamander / Nach dem Upgrade erhält das System den Heartbleed-Patch von 13.10.

Für alle anderen veralteten Ubuntu-Versionen bedeutet dies, dass grundsätzlich eine Neuinstallation erforderlich ist.

Stellen Sie sicher, dass der Patch angewendet wurde

Führen Sie im Wesentlichen openssl version -a und stellen Sie sicher, dass das Erstellungsdatum der 7. April 2014 oder später ist, aber sehen Sie mehr hier .

Starten Sie neu

Der beste Weg, um sicherzustellen, dass alle von OpenSSL abhängigen Dienste neu gestartet werden, ist Neustart .

36
Nathan Osman

RedHat 6.5 und CentOS 6.5

Diese sind anfällig. RedHats Erratum RHSA-2014-0376 sagt, dass gepatchte Bibliotheken verfügbar sind und alle Betroffenen zum frühestmöglichen Zeitpunkt ein Upgrade durchführen sollten.

Zum Zeitpunkt des Schreibens hatte CentOS noch keine feste Version, aber Karanbir Singhs Posting bei CentOS-Announce sagt, dass sie eine aktualisierte Version von openssl (openssl-1.0.1e-16.el6_5.4.0.1, beachten Sie die letzten vier wichtigen Ziffern, bei denen der ausnutzbare TLS-Befehl deaktiviert ist und die sicher angewendet werden können, da er bei seiner Veröffentlichung von einer festen Version überschrieben wird.

Die vorübergehend festgelegte Version scheint es noch nicht auf alle Spiegel geschafft zu haben, befindet sich jedoch im Haupt-Repository unter http://mirror.centos.org/centos/6/updates/x86_64/Packages/). (und ähnlich für i686).

Bearbeiten : Wie Iain sagt, scheint es jetzt eine vollständig gepatchte Version für C6.5 zu geben, und sie scheint um die Spiegel geschoben worden zu sein in Eile. Eine gerade yum update habe es für meine Server bekommen; es ist openssl-1.0.1e-16.el6_5.7.

Versionen von RH6 und C6 vor 6.5

Diese sind nicht anfällig. Laut dieser Hinweis von Red Hat ,

Dieses Problem hatte keine Auswirkungen auf die Versionen von openssl, die mit Red Hat Enterprise Linux 5 und Red Hat Enterprise Linux 6.4 und früheren Versionen ausgeliefert wurden.

Karanbir Singhs Posting bei CentOS-Announce ist ebenso klar über die Versionierung:

Wir wurden heute früher auf ein ernstes Problem in openssl aufmerksam gemacht, das in CentOS-6.5 ausgeliefert wurde

14
MadHatter

Debian Wheezy

Debian hat DSA-2896-1 ausgegeben und gepatchte Bibliotheken sind hier verfügbar . Ein Shell-Skript ist hier verfügbar .

1. Patch

Das Apt-Get-Repository wurde aktualisiert, sodass jetzt gepatchte Bibliotheken über apt-get update && apt-get upgrade Verfügbar sind.

apt-get upgrade libssl1.0.0 openssl

Alternativ (nicht empfohlen) können die Pakete manuell aktualisiert werden:

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_AMD64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_AMD64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_AMD64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_AMD64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_AMD64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_AMD64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_AMD64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_AMD64.deb

2. Server/Dienste neu starten

Starten Sie für den besten Schutz den gesamten Server neu. Wenn der Server nicht offline sein kann, starten Sie die erforderlichen Dienste neu.

3. Überprüfen Sie die OpenSSL-Version

[email protected]:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
[email protected]:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  AMD64            SSL shared libraries
13
jacksoncage

FreeBSD 10.0 oder openssl von Ports

Das FreeBSD-Sicherheitsteam hat einen Hinweis zu CVE-2014-0160 (auch bekannt als "Heartbleed") und: FreeBSD-SA-14: 06.openssl herausgegeben

  1. Aktualisieren von FreeBSD

    • Aktualisieren von FreeBSD über einen binären Patch

      Systeme, auf denen eine RELEASE-Version von FreeBSD auf den Plattformen i386 oder AMD64 ausgeführt wird, können dies über das Dienstprogramm freebsd-update (8) aktualisiert werden:

      # freebsd-update fetch
      # freebsd-update install
      
    • Aktualisieren von FreeBSD aus den Quellen

      1. Laden Sie den entsprechenden Patch von der unten angegebenen Position herunter und überprüfen Sie die getrennte PGP-Signatur mit Ihrem PGP-Dienstprogramm.

        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
        # gpg --verify openssl-10.patch.asc
        
      2. Führen Sie die folgenden Befehle als root aus:

        # cd /usr/src
        # patch < /path/to/patch
        
      3. Kompilieren Sie das Betriebssystem neu

        verwenden von buildworld und installworld wie im FreeBSD-Handbuch beschrieben.

  2. Aktualisieren Sie den Port openssl mit der Mindestversion 1.0.1_10

  3. Starten Sie alle Daemons mithilfe der Bibliothek neu oder starten Sie das System neu

  4. Stellen Sie sich so vor, als wäre Ihr System kompromittiert, und geben Sie alle Ihre SSL-Schlüssel und/oder Zertifikate sowie möglicherweise durchgesickerte Informationen erneut aus (siehe EEAA allgemeinere Antwort).

FreeBSD 9.x und FreeBSD 8.x

Diese Systeme sind standardmäßig nicht anfällig für das Problem Heartbleed, da sie auf der älteren Version 0.9.x der Bibliothek openssl basieren , es sei denn, Sie haben openssl von den Ports installiert (siehe oben).

Wenn diese Systeme nicht für das Problem Heartbleed anfällig sind, ist es möglicherweise ratsam, Ihr System aufgrund einer anderen Sicherheitsanfälligkeit local eher früher als später zu aktualisieren (siehe FreeBSD-))). SA-14: 06.openssl und der Abschnitt "FreeBSD 10.0" oben):

Ein lokaler Angreifer kann möglicherweise einen Signaturprozess überwachen und den Signaturschlüssel daraus wiederherstellen. [CVE-2014-0076]

Hinweis :

In der ursprünglichen Empfehlung Heartbleed sind FreeBSD 8.4 und 9.1 als potenziell anfällig aufgeführt. Dies ist nicht der Fall, da Heartbeat Extension fehlt (die Standard-OpenBSD-OpenSL-Bibliothek ist Version 0.9.x).

9
Ouki

Ich möchte darauf hinweisen, dass private Schlüssel nicht die einzigen Vermögenswerte sind, die als gefährdet angesehen werden sollten. Der Fehler kann zu einem Verlust von beliebigem Speicher führen, der im selben Adressraum (d. H. Im selben Prozess) wie OpenSSL ausgeführt wird. Wenn Sie also einen Serverprozess ausführen, bei dem eine anfällige Version von OpenSSL statisch oder dynamisch verknüpft ist, alle Informationen, die dieser Prozess jemals verarbeitet hat, einschließlich Kennwörtern, Kreditkartennummern und anderen persönlichen Daten sollte als potenziell gefährdet angesehen werden.

9
200_success

Ich fand es nahezu unmöglich, die Versionen von SSL zu bestimmen, die auf mehreren Appliances verwendet werden, mit denen ich arbeite. Obwohl es technisch gesehen keine Minderung ist, derzeit gefährdete Hosts identifizieren zu können, stand sie ganz oben auf meiner Liste.

Ich habe ein kleines VM zusammengestellt, das mit FiloSottiles Testmodul gegen beliebige Hosts und Ports prüft. Auf den ersten Blick sieht der Code gut aus.

Die Veröffentlichung des abgeschlossenen VM ist hier. Es ist im VMX-Format.

Warnwörter

Dieses Skript und VM wird nur zeigen den aktuellen Status Ihrer Systeme an. Es ist durchaus möglich, dass sich Ihre Systeme in der Vergangenheit in einem anfälligen Zustand befanden und missbraucht wurden.

Etwas, das hier auftaucht, hat definitiv eine hohe Priorität zu beheben, aber es bringt nicht Sie vom Haken, um Updates anzuwenden und alle Ihre Schlüssel zu ändern.

3
Tim Brigham

Amazon Linux (Linux-Distribution, die in Amazon EC2 verwendet wird)

https://aws.Amazon.com/Amazon-linux-AMI/security-bulletins/ALAS-2014-320/

Problemübersicht: Bei der Behandlung von TLS-Heartbeat-Erweiterungspaketen durch OpenSSL wurde eine Überprüfung der fehlenden Grenzen gefunden. Dieser Fehler kann verwendet werden, um bis zu 64 KB Speicher von einem verbundenen Client oder Server freizugeben.

Betroffene Versionen: Jedes Amazon Linux AMI, auf dem openssl 1.0.1 installiert ist, ist jedes Amazon Linux AMI 2013.03 oder höher und jedes Amazon Linux AMI, auf dem wurde auf 2013.03 oder höher aktualisiert. OpenSSL ist standardmäßig auf Amazon Linux AMI installiert.

Betroffene Pakete: openssl

Problemkorrektur: Führen Sie yum update openssl aus, um Ihr System zu aktualisieren. Nach der Installation des neuen Pakets müssen Sie entweder alle Dienste, die openssl verwenden, manuell neu starten oder Ihre Instanz neu starten. Während das neue Paket noch den Namen openssl-1.0.1e trägt, enthält es den Fix für CVE-2014-0160.

Neue Pakete: i686:

openssl-1.0.1e-37.66.amzn1.i686

openssl-static-1.0.1e-37.66.amzn1.i686

openssl-Perl-1.0.1e-37.66.amzn1.i686

openssl-devel-1.0.1e-37.66.amzn1.i686

openssl-debuginfo-1.0.1e-37.66.amzn1.i686

x86_64:

openssl-devel-1.0.1e-37.66.amzn1.x86_64

openssl-1.0.1e-37.66.amzn1.x86_64

openssl-debuginfo-1.0.1e-37.66.amzn1.x86_64

openssl-Perl-1.0.1e-37.66.amzn1.x86_64

openssl-static-1.0.1e-37.66.amzn1.x86_64
2
Garreth McDaid