Heartbleed: comment vérifier de manière fiable et portable la version OpenSSL?

Question

Je cherchais un moyen fiable et portable pour vérifier la version OpenSSL sur GNU/Linux et d'autres systèmes, afin que les utilisateurs puissent facilement découvrir s'ils devraient mettre à niveau leur SSL en raison du bogue Heartbleed.

Je pensais que ce serait facile, mais j'ai rapidement rencontré un problème sur Ubuntu 12.04 LTS avec le dernier OpenSSL 1.0.1g:

version openssl -a

Je m'attendais à voir une version complète, mais à la place, j'ai obtenu ceci:

OpenSSL 1.0.1 14 mars 2012 Construit sur: mar 4 juin 07:26:06 UTC 2013 Plateforme: [...]

À ma surprise désagréable, la lettre de version ne s'affiche pas. Pas de f, pas de g là, juste "1.0.1" et c'est tout. Les dates indiquées ne permettent pas non plus de découvrir une version (non) vulnérable.

La différence entre 1.0.1 (a-f) et 1.0.1g est cruciale.

Des questions:

Quel est un moyen fiable de vérifier la version, de préférence la distribution croisée?
Pourquoi la lettre de version ne s'affiche-t-elle pas en premier lieu? Je n'ai pas pu tester cela sur autre chose qu'Ubuntu 12.04 LTS.

D'autres signalent également ce comportement. Quelques exemples:

Quelques suggestions (spécifiques à la distribution) intégrées:

Ubuntu et Debian: apt-cache policy openssl et apt-cache policy libssl1.0.0. Comparez les numéros de version aux packages ici: http://www.ubuntu.com/usn/usn-2165-1/
Fedora 20: yum info openssl (merci @znmeb sur Twitter) et yum info openssl-libs

Vérifier si une ancienne version d'OpenSSL est toujours résidente:

Ce n'est pas complètement fiable, mais vous pouvez essayer lsof -n | grep ssl | grep DEL. Voir Heartbleed: comment vérifier de manière fiable et portable la version OpenSSL? pourquoi cela peut ne pas fonctionner pour vous.

Il s'avère que la mise à jour du paquet OpenSSL sur Ubuntu et Debian n'est pas toujours suffisante. Vous devez également mettre à jour le paquet libssl1.0.0 et -then- vérifier si openssl version -a indique built on: Mon Apr 7 20:33:29 UTC 2014.

HopelessN00b · Accepted Answer

En fonction de la date affichée par votre version d'OpenSSL, il semble que vous voyez la version complète affichée.

Open SSL 1.0.1 a été publié le 14 mars 2012 . La version 1.0.1a a été publiée le 19 avril 2012.

Donc, je vais continuer et affirmer que openssl version -a est le moyen approprié pour diffuser la version complète d'OpenSSL installée sur le système. Cela semble fonctionner pour toutes les distributions Linux auxquelles j'ai accès, et c'est la méthode suggérée dans la documentation OpenSSL help.ubuntu.com, aussi . Ubuntu LTS 12.04 est livré avec Vanilla OpenSSL v1.0.1, qui est la version qui ressemble à une version abrégée, du fait de ne pas avoir de lettre qui la suit.

Cela dit, il semble qu'il y ait un bug - major dans Ubuntu (ou comment ils conditionnent OpenSSL), dans ce openssl version -a continue de renvoyer la version 1.0.1 d'origine à partir du 14 mars 2012, que OpenSSL ait été mis à niveau ou non vers l'une des versions les plus récentes. Et, comme avec la plupart des choses quand il pleut, il pleut.

