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

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

Je pensais que ce serait facile, mais j'ai rapidement rencontré un problème sous 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 eu ceci:

OpenSSL 1.0.1 14 mars 2012
construit le: mar. juin 4 07:26:06 UTC 2013
Plate-forme: [...]

A ma désagréable surprise, la lettre de version ne s'affiche pas. Non f, non g, 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 (af) et 1.0.1g est cruciale.

Des questions:

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

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

• https://twitter.com/orblivion/status/453323034955223040
• https://twitter.com/axiomsofchoice/status/453309436816535554

Quelques suggestions (spécifiques à la distribution):

• Ubuntu et Debian: apt-cache policy opensslet 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) etyum 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 ne suffit pas toujours. Vous devez également mettre à jour le paquet libssl1.0.0, et -then- vérifier si openssl version -aindique built on: Mon Apr 7 20:33:29 UTC 2014.

Sur la base de la date affichée par votre version de OpenSSL, il semble que vous êtes voyez la version complète , il affiche.

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

Donc, je vais aller de l'avant et affirmer que openssl version -ac'est le moyen approprié, pour la distribution croisée, d'afficher 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 aussi la méthode suggérée dans la documentation helpSS.ubuntu.com OpenSSL . Ubuntu LTS 12.04 est livré avec la version vanille OpenSSL v1.0.1, qui est une version qui ressemble à une version abrégée, car aucune lettre ne la suit.

Cela dit, il semble qu’un bogue majeur se soit produit dans Ubuntu (ou dans la façon dont ils conditionnent OpenSSL), qui openssl version -acontinue de renvoyer la version 1.0.1 originale à partir du 14 mars 2012, que OpenSSL ait été mis à niveau ou non. des nouvelles versions. Et comme pour la plupart des choses quand il pleut, ça déverse.

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

Par exemple, sous Debian, la version corrigée affiche un numéro de version de 1.0.1e-2+deb7u5au lieu de la version en amont de 1.0.1g.

Par conséquent, il n’existe actuellement aucun moyen fiable et portable de vérifier les versions SSL sur les distributions Linux , car elles utilisent toutes leurs propres correctifs et mises à jour avec des schémas de numérotation de version différents. Vous devrez rechercher le numéro de version fixe pour chaque distribution 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.

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.

Votre code peut indiquer un numéro de version réputé vulnérable, mais le code lui-même n'est pas vulnérable . Et l'inverse - un code silencieusement vulnérable - pourrait être encore pire!

De nombreux fournisseurs qui intègrent des produits open-source tels que OpenSSL et OpenSSH intégreront de manière sélective des correctifs urgents à une version antérieure du code, afin de maintenir la stabilité et la prévisibilité de l'API. Cela est particulièrement vrai pour les plates-formes "Version à long terme" et les appliances.

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 créer de la confusion chez les utilisateurs). Donc, pour rendre cela transparent et vérifiable, certains fournisseurs ajoutent leurs propres chaînes à la version principale du paquet. C'est VersionAddendumce que font parfois Debian (OpenSSL) et FreeBSD (sous OpenSSH, via la directive sshd_config).

Les fournisseurs qui ne le font pas le font probablement pour minimiser les risques de casse en raison des nombreuses méthodes directes et indirectes utilisées par les autres programmes pour vérifier les numéros de version.

Donc ça peut ressembler à ça:

$ 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 ça 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 de telles choses en jeu, vous feriez mieux de ne pas faire confiance au numéro de version.

Malheureusement, je ne suis pas sûr qu'il existe un moyen multi-plateforme de le faire. Comme je le dis dans un billet de blog , la version d'OpenSSL affichée sur Ubuntu 12.04 REMAINS 1.0.1 après la mise à niveau vers une version corrigée.

Pour Ubuntu 12.04 SEULEMENT, vous pouvez dire si vous avez été mis à jour si tous les éléments ci-dessous sont vrais:

1. dpkg -s openssl | grep Version montre la version 1.0.1-4ubuntu5.12 ou ultérieure.
2. dpkg -s libssl1.0.0 | grep Version montre la version 1.0.1-4ubuntu5.12 ou ultérieure.
3. openssl version -a affiche une date de "construction" du 7 avril 2014 ou plus tard.

Merci à @danny pour l'info supplémentaire.

Essayez ce qui suit. Il va extraire toutes les chaînes de la Crypto bibliothèque ssh est lié avec . Il produit plus d'une ligne de sortie, mais peut éventuellement être converti en une 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 a pour résultat

...
OpenSSL 1.0.1c 10 May 2012

après

...
OpenSSL 1.0.1f 6 Jan 2014

Ouch, toujours pas g.

Certains de ces scripts testent-ils tous les services ou ne testent-ils que HTTPS ? Autant que je sache , PostgreSQL est vulnérable, mais ce n’est qu’une rumeur jusqu’à ce que survienne une attaque sauvage.

Un script metasploit est disponible.

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

Vous pouvez taper ceci (testé avec la version binaire GnuWin32 OpenSSL 1.0.1.6, datée du 14/01/2014), ou simplement utiliser le script dans le commentaire situé en dessous de 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 pulsation cardiaque semblable à celle-ci.

Sur un hôte corrigé, vous verrez une réponse semblable à celle 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 coeur OpenSSL

Il y a aussi ces outils:

• https://github.com/titanous/heartbleeder

• http://filippo.io/Heartbleed/

• https://github.com/musalbas/heartbleed-masstest

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.

Vous feriez mieux de mettre à jour OpenSSL OpenSSL 1.0.1j.

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

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-le example.compar le nom ou l'adresse IP du serveur que vous souhaitez vérifier.

Je reviendrai "safe"si votre serveur est ok ou "server extension "heartbeat" (id=15)"sinon.

Cela ne repose pas sur le numéro de version, mais sur la liste de l'extension du serveur qui cause le problème, il devrait donc être immunisé contre les shenanigans de la version de la bibliothèque.

La machine que vous utilisez openssl s_clientsur doit être en utilisant OpenSSL 1.0.1 ou plus tard pour que cela fonctionne.