Une faille dans OpenSSL permet d'accéder à des données sécurisées par TLS/SSL

Le , par DotNetMatt, Modérateur
Ces dernières heures, vous avez probablement entendu parler de cette faille de sécurité qui attaque en plein cœur la sécurité du Web : Heartbleed ("cœur qui saigne").


Elle touche OpenSSL et est présente dans la bibliothèque de chiffrement en version 1.0.1 et 1.0.2 bêta. La première étant aujourd'hui largement déployée, la découverte de cette faille a de quoi soulever des inquiétudes. Elle permet en effet à un attaquant d'accéder à des données sécurisées par TLS/SSL directement dans la mémoire du serveur, en récupérant les clefs. Cela aurait également pu impacter les certificats, pourtant réputés comme très sûrs.

Un ingénieur de Google, Adam Langley, qui a participé à la création du correctif, a quelque peu calmé le jeu sur Tweeter en indiquant qu'il n'avait pas réussi à récupérer les clefs, seulement un cookie.

Les géants du Web ont déjà appliqué le correctif, cependant les sites plus modestes ne sont pas encore tous immunisés. Les principaux éditeurs de logiciel font également leur maximum pour pousser le correctif chez leurs clients. Il est possible de vérifier si un site est vulnérable ou non en utilisant le site http://filippo.io/Heartbleed/.

La publication de cette faille de sécurité a eu lieu avant même que le moindre patch ne soit disponible, ce qui a provoqué une réaction très rapide des principaux acteurs du Web.

En attendant, il est recommandé d'être prudent lorsqu'un site utilise une connexion cryptée par SSL/TLS (url commençant par HTTPS). Changer de mot de passe n'est pas une solution, car celui-ci pourrait être récupéré via un site vulnérable lors du changement.

Si votre site est vulnérable, n'attendez pas pour appliquer le patch 1.0.1g sur vos serveurs. Il est disponible ici : http://www.openssl.org/source/
Il faut également déposer de nouvelles clés et renouveler son certificat de sécurité.


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de sneb5757 sneb5757
http://www.developpez.com
Membre actif
le 09/04/2014 20:55
Je ne suis pas tout à fait d'accord sur le changement de mot de passe.

Certes cela ne règle pas le problème, et si le service sur lequel est changé ce dernier est encore compromis, le risque reste le même. Mais sur un service impacté et sur lequel la faille de sécurité a été corrigé ça a du sens.

Le problème est de savoir si oui ou non un service a été impacté. Ce qui m'inquiète un peu ce sont les banques qui ne sont pas franchement bavardes sur les problèmes de sécurité. Si un service ne communique pas comment savoir s'il faut changer le mot de passe ou pas ? J'ai hésité, mais j'ai quand même posté un message sur mon FB pour inciter mes amis à changer leur mot de passe de leur web banking et service stockant des données sensibles. Je pense également qu'il faudrait être vigilant ( je veux dire plus que d'habitude) les prochains temps sur les mouvements d'argent des comptes en banques. C'est peut être un excès de prudence mais ça ne me parait pas une mauvaise recommandation. Votre avis ?

Ensuite certes aucune clé privé n'a été récupérer apparemment, mais chez yahoo! de nombreux mot de passe ont fuité de leur serveur d'authentification.
Avatar de pmithrandir pmithrandir
http://www.developpez.com
Expert Confirmé
le 10/04/2014 9:55
Si tu veux savoir, tu peux tester ta banque avec ce lien.
http://filippo.io/Heartbleed/

A priori la mienne est pas impactée.

En plus, si l'annonce a été faite hier matin dans les médias, l'update de open ssl était disponible 2 heures avant sur mon ordi. (distrib mageia) On peut donc espérer que les banques auront su réagir vite.
Avatar de Algo D.DN Algo D.DN
http://www.developpez.com
Membre éclairé
le 10/04/2014 9:58
Citation Envoyé par sneb5757  Voir le message
Je ne suis pas tout à fait d'accord sur le changement de mot de passe.

Certes cela ne règle pas le problème, et si le service sur lequel est changé ce dernier est encore compromis, le risque reste le même. Mais sur un service impacté et sur lequel la faille de sécurité a été corrigé ça a du sens.

Tout à fait d'accord, on ne peut pas demander aux utilisateurs de changer leurs pws si les serveurs (https donc sécurisés) restent vulnérables à cette faille...

Moi ce qui m’inquiète dans ce cas de figure (Heartbleed affectant OpenSSL) c'est la réactivité des éditeurs de logiciel pour patcher leurs solutions, surtout le temps de réponse à l'application du correctif, j'ose supposer que la réactivité est au rendez-vous pour les sites sensibles et les serveurs ayant normalement une bonne maintenance.

