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

88

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:

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:

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.

Martijn
la source
2
au moins, assurez-vous que la version OpenSSL que vous avez n'est pas g en raison de la date à laquelle elle s'affiche
Pato Sáinz
3
Cela fonctionne sur CentOS[[email protected]~]# openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013
Jacob
1
@ PatoSáinz J'ai vérifié apt-cache policy opensslet il a répondu avec: Installed: 1.0.1-4ubuntu5.12qui est la 1.0.1g récemment publiée par 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
1
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
1
Si cette date de construction est exacte, vous ne pouvez pas avoir de code "version validée" plus récent que 1.0.1e, car la version 1.0.1f a été publiée en 2014 conformément aux notes de version d'OpenSSL 1.0.1 . Certaines lignes ou sections peuvent avoir été rétroportées sur votre version d’Ubuntu avant la version officielle OpenSSL 1.0.1f, bien sûr. Et la date de construction peut être moins que complètement utile.
Mots de passe anti-faiblesse

Réponses:

66

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.

HopelessN00b
la source
3
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, il openssl version -ane s'agit pas d'une méthode portable (du moins, pas portable vers Ubuntu). J'ai vérifié apt-cache policy opensslet il a répondu avec: Installed: 1.0.1-4ubuntu5.12qui est la 1.0.1g que vient de publier Ubuntu pour 12.04 LTS. Je me suis déconnecté et je suis revenu avant de vérifier.
Martijn
19
HopelessN00b, il n’ya rien de douteux à propos de la politique de correction de portage au lieu de bump 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 ce n'est pas parce que ça casse le raisonnement " je cours sous foo xyz, donc je ne suis pas vulnérable au dernier exploit ", cela n'en fait pas une mauvaise chose.
MadHatter
10
@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 s'embêter avec les numéros de version? Peut aussi commencer à nommer toutes nos affaires avec des allitérations. Nous pouvons appeler les versions vulnérables de OpenSSL Holy Heartbleed et les versions fixes Cunning Coagulant .
HopelessN00b
7
@ HopelessN00b Je pense que vous êtes pris au piège du piège "ceci a été corrigé dans la version XYZ", 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 XYZ, pourquoi ne pas avoir ECDHA ???? ..etc". Il est logique de comprendre que ce ne sont que des corrections de bugs.
NickW
13
@ NickW @Jubal @MadHatter Cependant, la chose avec OpenSSL est la suivante: 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
18

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.

Royce Williams
la source
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
14

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.

Schof
la source
2
Ok, dans ce cas, je dois ajouter que la version du paquet 1.0.1-4ubuntu5.12est UNIQUEMENT pour Ubuntu 12.04 LTS. Si vous êtes sur Ubuntu 12.10, vous devriez voir au moins la version 1.0.1c-3ubuntu2.7et si vous êtes sur 13.10, alors ce devrait être au moins la version 1.0.1e-3ubuntu1.2, selon la source: ubuntu.com/usn/usn-2165-1
Martijn
1
C'est malheureusement insuffisant. Vous devez également mettre à jour libssl1.0.0explicitement sur Ubuntu. Si vous voyez une date de création antérieure au 7 avril 2014, même si la version openssl est correcte ( 1.0.1-4ubuntu5.12pour 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 -an’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
4

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.

WaTeim
la source
3
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, de la même manière que le openssl version -afait. 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 les versions les plus récentes?
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
2

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   [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

La source:

Il y a aussi ces outils:

Justin Goldberg
la source
0

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.

Rufinus
la source
0

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.

egarcia
la source
4
Utile, mais ne vous dit pas si vous avez une version avec l'extension et le correctif .
Mattdm
1
C'est en effet un bon moyen de vérifier la vulnérabilité et c'est ce que font certains scripts. En réalité, il n’exige pas d’accès SSH.
Stefan Lasiewski
8
AVERTISSEMENT IMPORTANT : la machine sur laquelle vous exécutezopenssl s_clientDOIT utiliser OpenSSL 1.0.1 ou une version ultérieure pour que cela fonctionne. Si vous exécutez cette commande sur une machine avec 0.9.8 ou 1.0.0, il signalera toujours "Sécuritaire", même pour les serveurs vulnérables .
voretaq7
Impair. J'utilise une version d'OpenSSL supposément affectée par ce bogue, mais cette chaîne n'apparaît pas dans le résultat ...
Michael,
@StefanLasiewski J'ai mis à jour ma réponse et supprimé la partie "need ssh"
egarcia le