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 ?

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.1 g), 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. 

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



Winderly Abonné
Le 08/04/2014 à 20h27