Quand à ceux pour qui la sécurité n'est qu'une notion abstraite
Avatar de dev14 dev14
http://www.developpez.com
Membre confirmé
le 10/04/2014 10:30
Bonjour,

votre lien de test assure que ma banque aussi n'est pas impactée. Mais qui me dit qu'elle n'a pas fait sa mise à jour il y a 1h, et qu'avant elle était concernée. Autrement dit, on devrait peut être changer nos mots de passe quand même?

Et pour d'autres sites (hébergés chez OVH) :

Uh-oh, something went wrong: write tcp ***********:****: broken pipe

Cela signifie que le diagnostic est impossible ou que la faille existe pour eux à votre avis?

Exemple aussi du site de pari en ligne : https://www.betclic.fr
Avatar de fredoche fredoche
http://www.developpez.com
Membre Expert
le 10/04/2014 10:47
Merci pour la news DotNetMatt

C'est un peu l'effervescence autour de ce sujet
Citation Envoyé par dev14  Voir le message
Bonjour,

votre lien de test assure que ma banque aussi n'est pas impactée. Mais qui me dit qu'elle n'a pas fait sa mise à jour il y a 1h, et qu'avant elle était concernée. Autrement dit, on devrait peut être changer nos mots de passe quand même?

Et pour d'autres sites (hébergés chez OVH) :

Uh-oh, something went wrong: write tcp ***********:****: broken pipe

Cela signifie que le diagnostic est impossible ou que la faille existe pour eux à votre avis?

Exemple aussi du site de pari en ligne : https://www.betclic.fr

Je ne sais trop que penser de ce site de test.

Concernant betclic, il est fort probable que ce soit un site servi par IIS, on y voit un cookie ASP.NET_SessionId
et si tu lis ici :
http://blogs.iis.net/erez/archive/20...d-and-iis.aspx
IIS ne serait pas affecté

Moi-même utilisant IIS7.5 sur 3 serveurs, j'ai testé toutes mes URLs servies en https parce que j'utilise différents certificats. La plupart ont répondu avec un "broken pipe " mais sur l'un d'eux ce testeur m'a remonté une lecture mémoire, uen seule fois, puis ensuite "broken pipe ". Donc ce site de test n'est peut-être pas totalement fiable, et il n'a rien d'officiel.

extrait de la FAQ du site en question :
broken pipe is also caused by the unaffected IIS server

Avatar de pmithrandir pmithrandir
http://www.developpez.com
Expert Confirmé
le 10/04/2014 11:04
Pour moi c'est pourtant simple.

