OpenSSL : la faille Heartbleed menace la sécurité du web, des sites ferment

OpenSSL : la faille Heartbleed menace la sécurité du web, des sites ferment

Tiens, aurait-on découvert une backdoor de la NSA ?

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

08/04/2014 5 minutes
135

OpenSSL : la faille Heartbleed menace la sécurité du web, des sites ferment

La découverte d'une faille sur OpenSSL sème un vent de panique sur le web, il faut dire que les conséquences peuvent être catastrophiques puisque vos identifiants et mots de passe peuvent être compromis, ainsi que vos échanges chiffrés. Certains se sont déjà mis à jour, tandis que d'autres ont carrément décidé de fermer leur site en attendant.

Heartbleed

Heartbeats, l'extension OpenSSL qui affole le web

OpenSSL est une bibliothèque open source permettant d'implémenter un protocole de chiffrement SSL/TLS sur des sites web, entre autres choses. Largement utilisée sur de nombreux serveurs à travers le monde, une faille portant le nom d'Heartbleed vient d'être découverte dans une de ses extensions : Heartbeats. Cela concerne toutes les versions de la 1.0.1 à 1.0.1f, ainsi que la 1.0.2 bêta. Les moutures précédentes de la branche 1.0.0 et 0.9.8 ne sont pas concernées.

Un site web a été mis en place afin d'expliquer les causes et conséquences potentielles de cette faille, et elles sont loin d'être anodines. En effet, ce « bug » permet à n'importe qui d'accéder à des informations stockées dans la mémoire d'un serveur, celles-ci pouvant être confidentielles : « cela compromet la clé de sécurité utilisée pour s'identifier et sécuriser le trafic, les logins et les mots de passe des utilisateurs, ainsi que le contenu. Cela permet aux pirates d'écouter des communications, de voler des données directement sur des serveurs web et chez les utilisateurs, tout en se faisant passer pour quelqu'un d'autres ».

Une faille vieille de deux ans, corrigée hier. De nombreuses distributions touchées

Mais le plus inquiétant reste à venir : cette faille existerait en fait depuis décembre 2011, mais c'est avec la mise en ligne d'OpenSSL 1.0.1 que les choses se sont aggravées. C'était en mars 2012, soit il y a plus de deux ans maintenant. La faille n'a finalement été découverte que très récemment par Neel Mehta de Google Security et, c'est seulement hier qu'un correctif a été publié (OpenSSL 1.0.1g), alors qu'une nouvelle bêta pour la 1.0.2 arrivera prochainement.

Problème : il faut que les serveurs se mettent à jour et soient réinitialisés, ce qui peut prendre du temps, car c'est généralement une procédure longue et qui ne se fait pas de manière régulière. Néanmoins, le bruit médiatique généré par cette affaire devrait grandement aider à accélérer les choses. Le site Hearbleed dresse une liste, non exhaustive des distributions touchées : 

  • Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
  • Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
  • CentOS 6.5, OpenSSL 1.0.1e-15
  • Fedora 18, OpenSSL 1.0.1e-4
  • OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
  • FreeBSD 8.4 (OpenSSL 1.0.1e) and 9.1 (OpenSSL 1.0.1c)
  • NetBSD 5.0.2 (OpenSSL 1.0.1e)
  • OpenSUSE 12.2 (OpenSSL 1.0.1c)

Notez que, sur son site internet, OpenSSL donne une astuce à ceux qui ne pourraient pas se mettre à jour immédiatement. Il n'y par contre pas de solution magique puisqu'il faut recompiler OpenSSL en ajoutant l'option suivante : 

-DOPENSSL_NO_HEARTBEATS

Les clés privées de chiffrement dans la nature, le cas des certificats des serveurs

Les données personnelles des utilisateurs ne sont pas les seuls éléments qu'il est possible de récupérer via cette faille, cela concerne également les clés privées ainsi que les clés secondaires des certificats. Mettre à jour OpenSSL n'est donc pas suffisant pour les serveurs et il faut également générer de nouveaux certificats au passage.

Mais, malgré cela, le mal pourrait déjà être fait. En effet, on peut parfaitement imaginer que certaines entités des renseignements (la NSA par exemple) enregistrent quantité d'informations sans forcément les avoir déchiffrées pour des questions de ressources, mais la récupération des clés privées pourrait grandement faciliter cette tâche a posteriori.

Minecraft ferme son site. Comment savoir si un serveur est touché ?

Afin de savoir si un site est touché par cette faille de sécurité, un mini site dédié a été mis en place. Il suffit d'entrer une URL pour savoir ce qu'il en est, attention toutefois puisqu'il existe des cas de faux positifs. Notez qu'un dépôt GitHub est également disponible, le projet étant open source.

Heartbleed OpenSSL

De son côté, Markus Persson joue la carte de la sécurité et a décidé de fermer temporairement le site de Minecraft. Il sera probablement de retour après une mise à jour, ce qui n'est pas le cas à l'heure où nous écrivons ces lignes. Nathan Adams, développeur chez Mojang, ne donne aucun délai et précise simplement que la balle est dans le camp d'Amazon dont ils utilisent les serveurs. D'autres comme Gandi ou CloudFlare ont déjà pris les devants et ont mis à jour leur infrastructure.

Redoubler de prudence et vérifier les mises à jour des sites

Il s'agit donc d'un problème d'une envergure très importante et qui touche de nombreux sites, il est donc recommandé de redoubler voire tripler de prudence puisque vos identifiants et vos mots de passes sont en jeu. Cette faille peut toucher les webmails ainsi que les réseaux sociaux, mais également les banques, les systèmes de paiement et les sites officiels. Si, comme certains, vous utilisez les mêmes identifiants pour plusieurs sites, alors les conséquences pourraient être encore plus catastrophiques. En effet, un pirate récupérant vos données personnelles pourrait s'en servir sur d'autres sites.

Tant que la situation n'est pas éclaircie, nous vous recommandons donc de ne pas vous rendre sur ces sites pour le moment et d'éviter les achats en ligne. Il faudra voir quelles seront les procédures mises en place par les services qui ont été touchés, tant pour alerter leurs utilisateurs que pour gérer les conséquences de cette faille. Nous tenterons de faire rapidement le point sur le sujet. 

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Heartbeats, l'extension OpenSSL qui affole le web

Une faille vieille de deux ans, corrigée hier. De nombreuses distributions touchées

Les clés privées de chiffrement dans la nature, le cas des certificats des serveurs

Minecraft ferme son site. Comment savoir si un serveur est touché ?

Redoubler de prudence et vérifier les mises à jour des sites

Commentaires (135)


Ayé, mes distros Linuxmint se sont mises à jour. De toute façon, je n’ai pas de serveur WEB public.


Debian propose la mise à jour depuis hier. <img data-src=" />

A jour pour moi depuis ce matin. :)


Oh non, et moi qui doit renouveler mon abo à PCI, si le web n’est plus sécurisé comment je fais ?<img data-src=" />



<img data-src=" />


À jour aussi, et nouvelles clés générées :

openssl req -x509 -newkey rsa:2048 -keyout /etc/ssl/private/\(keyfile -out /etc/ssl/certs/\)certfile -nodes -days 3650


Malheureusement, il y a eu certes un vent de panique sur le Net et pour autant, je n’ai pas encore vu une seule personne prouvant qu’il avait réussi à récupérer des informations sur un site impacté.

De ce que j’ai lu, pour pouvoir utiliser cet exploit, il faudrait qu’un hacker mettent en place un honeypot en SSL et que des utilisateurs se connectent sur ce honeypot. Les utilisateurs qui naviguent grâce à Firefox ou Chrome ne seraient pas impactés car Firefox désactive le HeartBeat en question & Chrome n’utilise pas OpenSSL (sauf pour sa version Android).

