Question 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 (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 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:

Quelques suggestions (spécifiques à la distribution):

  • 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ésident:

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 vérifier ensuite si openssl version -a indique built on: Mon Apr 7 20:33:29 UTC 2014.


86
2018-04-07 23:51


origine


au moins, assurez-vous que la version OpenSSL que vous avez n'est pas g à cause de la date qu'il montre - Pato Sáinz
Cela fonctionne sur CentOS [root@null~]# openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 - Jacob
@ PatoSáinz j'ai vérifié apt-cache policy openssl et il a répondu avec: Installed: 1.0.1-4ubuntu5.12 qui est la 1.0.1g que vient de publier Ubuntu pour 12.04 LTS. Je me suis déconnecté puis je suis rentré. Y a-t-il autre chose que je puisse faire pour vérifier? - Martijn
Je ferai remarquer, pour cela que je ne sais pas, au cas où cela serait utile ... Ubuntu 12.04 LTS fourni avec OpenSSL 1.0.1 (vanilla). - HopelessN00b
Si cette date de construction est exacte, vous ne pouvez pas avoir de code "version versée" plus récent que 1.0.1e, car 1.0.1f est sorti en 2014 par les notes de publication d'OpenSSL 1.0.1. Certaines lignes ou sections peuvent avoir été rétroportées sur votre version Ubuntu avant la version officielle OpenSSL 1.0.1f, bien sûr. Et la date de construction peut être moins que complètement utile. - Anti-weakpasswords


Réponses:


D'après la date affichée par votre version d'OpenSSL, il semble que vous sont voir la version complète affichée ici.

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 -a est le moyen approprié 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 est la méthode suggérée dans la documentation helpSS.ubuntu.com OpenSSL, ainsi que. Ubuntu LTS 12.04 est livré avec la version vanille OpenSSL v1.0.1, qui ressemble à une version abrégée, du fait qu’elle ne soit pas suivie d’une lettre.

Cela dit, il semble qu’il existe un Majeur bug dans Ubuntu (ou comment ils conditionnent OpenSSL), dans ce openssl version -a continue de renvoyer la version 1.0.1 d'origine à compter du 14 mars 2012, que OpenSSL ait été mis à niveau vers l'une des versions plus récentes ou non. 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 des mises à jour dans OpenSSL (ou d'autres packages), mais plutôt de s'appuyer sur les mises à jour en amont et sur la numérotation des versions que tout le monde reconnaît. Dans le cas d’OpenSSL, où les numéros de version de lettre 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û à la FIPS validé plugin majeur 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+deb7u5 au lieu de la version amont de 1.0.1g.

En conséquence, à ce moment, il n'y a pas de moyen fiable et portable de vérifier les versions SSL sur les distributions Linux, car ils utilisent tous leurs propres correctifs et mises à jour rétroportés 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.


67
2018-04-08 00:05



Mon installation est une simple Ubuntu 12.04 LTS sans quoi que ce soit que je me suis compilé ou téléchargé à partir de sources autres que les référentiels Ubuntu. Si Ubuntu distribue OpenSSL avec des numéros de version abrégés, alors openssl version -a n'est pas une méthode portable (du moins, pas portable vers Ubuntu). j'ai vérifié apt-cache policy openssl et il a répondu avec: Installed: 1.0.1-4ubuntu5.12 qui est la 1.0.1g que vient de publier Ubuntu pour 12.04 LTS. Je me suis déconnecté et je suis rentré avant de vérifier. - Martijn
HopelessN00b, il n’ya rien de douteux à propos de la politique de correction de portage au lieu de bump des versions; c'est un très bon moyen d'assurer la stabilité de la plate-forme, ce qui est hautement souhaitable dans un environnement de serveur. Comme toute décision, cela a des conséquences dont les utilisateurs doivent être conscients; mais juste parce que ça casse le "J'exécute foo x.y.z donc je ne suis pas vulnérable au dernier exploit"ligne de raisonnement, cela n'en fait pas une mauvaise chose. - MadHatter
@towo Les numéros de version existent pour une raison. Si nous allons simplement jeter les numéros de version en amont par la fenêtre parce que "entreprise", ou peu importe, pourquoi se soucier des numéros de version? Peut aussi commencer à nommer toutes nos affaires avec des allitérations. Nous pouvons appeler les versions vulnérables d'OpenSSL Saint Heartbleed et les fixes Coagulant rusé. - HopelessN00b
@ HopelessN00b Je pense que vous êtes pris par le piège "ceci a été corrigé dans la version X.Y.Z", ils ne suivent pas les numéros de version, car tout ce qui est importé dans la dernière version est un bogue et des correctifs de sécurité. S'ils ont heurté le numéro de version, vous vous attendez également à la fonctionnalité supplémentaire .. "J'ai OpenSSL v X.Y.Z, pourquoi ne pas avoir ECDHA ???? ..etc". Il est logique de comprendre que ce ne sont que des corrections de bugs. - NickW
@ NickW @Jubal @MadHatter La chose avec OpenSSL, cependant, est que: 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. Donc, rien n'est gagné en abandonnant le schéma de versioning en amont; Le portage des mises à jour est essentiellement identique à l'utilisation de la version mise à jour, car la mise à jour inclut uniquement des correctifs de sécurité et des bogues. Cela confond les choses et ne nous laisse aucun moyen de vérifier de manière portable la version d'OpenSSL sur des distributions Linux. - HopelessN00b


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

Vous pourriez avoir du code qui rapporte un numéro de version réputé vulnérable, mais le code actuel 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 provoquer des faux positifs dans les scanners de vulnérabilité (et de créer de la confusion chez les utilisateurs). Ainsi, pour rendre cela transparent et vérifiable, certains fournisseurs ajoutent leurs propres chaînes à la version principale du package. Debian (OpenSSL) et FreeBSD (sous OpenSSH, via le logiciel VersionAddendum sshd_config) fait parfois cela.

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 il a été patché:

$ 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 êtes mieux si vous ne faites pas confiance au numéro de version.


18
2018-04-08 20:52



Il est clair que la vérification des versions n’est pas aussi facile et transparente que je l’espérais. La vérification de la vulnérabilité est multi-plateforme, mais aussi plus difficile à faire: vous devez disposer d'un PoC ou d'un test fiable pour le service logiciel vulnérable que vous exécutez. Dans ce cas, tout a commencé avec une PoC pour Apache et nginx. Et si je n'utilisais que SMTP avec SSL à ce moment-là et que je voulais vérifier si je suis vulnérable? Nous aurons éventuellement des tests pour la plupart des services, mais cela peut prendre un certain temps. - Martijn
Martijn, c'est un point juste. Lorsqu'un test n'est pas disponible, les méthodes secondaires (telles que le suivi de la somme de contrôle des fichiers binaires affectés sur vos systèmes cibles) sont moins optimales, mais peuvent être suffisantes pour que le travail soit effectué ... et ensuite pour passer au feu suivant. :-) - Royce Williams


Malheureusement, je ne suis pas sûr qu'il y est une façon multi-plateforme de le faire. Comme je discute dans un 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 Versionmontre la version 1.0.1-4ubuntu5.12 ou ultérieure.
  2. dpkg -s libssl1.0.0 | grep Versionmontre 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.


14
2018-04-08 03:15



Ok, dans ce cas je dois ajouter cette version du paquet 1.0.1-4ubuntu5.12 est UNIQUEMENT pour Ubuntu 12.04 LTS. Si vous êtes sur Ubuntu 12.10, vous devriez voir au moins la version 1.0.1c-3ubuntu2.7 et si vous êtes sur 13.10 alors il devrait être au moins la version 1.0.1e-3ubuntu1.2, selon la source: ubuntu.com/usn/usn-2165-1 - Martijn
C'est malheureusement insuffisant. Vous doit aussi mise à niveau libssl1.0.0 explicitement sur Ubuntu. Si vous voyez une date de construction antérieure au 7 avril 2014, même si openssl est la version semble correcte (1.0.1-4ubuntu5.12 pour Ubuntu 12.04), vous êtes probablement toujours vulnérable. - danny
@ Danny Vous venez de me sauver tellement de travail. J'essayais de comprendre pourquoi la date de construction était correcte sur certains systèmes 12.04 et fausse sur d'autres. Vous êtes une bouée de sauvetage! - Schof
openssl version -a n’aura peut-être pas besoin de la date de compilation du 7 avril, car le correctif est transféré dans les versions antérieures. - Patrick James McDougle


Essayez ce qui suit. Il va extraire toutes les chaînes du crypto Bibliothèque à laquelle ssh est liée. 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.


4
2018-04-08 14:45



Je pensais que vous étiez sur le point de fournir une bonne solution, mais malheureusement, cela ne fonctionne pas pour la bibliothèque de chiffrement sur Ubuntu 12.04 LTS. Il affiche toutes les chaînes avec la version [...] part of OpenSSL 1.0.1 14 Mar 2012, la même façon que openssl version -a Est-ce que. C'est un truc qui peut marcher dans d'autres cas! - Martijn
@Martijn C'est dommage, mais cela fonctionne avec Ubuntu 12.10. Étrange qu'il se soit mal identifié le 12.04. Y a-t-il plusieurs bibliothèques? Est-il possible que ssh n'utilise pas la version la plus récente? - waTeim
Je n'ai pas pu trouver d'autres fichiers binaires openssl ni de bibliothèques de chiffrement. D’autres suggèrent que la différence est que, sur 12.04 LTS, Ubuntu rétorque les modifications apportées à la version 1.0.1 sans augmenter la version. Bien que 12.10 ne soit pas un LTS, Ubuntu utilise la dernière version à la place d’un backport. - Martijn


Est-ce que l'un de ces scripts teste tous les services ou ne teste-t-il que HTTPS? Autant que je sache, PostgreSQL est vulnérable, mais ce n’est qu’une rumeur jusqu’à ce qu’une attaque à l’état sauvage fasse surface.

Il y a un metasploit script disponible pour utilisation.

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

Vous pouvez taper ceci (testé avec GnuWin32 OpenSSL version binaire 1.0.1.6 du 14/01/2014), ou utilisez simplement 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:

Il y a aussi ces outils:


2
2018-04-09 11:43





Pour Ubuntu, vous pouvez utiliser:

aptitude show libssl1.0.0 | grep Version

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


0
2018-04-08 11:14





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

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


0
2017-10-19 01:57