Tu testes :
- si c'est infecté, tu ne t'y connecte surtout pas
- sinon, tu change ton mot de passe par précaution(vu qu'ils sont clean ou ont résolu le problème)
Avatar de DotNetMatt DotNetMatt
http://www.developpez.com
Modérateur
le 10/04/2014 11:17
Concernant les mots de passe, si le site est vulnérable a un instant T, un attaquant a potentiellement pu les récupérer. Si le mot de passe est changé à un instant T+1 et que le site est toujours vulnérable, cela ne sert à rien puisque l'attaquant a également pu le récupérer...

Il faut donc attendre que le patch 1.0.1g ait été installé ET que le site ait modifié son certificat avant de modifier son mot de passe en toute sécurité. En effet, si l'attaquant a pu récupérer les clefs de cryptage, le certificat ne sert plus à grand chose, même s'il a installé le patch...

Les grandes entreprises ont pour la plupart pris des mesures rapidement. Après comme il n'y a pas beaucoup de communication sur le sujet, il n'est pas évident de savoir si seul le patch a été installé, et si le certificat a été remplacé ou non...

En tout cas ça remet sérieusement en question le mythe du tout-sécurisé grâce à la transparence de l'open-source que tout le monde peut tester et mettre à jour... Ce bug a été découvert, mais combien sont actuellement présents et ne sont pas encore connus ?
Avatar de sneb5757 sneb5757
http://www.developpez.com
Membre actif
le 10/04/2014 11:58
Citation Envoyé par DotNetMatt  Voir le message
Concernant les mots de passe, si le site est vulnérable a un instant T, un attaquant a potentiellement pu les récupérer. Si le mot de passe est changé à un instant T+1 et que le site est toujours vulnérable, cela ne sert à rien puisque l'attaquant a également pu le récupérer...

Il faut donc attendre que le patch 1.0.1g ait été installé ET que le site ait modifié son certificat avant de modifier son mot de passe en toute sécurité. En effet, si l'attaquant a pu récupérer les clefs de cryptage, le certificat ne sert plus à grand chose, même s'il a installé le patch...

Les grandes entreprises ont pour la plupart pris des mesures rapidement. Après comme il n'y a pas beaucoup de communication sur le sujet, il n'est pas évident de savoir si seul le patch a été installé, et si le certificat a été remplacé ou non...

En tout cas ça remet sérieusement en question le mythe du tout-sécurisé grâce à la transparence de l'open-source que tout le monde peut tester et mettre à jour... Ce bug a été découvert, mais combien sont actuellement présents et ne sont pas encore connus ?



Les jours à venir seront intéressant pour juger la gestion de crise de différentes entreprises. Car le problème est bien là. Comment savoir si une entreprise affecté a bien mis à jour sa bibliothèque ? Il y'a certe des moyens de tester (comme le souligne pmithrandir) mais l'utilisateur néophyte n'aura pas franchement le réflexe. Et a mon avis il n'a pas l'avoir. Il me semble qu'une directive européenne est en cours de préparation pour obliger les entreprises à communiquer sur les incidents de sécurité. Il me semble que cet incident souligne bien l'intérêt d'une telle directive.

Les jours à venir seront assez intéressants pour voir si des entreprises affectées communiquent ou non. Ma banque par exemple a été affectée mais n'a pas communiqué. Je l'ai appris par la presse.

Cocnernant l'open source c'est peut être parce que le code était ouvert que la faille a pu être découverte non ? Ce que cette histoire nous apprend c'est qu'il y'a un vrai travail à faire sur la qualité du code et sur les tests de ce genre de bibliothèque. Et ce n'est pas du tout un problème propre à l'open source.

Citation Envoyé par pmithrandir  Voir le message
Si tu veux savoir, tu peux tester ta banque avec ce lien.
http://filippo.io/Heartbleed/

A priori la mienne est pas impactée.

En plus, si l'annonce a été faite hier matin dans les médias, l'update de open ssl était disponible 2 heures avant sur mon ordi. (distrib mageia) On peut donc espérer que les banques auront su réagir vite.

Oui mais le soucis est de tester toutes les interfaces pour conclure que c'est clean. Pour le credit mutuel j'ai testé le web banking et il était clean. Par contre, le serveur de paiement qui est sur une adresse différente ne l'était pas. Comme je disais ce n'est pas à nous en tant que client d’effectuer des tests. D'ailleurs une majorité de clients ne le feront pas d'eux même. Ils n'ont d'ailleurs pas à le faire c'est aux entreprises de communiquer.

Et puis je vais faire mon paranoïaque de base. Mais ce genre de site de test n'est pas forcément clean. Dans le cas présent il a l'air clean mais qu'est qui prouve qu'il n'est pas utilisé pour faire une liste des sites infectés et la publier ? En tout cas dans l'entreprise où je travaille, j'ai demandé à ce que les tests sur nos serveurs HTTPS concernant la faille ne soit réalisé à partir de tel site mais seulement à partir de site dont nous avions vérifié le code au préalable.
Avatar de GTSLASH GTSLASH
http://www.developpez.com
Inactif
le 10/04/2014 12:18
Donc si j'ai bien compris si je me connecte sur un site avec cette faille tous passera en clair ? Mot de passe, N° Carte de credit,...

C'est beau l'Open Source.

Je suis d'accord que la communautés peut être réactif et corriger rapidement ce genre de bug. Encore faut il que ca soit corrige plus rapidement qu'une firme tel que Microsoft, Google ou autre (permeter moi de douter mais bon soit)

Mais vous ne m'empecherez pas d'etre certain qu'il est plus facile de trouver une faille dans un logiciel dont on a le code source.

Si je me trompe une correction est vraiment la bien venue.
Avatar de Jimmy_ Jimmy_
http://www.developpez.com
Membre émérite
le 10/04/2014 12:42
Il faut relativiser , l'attaquant ne contrôle pas la zone mémoire qu'il va récupérer,
même s'il peut tenter l'attaque autant de fois qu'il veux, le résultat est aléatoire.
Offres d'emploi IT
Développeur Applications mobiles (H/F)
CDI
Aramis - Ile de France - Arcueil (94110)
Parue le 26/09/2014
Développeur php5 symfony2
CDI
COEMY GROUP - Ile de France - Paris (75000)
Parue le 10/10/2014
Développeur web zend
Alternance
IP-FORMATION - Rhône Alpes - Lyon (69000)
Parue le 03/10/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula