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

88

Ich suchte nach einer zuverlässigen und portablen Möglichkeit, die OpenSSL-Version unter GNU / Linux und anderen Systemen zu überprüfen, damit Benutzer aufgrund des Heartbleed-Fehlers leicht feststellen können, ob sie ihr SSL aktualisieren sollten.

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

openssl version -a

Ich hatte erwartet, eine Vollversion zu sehen, aber stattdessen bekam 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 wird der Versionsbrief nicht angezeigt. Kein f, kein g da, nur "1.0.1" und das wars. Die aufgeführten Daten helfen auch nicht dabei, eine (nicht) anfällige Version zu finden.

Der Unterschied zwischen 1.0.1 (af) und 1.0.1g ist entscheidend.

Fragen:

  • Was ist ein zuverlässiger Weg, um die Version zu überprüfen, vorzugsweise Cross-Distribution?
  • Warum wird der Versionsbrief nicht an erster Stelle angezeigt? Ich konnte dies nur mit Ubuntu 12.04 LTS testen.

Andere melden dieses Verhalten ebenfalls. Einige Beispiele:

Einige (distro-spezifische) Vorschläge für:

  • Ubuntu und Debian: apt-cache policy opensslund 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) undyum info openssl-libs

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

Es stellt sich heraus, dass die Aktualisierung des OpenSSL-Pakets unter Ubuntu und Debian nicht immer ausreicht. Sie sollten auch das Paket libssl1.0.0 aktualisieren und dann prüfen, ob dies openssl version -aangezeigt wird built on: Mon Apr 7 20:33:29 UTC 2014.

linux ubuntu security openssl heartbleed Martijn
quelle
2
Stellen Sie zumindest sicher, dass die von Ihnen verwendete OpenSSL-Version aufgrund des Datums nicht g ist
Pato Sáinz,
3
Dies funktioniert auf CentOS[root@null~]# openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013
Jacob
1
@ PatoSáinz Ich habe es überprüft apt-cache policy opensslund es antwortete mit: Das Installed: 1.0.1-4ubuntu5.12ist die 1.0.1g, die gerade von Ubuntu für 12.04 LTS veröffentlicht wurde. Ich habe mich abgemeldet und wieder angemeldet. Kann ich noch etwas tun, um mich zu verifizieren?
Martijn
1
Ich werde darauf hinweisen, dass das nicht weiß, falls es hilfreich ist ... Ubuntu 12.04 LTS wird mit OpenSSL 1.0.1 (Vanille) ausgeliefert.
HopelessN00b
1
Wenn dieses Erstellungsdatum korrekt ist, können Sie keinen versionierten Code haben, der aktueller als 1.0.1e ist, da 1.0.1f 2014 gemäß den OpenSSL 1.0.1- Versionshinweisen veröffentlicht wurde . Einzelne Zeilen oder Abschnitte wurden möglicherweise vor dem offiziellen Release von OpenSSL 1.0.1f auf Ihre Ubuntu-Version zurückportiert. Und das Erstellungsdatum ist möglicherweise weniger hilfreich.
Anti-Weakpasswords

Antworten:

66

Auf der Grundlage des von Ihrer Version von OpenSSL angezeigten Datum, es scheint , Sie sind die Vollversion dort angezeigt zu sehen.

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

Ich gehe also weiter und behaupte, dass dies openssl version -adie richtige, distanzübergreifende Methode ist, um 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, und ist auch die in der OpenSSL-Dokumentation von help.ubuntu.com vorgeschlagene Methode . Ubuntu LTS 12.04 wird mit Vanilla OpenSSL v1.0.1 ausgeliefert. Dies ist die Version, die wie eine Kurzversion aussieht, da kein Buchstabe darauf folgt.

Allerdings scheint es einen großen Fehler in Ubuntu zu geben (oder wie OpenSSL gepackt wird), der openssl version -aweiterhin die ursprüngliche Version 1.0.1 vom 14. März 2012 zurückgibt, unabhängig davon, ob OpenSSL auf eine andere Version aktualisiert wurde oder nicht der neueren Versionen. Und wie bei den meisten Dingen, wenn es regnet, gießt es.