Enfin, certes le hacker pourrait récupérer jusqu’à 64Ko de données par “session”, mais on ne sait pas quelles sont ces données : est-ce que c’est 64Ko aléatoire? toujours les mêmes?



C’est très bien qu’il y ai eu une diffusion de l’information importante, mais pour autant, je trouve que le site HeartBleed.com n’est pas très avare sur “Quels sont les vrais risques?”.



(Ah et aussi les mecs de chez CloudFlare ont dit qu’ils n’allaient changer les certificats que si ils arrivent à récupérer ces informations en utilisant l’exploit)…


https://www.startpage.com m’envoie bouler. (sous Firefox)<img data-src=" />


Aucune analyse dans cet article de l’impact, ô combien important, du leak des clés privées et donc de la compromission des certificats … <img data-src=" />








Avygeil a écrit :



Oh non, et moi qui doit renouveler mon abo à PCI, si le web n’est plus sécurisé comment je fais ?<img data-src=" />



<img data-src=" />





http://filippo.io/Heartbleed/#www.cmcicpaiement.fr



;)



[Mode Yzokras]

Pfff PCI qui fait encore son pro-MS[/Mode Yzokras] <img data-src=" />








Zergy a écrit :



Debian propose la mise à jour depuis hier. <img data-src=" />

A jour pour moi depuis ce matin. :)





<img data-src=" /> J’ai mis ma Jessie à jour aussi ce matin.









lol.2.dol a écrit :



Malheureusement, il y a eu certes un vent de panique sur le Net et pour autant, je n’ai pas encore vu une seule personne prouvant qu’il avait réussi à récupérer des informations sur un site impacté.

De ce que j’ai lu, pour pouvoir utiliser cet exploit, il faudrait qu’un hacker mettent en place un honeypot en SSL et que des utilisateurs se connectent sur ce honeypot. Les utilisateurs qui naviguent grâce à Firefox ou Chrome ne seraient pas impactés car Firefox désactive le HeartBeat en question & Chrome n’utilise pas OpenSSL (sauf pour sa version Android).

Enfin, certes le hacker pourrait récupérer jusqu’à 64Ko de données par “session”, mais on ne sait pas quelles sont ces données : est-ce que c’est 64Ko aléatoire? toujours les mêmes?



C’est très bien qu’il y ai eu une diffusion de l’information importante, mais pour autant, je trouve que le site HeartBleed.com n’est pas très avare sur “Quels sont les vrais risques?”.



(Ah et aussi les mecs de chez CloudFlare ont dit qu’ils n’allaient changer les certificats que si ils arrivent à récupérer ces informations en utilisant l’exploit)…







http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html





Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.









Zergy a écrit :



Debian propose la mise à jour depuis hier. <img data-src=" />

A jour pour moi depuis ce matin. :)





Moi j’ai fait une mise à jour d’openssl hier soir tard (après minuit) sur Debian Wheezy, et aujourd’hui quand j’ai fait le test, j’étais encore vulnérable. Je pense qu’il y a eu une nouvelle mise à jour dans la journée, qui cette fois corrige le problème… Ou alors j’ai raté qqch.



Bon, ben go recompile …

Merci pour l’info !








®om a écrit :



http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html





Justement “It allows an attacker to read up to 64KB of memory, and the security researchers have said:”. Il démontre que théoriquement ça fonctionne, après il avoue lui même qu’il aimerait bien voir un PoC.

Même si il a mis à jour son article depuis :



This section originally contained my skepticism about the PoC due to the nature of how the heap works via sbrk. However, many readers reminded me that mmap could be used by malloc instead, which changes everything.



Il n’en reste pas moins que le PoC est pour l’instant, à ma connaissance, introuvable.



J’ai mis a jours mon serveur sous CentOS, ce qui a corrige le probleme.

Maintenant il faut que je régénère mes certifs SSL.








lol.2.dol a écrit :



Malheureusement, il y a eu certes un vent de panique sur le Net et pour autant, je n’ai pas encore vu une seule personne prouvant qu’il avait réussi à récupérer des informations sur un site impacté.

De ce que j’ai lu, pour pouvoir utiliser cet exploit, il faudrait qu’un hacker mettent en place un honeypot en SSL et que des utilisateurs se connectent sur ce honeypot. Les utilisateurs qui naviguent grâce à Firefox ou Chrome ne seraient pas impactés car Firefox désactive le HeartBeat en question & Chrome n’utilise pas OpenSSL (sauf pour sa version Android).

Enfin, certes le hacker pourrait récupérer jusqu’à 64Ko de données par “session”, mais on ne sait pas quelles sont ces données : est-ce que c’est 64Ko aléatoire? toujours les mêmes?



C’est très bien qu’il y ai eu une diffusion de l’information importante, mais pour autant, je trouve que le site HeartBleed.com n’est pas très avare sur “Quels sont les vrais risques?”.







Tu n’as pas tout compris : une connexion sur un serveur SSL impacté et tu récupère de la mémoire du processus. C’est très facile de récupérer des cookies de session, des morceaux de mail, des num de carte de crédit, des messages privés de forum, etc. Par contre on ne contrôle rien, il faut tester “en boucle”.



De là à récupérer la clé privée SSL j’y crois moyen (mais pourquoi pas), mais avoir des identifiants sur des webapps ça c’est pas compliqué.









®om a écrit :



Moi j’ai fait une mise à jour d’openssl hier soir tard (après minuit) sur Debian Wheezy, et aujourd’hui quand j’ai fait le test, j’étais encore vulnérable. Je pense qu’il y a eu une nouvelle mise à jour dans la journée, qui cette fois corrige le problème… Ou alors j’ai raté qqch.







il faut bien relancer les services concernés. Par exemple, pour nginx, un simple service nginx restart ne suffit pas, il faut stop/start afin qu’il utilise la nouvelle bibliothèque.



Le site qui gère les horaires, étudiants, notes, prof, salle etc.. de toute la suisse occidentale est vulnérable.



Un hacker de dispo pour changer mes notes ? <img data-src=" />








lol.2.dol a écrit :



Il n’en reste pas moins que le PoC est pour l’instant, à ma connaissance, introuvable.







http://s3.jspenguin.org/ssltest.py










®om a écrit :



Moi j’ai fait une mise à jour d’openssl hier soir tard (après minuit) sur Debian Wheezy, et aujourd’hui quand j’ai fait le test, j’étais encore vulnérable. Je pense qu’il y a eu une nouvelle mise à jour dans la journée, qui cette fois corrige le problème… Ou alors j’ai raté qqch.





MàJ faite à 8h30-8h40 chez moi, il y a peut-être eux une seconde mise à jour dans la nuit.

Ah, oui, il faut redémarrer les services utilisant SSL (Apache, SSH, ect…)









neves a écrit :



Tu n’as pas tout compris : une connexion sur un serveur SSL impacté et tu récupère de la mémoire du processus. C’est très facile de récupérer des cookies de session, des morceaux de mail, des num de carte de crédit, des messages privés de forum, etc. Par contre on ne contrôle rien, il faut tester “en boucle”.



De là à récupérer la clé privée SSL j’y crois moyen (mais pourquoi pas), mais avoir des identifiants sur des webapps ça c’est pas compliqué.





On est d’accord pour la clé privée SSL (pourtant c’est ce qui excite l’Internet aujourd’hui…).

Pour le reste, ce que j’aimerai savoir c’est savoir si la fenêtre des 64Ko est mouvante ou pas? De ce que j’ai compris c’est totalement aléatoire…

Enfin, de ce que j’ai lu les navigateurs Firefox, Chrome n’ont pas l’air d’être touché. Ce qui voudrait dire que l’impact n’est pas aussi important que l’on pense. Ca n’en reste pas moins un problème grave et à traiter rapidement, mais faut-il vraiment se mettre à régénérer tout les certificats et resetter tout les mots de passe?









