Frage Heartbleed: Wie kann man die OpenSSL-Version zuverlässig und portabel überprüfen?


Ich habe mir eine zuverlässige und portable Methode angeschaut, um die OpenSSL-Version auf GNU / Linux und anderen Systemen zu überprüfen, so dass Benutzer leicht erkennen können, ob sie ihr SSL wegen des Heartbleed-Fehlers aktualisieren sollten.

Ich dachte, es wäre einfach, aber ich stieß schnell auf ein Problem auf Ubuntu 12.04 LTS mit dem neuesten OpenSSL 1.0.1g:

OpenSSL-Version

Ich habe erwartet, eine Vollversion zu sehen, aber stattdessen habe ich Folgendes:

OpenSSL 1.0.1 14. März 2012
gebaut am: Di Jun 4 07:26:06 UTC 2013
Plattform: [...]

Zu meiner unangenehmen Überraschung zeigt sich der Versionsbrief nicht. Kein f, kein g, nur "1.0.1" und das war's. Die aufgelisteten Daten helfen auch nicht bei der Entdeckung einer (nicht) anfälligen Version.

Der Unterschied zwischen 1.0.1 (a-f) und 1.0.1g ist entscheidend.

Fragen:

  • Was ist ein zuverlässiger Weg, um die Version zu überprüfen, vorzugsweise über Distro?
  • Warum wird der Versionsbrief nicht angezeigt? Das konnte ich an nichts anderem als an Ubuntu 12.04 LTS testen.

Andere berichten ebenfalls über dieses Verhalten. Ein paar Beispiele:

Einige (distrosspezifische) Vorschläge kommen herein:

  • Ubuntu und Debian: apt-cache policy openssl und apt-cache policy libssl1.0.0. Vergleichen Sie die Versionsnummern mit den Paketen hier: http://www.ubuntu.com/usn/usn-2165-1/
  • Fedora 20: yum info openssl (Danke @znmeb auf Twitter) und yum info openssl-libs

Überprüfen, ob eine ältere Version von OpenSSL noch resident ist:

Es stellt sich heraus, dass das Aktualisieren des OpenSSL-Pakets auf Ubuntu und Debian nicht immer ausreicht. Sie sollten auch das Paket libssl1.0.0 aktualisieren und dann prüfen, ob openssl version -a zeigt an built on: Mon Apr 7 20:33:29 UTC 2014.


86
2018-04-07 23:51


Ursprung


zumindest sicher sein, dass die OpenSSL-Version Sie haben ist nicht g wegen des Datums, das es zeigt - Pato Sáinz
Dies funktioniert auf CentOS [root@null~]# openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 - Jacob
@ PatoSáinz Ich habe überprüft apt-cache policy openssl und es antwortete mit: Installed: 1.0.1-4ubuntu5.12 Das ist die 1.0.1g, die gerade von Ubuntu für 12.04 LTS veröffentlicht wurde. Ich habe mich aus- und wieder eingeloggt. Kann ich sonst noch etwas überprüfen? - Martijn
Ich werde darauf hinweisen, für die, die nicht wissen, falls es hilfreich ist ... Ubuntu 12.04 LTS ausgeliefert mit OpenSSL 1.0.1 (Vanille). - HopelessN00b
Wenn dieses Build-Datum korrekt ist, können Sie den Code "release versioned" nicht aktueller als 1.0.1e haben, da 1.0.1f im Jahr 2014 herauskam die OpenSSL 1.0.1 Versionshinweise. Einzelne Zeilen oder Abschnitte wurden natürlich vor der offiziellen Veröffentlichung von OpenSSL 1.0.1f auf Ihre Ubuntu-Version zurückportiert. Und das Build-Datum ist vielleicht weniger hilfreich. - Anti-weakpasswords


Antworten:


Basierend auf dem Datum, das von Ihrer Version von OpenSSL angezeigt wird, scheinen Sie es sind Sehen Sie sich die Vollversion an, die dort angezeigt wird.

Open SSL 1.0.1 wurde am 14. März 2012 veröffentlicht. 1.0.1a wurde am 19. April 2012 veröffentlicht.

Also werde ich weitermachen und das behaupten openssl version -a ist die richtige, übergreifende Möglichkeit, die Vollversion von OpenSSL anzuzeigen, die auf dem System installiert ist. Es scheint für alle Linux-Distributionen zu funktionieren, auf die ich Zugriff habe ist auch die Methode, die in der OpenSSL-Dokumentation von help.ubuntu.com vorgeschlagen wird. Ubuntu LTS 12.04 wurde mit Vanilla OpenSSL v1.0.1 ausgeliefert, einer Version, die wie eine abgekürzte Version aussieht, da sie keinen Buchstaben hat.

