Solution 1 :
D'après la date affichée par votre version d'OpenSSL, il semble que vous êtes voir la version complète affichée ici.
Open SSL 1.0.1 est sorti le 14 mars 2012. 1.0.1a est sorti le 19 avril 2012.
Donc, je vais continuer et affirmer que openssl version -a est le moyen approprié, inter-distributions, 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 également la méthode suggérée dans la documentation OpenSSL de help.ubuntu.com. Ubuntu LTS 12.04 est livré avec vanilla OpenSSL v1.0.1, qui est la version qui ressemble à une version abrégée, car elle n'est pas suivie d'une lettre.
Cela dit, il semble qu'il y ait un majeur bogue dans Ubuntu (ou comment ils empaquetent OpenSSL), dans ce openssl version -a continue de renvoyer la version 1.0.1 d'origine à partir du 14 mars 2012, qu'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 à avoir l'habitude de rétroporter les 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 en 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 peut être dû au plug-in validé par FIPS, les principales distributions Linux livrées avec OpenSSL. En raison des exigences relatives à la revalidation qui se déclenchent en raison de tout changement, même les changements qui corrigent les failles de sécurité, la version est verrouillée.
Par exemple, sur Debian, la version corrigée 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, à l'heure actuelle, 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.
Solution 2 :
Si vous voulez quelque chose de vraiment multiplateforme, 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 - du code silencieusement vulnérable - pourrait être encore pire !
De nombreux fournisseurs qui regroupent des produits open source comme OpenSSL et OpenSSH adapteront de manière sélective les correctifs urgents à une ancienne version du code, afin de maintenir la stabilité et la prévisibilité de l'API. Cela est particulièrement vrai pour les plates-formes de "version à long terme" et 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 dérouter 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 le VersionAddendum directive sshd_config) le font parfois.
Les fournisseurs qui ne le font pas le font probablement pour minimiser les risques de panne en raison des nombreuses façons directes et indirectes utilisées par d'autres programmes pour vérifier 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 s'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 celle-ci en jeu, il vaut mieux que vous ne fassiez pas confiance au numéro de version.
Solution 3 :
Malheureusement, je ne suis pas sûr qu'il existe une manière multiplateforme de le faire. Comme je le dis dans un article de blog, la version d'OpenSSL affichée sur Ubuntu 12.04 RESTE 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 Versionmontre la version 1.0.1-4ubuntu5.12 ou ultérieure.dpkg -s libssl1.0.0 | grep Versionmontre la version 1.0.1-4ubuntu5.12 ou ultérieure.openssl version -aindique une date de "construction" du 7 avril 2014 ou une date ultérieure.
Merci à @danny pour les informations supplémentaires.
Solution 4 :
Essayez ce qui suit. Il va extraire toutes les chaînes du crypto bibliothèque à 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 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
la commande ci-dessus donne
...
OpenSSL 1.0.1c 10 May 2012
après
...
OpenSSL 1.0.1f 6 Jan 2014
Ouch, toujours pas de g.
Solution 5 :
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 sauvage fasse surface.
Un script metasploit est disponible.
https://github.com/rapid7/metasploit-framework/commit/dd69a9e5dd321915e07d8e3dc8fe60d3c54f551a
Vous pouvez taper ceci (testé avec la version binaire OpenSSL GnuWin32 1.0.1.6, datée du 14/01/2014), ou simplement utiliser le script dans le commentaire sous 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 patché, 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 [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
Origine :
- Article de blog Comment tester si votre cœur OpenSSL saigne
Il existe également ces outils :
-
https://github.com/titanous/heartbleeder
-
http://filippo.io/Heartbleed/
-
https://github.com/musalbas/heartbleed-masstest