lol.2.dol a écrit :



On est d’accord pour la clé privée SSL (pourtant c’est ce qui excite l’Internet aujourd’hui…).

Pour le reste, ce que j’aimerai savoir c’est savoir si la fenêtre des 64Ko est mouvante ou pas? De ce que j’ai compris c’est totalement aléatoire…







Oui c’est “mouvant”. Et non contrôlable “à priori”.







lol.2.dol a écrit :



Enfin, de ce que j’ai lu les navigateurs Firefox, Chrome n’ont pas l’air d’être touché. Ce qui voudrait dire que l’impact n’est pas aussi important que l’on pense. Ca n’en reste pas moins un problème grave et à traiter rapidement, mais faut-il vraiment se mettre à régénérer tout les certificats et resetter tout les mots de passe?







C’est un problème côté serveur, et c’est quand même un gros carnage : le webmail de yahoo est vulnérable actuellement, toutes les personnes qui s’y authentifient donnent leur mot de passe en clair aux personnes qui jouent avec le bug en ce moment.










KIllersg a écrit :



Le site qui gère les horaires, étudiants, notes, prof, salle etc.. de toute la suisse occidentale est vulnérable.



Un hacker de dispo pour changer mes notes ? <img data-src=" />







http://www.exploit-db.com/exploits/32745/ :3 <img data-src=" />









lol.2.dol a écrit :



Enfin, de ce que j’ai lu les navigateurs Firefox, Chrome n’ont pas l’air d’être touché.





C’est un problème côté serveur (un client mal intentionné pourrait récupérer des données), pas côté client.









KIllersg a écrit :



Le site qui gère les horaires, étudiants, notes, prof, salle etc.. de toute la suisse occidentale est vulnérable.



Un hacker de dispo pour changer mes notes ? <img data-src=" />







Bah j’ai hack le webmail de mon école y’a 10 min <img data-src=" />



J’ai mail l’admin pour lui dire de patcher, il m’a répondu : “J’y travaille”









Zergy a écrit :



MàJ faite à 8h30-8h40 chez moi, il y a peut-être eux une seconde mise à jour dans la nuit.

Ah, oui, il faut redémarrer les services utilisant SSL (Apache, SSH, ect…)





Oui, il me semble que je l’avais fait… Mais pas sûr à 100%.

En tout cas sur la mise à jour d’aujourd’hui, une dialog demande de redémarrer les services.









Glyphe a écrit :



Aucune analyse dans cet article de l’impact, ô combien important, du leak des clés privées et donc de la compromission des certificats … <img data-src=" />







Une partie a été ajoutée concernant les clés justement <img data-src=" />









neves a écrit :



http://s3.jspenguin.org/ssltest.py





Oui, j’ai vu ça. Pourtant, j’ai pas encore réussi à récupérer des données claires et utiles.







neves a écrit :



Oui c’est “mouvant”. Et non contrôlable “à priori”.





OK, c’est bien ce que je pensais. Mais c’est mouvant sur combien de données quel type de paquet?)





J’ai peut être l’air sceptique mais j’aimerai juste qu’un type balance un “Bam! Voilà ce que j’ai fait, et voilà ce qu’ai récupéré en utilisant cet exploit”. <img data-src=" />









lol.2.dol a écrit :



Oui, j’ai vu ça. Pourtant, j’ai pas encore réussi à récupérer des données claires et utiles.





OK, c’est bien ce que je pensais. Mais c’est mouvant sur combien de données quel type de paquet?)





J’ai peut être l’air sceptique mais j’aimerai juste qu’un type balance un “Bam! Voilà ce que j’ai fait, et voilà ce qu’ai récupéré en utilisant cet exploit”. <img data-src=" />





C’est pas si mouvant que ça, sinon comment le site de vérif pourrait-il récupérer son propre paquet ?



Ce que j’arrive pas a comprendre c’est si cette faille est exploitable uniquement lors de l’utilisation par un visiteur du fameux OpenSSL, ou si, cette faille est exploitable a partir du moment ou cette extension est installé sur le serveur même si cette dernière n’est pas réellement exploité








lol.2.dol a écrit :



J’ai peut être l’air sceptique mais j’aimerai juste qu’un type balance un “Bam! Voilà ce que j’ai fait, et voilà ce qu’ai récupéré en utilisant cet exploit”. <img data-src=" />







Test toi même, tout le monde en parle de l’exemple avec yahoo.

python ssltest.py mail.yahoo.com et cherche login et passwd.









neves a écrit :



C’est un problème côté serveur, et c’est quand même un gros carnage : le webmail de yahoo est vulnérable actuellement, toutes les personnes qui s’y authentifient donnent leur mot de passe en clair aux personnes qui jouent avec le bug en ce moment.





Ça peut devenir un problème côté client si le serveur est malicieux.



Mais c’est utile uniquement en cas de cible particulière. Mais ça pourrait permettre de compromettre les autres services utilisant openSSH d’une cible se connectant à un serveur web.









®om a écrit :



C’est un problème côté serveur (un client mal intentionné pourrait récupérer des données), pas côté client.





Si j’ai bien suivi c’est pour tout ce qui utilise la version bugguée d’OpenSSL. Un client allant sur un serveur malicieux pourra éventuellement fournir des données privées, c’est bien plus limité mais ce n’est pas tout à fait inexistant.









kontas a écrit :



Ce que j’arrive pas a comprendre c’est si cette faille est exploitable uniquement lors de l’utilisation par un visiteur du fameux OpenSSL, ou si, cette faille est exploitable a partir du moment ou cette extension est installé sur le serveur même si cette dernière n’est pas réellement exploité





Il faut que ça soit utilisé.



La faille utilise un bug dans le heartbeat TLS. Il faut donc que celui-ci soit utilisé pour pouvoir utiliser la faille. De plus la faille ne permet de récupérer que des infos manipulées par openSSL. Il faut donc que l’utilisateur utilise le heartbeat TLS pour être en danger.









lol.2.dol a écrit :



Oui, j’ai vu ça. Pourtant, j’ai pas encore réussi à récupérer des données claires et utiles.





OK, c’est bien ce que je pensais. Mais c’est mouvant sur combien de données quel type de paquet?)





J’ai peut être l’air sceptique mais j’aimerai juste qu’un type balance un “Bam! Voilà ce que j’ai fait, et voilà ce qu’ai récupéré en utilisant cet exploit”. <img data-src=" />





http://heartbleed.com/



We have tested some of our own services from attacker’s perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.









neves a écrit :



Test toi même, tout le monde en parle de l’exemple avec yahoo.

python ssltest.py mail.yahoo.com et cherche login et passwd.





OK. Je vais y jeter un oeil (pas sur Yahoo parce que ça se fait pas).









lol.2.dol a écrit :



OK. Je vais y jeter un oeil (pas sur Yahoo parce que ça se fait pas).





+1. Fait le sur NI :Plangue:









TaigaIV a écrit :



http://heartbleed.com/





Oui, oui! C’est ce que tout le monde a recopié partout sur le Net sans pour autant en apporter la preuve. Je suis sceptique surtout quand je vois un affolement public! <img data-src=" />









lol.2.dol a écrit :



Oui, oui! C’est ce que tout le monde a recopié partout sur le Net sans pour autant en apporter la preuve. Je suis sceptique surtout quand je vois un affolement public! <img data-src=" />





Peut-être que tu peux regarder le patch et te faire une idée des conséquences :



http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902



Si tu as des doutes rien ne t’oblige à mettre à jour et à faire quoique ce soit <img data-src=" />









Khalev a écrit :



+1. Fait le sur NI :Plangue:





NI n’est pas vulnérable : il utilise Cloudflare.









fred42 a écrit :



NI n’est pas plus vulnérable : il utilise Cloudflare.