Ubuntu ist nicht die einzige große Distribution, die es sich zur Gewohnheit macht, Updates in OpenSSL (oder andere Pakete) zurück zu portieren, anstatt sich auf die Upstream-Updates und die Versionsnummerierung zu verlassen, die jeder kennt. Im Fall von OpenSSL, bei dem die Buchstabenversionsnummern nur Fehlerbehebungs- und Sicherheitsupdates darstellen, scheint dies fast unverständlich zu sein. Ich wurde jedoch darüber informiert, dass dies möglicherweise an dem mit OpenSSL gelieferten, von FIPS validierten Plug-in für große Linux-Distributionen liegt. Aufgrund der Anforderungen im Zusammenhang mit der erneuten Validierung, die aufgrund von Änderungen ausgelöst werden, selbst Änderungen, die Sicherheitslücken schließen, ist die Version gesperrt.

Beispielsweise zeigt die feste Version unter Debian eine Versionsnummer von 1.0.1e-2+deb7u5anstelle der Upstream-Version von an 1.0.1g.

Aus diesem Grund gibt es derzeit keine zuverlässige, tragbare Möglichkeit, SSL-Versionen für Linux-Distributionen zu überprüfen , da alle ihre eigenen, zurückportierten Patches und Aktualisierungen mit unterschiedlichen Versionsnummernschemata verwenden. Sie müssen die feste Versionsnummer für jede von Ihnen ausgeführte Linux-Distribution ermitteln und die installierte OpenSSL-Version anhand der spezifischen Versionsnummer dieser Distribution überprüfen, um festzustellen, ob auf Ihren Servern eine anfällige Version ausgeführt wird oder nicht.

HopelessN00b
quelle
3
Meine Installation ist eine einfache Ubuntu 12.04 LTS ohne irgendetwas, das ich selbst kompiliert oder von anderen Quellen als den Ubuntu-Repositories heruntergeladen habe. Wenn Ubuntu OpenSSL mit verkürzten Versionsnummern verteilt, openssl version -aist dies keine portable Methode (zumindest nicht für Ubuntu portierbar). Ich habe es überprüft apt-cache policy opensslund es antwortete mit: Das Installed: 1.0.1-4ubuntu5.12ist die 1.0.1g, die gerade von Ubuntu für 12.04 LTS veröffentlicht wurde. Ich habe mich abgemeldet und wieder angemeldet, bevor ich eingecheckt habe.
Martijn
19
HopelessN00b, die Politik des Backportierens von Fixes anstelle des Bumpens von Versionen ist nicht zweifelhaft. Dies ist eine sehr gute Methode, um die Plattformstabilität zu gewährleisten, was in einer Serverumgebung äußerst wünschenswert ist. Wie jede Entscheidung hat sie Konsequenzen, deren sich Benutzer bewusst sein müssen. Aber nur, weil es das " Ich leite foo xyz " unterbricht, bin ich / bin ich nicht anfällig für die neueste Exploit- Argumentation. Das macht es nicht zu einer schlechten Sache.
MadHatter
10
@towo Versionsnummern existieren aus einem Grund. Wenn wir nur die Upstream-Versionsnummern aus dem Fenster werfen, weil "enterprisey" oder was auch immer, warum sollten wir uns überhaupt um Versionsnummern kümmern? Kann auch einfach anfangen, all unsere Sachen mit Alliterationen zu benennen. Wir können die verwundbaren OpenSSL-Versionen Holy Heartbleed und die reparierten Cunning Coagulant nennen .
HopelessN00b
7
@ HopelessN00b Ich glaube, Sie werden von der "Dies wurde in Version XYZ behoben" -Falle eingeholt. Sie folgen nicht den Versionsnummern, da in die neueste Version nur Fehler- und Sicherheitskorrekturen importiert werden. Wenn sie die Versionsnummer anstießen, würden Sie auch die zusätzliche Funktionalität erwarten. "Ich habe OpenSSL v XYZ, warum habe ich nicht ECDHA ???? ..etc". Es ist sinnvoll, wenn Sie verstehen, dass es nur Bugfixes sind.
NickW
13
@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.Also nichts gewonnen wird , wenn man das Upstream-Versionierungsschema aufgibt; Das Backportieren der Updates entspricht im Wesentlichen der Verwendung der aktualisierten Version, da das Update ohnehin nur Sicherheits- und Fehlerkorrekturen enthält. Das verwirrt die Dinge und lässt uns keine Möglichkeit, die OpenSSL-Version in Linux-Distributionen portabel zu überprüfen.
HopelessN00b
18