Ubuntu n'est pas la seule distribution majeure dans l'habitude de rétroporter des mises à jour dans OpenSSL (ou d'autres packages), plutôt que de s'appuyer sur les mises à jour en amont et la numérotation des versions que tout le monde reconnaît. Dans le cas d'OpenSSL, où les numéros de version des lettres ne représentent que des corrections de bogues et des mises à jour de sécurité, cela semble presque incompréhensible, mais j'ai été informé que cela peut être dû au validé par FIPS plugin principales distributions Linux expédier emballé avec OpenSSL. En raison des exigences de revalidation qui se déclenchent en raison de tout changement, même des changements qui bouchent les failles de sécurité, il est verrouillé en version.

Par exemple, sur Debian, la version fixe affiche un numéro de version de 1.0.1e-2+deb7u5 au lieu de la version amont de 1.0.1g.

Par conséquent, pour le moment, il n'existe aucun moyen fiable et portable de vérifier les versions SSL dans les distributions Linux , car ils utilisent tous leurs propres correctifs et mises à jour rétroportés avec différents schémas de numérotation des versions. Vous devrez rechercher le numéro de version fixe pour chaque distribution différente de Linux que vous exécutez et vérifier la version OpenSSL installée par rapport à la numérotation de version spécifique de cette distribution pour déterminer si vos serveurs exécutent une version vulnérable ou non.

Royce Williams · Answer

Si vous voulez quelque chose de vraiment multi-plateforme, vérifiez la vulnérabilité elle-même plutôt que de vous fier aux numéros de version.

Vous pouvez avoir du code qui signale un numéro de version connu pour être vulnérable, mais le code réel n'est pas vulnérable . Et l'inverse - un code silencieusement vulnérable - pourrait être encore pire!

De nombreux fournisseurs qui regroupent des produits open source comme OpenSSL et OpenSSH moderniseront sélectivement les correctifs urgents vers une ancienne version de code, afin de maintenir la stabilité et la prévisibilité de l'API. Cela est particulièrement vrai pour les "versions à long terme" et les plates-formes d'appliance.

Mais les fournisseurs qui le font en silence (sans ajouter leur propre suffixe de chaîne de version) courent le risque de déclencher des faux positifs dans les scanners de vulnérabilité (et de confondre les utilisateurs). Donc, pour rendre cela transparent et vérifiable, certains fournisseurs ajoutent leurs propres chaînes à la version principale du package. Debian (OpenSSL) et FreeBSD (dans OpenSSH, via la directive VersionAddendum sshd_config) le font parfois.

Les fournisseurs qui ne le font pas le font probablement pour minimiser les risques de casse en raison des nombreuses façons directes et indirectes par lesquelles d'autres programmes vérifient les numéros de version.

Cela peut donc ressembler à ceci:

$ 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

... même si il a été corrigé :

$ 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

Avec des choses comme ça en jeu, vous feriez mieux si vous ne faites pas confiance au numéro de version.

Schof · Answer

Malheureusement, je ne suis pas sûr qu'il existe un moyen multiplateforme de le faire. Comme je l'explique dans un article de blog , la version d'OpenSSL affichée sur Ubuntu 12.04 REMAINS 1.0.1 après la mise à niveau vers une version fixe.

Pour Ubuntu 12.04 UNIQUEMENT, vous pouvez savoir si vous avez été mis à jour si toutes les conditions ci-dessous sont vraies:

dpkg -s openssl | grep Version affiche la version 1.0.1-4ubuntu5.12 ou ultérieure.
dpkg -s libssl1.0.0 | grep Version affiche la version 1.0.1-4ubuntu5.12 ou ultérieure.
openssl version -a affiche une date "intégrée" du 7 avril 2014 ou version ultérieure.

Merci à @danny pour les informations supplémentaires.

waTeim · Answer

Essayez ce qui suit. Il extraira toutes les chaînes de la bibliothèque crypto contre laquelle ssh est lié. Il produit plus d'une ligne de sortie, mais si nécessaire, peut être converti en 1 ligne.

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

produit

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

par exemple. sur Gentoo avant d'émerger

[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

la commande ci-dessus entraîne

... OpenSSL 1.0.1c 10 May 2012

après

... OpenSSL 1.0.1f 6 Jan 2014

Aïe, toujours pas de g.

Justin Goldberg · Answer

L'un de ces scripts teste-t-il tous les services ou teste-t-il uniquement HTTPS ? AFAIK , PostgreSQL est vulnérable, mais ce n'est qu'une rumeur jusqu'à ce qu'une attaque dans la nature fasse surface.

Un script metasploit est disponible.

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

Vous pouvez taper ceci (testé avec GnuWin32 OpenSSL version binaire 1.0.1.6, datée du 2014-01-14), ou simplement utiliser le script dans le commentaire ci-dessous celui-ci. C'est plus précis et plus simple!

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

Une fois connecté, tapez B et vous verrez sur un hôte vulnérable et vous ne serez pas déconnecté:

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

Vous obtiendrez une réponse de battement de cœur qui ressemble à celle-ci.

Sur un hôte corrigé, vous verrez une réponse similaire à ci-dessous et vous serez déconnecté:

Entrez B

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

La source:

Article de blog Comment tester si votre cœur OpenSSL saigne

Il y a aussi ces outils:

Kevin Nguyen · Answer

Vous feriez mieux de passer à la dernière version d'OpenSSL OpenSSL 1.0.1j.

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

egarcia · Answer

J'ai trouvé ce script dans devcentral :

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

Remplacez example.com Par le nom ou l'adresse IP du serveur que vous souhaitez vérifier.

Renvoie "safe" Si votre serveur fonctionne bien ou "server extension "heartbeat" (id=15)" sinon.

Cela ne dépend pas du numéro de version, mais de la liste de l'extension de serveur à l'origine du problème, elle devrait donc être à l'abri des manigances de la version de la bibliothèque.

La machine que vous exécutez openssl s_client Sur doit utiliser OpenSSL 1.0.1 ou une version ultérieure pour que cela fonctionne.

Rufinus · Answer

Pour Ubuntu, vous pouvez utiliser:

aptitude show libssl1.0.0 | grep Version

Et comparez avec http://www.ubuntu.com/usn/usn-2165-1/ . Après un redémarrage (!!!), vous pouvez vérifier avec http://possible.lv/tools/hb.