<img data-src=" />









hellmut a écrit :



<img data-src=" />





Oui, bonne correction.



Mais je voulais surtout dire que ce n’était pas possible de tester sur NI au moment où le “conseil” avait été donné.









fred42 a écrit :



Oui, bonne correction.



Mais je voulais surtout dire que ce n’était pas possible de tester sur NI au moment où le “conseil” avait été donné.





oui effectivement, ça a été corrigé avant l’article à priori.



ça fait bizarre de dire NI, j’ai l’impression qu’on parle de Nil à chaque fois. ^^



Et hop, un patch de plus pour Synology…



Je viens de tester sur ma Syno avec DSM 4.2, la vulnérabilité est présente. Heureusement il n’est ouvert qu’à des IP bien déterminées et n’est pas public !



Sinon, pour quelques banques en ligne, pas de problème :



\( bin/Heartbleed www.secure.bnpparibas.net:443

2014/04/08 18:14:36 www.secure.bnpparibas.net:443 - SAFE



\)
bin/Heartbleed secure.ingdirect.fr:443

2014/04/08 18:15:02 secure.ingdirect.fr:443 - SAFE



\( bin/Heartbleed www.cortalconsors.fr:443

2014/04/08 18:15:28 www.cortalconsors.fr:443 - SAFE



\)
bin/Heartbleed www.bforbank.com:443

2014/04/08 18:15:51 www.bforbank.com:443 - SAFE



\( bin/Heartbleed www.monabanq.com:443

2014/04/08 18:16:27 www.monabanq.com:443 - SAFE



\)
bin/Heartbleed www.fortuneo.fr:443

2014/04/08 18:16:44 www.fortuneo.fr:443 - SAFE


D’après le test fourni dans l’article :



fr.yahoo.com IS VULNERABLE.

http://en.zimagez.com/zimage/fryahoocomisvulnerable20140408.php








neves a écrit :



Test toi même, tout le monde en parle de l’exemple avec yahoo.

python ssltest.py mail.yahoo.com et cherche login et passwd.







Anéfé…

:eeek:









TaigaIV a écrit :



Si j’ai bien suivi c’est pour tout ce qui utilise la version bugguée d’OpenSSL. Un client allant sur un serveur malicieux pourra éventuellement fournir des données privées, c’est bien plus limité mais ce n’est pas tout à fait inexistant.





Effectivement, je n’avais pas pensé à ça.



Sinon je trouve hallucinant qu’un site comme [url=]yahoo.com[/url] soit toujours vulnérable…









®om a écrit :



Effectivement, je n’avais pas pensé à ça.



Sinon je trouve hallucinant qu’un site comme [url=]yahoo.com[/url] soit toujours vulnérable…







Je confirme :

$ bin/Heartbleed yahoo.com:443

2014/04/08 18:41:58 ([]uint8) {

00000000 02 00 79 68 65 61 72 74 62 6c 65 65 64 2e 66 69 |..yheartbleed.fi|

00000010 6c 69 70 70 6f 2e 69 6f 59 45 4c 4c 4f 57 20 53 |lippo.ioYELLOW S|

00000020 55 42 4d 41 52 49 4e 45 a6 97 2a 7f e4 e2 9b 36 |UBMARINE..*….6|

00000030 1f b7 08 96 1a 0e 9e 7c 30 d7 6c 38 6f f5 2e 00 |…….|0.l8o…|

00000040 05 00 05 01 00 00 00 00 00 0a 00 08 00 06 00 17 |…………….|

00000050 00 18 00 19 00 0b 00 02 01 00 00 0d 00 0a 00 08 |…………….|

00000060 04 01 04 03 02 01 02 03 ff 01 00 01 00 00 04 01 |…………….|

00000070 00 00 54 00 00 00 12 00 10 00 00 0d 48 69 68 23 |..T………Hih#|

00000080 2e 43 1e 0c b2 a3 4b d9 66 13 ee 84 |.C….K.f…|

}



2014/04/08 18:41:58 yahoo.com:443 - VULNERABLE



@Bylon, oui, ou : python ssltest.py mail.yahoo.com



où tu trouves quasiment à chaque exécution au moins un login avec un password d’un utilisateur yahoo…








kaito_kid a écrit :



http://www.exploit-db.com/exploits/32745/ :3 <img data-src=" />





Merci <img data-src=" />







oXis a écrit :



Bah j’ai hack le webmail de mon école y’a 10 min <img data-src=" />



J’ai mail l’admin pour lui dire de patcher, il m’a répondu : “J’y travaille”







J’ai aussi envoyé un mail pour prévenir mais pas de réponse, après 16h il doit déjà prendre l’apéro <img data-src=" />








ca prouve bien que si on n’a pas Windows,on est pas securisé.








neves a écrit :



Test toi même, tout le monde en parle de l’exemple avec yahoo.

python ssltest.py mail.yahoo.com et cherche login et passwd.





OK.

Bon bah j’ai ma preuve <img data-src=" />



Au final, c’est pas vraiment les clés privés qui sont les plus en danger mais plutôt les bases de password…



Merci de l’aide, ça m’éclaire et du coup, je suis bien moins sceptique!



Le petit cœur de la NSA doit saigner en ce moment, son bébé est mouru. <img data-src=" />


Put* de Yahoo, sont pas doués…



Je suis sûr qu’une (ou plusieurs) ferme de bots est en train de tout aspirer :/








Oungawak a écrit :



Le petit cœur de la NSA doit saigner en ce moment, son bébé est mouru. <img data-src=" />





On dirait que les révélations de Snowden ont motivé certains audits de code récemment… C’est une très bonne chose (même si la NSA a très probablement encore de l’avance sur les vulnérabilités SSL).









lol.2.dol a écrit :



Malheureusement, il y a eu certes un vent de panique sur le Net et pour autant, je n’ai pas encore vu une seule personne prouvant qu’il avait réussi à récupérer des informations sur un site impacté.

De ce que j’ai lu, pour pouvoir utiliser cet exploit, il faudrait qu’un hacker mettent en place un honeypot en SSL et que des utilisateurs se connectent sur ce honeypot. Les utilisateurs qui naviguent grâce à Firefox ou Chrome ne seraient pas impactés car Firefox désactive le HeartBeat en question & Chrome n’utilise pas OpenSSL (sauf pour sa version Android).

Enfin, certes le hacker pourrait récupérer jusqu’à 64Ko de données par “session”, mais on ne sait pas quelles sont ces données : est-ce que c’est 64Ko aléatoire? toujours les mêmes?



C’est très bien qu’il y ai eu une diffusion de l’information importante, mais pour autant, je trouve que le site HeartBleed.com n’est pas très avare sur “Quels sont les vrais risques?”.



(Ah et aussi les mecs de chez CloudFlare ont dit qu’ils n’allaient changer les certificats que si ils arrivent à récupérer ces informations en utilisant l’exploit)…





Par cette faille n’importe-qui (donc pas besoin de honeypot) qui se connecte au serveur en SSL peut récupérer 64Ko d’une partie aléatoire de la mémoire du serveur. Il ne s’attaque donc pas directement à un flux entre un client et le serveur pour le déchiffrer comme c’est souvent le cas pour les failles SSL.



Pour moi qui opère un serveur avec 32go de ram je vous laisse imaginer la difficulté de récupérer quoi que se soit d’utilisable <img data-src=" /> Surtout que la faille est limitée par la politique anti-DDoS qui ralenti l’attaquant.



Malgré tout j’ai MàJ les serveurs, changé les clefs privé, comparé l’intégrité des système par rapport aux archives, supprimé toutes les sessions actives et lancé une demande de changement de mots de passe à tous mes utilisateurs (l’actuel continu de marcher pour tout ce qui est IMAP, ActiveSync… Mais à la prochaine connexion au service web, ils serons obligés de changer )