Wenn Sie etwas wirklich plattformübergreifendes möchten, suchen Sie nach der 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 anfällig ist , der tatsächliche Code ist jedoch nicht anfällig . Und das Gegenteil - lautlos anfälliger Code - könnte noch schlimmer sein!

Viele Anbieter, die Open-Source-Produkte wie OpenSSL und OpenSSH bündeln, werden dringende Korrekturen selektiv auf eine ältere Codeversion nachrüsten, um die API-Stabilität und -Vorhersagbarkeit zu gewährleisten. Dies gilt insbesondere für "Langzeitversionen" und Appliance-Plattformen.

Hersteller, die dies im Hintergrund tun (ohne ein eigenes Versions-String-Suffix hinzuzufügen), laufen jedoch Gefahr, bei Schwachstellenscannern falsche Positive auszulösen (und Benutzer zu verwirren). Um dies transparent und überprüfbar zu machen, hängen einige Anbieter ihre eigenen Zeichenfolgen an die Hauptpaketversion an. Sowohl Debian (OpenSSL) als auch FreeBSD (in OpenSSH über die VersionAddendumDirektive sshd_config) tun dies manchmal.

Anbieter, die dies nicht tun, tun dies wahrscheinlich, um die Wahrscheinlichkeit eines Bruchs zu minimieren, da andere Programme die Versionsnummern auf viele direkte und indirekte Arten prüfen.

So kann es also 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 gepatcht wurde :

$ 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 ist es besser, wenn Sie der Versionsnummer nicht vertrauen.

Royce Williams
quelle
Es ist klar, dass das Überprüfen von Versionen nicht so einfach und transparent ist, wie ich es mir erhofft hatte. Die Überprüfung auf die Sicherheitsanfälligkeit ist plattformübergreifend, aber auch schwieriger: Sie müssen über einen zuverlässigen PoC verfügen oder einen Test für den jeweiligen Dienst für anfällige Software durchführen, den Sie ausführen. In diesem Fall begann alles mit einem PoC für Apache und Nginx. Was ist, wenn ich zu diesem Zeitpunkt nur SMTP mit SSL verwendet habe und prüfen möchte, ob ich anfällig bin? Irgendwann werden wir Tests für die meisten Dienste haben, aber es kann eine Weile dauern.
Martijn
Martijn, das ist ein fairer Punkt. Wenn ein Test nicht verfügbar ist, sind sekundäre Methoden (z. B. das Auffinden der Prüfsumme für die betroffenen Binärdateien auf Ihren Zielsystemen) weniger optimal, reichen jedoch möglicherweise aus, um die Aufgabe zu erledigen ... und fahren dann mit dem nächsten Brand fort. :-)
Royce Williams
14

Leider bin ich mir nicht sicher, ob es dafür eine plattformübergreifende Möglichkeit gibt. Wie ich in einem Blogbeitrag erläutere, wird die Version von OpenSSL nach dem Upgrade auf eine feste Version unter Ubuntu 12.04 REMAINS 1.0.1 angezeigt.

NUR für Ubuntu 12.04 können Sie feststellen, ob Sie aktualisiert wurden, wenn alle der folgenden Aussagen zutreffen:

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

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

Schof
quelle
2
Ok, in diesem Fall muss ich hinzufügen, dass die Paketversion 1.0.1-4ubuntu5.12NUR für Ubuntu 12.04 LTS ist. Wenn Sie auf Ubuntu 12.10 sind , sollten Sie mindestens Version sehen , 1.0.1c-3ubuntu2.7und wenn Sie auf 13.10 sind dann sollte es mindestens Version sein 1.0.1e-3ubuntu1.2, nach Quelle: ubuntu.com/usn/usn-2165-1
Martijn
1
Das reicht leider nicht aus. Sie müssen auch libssl1.0.0explizit auf Ubuntu aktualisieren . Wenn Sie ein Build-on-Datum vor dem 7. April 2014 sehen, selbst wenn die Version von openssl korrekt aussieht ( 1.0.1-4ubuntu5.12für Ubuntu 12.04), sind Sie wahrscheinlich immer noch anfällig.
Danny
@danny Du hast mir so viel Arbeit gerettet. Ich habe versucht herauszufinden, warum das Erstellungsdatum bei einigen 12.04-Systemen richtig und bei anderen falsch war. Du bist ein Lebensretter!
Schof
openssl version -aMöglicherweise wird das Erstellungsdatum vom 7. April nicht benötigt, da das Update auf ältere Releases zurückportiert wird.
Patrick James McDougle
4