Allerdings scheint es, dass es ein Haupt Fehler in Ubuntu (oder wie sie OpenSSL Paket), in diesem openssl version -a gibt die ursprüngliche Version 1.0.1 ab dem 14. März 2012 zurück, unabhängig davon, ob OpenSSL auf eine der neueren Versionen aktualisiert wurde oder nicht. Und wie bei den meisten Dingen, wenn es regnet, ergießt es sich.

Ubuntu ist nicht die einzige große Distribution, die es gewohnt ist, Updates in OpenSSL (oder andere Pakete) zurückzuleiten, sondern sich auf Upstream-Updates und Versionsnummern zu verlassen, die jeder erkennt. Im Fall von OpenSSL, wo die Versionsnummern der Buchstaben nur Bugfixes und Sicherheitsupdates darstellen, scheint das fast unverständlich, aber ich wurde darüber informiert, dass dies an der FIPS-validiert plugin major Linux Distributionen werden mit OpenSSL ausgeliefert. Aufgrund von Anforderungen an die Revalidierung, die aufgrund von Änderungen ausgelöst werden, werden auch Änderungen, die Sicherheitslücken schließen, versionsverriegelt.

Zum Beispiel zeigt die feste Version unter Debian eine Versionsnummer von 1.0.1e-2+deb7u5 anstelle der Upstream-Version von 1.0.1g.

Als Ergebnis, zu dieser Zeit, Es gibt keine zuverlässige, portable Möglichkeit, SSL-Versionen in Linux-Distributionen zu überprüfen, weil sie alle ihre eigenen zurückportierten Patches und Updates mit unterschiedlichen Versionsnummern verwenden. Sie müssen die feste Versionsnummer für jede andere von Ihnen ausgeführte Linux-Distribution nachschlagen und die installierte OpenSSL-Version anhand der spezifischen Versionsnummerierung dieser Distribution prüfen, um festzustellen, ob Ihre Server eine anfällige Version ausführen oder nicht.


67
2018-04-08 00:05



Meine Installation ist eine einfache Ubuntu 12.04 LTS ohne etwas, das ich selbst zusammengestellt oder von anderen Quellen als den Ubuntu-Repositories heruntergeladen habe. Wenn Ubuntu OpenSSL mit abgekürzten Versionsnummern verteilt, dann openssl version -a ist keine portable Methode (zumindest nicht portabel zu Ubuntu). Ich habe es überprüft apt-cache policy openssl und es antwortete mit: Installed: 1.0.1-4ubuntu5.12 Das ist die 1.0.1g, die gerade von Ubuntu für 12.04 LTS veröffentlicht wurde. Ich habe mich aus- und wieder eingeloggt, bevor ich nachgesehen habe. - Martijn
HoffnungslosN00b, es gibt nichts Zweifeln an der Politik der Rückportierung von Fixes statt bumping Versionen; Dies ist eine sehr gute Möglichkeit, die Plattformstabilität zu gewährleisten, was in einer Serverumgebung sehr wünschenswert ist. Wie jede Entscheidung hat sie Konsequenzen, die Benutzer beachten müssen; aber nur weil es bricht "Ich renne foo x.y.z und bin daher nicht anfällig für den neuesten Exploit"Argumentation, das macht es nicht schlecht. - MadHatter
@towo Versionsnummern existieren aus einem Grund. Wenn wir nur die Upstream-Versionsnummern aus dem Fenster holen, weil "Enterprisey" oder was auch immer, warum überhaupt mit Versionsnummern zu tun haben? Möge auch gleich anfangen, all unsere Sachen mit Alliterationen zu benennen. Wir können die anfälligen OpenSSL-Versionen aufrufen Heiliges Heartbleed und die festen Schlauer Koagulant. - HopelessN00b
@ HopelessN00b Ich denke, dass Sie sich auf die "Diese Version wurde in Version X.Y.Z" -Falle verfangen haben, sie folgen nicht den Versionsnummern, da alles, was in die neueste Version importiert wird, Bug- und Sicherheitsfixes sind. Wenn sie die Versionsnummer stoßen würden, würden Sie auch die zusätzliche Funktionalität erwarten. "Ich habe OpenSSL v X.Y.Z, warum habe ich nicht ECDHA ???? .. etc". Es macht Sinn, wenn Sie verstehen, dass es nur Bugfixes sind. - NickW
@NickW @Jubal @MadHatter die Sache mit OpenSSL ist jedoch, dass: After the release of OpenSSL 1.0.0 the versioning scheme changed. Letter releases (e.g. 1.0.1a) can only contain bug and security fixes and no new features. Es wird also nichts unternommen, das Upstream-Versionierungsschema aufzugeben; Das Zurückportieren der Updates ist im Wesentlichen das Gleiche wie das Verwenden der aktualisierten Version, da das Update nur Sicherheit und Fehlerkorrekturen enthält. Was es tut, ist verwirrend und lässt uns keine Möglichkeit, die OpenSSL-Version portabel über Linux-Distributionen zu überprüfen. - HopelessN00b