GentooUser a écrit :



comparé l’intégrité des système par rapport aux archives







Tu utilises quoi ?



Sur Debian, il y a debsums -c, mais si debsums a été modifié ?









®om a écrit :



On dirait que les révélations de Snowden ont motivé certains audits de code récemment… C’est une très bonne chose (même si la NSA a très probablement encore de l’avance sur les vulnérabilités SSL).





Oui. :)



Et ça me fait penser qu’avec tout le monde qui change ses clés de chiffrement, le porte-feuille de clés volés que s’était constitué la NSA à dû s’étioler un peu.



Content d’avoir mon mail principal en Yahoo.fr <img data-src=" />








®om a écrit :



Moi j’ai fait une mise à jour d’openssl hier soir tard (après minuit) sur Debian Wheezy, et aujourd’hui quand j’ai fait le test, j’étais encore vulnérable. Je pense qu’il y a eu une nouvelle mise à jour dans la journée, qui cette fois corrige le problème… Ou alors j’ai raté qqch.









Je confirme:)









Flogik a écrit :



Content d’avoir mon mail principal en Yahoo.fr <img data-src=" />







C’est juste une honte de la part d’un acteur majeur comme Yahoo …









Flogik a écrit :



Content d’avoir mon mail principal en Yahoo.fr <img data-src=" />





Ça change rien… ça concerne tous les comptes yahoo..



Je viens de passer 1 heure a patcher toutes mes Gentoo, et avant de relancer les services je fais un test de vulnérabilité, et en fait le HeartBeat n’était pas dans les flags de compilation <img data-src=" />



Comme quoi avoir des compilations exotiques ça sert parfois <img data-src=" />








bilbonsacquet a écrit :



Ça change rien… ça concerne tous les comptes yahoo..







Une question par rapport à ça : le leak d’info concernant le username et le MDP provient seulement au moment de la connexion ou même une fois connecté lorsque l’on regarde si l’on a reçu de nouveaux mails par exemple .









®om a écrit :



Tu utilises quoi ?



Sur Debian, il y a debsums -c, mais si debsums a été modifié ?





J’utilise juste md5sum -c (et un second algo pour confirmer le résultat) entre la liste générée lors de la sauvegarde et le fs courant.



Je n’utilise bien-sûr par les binaires d’un hôte exposé, mais ceux le l’hôte sur lequel tourent les VM ou du serveurs NFS qui fournis leur rootfs aux VM exposées ou du serveur de sauvegarde.



Une idée pas mal : générer une nouvelle sauvegarde et la comparer à l’ancienne.



Merci pour cet article, mon serveur était vulnérable, je l’ai mis à jour, maintenant il ne l’est plus <img data-src=" />



PS: serveur Debian 7 Wheezy, la màj est déjà propagée








®om a écrit :



On dirait que les révélations de Snowden ont motivé certains audits de code récemment… C’est une très bonne chose (même si la NSA a très probablement encore de l’avance sur les vulnérabilités SSL).





Snowden avait conseillé de tout crypter en SSL /TLS et qu’avec ça on pouvait être protégé

Cela implique donc que la NSA ne sait pas (toujours?) “pirater” SSL/TLS !

Et d’ailleurs, il avait indiqué qu’ils passaient par d’autres intermédiaires (faille logiciel, OS, etc) pour outrepasser cette contrainte.









Nakqz a écrit :



C’est juste une honte de la part d’un acteur majeur comme Yahoo …





la honte c’est surtout de continuer à accepter des identifications sans aucun message de prévention, ce qui fait que tout le monde continue à se connecter.

je viens de prévenir quelques potes, dont un qui utilise son compte yahoo comme identifiant apple et icloud… je vous laisse imaginer le délire.

avec la synchro automatique de ses mails c’est sur et certain que ses identifiants ont été récupérés.



c’est totalement irresponsable de la part de yahoo.









zempa a écrit :



Snowden avait conseillé de tout crypter en SSL /TLS et qu’avec ça on pouvait être protégé

Cela implique donc que la NSA ne sait pas (toujours?) “pirater” SSL/TLS !





oui enfin non.

ça implique que Snowden n’était pas au courant d’une exploitation de faille SSL/TLS par la NSA.

pas dutout la même chose.



Qu’en est-il de des boites mail de Microsoft ?


C’est la conclusion de l’article içi qui me semble le plus important.



Ces librairies à auditer sont un cauchemar du fait de la permissivité du C. Il devient urgent d’avoir un language safe. Alors oui il existe des solutions mais rien de déployé à grande échelle.








Khalev a écrit :



Il faut que ça soit utilisé.



La faille utilise un bug dans le heartbeat TLS. Il faut donc que celui-ci soit utilisé pour pouvoir utiliser la faille. De plus la faille ne permet de récupérer que des infos manipulées par openSSL. Il faut donc que l’utilisateur utilise le heartbeat TLS pour être en danger.







Merci beaucoup pour tes explications claires ;)



D’après le site de test un de mes serveurs sous Débian serait exposé, mais nous n’utilisons pas de openSSL ni heartBleed, aucune idée de pourquoi ils avaient étaient installé





Une faille vieille de deux ans, corrigée hier







Belle réactivité de la communauté du libre… <img data-src=" />

Et ils veulent vraiment que les gens quittent MS et Apple pour des produits libres, alors qu’il leur faut 2 ans pour corriger une faille ?

Comment leur faire confiance vu qu’ils sont pas foutu de faire leur boulot ?








moi1000 a écrit :



Belle réactivité de la communauté du libre… <img data-src=" />

Et ils veulent vraiment que les gens quittent MS et Apple pour des produits libres, alors qu’il leur faut 2 ans pour corriger une faille ?

Comment leur faire confiance vu qu’ils sont pas foutu de faire leur boulot ?





bien tenté <img data-src=" /> mais bon, trop gros, passera pas









moi1000 a écrit :



Belle réactivité de la communauté du libre… <img data-src=" />

Et ils veulent vraiment que les gens quittent MS et Apple pour des produits libres, alors qu’il leur faut 2 ans pour corriger une faille ?

Comment leur faire confiance vu qu’ils sont pas foutu de faire leur boulot ?









Ha ben voilà, on l’a eu finalement le commentaire neuneu de la soirée ! <img data-src=" />









viruseb a écrit :



C’est la conclusion de l’article içi qui me semble le plus important.



Ces librairies à auditer sont un cauchemar du fait de la permissivité du C. Il devient urgent d’avoir un language safe. Alors oui il existe des solutions mais rien de déployé à grande échelle.







Je vois bien en quoi la permissivité du C est le mega problème ici ?

Dans ce cas on est face à une entrée non vérifiée et du coup à des débordements de tableau.



Moi ce qui m inquiete c est tout les differents logiciels qui integrent open ssl, ca va etre galere de tout mettre a jour.


Je ne suis pas en sépcialiste de ssl. Est ce que les serveurs utilisent tout le temps les même clés ?

Si oui, ils faut donc logiquement supposé que ces clés sont compromises et donc les changer, c’est génant ?








dam1605 a écrit :



Je vois bien en quoi la permissivité du C est le mega problème ici ?

Dans ce cas on est face à une entrée non vérifiée et du coup à des débordements de tableau.



Justement, d’autres langages sont bien plus stricts sur les dépassements de tableaux et empêchent de labourer dans la mémoire.

Du coup, sur ce genre de truc, on risque le déni de service mais potentiellement uniquement sur celui qui a essayé de faire labourer la mémoire. <img data-src=" />



Starbetrayer a écrit :



Moi ce qui m inquiete c est tout les differents logiciels qui integrent open ssl, ca va etre galere de tout mettre a jour.



Quand il y a des gens sérieux, ça se fait rapidement.