Probieren Sie Folgendes aus. Es werden alle Zeichenfolgen aus der Kryptobibliothek extrahiert , mit der ssh verknüpft ist. Es erzeugt mehr als eine Ausgabezeile, kann aber bei Bedarf in eine 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

zB auf Gentoo bevor es auftaucht

[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 ergibt

...
OpenSSL 1.0.1c 10 May 2012

nach

...
OpenSSL 1.0.1f 6 Jan 2014

Autsch, noch kein g.

waTeim
quelle
3
Ich dachte, Sie wären kurz davor, eine gute Lösung anzubieten, aber leider funktioniert dies nicht für die Kryptobibliothek unter Ubuntu 12.04 LTS. Es zeigt alle Zeichenfolgen mit der Version auf [...] part of OpenSSL 1.0.1 14 Mar 2012die gleiche Weise an, wie dies der openssl version -aFall ist. Dies ist jedoch 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. Gibt es mehrere Bibliotheken? Ist es möglich, dass ssh nicht die aktuellsten verwendet?
WaTeim
Ich konnte keine anderen openssl-Binärdateien oder Kryptobibliotheken finden. Es wird von anderen vermutet, dass der Unterschied darin besteht, dass Ubuntu unter 12.04 LTS die Änderungen auf 1.0.1 zurückportiert, ohne die Version zu aktualisieren. Während 12.10 kein LTS ist und Ubuntu dort die neueste Version anstelle eines Backports verwendet.
Martijn
2

Testen diese Skripte alle Dienste oder nur HTTPS ? AFAIK , PostgreSQL ist anfällig, aber das ist nur ein Gerücht, bis ein wilder Angriff auftaucht.

Es steht ein Metasploit- Skript zur Verfügung.

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

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

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

Sobald eine Verbindung vom Typ B hergestellt wurde, wird auf einem anfälligen Host Folgendes angezeigt, und die Verbindung wird 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 wird eine Antwort ähnlich der folgenden angezeigt, und die Verbindung wird 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   [email protected]...
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 Tools:

Justin Goldberg
quelle
0

Für Ubuntu können Sie verwenden: 

aptitude show libssl1.0.0 | grep Version

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

Rufinus
quelle
0

Ich habe dieses Skript in devcentral gefunden :

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

Ersetzen Sie example.comdurch den Namen oder die IP-Adresse des Servers, den Sie überprüfen möchten.

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

Dies hängt nicht von der Versionsnummer ab, sondern von der Auflistung der Servererweiterung, die das Problem verursacht. Sie sollte daher immun gegen die Spielereien der Bibliotheksversion sein.

Die Maschine , die Sie laufen openssl s_clientauf muss sein für diese Verwendung von OpenSSL 1.0.1 oder höher , um zu arbeiten.

egarcia
quelle
4
Nützlich, sagt Ihnen aber nicht, ob Sie eine Version mit der Erweiterung und dem Fix haben .
Mattdm
1
Dies ist in der Tat eine gute Möglichkeit, die Sicherheitsanfälligkeit zu überprüfen, und dies tun einige Skripte. Eigentlich ist kein SSH-Zugriff erforderlich.
Stefan Lasiewski
8
BIG SCARY WICHTIGE WARNUNG - Der Computer, auf dem Sie ausgeführt werden,openssl s_clientMUSS 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, MELDEN SIE IMMER "Sicher", auch für anfällige Server .
Voretaq7
Ungerade. Ich verwende eine OpenSSL-Version, die angeblich von diesem Fehler betroffen ist, aber diese Zeichenfolge wird in der Ausgabe nicht angezeigt ...
Michael
@StefanLasiewski Ich habe meine Antwort aktualisiert und den Teil "need ssh" entfernt
egarcia