Wenn Sie etwas wirklich plattformübergreifendes wollen, Überprüfen Sie die Sicherheitsanfälligkeit selbst, anstatt sich auf Versionsnummern zu verlassen. 

Möglicherweise verfügen Sie über Code, der eine Versionsnummer meldet, von der bekannt ist, dass sie angreifbar ist. aber der eigentliche Code ist nicht anfällig. Und der umgekehrte - leise ungeschützte Code - könnte noch schlimmer sein!

Viele Anbieter, die Open-Source-Produkte wie OpenSSL und OpenSSH bündeln, werden dringend erforderliche Korrekturen an einer älteren Codeversion nachrüsten, um die API-Stabilität und Vorhersagbarkeit zu gewährleisten. Dies gilt insbesondere für "Langzeit-Release" und Appliance-Plattformen.

Anbieter, die dies stillschweigend tun (ohne ihr eigenes Versionszeichenkettensuffix hinzuzufügen), laufen Gefahr, bei Schwachstellenscannern (und verwirrenden Benutzern) falsche Positive auszulösen. Um dies transparent und überprüfbar zu machen, hängen einige Hersteller ihre eigenen Strings an die Hauptpaketversion an. Sowohl Debian (OpenSSL) als auch FreeBSD (in OpenSSH, über die VersionAddendum sshd_config Direktive) mach das manchmal.

Anbieter, die dies nicht tun, tun dies wahrscheinlich, um die Möglichkeit eines Bruchs zu minimieren, aufgrund der vielen direkten und indirekten Wege, auf denen andere Programme Versionsnummern überprüfen.

So kann es so aussehen:

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.4 LTS"

$ openssl version
OpenSSL 1.0.1 14 Mar 2012

... obwohl Es wurde gepatcht:

$ dpkg -l openssl | grep openssl
ii  openssl  1.0.1-4ubuntu5.12  [truncated]

$ ls -la `which openssl`
-rwxr-xr-x 1 root root 513208 Apr  7 12:37 /usr/bin/openssl

$ md5sum /usr/bin/openssl
ea2a858ab594905beb8088c7c2b84748  /usr/bin/openssl

Mit solchen Dingen im Spiel bist du besser dran traue der Versionsnummer nicht.


18
2018-04-08 20:52



Es ist klar, dass das Überprüfen von Versionen nicht so einfach und transparent ist, wie ich es mir erhofft hatte. Das Überprüfen der Sicherheitsanfälligkeit ist plattformübergreifend, aber auch schwieriger: Sie müssen über einen zuverlässigen PoC oder einen Test für den jeweiligen anfälligen Softwareservice verfügen, den Sie ausführen. In diesem Fall begann alles mit einem PoC für Apache und nginx. Was wäre, wenn ich in diesem Moment nur SMTP mit SSL verwenden würde und ich überprüfen wollte, ob ich anfälliger bin? Irgendwann werden wir Tests für die meisten Dienste haben, aber es kann eine Weile dauern. - Martijn
Martijn, das ist ein guter Punkt. Wenn ein Test nicht verfügbar ist, sind sekundäre Methoden (wie das Aufspüren der Prüfsumme für die betroffenen Binärdateien auf Ihren Zielsystemen) weniger optimal, aber möglicherweise gut genug, um die Aufgabe zu erledigen ... und dann zum nächsten Feuer überzugehen. :-) - Royce Williams


Leider bin ich da nicht sicher ist ein plattformübergreifender Weg dies zu tun. Wie ich in einem Blogbeitrag diskutiere, die Version von OpenSSL, die auf Ubuntu 12.04 REMAINS 1.0.1 nach dem Upgrade auf eine feste Version angezeigt wird.

Nur für Ubuntu 12.04 können Sie feststellen, ob Sie aktualisiert wurden, wenn alle folgenden Bedingungen zutreffen:

  1. dpkg -s openssl | grep Versionzeigt Version 1.0.1-4ubuntu5.12 oder höher.
  2. dpkg -s libssl1.0.0 | grep Versionzeigt Version 1.0.1-4ubuntu5.12 oder höher.
  3. openssl version -a zeigt ein "built on" Datum vom 7. April 2014 oder später an.