Chez nous, les INpacts ont été évalués et les mesures prises immédiatement.

Maintenant, on peut continuer ce qu’on était en train de faire. <img data-src=" />









dam1605 a écrit :



Je vois bien en quoi la permissivité du C est le mega problème ici ?

Dans ce cas on est face à une entrée non vérifiée et du coup à des débordements de tableau.





Parce que cette classe d’erreur si courante n’existe pas avec des langages managés. Il y aurait eu une exception, mais en aucun cas un accès non autorisé à la mémoire.









dam1605 a écrit :



Je ne suis pas en sépcialiste de ssl. Est ce que les serveurs utilisent tout le temps les même clés ?

Si oui, ils faut donc logiquement supposé que ces clés sont compromises et donc les changer, c’est génant ?





Un serveur utilise toujours les mêmes clés,mais il est possible de révoquer une clé si elle a été compromise.

Là, le GROS souci, c’est qu’il faudrait potentiellement révoquer quasiment toutes les clés. Ça risque d’être un gros bordel…









Glyphe a écrit :



Ha ben voilà, on l’a eu finalement le commentaire neuneu de la soirée !





+1 le pire c’est que c’était prévisible que quelqu’un allait la sortir celle-là…









Mihashi a écrit :



Là, le GROS souci, c’est qu’il faudrait potentiellement révoquer quasiment toutes les clés. Ça risque d’être un gros bordel…



Certificate Patrol s’affole déjà. <img data-src=" />









san-claudio a écrit :



D’après le test fourni dans l’article :



fr.yahoo.com IS VULNERABLE.

http://en.zimagez.com/zimage/fryahoocomisvulnerable20140408.php





Tu serais pas sous XP vu le screen … <img data-src=" />

T’es doublement foutu <img data-src=" />









moi1000 a écrit :



Belle réactivité de la communauté du libre… <img data-src=" />

Et ils veulent vraiment que les gens quittent MS et Apple pour des produits libres, alors qu’il leur faut 2 ans pour corriger une faille ?

Comment leur faire confiance vu qu’ils sont pas foutu de faire leur boulot ?







S’il y a eu des mise à jour de sécurité pour Windows XP pendant plus de 10ans, c’est pourquoi à ton avis ?









Starbetrayer a écrit :



Moi ce qui m inquiete c est tout les differents logiciels qui integrent open ssl, ca va etre galere de tout mettre a jour.







Suffit de mettre à jour le paquet de la lib.



Oui si la lib est partagé et non pas intégré dans le logiciel.


Question, les synology sont-ils vulnérables (le mien me dit qu’il l’est)








tyrus a écrit :



Oui si la lib est partagé et non pas intégré dans le logiciel.







+1, je connais un paquet de logiciels sous windows qui ont la lib openssl integree



Elle doit être géniale cette extension, pour qu’autant de monde l’utilise…








Hipparchia a écrit :



Question, les synology sont-ils vulnérables (le mien me dit qu’il l’est)







oui









lol.2.dol a écrit :



(Ah et aussi les mecs de chez CloudFlare ont dit qu’ils n’allaient changer les certificats que si ils arrivent à récupérer ces informations en utilisant l’exploit)…





Sympa mais si un pirate fait la course contre eux ?





Ubuntu 12.04.4 LTS





Je suis en 12.04.1, donc c’est bon ou pas ? <img data-src=" />








neves a écrit :



oui





Donc si je me co depuis l’exterieur sur mon syno mes ID circulent en clair O_o



Je suis pleinement rassuré, je n’ai que des serveurs sous IIS. <img data-src=" />








hellmut a écrit :



oui enfin non.

ça implique que Snowden n’était pas au courant d’une exploitation de faille SSL/TLS par la NSA.

pas dutout la même chose.





J’ai plutôt tendance à lui donner davantage de crédit qu’à des suppositions/interprétations aussi vraisemblables qu’elles puissent paraitre.



Quelqu’un qui a réussi à dérober un nombre important de document “Top secret” ne se risquerait pas à affirmer de telles choses sans avoir un minimum de certitude.

Son travail rappelons-le, consistait précisément à pirater les systèmes, donc…









Hipparchia a écrit :



Donc si je me co depuis l’exterieur sur mon syno mes ID circulent en clair O_o







Que tu te connectes depuis l’extérieur ou depuis l’intérieur de chez toi, si le port HTTPS est accessible (5001 par défaut), il y a une possibilité pour que ton cookie de session synology (id sur le DSM 5) soit récupérable (ton mot de passe peut être aussi). Avec ce cookie, on peut se connecter sur ton NAS sans mot de passe.



Pour ceux utilisant SPDY sur leur serveur le mod_spdy Apache n’est pas encore patché sur les packages fournis par Google. Donc il faut le déactiver/désinstaller et redémarrer les services. Par contre le code source semble avoir été patché.








Para-doxe a écrit :



Suffit de mettre à jour le paquet de la lib.





Bien sûr que non - il faut faire de nouveau certificats car ils ont pu être volés en utilisant la faille - ça prend du temps et ce n’est pas forcément gratuit.



Sans compter tous les comptes utilisateur créés sur le site en question.

Tous les mots de passe devront être changés après correction de la faille.



Pour tester si votre site/serveur est vulnérable vous pouvez aussi utiliser http://submeet.net/tools/heartbleed.php








BGirard0 a écrit :



Pour tester si votre site/serveur est vulnérable vous pouvez aussi utiliser http://submeet.net/tools/heartbleed.php





J’aurais tendance à me méfier des testeurs de failles - ça donne une liste de serveurs vulnérables au testeur, et certains peuvent être/sont malicieux.









psn00ps a écrit :



Bien sûr que non - il faut faire de nouveau certificats car ils ont pu être volés en utilisant la faille - ça prend du temps et ce n’est pas forcément gratuit.



Sans compter tous les comptes utilisateur créés sur le site en question.

Tous les mots de passe devront être changés après correction de la faille.







Personnellement j’ai vraiment du mal à croire qu’on arrive à sortir la clé privée comme ça. Mais par principe de précaution, en effet…



Rien à redire sur les comptes utilisateurs par contre.









zempa a écrit :



J’ai plutôt tendance à lui donner davantage de crédit qu’à des suppositions/interprétations aussi vraisemblables qu’elles puissent paraitre.



Quelqu’un qui a réussi à dérober un nombre important de document “Top secret” ne se risquerait pas à affirmer de telles choses sans avoir un minimum de certitude.

Son travail rappelons-le, consistait précisément à pirater les systèmes, donc…





je suis complètement d’accord.

seulement Snowden a quitté la NSA il y a pas loin d’un an.

ça laisse du temps à la NSA (ou pas, j’en sais rien), pour trouver la faille.

c’est pas loin du FUD, mais on ne peut pas ignorer le fait que quelqu’un l’ait peut-être trouvée avant cette annonce.









hellmut a écrit :



c’est pas loin du FUD, mais on ne peut pas ignorer le fait que quelqu’un l’ait peut-être trouvée avant cette annonce.







Les chinois ? Comme ya 3-4mois, avec l’histoire du port TCP 32764 sur certains routeurs alors que l’info trainait sur Baidu depuis 2008. <img data-src=" />



