Mot de passe et la faille Heartbleed dans OpenSSL

Utilisez l'action rapide suivante pour savoir si un site sécurisé (auquel vous accédez en HTTPS et non en HTTP) sur lequel vous allez est hébergé sur un serveur affecté par la failleHeartbleed.

Faites ceci pour chacun des sites sécurisés que vous utilisez sur lesquels vous êtes obligé de vous identifier (identifiant et mot de passe) et n'utilisez plus les sites vulnérables tant que les administrateurs des serveurs qui les hébergent n'ont pas corrigé la .failleHeartbleed

Recherche de vulnérabilité Heartbleed (Heartbleed vulnerability-checking).

Test de vulnérabilité Hearthbleed du serveur d'un domaine Le serveur d'Assiste.com n'est pas vulnérable (10.04.2014 - 22h30) En sus, Assiste.com ne vous demande jamais de vous identifier

Test de vulnérabilité Hearthbleed du serveur d'un domaine Wikipedia.org est vulnérable (10.04.2014 - 22h30)

Le transport de données dans le mode client/serveur, entre le « client » (votre appareil) et le « serveur » sur lequel se trouve un site utilisé, peut être sécurisé ou non sécurisé. Le « client » (votre appareil) est essentiellement opéré par votre navigateur Web comme Firefox, Internet Explorer, Opera, Google Chrome, Safari, etc., le client de messagerie, comme Outlook Express, Outlook, Thunderbird, etc., toutes les applications communicantes, dont les applications client/serveur comme FileZilla... et toutes les technologies de votre système d'exploitation.

Lorsque vous consultez un site de recettes de cuisine, il n'est généralement pas utile de s'identifier et il n'est pas utile de sécuriser le transport de données.

Lorsque vous travaillez sur vos comptes bancaires, sur le site de votre banque, d'une administration, etc. il est indispensable de vous identifier et il est indispensable que le transport de données (les transactions entre client et serveur) soit chiffré.

Il existe donc des protocoles de sécurisation (ou non) des échanges, sur le Web (HTTP, HTTPS, FTP, FTPS, etc.), qui sont reconnus automatiquement par votre navigateur (qui vous le signale avec l'apparition d'une clé ou un cadenas fermé au début de la barre d'adresse. L'adresse elle-même de la page sécurisée commence par https:// au lieu de hhttp:// pour les transactions non sécurisées.).

Ce protocole s'appelait initialement SSL. Il s'appelle, depuis 2001, TLS (Transport Layer Security), mais SSL (Secure Sockets Layer) reste le terme employé. Un autre protocole, appelé DTLS (Datagram Transport Layer Security) est une variante de SSL.

Il existe plusieurs implémentations de SSL, dont openSSL, GnuTLS et JSSE.

Heartbleed - Faille de sécurité dans openSSL

Les deux protocoles TLS et DTLS sont affectés par une faille découverte et annoncée publiquement le 07.04.2014. Il ne s'agit pas d'une annonce Zero Day. Cette faille existe dans plusieurs mises à jour successives d'openSSL, depuis deux ans.

Qui est affecté par la faille Heartbleed ?

La faille Heartbleed affecte tous les internautes du monde consultant un site sécurisé nécessitant une identification et une authentification par mot de passe, lorsque ce site est hébergé sur un serveur utilisant la sécurisation OpenSSL, c'est-à-dire presque tous les sites sécurisés du monde.

Toutes les données qui transitent entre votre appareil et le serveur (identifiant, mot de passe, et toutes les données, dont les numéros de cartes bancaires ou de comptes bancaires, etc.) sont chiffrées selon le protocole TLS ou DTLS. Toutes les applications de communication utilisent cette couche de chiffrement.

OpenSSL, qui est un logiciel installé côté serveur, gère le chiffrement et le déchiffrement des transactions sécurisées.

La découverte, baptisée Heartbleed (cœur qui saigne), est créditée, initialement, à Neel Mehta de Google Security. Une équipe d'ingénieurs sécurité (Riku, Antti and Matti) de Codenomicon revendique également un travail sur cette faille et la mise en place de l'outil (Heartbleed vulnerability-checking) permettant de voir si vos sites, et donc vos transactions avec ces sites, sont affectés par cette faille.

Cette faille est d'une gravité extrême. Sur une échelle de 1 à 10, elle est classée 11.

Elle permet aux cybercriminels de pénétrer dans une zone de 64 KO de mémoire, sur les serveurs utilisant les versions 1.0.1 ou 1.0.2-beta releases d'OpenSSL (incluant les releases 1.0.1f et 1.0.2-beta1).

Dans ces zones peuvent être récupérés, en clair (après décryptage), des identifiants, mots de passe et autres données privées (numéros de cartes bancaires...) et censées être hautement protégées.

Les limites d'exploitation de cette faille sont inconnues. Les conséquences à moyen et long terme sont insoupçonnables : des certificats de sécurité eux-mêmes pourraient être compromis et leurs clés de déchiffrement, privées, pourraient avoir été accédées, ce qui rendrait le protocole TSL/DTSL inutile (les cybercriminels pourraient toujours accéder au déchiffrement, même après l'application du correctif). Or les clés privées de chiffrement représentent le Saint des Saints, le naos de la forteresse de la sécurité, celle du chiffrement. Avec ces clés, tous les trafics peuvent être lus dans le texte, y compris tous les trafics futurs.

Outre l'application du correctif de sécurité, il faudrait mettre à jour tous les identifiants/mots de passe, côté internautes, et utiliser de nouveaux certificats de sécurité côté domaines (ce qui est payant).

L'attaque ne laisse strictement aucune trace. Elle peut être réitérée un nombre illimité de fois pour capturer des contenus différents dans les 64 KO compromis de mémoire des serveurs.

https://www.openssl.org/news/secadv_20140407.txt.

OpenSSL Security Advisory [07 Apr 2014]
========================================
TLS heartbeat read overrun (CVE-2014-0160)
==========================================
A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.
Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.
Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.
Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.
1.0.2 will be fixed in 1.0.2-beta2.

L'intégralité mondiale des déclarations de failles de sécurité (les CVE - Common Vulnerabilities and Exposures) se fait dans une base de données unique : https://cve.mitre.org.

1. Les publications des CVE se font, initialement, de manière totalement « vide » (sans aucune description) tant que la faille n’est pas corrigée afin de ne donner aucune idée aux cybercriminels. Cela permet uniquement au découvreur de la faille de fixer la date de sa découverte dans la compétition qui peut exister entre chercheurs en sécurité.

2. Le découvreur signale de manière détaillée sa découverte aux auteurs de l’application faillible et leur laisse un délai pour développer et publier un correctif (par exemple 1, 2 ou 3 mois) en les prévenant (menaçant) de publier la faille et son mode d’exploitation au-delà.

3. Une fois la faille corrigée, les auteurs de l’application faillible corrigée publient le/les correctifs.
   Voir la liste quotidienne des alertes et avis de correctifs aux failles de sécurité.

4. Généralement, au bout d'un mois après la publication des correctifs, https://cve.mitre.org ajoute le détail de la faille, dont les correctifs sont censés être enfin appliqués par tous les utilisateurs, au CVE.

CVE de la faille Heartbleed : CVE-2014-0160

Concerne les administrateurs et opérateurs des serveurs concernés. Le patch du bug étant publié, il faut :

1. Appliquer le patch.

2. Créer une nouvelle paire de clé publique/clé privée.

3. Mettre à jour le certificat SSL.

4. Changer (obliger les utilisateurs du service à changer) les couples identifiants/mots de passe.