Danke an @danny für die zusätzlichen Informationen.


14
2018-04-08 03:15



Ok, in diesem Fall muss ich diese Paketversion hinzufügen 1.0.1-4ubuntu5.12 ist NUR für Ubuntu 12.04 LTS. Wenn Sie auf Ubuntu 12.10 sind, sollten Sie mindestens die Version sehen 1.0.1c-3ubuntu2.7und wenn du am 13.10 bist, sollte es mindestens Version sein 1.0.1e-3ubuntu1.2, nach Quelle: ubuntu.com/usn/usn-2165-1 - Martijn
Dies ist leider nicht ausreichend. Sie Muss auch upgraden libssl1.0.0 explizit auf ubuntu. Wenn Sie ein Builddatum vor dem 7. April 2014 sehen, auch wenn die Version von openssl korrekt aussieht (1.0.1-4ubuntu5.12 für Ubuntu 12.04) sind Sie wahrscheinlich immer noch verwundbar. - danny
@danny Du hast mir gerade so viel Arbeit erspart. Ich habe versucht herauszufinden, warum das Build-Datum bei einigen 12.04-Systemen richtig und bei anderen falsch war. Du bist ein Lebensretter! - Schof
openssl version -a Möglicherweise wird das Erstellungsdatum des 7. April nicht benötigt, da der Fix in die älteren Versionen zurückportiert wird. - Patrick James McDougle


Versuchen Sie Folgendes. Es wird alle Zeichenfolgen aus der Krypto Bibliothek, gegen die ssh verlinkt ist. Es erzeugt mehr als eine Ausgabezeile, kann aber bei Bedarf in 1 Zeile konvertiert werden.

ldd `which ssh` | awk '/\// { print $3 }' | grep crypto | xargs strings  | grep OpenSSL

produziert

OpenSSLDie
DSA_OpenSSL
...
MD4 part of OpenSSL 1.0.1f 6 Jan 2014 
MD5 part of OpenSSL 1.0.1f 6 Jan 2014
... 
etc

z.B. auf Gentoo bevor auftauchen

[ebuild     U  ] dev-libs/openssl-1.0.1f [1.0.1c] USE="bindist (sse2) tls-heartbeat%* zlib -gmp -kerberos -rfc3779 -static-libs {-test} -vanilla" 4,404 kB

Der obige Befehl führt zu

...
OpenSSL 1.0.1c 10 May 2012

nach dem

...
OpenSSL 1.0.1f 6 Jan 2014

Autsch, immer noch kein g.


4
2018-04-08 14:45



Ich dachte, du wärst sehr nah dran, eine gute Lösung zu finden, aber leider funktioniert das nicht für die Krypto-Bibliothek auf Ubuntu 12.04 LTS. Es zeigt alle Strings mit Version an [...] part of OpenSSL 1.0.1 14 Mar 2012, Der selbe Weg wie openssl version -a tut. Dies ist ein Trick, der in anderen Fällen funktionieren kann! - Martijn
@Martijn Nun, das ist bedauerlich, aber es funktioniert auf Ubuntu 12.10. Seltsam, dass es sich am 12.04. Falsch identifizieren würde. Gibt es mehrere Bibliotheken? Ist es möglich, dass ssh nicht auf dem neuesten Stand ist? - waTeim
Ich konnte keine anderen Openssl-Binärdateien oder Krypto-Bibliotheken finden. Es wird von anderen vorgeschlagen, dass der Unterschied darin besteht, dass Ubuntu bei 12.04 LTS die Änderungen auf 1.0.1 zurückversetzt, ohne die Version zu erhöhen. Während 12.10 kein LTS ist, verwendet Ubuntu anstelle eines Backports die neueste Version. - Martijn


Teste irgendeines dieser Skripte alle Dienste oder testet es nur HTTPS? so viel ich weiss, PostgreSQL ist anfällig, aber das ist nur ein Gerücht, bis ein In-The-Wild-Angriff auftaucht.

Da ist ein Metasploit Skript zur Verwendung verfügbar.

https://github.com/rapid7/metasploit-framework/commit/dd69a9e5dd321915e07d8e3dc8fe60d3c54f551a

Sie können dies eingeben (getestet mit GnuWin32 OpenSSL-Binärversion 1.0.1.6, vom 2014-01-14), oder verwenden Sie einfach das Skript im Kommentar unter diesem. Es ist genauer und einfacher!

s_client -connect a23-75-248-141.deploy.static.akamaitechnologies.com:443 -debug -state

Sobald Sie verbunden sind, tippen Sie auf einen anfälligen Host und Sie werden nicht getrennt:

B

HEARTBEATING
write to 0x801c17160 [0x801cbc003] (66 bytes => 66 (0x42))
0000 - 18 03 03 00 3d 8f 6f 3c-52 11 83 20 9c a2 c0 49   ....=.o 5 (0x5))
0000 - 18 03 03 00 3d                                    ....=
read from 0x801c17160 [0x801cb7008] (61 bytes => 61 (0x3D))
0000 - 05 4d f5 c0 db 96 d1 f5-c7 07 e5 17 1f 3b 48 34   .M...........;H4
0010 - 6e 11 9d ba 10 0c 3a 34-eb 7b a5 7c c4 b6 c0 c0   n.....:4.{.|....
0020 - b0 75 0e fe b7 fa 9e 04-e9 4e 4a 7d 51 d3 11 1f   .u.......NJ}Q...
0030 - e2 23 16 77 cb a6 e1 8e-77 84 2b f8 7f            .#.w....w.+..
read R BLOCK

Sie erhalten eine Heartbeat-Antwort, die dieser ähnelt.

Auf einem gepatchten Host sehen Sie eine ähnliche Antwort wie unten, und Sie werden getrennt:

Geben Sie B ein

HEARTBEATING
write to 0x801818160 [0x8019d5803] (101 bytes => 101 (0x65))
0000 - 18 03 03 00 60 9c a3 1e-fc 3b 3f 1f 0e 3a fe 4c   ....`....;?..:.L
0010 - a9 33 08 cc 3d 43 54 75-44 7d 2c 7b f3 47 b9 56   .3..=CTuD},{.G.V
0020 - 89 37 c1 43 1c 80 7b 87-66 ff cb 55 5f 8d 1a 95   .7.C..{.f..U_...
0030 - 1b 4c 65 14 21 a1 95 ac-7a 70 79 fc cc a0 cf 51   .Le.!...zpy....Q
0040 - 0f 7e c5 56 14 c8 37 c1-40 0b b8 cb 43 96 8a e6   .~.V..7.@...C...
0050 - 21 42 64 58 62 15 fb 51-82 e6 7f ef 21 1b 6f 87   !BdXb..Q....!.o.
0060 - b9 c2 04 c8 47                                    ....G

Quelle:

Es gibt auch diese Werkzeuge:


2
2018-04-09 11:43





Für Ubuntu können Sie verwenden:

aptitude show libssl1.0.0 | grep Version

Und vergleichen Sie mit http://www.ubuntu.com/usn/usn-2165-1/. Nach einem Neustart (!!!) können Sie mit überprüfen http://possible.lv/tools/hb.


0
2018-04-08 11:14





Sie sollten besser auf das neueste OpenSSL OpenSSL 1.0.1j upgraden.

http://blog.vincosolution.com/2014/10/upgrade-openssl-1-0-1j-debianubuntu.html


0
2017-10-19 01:57





ich fand Dieses Skript in devcentral:

openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe

Ersetzen example.com mit dem Namen oder der IP-Adresse des Servers, den Sie überprüfen möchten.

Wird zurückkehren "safe" wenn dein Server in Ordnung ist oder "server extension "heartbeat" (id=15)" wenn nicht.

Dies hängt nicht von der Versionsnummer ab, sondern von der Auflistung der Servererweiterung, die das Problem verursacht. Daher sollte es gegen die Bibliotheksversions-Shenanigans immun sein.

Die Maschine, die Sie ausführen openssl s_client auf Muss Verwenden Sie OpenSSL 1.0.1 oder höher, damit dies funktioniert.


0
2018-04-08 09:12



Nützlich, sagt Ihnen aber nicht, ob Sie eine Version mit der Erweiterung haben und die Lösung. - mattdm
Dies ist in der Tat ein guter Weg, um nach der Schwachstelle zu suchen, und was einige Skripte tun. Es erfordert keinen SSH-Zugriff. - Stefan Lasiewski
BIG SCARY WICHTIGE WARNUNG - Die Maschine, die Sie ausführen openssl s_client on MUSS OpenSSL 1.0.1 oder höher verwenden, damit dies funktioniert. Wenn Sie diesen Befehl auf einem Computer mit 0.9.8 oder 1.0.0 ausführen IT wird immer "sicher", auch für anfällige Server. - voretaq7
Ungerade. Ich führe eine Version von OpenSSL, die angeblich von diesem Fehler betroffen ist, aber diese Zeichenfolge erscheint nicht in der Ausgabe ... - Michael
@StefanLasiewski Ich habe meine Antwort aktualisiert und den "need ssh" -Teil entfernt - egarcia