Hum, est ce que ça implique qu’il faudrait légitimement changer tout ses mots de passe de webmail (gmail en https), de comptes bancaires (en https…), de sites de commerce (genre amazon en https) ? (le sitehttp://filippo.io/Heartbleed donne du ok pour ces sites, mais ça ne dit pas s’ils ont jamais été victimes de la faille).



Et idem pour les certificats pour se connecter à des machines en SSH ? (genre, pour git, pour du bête SSH, …)


Mais, rassurez-moi, y a pas qu’OpenSSL qui existe pour les certifs ? Et tous les gros sites ne l’exploitent pas forcément, si ? <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />








Baldurien a écrit :



Hum, est ce que ça implique qu’il faudrait légitimement changer tout ses mots de passe de webmail (gmail en https), de comptes bancaires (en https…), de sites de commerce (genre amazon en https) ? (le sitehttp://filippo.io/Heartbleed donne du ok pour ces sites, mais ça ne dit pas s’ils ont jamais été victimes de la faille).



Et idem pour les certificats pour se connecter à des machines en SSH ? (genre, pour git, pour du bête SSH, …)







Oui, il faudrait changer tous les mots de passe de tous les sites qui utilisent ou qui ont utilisé OpenSSL… Car effectivement, rien ne prouve que des personnes mal intentionnées n’avaient pas trouvé ce bug avant.



Pareil pour OpenSSH.







RinSa a écrit :



Mais, rassurez-moi, y a pas qu’OpenSSL qui existe pour les certifs ? Et tous les gros sites ne l’exploitent pas forcément, si ? <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />







Non effectivement, il y a GnuTls, mais peu utilisé, et IIS, qui sont à l’abri. Et toutes les autres implémentations de SSL certainement, mais OpenSSL est de loin la plus utilisée.



C’est franchement catastrophique.









Baldurien a écrit :



Hum, est ce que ça implique qu’il faudrait légitimement changer tout ses mots de passe de webmail (gmail en https), de comptes bancaires (en https…), de sites de commerce (genre amazon en https) ? (le sitehttp://filippo.io/Heartbleed donne du ok pour ces sites, mais ça ne dit pas s’ils ont jamais été victimes de la faille).



Et idem pour les certificats pour se connecter à des machines en SSH ? (genre, pour git, pour du bête SSH, …)





OpenSSH utilise bien OpenSSL, mais pas la partie TLS, donc il n’est pas affecté.

Mais git peut utiliser du HTTPS, donc ceux là oui.



Merci Sébastien, c’est fait !


Comme quoi, un bon vieux user/password envoyé en clair dans un formulaire… <img data-src=" />








127.0.0.1 a écrit :



Comme quoi, un bon vieux user/password envoyé en clair dans un formulaire… <img data-src=" />



Pendez le en salle B4 !! <img data-src=" /><img data-src=" />



Tout va péter…boum !!!



<img data-src=" />

<img data-src=" />


Yahoo a fixé la faille: “Heartbleed” vulnerability update





Our team has successfully made the appropriate corrections across the main Yahoo properties:




     Yahoo Homepage   

Yahoo Search

Yahoo Mail

Yahoo Finance

Yahoo Sports

Yahoo Food

Yahoo Tech

Flickr

Tumblr





We’re working to implement the fix across the rest of our sites right now.








psn00ps a écrit :



J’aurais tendance à me méfier des testeurs de failles donnés dans le premier message d’un inscrit du jour





<img data-src=" />









dam1605 a écrit :



Je vois bien en quoi la permissivité du C est le mega problème ici ?

Dans ce cas on est face à une entrée non vérifiée et du coup à des débordements de tableau.







En managé tu fait un dépassement de tableau tu as le droit à une exception. Forcement sans rien faire le même code devient plus sur.



Il y a évidement d’autres problèmes, le management mémoire en particulier.



Vous me direz il suffit de réaliser des fonctions qui vérifie les entrées, faire des memcpy safe,… Cela ne fait que mettre des béquilles pour un langage qui à mon avis n’est plus fait pour ce type de librairies.



Il y a 15 ans, la tailles des codes et des besoins de sécurité n’était pas du tout les mêmes et le C était un bon, et de toute façon le seul, choix. Maintenant la pression exercée sur chaque ligne de code en terme d’attaque sécuritaire est sans commune mesure.



Vérifier à la main chaque procédure pour savoir si elle présente une faille n’est plus réalisable. Un peu comme si l’on vérifiait à la main chaque pièce qui sort d’une chaîne, heureusement la vision industrielle est passée par là.









Freud a écrit :



Non effectivement, il y a GnuTls, mais peu utilisé, et IIS, qui sont à l’abri. Et toutes les autres implémentations de SSL certainement, mais OpenSSL est de loin la plus utilisée.





Attention, les “vieilles” versions d’OpenSSL ne sont pas affectées par le problème (ex sur Debian Squeeze).



Donc ce ne sont pas TOUS les serveurs avec OpenSSL qui sont affectés.









neves a écrit :



Personnellement j’ai vraiment du mal à croire qu’on arrive à sortir la clé privée comme ça. Mais par principe de précaution, en effet…



Rien à redire sur les comptes utilisateurs par contre.





Il y a de forte chance que les bidules utilisant OpenSSL aient besoin d’accéder à la clé privée pour fonctionner, la fuite venant d’OpenSSL ça ne me semble pas si douteux que ça.



L’article du Monde et du Parisien (le même pour les deux journaux) concernant cette vulnérabilité sont consternants de médiocrité et d’erreurs, tant techniques que d’interprétation.








viruseb a écrit :



En managé tu fait un dépassement de tableau tu as le droit à une exception. Forcement sans rien faire le même code devient plus sur.



Il y a évidement d’autres problèmes, le management mémoire en particulier.



Vous me direz il suffit de réaliser des fonctions qui vérifie les entrées, faire des memcpy safe,… Cela ne fait que mettre des béquilles pour un langage qui à mon avis n’est plus fait pour ce type de librairies.



Il y a 15 ans, la tailles des codes et des besoins de sécurité n’était pas du tout les mêmes et le C était un bon, et de toute façon le seul, choix. Maintenant la pression exercée sur chaque ligne de code en terme d’attaque sécuritaire est sans commune mesure.



Vérifier à la main chaque procédure pour savoir si elle présente une faille n’est plus réalisable. Un peu comme si l’on vérifiait à la main chaque pièce qui sort d’une chaîne, heureusement la vision industrielle est passée par là.







le pb des depassement de memoire en C a été longement discuté sur ce thread par ex:https://news.ycombinator.com/item?id=7548991

bien que gd amateur de code managé, comme certains l ont souligné là bas, ce n est pas une solution pour openSSL, car c est plus difficile a verifier ce qui ce passe (cote boite noire du framework pas top).

Ce qui me semble bcp plus intéressant, c est d utiliser un langage haut niveau qui se compile en C. Il y a des choses tres interessantes avec Haskell. On laisse ainsi la gestion de la memoire a un compilateur, moins susceptible qu un humain sur ce genre d erreur. Et on peut (et doit) tjs faire la review du code C, qui doit rester simple a lire, si le compilateur fait bien son boulot!









®om a écrit :



À jour aussi, et nouvelles clés générées :

openssl req -x509 -newkey rsa:2048 -keyout /etc/ssl/private/\(keyfile -out /etc/ssl/certs/\)certfile -nodes -days 3650







Oouch, un certificat valable 10 ans ?!









neves a écrit :



L’article du Monde et du Parisien (le même pour les deux journaux) concernant cette vulnérabilité sont consternants de médiocrité et d’erreurs, tant techniques que d’interprétation.









Quels erreurs ? L’article du monde est pas très bon mais lors de ma lecture rapide je n’ai pas vu d’erreur d’interprétation fondamentale.









ben5757 a écrit :



Quels erreurs ? L’article du monde est pas très bon mais lors de ma lecture rapide je n’ai pas vu d’erreur d’interprétation fondamentale.





C’était une reprise de la dépêche AFP. Je pense qu’il fait référence au passage ou tu pouvais lire que HB te permet d’accéder au code source traité par le processeur <img data-src=" />









ben5757 a écrit :



Quels erreurs ? L’article du monde est pas très bon mais lors de ma lecture rapide je n’ai pas vu d’erreur d’interprétation fondamentale.







En fait c’est surtout celui du Parisien (mais je crois que celui du Monde a été réécrit en partie) :





Des spécialistes informatiques ont mis en garde mardi contre une importante faille dans un logiciel d’encodage utilisé par la moitié des sites internet, qui permet aux pirates de pénétrer dans les ordinateurs pour y récupérer codes et mots de passe.





Logiciel d’encodage ? La moitié des sites internet ? pénétrer dans les ordinateurs ?





a été baptisée « Heartbleed » (« cœur qui saigne ») parce qu’elle touche au cœur du logiciel OpenSSL





Ah, je pensais que c’était parce que la fonctionnalité touchée par la vulnérabilité était Heartbeats TLS…





le code source (instructions pour le microprocesseur)











les «clés» utilisées pour déverrouiller des données cryptées ou imiter un site. «Ce sont les joyaux de la couronne, les clés d’encodage elles-mêmes»











il existe plusieurs manières d’implémenter OpenSSL







Ouais ok je l’ai vraiment lu en diagonal alors . Je vais m’auto fouetter


Faille SSL, et si la NSA était au courant !

http://www.zataz.com/news/23352/openssl_-tls_-ssl_.html








san-claudio a écrit :



Faille SSL, et si la NSA était au courant !

http://www.zataz.com/news/23352/openssl_-tls_-ssl_.html







Un article d’une très grande qualité <img data-src=" /> <img data-src=" />









san-claudio a écrit :



Faille SSL, et si la NSA était au courant !

http://www.zataz.com/news/23352/openssl_-tls_-ssl_.html





Toujours aussi pourri Zataz, quand je pense que ce mec se paie en dénonçant les admins de trackers BT, et que certains sont allés lui filer du fric quand il était emmerdé par une entreprise. Zataz me file la gerbe.



Pour info : www.service-public.fr est touché !








Crysalide a écrit :



Toujours aussi pourri Zataz, quand je pense que ce mec se paie en dénonçant les admins de trackers BT, et que certains sont allés lui filer du fric quand il était emmerdé par une entreprise. Zataz me file la gerbe.







Bancal ce site <img data-src=" /> <img data-src=" />









viruseb a écrit :



En managé tu fait un dépassement de tableau tu as le droit à une exception. Forcement sans rien faire le même code devient plus sur.



Il y a évidement d’autres problèmes, le management mémoire en particulier.



Vous me direz il suffit de réaliser des fonctions qui vérifie les entrées, faire des memcpy safe,… Cela ne fait que mettre des béquilles pour un langage qui à mon avis n’est plus fait pour ce type de librairies.



Il y a 15 ans, la tailles des codes et des besoins de sécurité n’était pas du tout les mêmes et le C était un bon, et de toute façon le seul, choix. Maintenant la pression exercée sur chaque ligne de code en terme d’attaque sécuritaire est sans commune mesure.



Vérifier à la main chaque procédure pour savoir si elle présente une faille n’est plus réalisable. Un peu comme si l’on vérifiait à la main chaque pièce qui sort d’une chaîne, heureusement la vision industrielle est passée par là.







D’accord mais ce n’est pas aussi simple que ça d’utiliser un langage managé…

Les débordements ne sont pas le seul problème, il faut aussi vérifier l’initialisation/la réutilisation des structures de données pour éviter de lire des vieux trucs…

Par ailleurs vérifier à chaque accès à un tableau que celui-ci est assez grand et que la cellule est initialisée à un côut non négligeable. Pas sûr que tous les gérants de serveurs soit prêt à en payer le prix.









dam1605 a écrit :



D’accord mais ce n’est pas aussi simple que ça d’utiliser un langage managé…

Les débordements ne sont pas le seul problème, il faut aussi vérifier l’initialisation/la réutilisation des structures de données pour éviter de lire des vieux trucs…

Par ailleurs vérifier à chaque accès à un tableau que celui-ci est assez grand et que la cellule est initialisée à un côut non négligeable. Pas sûr que tous les gérants de serveurs soit prêt à en payer le prix.







Je ne pense pas que le managé soit le bon type de langage pour ce genre de cas.



A mon avis il faut que les langages à preuves formelle se démocratisent. Haskell, go, rust… ok mais en est encore du domaine de expérimentation.



Par contre les langages managé ont fait bien avancer les outils d’analyse de codes ne serait-ce à cause de l’introspection. C’est pour moi un composant essentiel pour ces problèmes de sécurisations.



@lol2dol:



Je mets en doute la croyance selon laquelle aucune faille n’aurait été utilisée. Tout bonnement car l’exploitation de la faille ne laisse aucune trace visible et a pru se faire en faisant exclusivement des utilisations en apparence tout à fait normales, totalement conformes au protocole, le serveur ayant renvoyé seulement plus d’informations que nécessaire, des infos que normalement on peut ignorer selon même les spécifications du protocole.



De fait pendant 2 ans des informations ont fuité sur d’autres utilisateurs que ceux qui effectuaient des requêtes valides. C’est une échelle de temps assez grande pour que d’énormes journaux de transactions aient été constitués et des infos récupérées massivement, assez pour récupérer une grande quantité d’infos personnelles sensées être cryptées et inaccessibles à ceux qui effectuaient ces requêtes en toute bonne foi (ou pas) et à ceux qui les écoutent.



Même si l’info est minime et ne concernait que 1% des données échangées, à l’échelle des 2 tiers du web pendant 2 ans, c’est une fuite gigantesque. Il est trop tard pour l’empêcher, elle a déjà eu lieu et on ne sait pas ce que vont devenir les données collectées au départ innocemment mais qui vont tenter les plus gros escrocs du net et les agences espionnes de tout poil qui seront tentées d’aller espionner à leur insu des millions d’utilisateurs qui ne changeront pas leurs mots de passe.



La fuite en effet reste exploitable même après correction des sites affectés. et il n’y a pas plus ni moins de danger à s’y connecter depuis cette découverte et même après la correction de la vulnérabilité.



La seule parade réelle c’est effectivement de changer les mots de passe dès que la faille est corrigée (mais pas avant car la fuite mémoire est toujours activé et fera fuiter votre nouveaux mot de passe de la même façon que l’ancien, et il est impossible de savoir qui écoute ces fuites).



Déjà depuis quelques ours on voit se développer toute une série de spams et de pages de publicté sur Facebook ou d’autres sites sociaux pour de faux jeux et des fausses promos, avec un lien à suivre qui n’aboutit ensuite à pas gand chose Je suis persuadé que ces liens sont là uniquement pour tenter d’exploiter la faille ne récupérant des données même si les attaques actuelles ne savent pas encore comment les filtrer pour les utiliser. Dans nombre de cas, ces liens ne demandent même rien du tout à l’utilisateur et n’exigent aucun clic: Facebook a beau avoir corrigé sa propre faille, il n’a encore rien fait contre ces pseudo-pages qui aussitôt vous redirigent vers un domaine tiers qui ensuite affiche n’importe quoi ou quelque chose en apparence innocent.



Assez vite on va voir un marché noir d’outils d’analyse de ces fuites pour en exfiltrer les infos sensibles intéressantes.

Déjà des réseaux de diffusion de publicités sont infectés, de même que les réseaux de “syndication” de contenus par ces contenus au comportamment plus qu’étrange. On n’est qu’au début de l’epxloitation de la faille et cela va durer aussi longtemps que les utilisateurs n’auront pas tous modifiés leurs mots de passe sur tous les sites corrigés de la vulnérabilité, et tant que les utilisateurs continueront à utiliser des mots de passe partagés sur plusieurs sites.



Plus que jamais les outils de génération de mot de passe forts et d’archivage dans des coffre-forts locaux seront utiles.



Citons quelques outils qui fonctionnent bien:

Dashlane, KeePass.fr



(Et sans doute les antivirus proposeront par défaut maintenant cet outil devenu indispensable).