Lösung 1:
Basierend auf dem Datum, das von Ihrer Version von OpenSSL angezeigt wird, scheint es, dass Sie es sind die dort angezeigte Vollversion 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.
Also werde ich fortfahren und diesen openssl version -a
bestätigen ist die richtige, distributionsübergreifende Methode, 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 Methode, die in der OpenSSL-Dokumentation von help.ubuntu.com vorgeschlagen wird. Ubuntu LTS 12.04 wird mit Vanilla OpenSSL v1.0.1 ausgeliefert, das ist die Version, die wie eine abgekürzte Version aussieht, da ihr kein Buchstabe folgt.
Allerdings scheint es, dass es ein Major gibt Fehler in Ubuntu (oder wie sie OpenSSL verpacken), in diesem openssl version -a
gibt weiterhin die Originalversion 1.0.1 vom 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, schüttet es.
Ubuntu ist nicht die einzige große Distribution, die Updates in OpenSSL (oder andere Pakete) zurückportiert, anstatt sich auf die Upstream-Updates und die Versionsnummerierung zu verlassen, die jeder kennt. Im Fall von OpenSSL, wo die Buchstaben-Versionsnummern nur Fehlerkorrekturen und Sicherheitsupdates darstellen, scheint dies fast unverständlich, aber ich wurde darüber informiert, dass dies möglicherweise an dem FIPS-validierten Plugin liegt, das große Linux-Distributionen mit OpenSSL ausliefern. Aufgrund von Anforderungen rund um die Revalidierung, die aufgrund jeder Änderung ausgelöst werden, selbst wenn Änderungen Sicherheitslücken schließen, ist die Version gesperrt.
Unter Debian zeigt die feste Version beispielsweise eine Versionsnummer von 1.0.1e-2+deb7u5
an anstelle der Upstream-Version von 1.0.1g
.
Daher gibt es derzeit kein zuverlässiges, portables Verfahren zum Überprüfen von SSL-Versionen in verschiedenen Linux-Distributionen , da sie alle ihre eigenen zurückportierten Patches und Updates mit unterschiedlichen Schemata der Versionsnummerierung verwenden. Sie müssen die feste Versionsnummer für jede unterschiedliche Linux-Distribution, die Sie ausführen, nachschlagen und die installierte OpenSSL-Version mit der spezifischen Versionsnummerierung dieser Distribution vergleichen, um festzustellen, ob auf Ihren Servern eine anfällige Version ausgeführt wird oder nicht.
Lösung 2:
Wenn Sie etwas wirklich Plattformübergreifendes wollen, suchen Sie nach der Schwachstelle selbst, anstatt sich auf Versionsnummern zu verlassen.
Möglicherweise haben Sie Code, der eine bekanntermaßen anfällige Versionsnummer meldet, aber der eigentliche Code ist nicht anfällig . Und das Gegenteil – stillschweigend angreifbarer Code – könnte sogar noch schlimmer sein!
Viele Anbieter, die Open-Source-Produkte wie OpenSSL und OpenSSH bündeln, werden dringende Korrekturen selektiv in einer älteren Codeversion nachrüsten, um die API-Stabilität und Vorhersagbarkeit aufrechtzuerhalten. Dies gilt insbesondere für "Langzeitversionen" und Anwendungsplattformen.
Aber Anbieter, die dies im Hintergrund tun (ohne ihr eigenes Versions-String-Suffix hinzuzufügen), laufen Gefahr, Fehlalarme in Schwachstellen-Scannern 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 VersionAddendum
sshd_config Direktive) tun dies manchmal.
Anbieter, die dies nicht tun, tun dies wahrscheinlich, um die Wahrscheinlichkeit eines Fehlers aufgrund der vielen direkten und indirekten Möglichkeiten zu minimieren, auf denen andere Programme Versionsnummern überprüfen.
Das kann also 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 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
Wenn solche Dinge im Spiel sind, sind Sie besser dran, wenn Sie der Versionsnummer nicht vertrauen.
Lösung 3:
Leider bin ich mir nicht sicher, ob es gibt eine plattformübergreifende Möglichkeit, dies zu tun. Wie ich in einem Blogbeitrag erörtere, BLEIBT die auf Ubuntu 12.04 angezeigte Version von OpenSSL nach dem Upgrade auf eine feste Version 1.0.1.
NUR für Ubuntu 12.04 können Sie feststellen, ob Sie aktualisiert wurden, wenn alle der folgenden Punkte zutreffen:
dpkg -s openssl | grep Version
zeigt Version 1.0.1-4ubuntu5.12 oder höher.dpkg -s libssl1.0.0 | grep Version
zeigt Version 1.0.1-4ubuntu5.12 oder höher.openssl version -a
zeigt als "Erbaut am"-Datum den 7. April 2014 oder später an.
Danke an @danny für die zusätzlichen Informationen.
Lösung 4:
Probieren Sie Folgendes aus. Es extrahiert alle Zeichenfolgen aus der Krypto Bibliothek, gegen die ssh gelinkt ist. Es erzeugt mehr als eine Ausgabezeile, könnte aber bei Bedarf in eine Zeile umgewandelt 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 vor emerge
[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
...
OpenSSL 1.0.1f 6 Jan 2014
Autsch, immer noch kein g.
Lösung 5:
Testen diese Skripte alle Dienste oder testen sie nur HTTPS? AFAIK, PostgreSQL ist verwundbar, aber das ist nur ein Gerücht, bis ein Angriff in freier Wildbahn 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 darunter verwenden. Es ist genauer und einfacher!
s_client -connect a23-75-248-141.deploy.static.akamaitechnologies.com:443 -debug -state
Sobald Sie verbunden sind, geben Sie B ein und Sie sehen auf einem 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 die Verbindung wird getrennt:
Geben Sie B
einHEARTBEATING
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:
- Blogbeitrag Wie Sie testen, ob Ihr OpenSSL-Heartbleeds auftritt
Es gibt auch diese Tools:
-
https://github.com/titanous/heartbleeder
-
http://filippo.io/Heartbleed/
-
https://github.com/musalbas/heartbleed-masstest