Heartbleed : tandis qu'Android est menacé, la NSA nie toute implication

Heartbleed : tandis qu’Android est menacé, la NSA nie toute implication

Il faudra sans doute encore un peu de temps pour connaître toutes les retombées

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

15/04/2014 7 minutes
51

Heartbleed : tandis qu'Android est menacé, la NSA nie toute implication

L’actualité de la sécurité a été marquée récemment par la faille dite « Heartbleed », un trou béant dans le protocole OpenSSL. Menaçant de très nombreux sites, la révélation de la brèche a engendré une avalanche de mises à jour, notamment pour les serveurs touchés. Mais le danger pourrait également toucher les appareils et applications mobiles selon plusieurs chercheurs en sécurité.

heartbleed

Crédits : snoopsmaus, licence Creative Commons

Heartbleed ne fait pas de distinction entre les plateformes 

La faille Heartbleed doit son nom à son origine. Découverte au sein de l’extension HeartBeat de la bibliothèque OpenSSL, utilisée par de nombreux logiciels, systèmes d’exploitation et appareils, elle représente un danger bien réel. Exploitée, elle peut permettre le vol des identifiants de connexions, les données transitant par une connexion a priori sécurisée et jusqu’aux informations bancaires quand un paiement en ligne est effectué.

 

Depuis la version 1.0.1 d’OpenSSL, pourtant sortie en 2012, la faille permet en fait à un utilisateur malintentionné de récupérer jusqu’à 60 Ko de données stockées par un serveur via une requête spécialement conçue. Il s’agit d’une porte dérobée dans une connexion prolongée, l’extension HeartBeat devant son nom au fait que le client et le serveur s’échangent de temps à autre des signaux pour vérifier que la communication est toujours active. L’Electronic Frontier Foundation avait d’ailleurs appelé à une utilisation renforcée des mécanismes dits de « perfect forward secrecy », qui empêchent que la compromission d’un lot de données se répercute sur les autres. Ce qui peut se faire avec la faille Heartbleed.

 

Mais si l’on a beaucoup parlé des sites web, directement touchés par cette brèche, la situation ne s’y limite pas. Les applications mobiles ainsi que les smartphones peuvent y être sujets. C’est ce qu’indique notamment la société de sécurité Lookout Mobile. Son principal chercheur en sécurité, Marc Rogers, avertit ainsi que plusieurs versions d’Android sont vulnérables, notamment les moutures 4.1.1 et même certaines variantes de la 4.2.2 lorsqu’elles ont été modifiées par des constructeurs, comme cela arrive souvent avec le système de Google.

L'attaque la plus simple passerait par un site web malveillant 

Selon l’expert, s’en prendre aux mobiles Android n’est pas aussi simple qu’attaquer un serveur vulnérable, mais la manipulation peut néanmoins être mise en place. Son exploitation la plus aisée passerait par un site malveillant contenant des liens spécifiques vers des sites importants comme ceux des banques. Le lien contiendrait bien l’adresse du site bancaire mais serait accompagné d’instructions supplémentaires pour introduire du code malveillant. Une fois ouvert dans un nouvel onglet, le site va échanger des informations avec l’appareil, qui pourront être récupérées par l’attaquant.

 

Deux facteurs cependant limitent l’efficacité de l’exploitation de la faille. D’une part, les appareils sous Android 4.1.X ne représentent qu’un tiers du parc Android. En outre, la sandbox, mécanisme de sécurité qui consiste à isoler un ou plusieurs composants dans une zone de mémoire spécifique, empêche théoriquement ce genre de fuite de données. Elle ne s’applique cependant qu’au cas où une application tierce voudrait récupérer les dites données.

Attention aux réseaux Wi-Fi 

Il faut donc garder en mémoire que la faille Heartbleed représente un danger réel pour une partie du parc Android et que le danger est maximisé lors de l’utilisation des réseaux Wi-Fi. D’autant que, comme le rappelle Mike Rogers, Heartbleed peut être utilisée en conjonction avec d’autres failles de sécurité. Il appelle donc ceux qui ont un appareil vulnérable à faire particulièrement attention aux réseaux auxquels ils se connectent. Il existe d’ailleurs une application conçue pour renseigner l’utilisateur à ce sujet, Heartbleed Detector, créée par Lookout Mobile.

 

Mais le principal danger viendra du correctif. Google a déjà confirmé qu'une mise à jour était en développement et que les partenaires étaient sollicités pour la diffuser dès que possible. Comme c’est régulièrement le cas avec Android, tous les appareils ne la recevront pas et la faille continuera de pouvoir être exploitée sur une partie du parc affecté.

La tempête se calme, la plupart des sites ont été mis à jour 

Dans un communiqué publié samedi, Symantec annonce de son côté plusieurs informations intéressantes. Ainsi, les sites du classement Top 1 000 d’Alexa ne sont plus vulnérables à la faille. Les corrections ont été pour la plupart très rapidement déployées. Dans le Top 50 000, le pourcentage de sites vulnérables ne dépasse pas 1,8 %, ce qui prouve là encore une bonne réactivité des entreprises concernées.

 

Du côté des entreprises, qu’elles possèdent elles-mêmes leurs propres serveurs ou qu’elles les louent, elles doivent s’assurer que la mise à jour vers OpenSSL 1.0.1g a bien été faite. Une fois cette étape réalisée, un nouveau certificat de sécurité doit être mis en place.

 

heartbleedCastorama Heartbleed

 

Côté utilisateurs, Symantec propose un outil permettant de savoir si le site est vulnérable ou non. Pour savoir si tel est bien le cas, attention cependant : il faut chercher spécifiquement le symbole vert indiquant que tout est en ordre, comme avec amazon.com par exemple. Il est recommandé de ne changer les mots de passe que lorsque l'indicateur est au vert, et d'attendre pour les autres que ce soit le cas. Dans le cas de Castorama par exemple, le site n'est plus vulnérable à Heartbleed, mais le certificat n'a toujours pas été mis à jour puisqu'il date toujours du 19 décembre 2012.

La NSA affirme ne jamais avoir utilisé Heartbleed 

Il est globalement admis cependant que la faille Heartbleed n’a pas encore dévoilé tous ses secrets et ses répercussions potentielles. L’un des aspects polémiques de la faille est l’implication de la NSA. Un article publié samedi par Bloomberg indiquait ainsi que l’agence américaine de sécurité était au courant de la faille depuis deux ans, et qu’elle l’avait par ailleurs largement exploitée. À tel point d’ailleurs que la faille, découverte en décembre 2011, serait devenue l’un des principaux outils dans l’aspiration des données.

 

Ces informations ont pris un tour plus sérieux lorsqu’un deuxième article, du New York Times cette fois, est venu affirmer que non seulement la NSA avait bien exploité Heartbleed, mais qu’elle avait en plus reçu expressément le feu vert de la Maison Blanche. Le journal américain rappelle que la NSA est coutumière de l’exploitation des failles et qu’il s’agit de la face sombre de l’agence, l’autre concernant au contraire l’amélioration générale de la sécurité. Ce qui rappelle directement les recommandations d’un panel d’experts qui avait demandé à Barack Obama d’agir pour que l’agence retrouve sa mission première, à savoir la protection. Les actions en « sous-marin » de la NSA avaient par ailleurs été largement dénoncées par Edward Snowden, ainsi que par Tim Berners-Lee.

 

Pour autant, l’agence s’est fendue d’un communiqué pour nier toute utilisation de la faille Heartbleed : « La NSA n'était pas au courant de la vulnérabilité récemment identifiée dans OpenSSL, appelée Heartbleed, jusqu'à ce qu'elle soit rendue publique dans un rapport d'une société privée de sécurité informatique. Les informations faisant état du contraire sont fausses ».

 

Une affirmation appuyée par Caitlin Hayden, porte-parole du Conseil de sécurité nationale, qui s’est appuyée sur un argument simple : « Le gouvernement fédéral a lui aussi recours à l'OpenSSL pour protéger les utilisateurs des sites gouvernementaux. Cette administration prend au sérieux sa responsabilité d'aider au maintien d'un internet ouvert, interopérable, sécurisé et sûr. Si le gouvernement fédéral, y compris la communauté du renseignement, avaient découvert cette vulnérabilité avant la semaine passée, elle en aurait informé la communauté responsable d'OpenSSL ».

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Heartbleed ne fait pas de distinction entre les plateformes 

L'attaque la plus simple passerait par un site web malveillant 

Attention aux réseaux Wi-Fi 

La tempête se calme, la plupart des sites ont été mis à jour 

La NSA affirme ne jamais avoir utilisé Heartbleed 

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Fermer

Commentaires (51)


Comment est-ce qu’un client (tel qu’un appareil sous Android) pourrait-il être impacté par la faille, sachant que techniquement elle permet d’avoir accès à des données aléatoires stockées en RAM du serveur applicatif ?


Suffit qu’un des journalistes du NY Times, Guardian et autres sortent le document Powerpoint qui va bien, et la NSA va tourner cacao <img data-src=" />




«un trou béant dans le protocole OpenSSL»



OpenSSL est une implémentation du protocole SSL/TLS, ce n’est pas un protocole en lui-même.


Avec Internet, il est maintenant admis que tout appareil qui ne reçoit pas régulièrement des mises à jour de sécurité est un danger pour ses utilisateurs et pour le réseau tout entier.



On a beaucoup parlé de l’arrêt des mises à jour de Windows XP (après une durée de vie très très longue). Mais que fait t’on de tout ces smartphones dont les mises à jour ne durent souvent que pendant quelques mois ?



Pourquoi faut t’il toujours attendre qu’il arrive une catastrophe pour que l’on suive ce que le bon sens et la sagesse nous auraient commandé de faire ?















hadoken a écrit :



Comment est-ce qu’un client (tel qu’un appareil sous Android) pourrait-il être impacté par la faille, sachant que techniquement elle permet d’avoir accès à des données aléatoires stockées en RAM du serveur applicatif ?





Je réponds à ma propre question après quelques recherches : en fait la faille est symétrique, c’est à dire qu’un serveur infecté peut également aller piocher dans la RAM du second peer utilisant un OpenSSL avec la faille (c’est donc le client, et donc un device Android en l’occurrence).



Donc ce qui serait possible serait d’emmener l’utilisateur vers une URL d’un site frauduleux, et de récupérer des données random de la RAM du smartphone.



J’aime bien la miniature qui mentionne Amazon et l’agrandissement qui cible Darty :p








AirTé a écrit :



J’aime bien la miniature qui mentionne Amazon et l’agrandissement qui cible Darty :p







Fixed <img data-src=" />









sr17 a écrit :



Avec Internet, il est maintenant admis que tout appareil qui ne reçoit pas régulièrement des mises à jour de sécurité est un danger pour ses utilisateurs et pour le réseau tout entier.



On a beaucoup parlé de l’arrêt des mises à jour de Windows XP (après une durée de vie très très longue). Mais que fait t’on de tout ces smartphones dont les mises à jour ne durent souvent que pendant quelques mois ?



Pourquoi faut t’il toujours attendre qu’il arrive une catastrophe pour que l’on suive ce que le bon sens et la sagesse nous auraient commandé de faire ?







C’est ce que je disais aussi sur une précédente actu qui parlait des durées de support d’Android (et à mes yeux, des OS smartphone en général).

Garder un système obsolète non supporté sur un réseau est une connerie monumentale.



D’un côté ça hurle à la mort parce que Microsoft veut abandonner un OS obsolète de plus de dix ans, de l’autre tout le monde est content de voir qu’un smartphone a six mois d’update système… Deux poids deux mesures. <img data-src=" />



Sinon pour la NSA, je dirais juste qu’ils ont pas besoin d’exploiter la faille, quand on a un accès premium partout pourquoi se faire chier à entrer par la backdoor de service ? <img data-src=" />

(oui c’était gratuit <img data-src=" />)









gathor a écrit :



Fixed <img data-src=" />





Publicité subliminale ! Z’avez pas honte !? <img data-src=" />



<img data-src=" />



Et le sous titre de la 1ere news sur Heartbleed était…

Tiens, aurait-on découvert une backdoor de la NSA ? <img data-src=" />








sr17 a écrit :



Pourquoi faut t’il toujours attendre qu’il arrive une catastrophe pour que l’on suive ce que le bon sens et la sagesse nous auraient commandé de faire ?







Je pense que le principal problème du bon sens dans le cas présent, c’est que ça coûte du pognon <img data-src=" />



Et comment on fait avec la grande majorité des téléphones android qui n’ont jamais droit à la moindre mis à jour?



Et bien on écarte les fesses, merci google…








Holly Brius a écrit :



Et comment on fait avec la grande majorité des téléphones android qui n’ont jamais droit à la moindre mis à jour?



Et bien on écarte les fesses, merci google les constructeurs…





Y a un moment où il faut arrêter de taper sur la cible évidente pour se tourner vers celle qui est responsable…









WereWindle a écrit :



Y a un moment où il faut arrêter de taper sur la cible évidente pour se tourner vers celle qui est responsable…





Le type qui a codé ce truc avec ses pieds, n’est pas responsable de la politique de merde de google avec android… résultat des dizaines de millions de téléphone qui vont rester attaquable dans tout les sens pendant des années… sur une faille maintenant bien documenté…



Tu trouve sans doute ça super…









Holly Brius a écrit :



Le type qui a codé ce truc avec ses pieds, n’est pas responsable de la politique de merde de google avec android… résultat des dizaines de millions de téléphone qui vont rester attaquable dans tout les sens pendant des années… sur une faille maintenant bien documenté…





Je vois pas trop la responsabilité de Google là dedans hein.

Ils ont comblé la faille sur Android. Si les constructeurs des mobiles font pas la mise à jour parce qu’ils en ont pas envie / ça leur coûte trop cher / ils préfèrent vendre le dernier modèle en date, quelle est la responsabilité de Google?



Ils développent un système, qu’ils tiennent à jour, et que les constructeurs peuvent utiliser gratuitement et modifier à leur guise. C’est pas eux qui fabriquent les mobiles à ce que je sache. Ils auraient de toute manière strictement rien à gagner à laisser des terminaux sur le carreau, bien au contraire.









Holly Brius a écrit :



Le type qui a codé ce truc avec ses pieds, n’est pas responsable de la politique de merde de google avec android…





c’est google qui a codé openSSL ? <img data-src=" />





Holly Brius a écrit :



résultat des dizaines de millions de téléphone qui vont rester attaquable dans tout les sens pendant des années… sur une faille maintenant bien documenté…





Une fois encore, c’est google qui produit ces téléphones et il contrôle totalement les décisions des boards des différents constructeurs ? C’est une grosse boîte, certes mais faut pas pousser…







Holly Brius a écrit :



Tu trouve sans doute ça super…





Carrément ! J’avoue qu’une forme quelconque d’apocalypse zombie, que ce soit celle-ci ou celle résultant de ceux qui s’accrochent à XP m’apparaît très tentante.



Comme si ce que je trouvais avait une quelconque pertinence…









Holly Brius a écrit :



Le type qui a codé ce truc avec ses pieds, n’est pas responsable de la politique de merde de google avec android… résultat des dizaines de millions de téléphone qui vont rester attaquable dans tout les sens pendant des années… sur une faille maintenant bien documenté…



Tu trouve sans doute ça super…







Google a envoyé aux OEM comment corriger la faille. On va voir si les OEM vont faire leur boulo.



Apres, je veux pas dire, mais la faille est quand même super galère à faire fonctionner <img data-src=" />



Les stats de mon app donnent 4.1.1 à 4.8% (7eme OS en PDM) (là où 4.1.2 est à 23.9%), donc il semble que la 4.1.1 est plus une version intérimaire qu’autre chose … je serai curieux de savoir combien sont en 4.1.1 et ont une mise à jour disponible mais ne l’installent pas (parce que c’est pas du update auto, ou que ils savent pas comment faire).









unicyclon a écrit :



quelle est la responsabilité de Google?





D’avoir choisie un modelé de fonctionnement de MERDE…

Tes mise à jour de windows/linux ne sont pas tributaire du bon vouloir du fabricant de ton PC…







WereWindle a écrit :



c’est google qui a codé openSSL ? <img data-src=" />





Non, ai-je dit ça? Par contre c’est l’OS fournit par google qui l’utilise, mais bon t’as l’air un peu bouché…







WereWindle a écrit :



Une fois encore, c’est google qui produit ces téléphones et il contrôle totalement les décisions des boards des différents constructeurs ? C’est une grosse boîte, certes mais faut pas pousser…





Voir ci dessus…







WereWindle a écrit :



Comme si ce que je trouvais avait une quelconque pertinence…





En même temps, vu ta mauvaise foi, c’est pas étonnant…<img data-src=" />



Moi je suis avec la 4.1.2 sur mon GSII, je suis concerné donc, c’est ça ? Il serait peut-être temps de flasher CM alors…








atomusk a écrit :



Les stats de mon app donnent 4.1.1 à 4.8% (7eme OS en PDM) (là où 4.1.2 est à 23.9%), donc il semble que la 4.1.1 est plus une version intérimaire qu’autre chose … je serai curieux de savoir combien sont en 4.1.1 et ont une mise à jour disponible mais ne l’installent pas (parce que c’est pas du update auto, ou que ils savent pas comment faire).





Je peux donc remercier mon constructeur d’être encore en 2.3 sur un téléphone qui a 2 ans… <img data-src=" />









Holly Brius a écrit :



Tes mise à jour de windows/linux ne sont pas tributaire du bon vouloir du fabricant de ton PC…





Tu as tout à fait raison. Tu peux donc parfaitement changer de système sur ton mobile si tu en as envie, et profiter des mises à jour de la communauté. Il existe un tas de distributions Android parfaitement à jour.



Comme sur ton ordi en somme. Si ton OS ou la fréquence de ses mises à jour te convient pas, changes en. Si tu peux pas, plains toi à ton constructeur, c’est lui qui verrouille le bootloader.









renaud07 a écrit :



Moi je suis avec la 4.1.2 sur mon GSII, je suis concerné donc, c’est ça ? Il serait peut-être temps de flasher CM alors…







Il faudrait vérifier, mais normalement, n’est concerné que 4.1.1 et certains 4.2.2 spécifiques (sans plus d’info que je sache)









Holly Brius a écrit :



Je peux donc remercier mon constructeur d’être encore en 2.3 sur un téléphone qui a 2 ans… <img data-src=" />







Ca dépend … si ton téléphone est tellement pourri que son SOC n’est pas compatible avec 4.x (car le saut 2.3-&gt;4.x est violent), oui, tu peux le remercier <img data-src=" />



Après tant qu’il n’y a pas de faille connue, que le téléphone fonctionne comme au 1er jour, et que tu as les apps que tu veux …



Par contre c’est quel téléphone ?





La NSA affirme ne jamais avoir utilisé Heartbleed





Il y a pas à se poser de questions.

Si la NSA le nie fortement et qu’elle ment, on risque de recevoir un petit mémo d’Edward (oui le vampire qui a pompé les documents de la NSA ;) ) prouvant que c’est faux !

Si on a rien, on peut légitimement suggérer que pour une fois la NSA dit la vérité !


Quand bien même il y a des mises à jour, combien de personnes mettent à jours les appareils ? (nous oui, c’est notre truc l’informatique mais M. toutlemonde ?)

La NSA à avoué de toute façon avoir en stockent des centaines voir des milliers de failles qu’ils exploitent, alors une de plus ou de moins…me demande même s’ils n’ont pas des taupes dans l’open source (en plus du proprio) pour y mettre des failles exprès ! Après, s’ils ont du temps à perdre pour regarder mes mails, je les plaint plus que je ne les craint








unicyclon a écrit :



Tu as tout à fait raison. Tu peux donc parfaitement changer de système sur ton mobile si tu en as envie, et profiter des mises à jour de la communauté. Il existe un tas de distributions Android parfaitement à jour.



Comme sur ton ordi en somme. Si ton OS ou la fréquence de ses mises à jour te convient pas, changes en. Si tu peux pas, plains toi à ton constructeur, c’est lui qui verrouille le bootloader.





La toute petite différence est peut être que la mise à jour sous Linux/OS X/Windows est transparente pour l’utilisateur…

Car une grande majorité des utilisateurs de PC ne changeront jamais d’OS même pour des raisons de sécurité…



Quant à l’implication de Google… désolé, mais Google est au sommet de la pyramide Android… Si Google n’a pas su ou voulu imposer des conditions plus restrictives de mises à jour, c’est bien lui le responsable non ?



Vincent Hermann, NxI :



un deuxième article, du New York Times cette fois, est venu affirmer que non seulement la NSA avait bien exploité Heartbleed, mais qu’elle avait en plus reçu expressément le feu vert de la Maison Blanche.





David E. Sanger, New York Times :



There is no evidence that the N.S.A. had any role in creating Heartbleed, or even that it made use of it. When the White House denied prior knowledge of Heartbleed on Friday afternoon, it appeared to be the first time that the N.S.A. had ever said whether a particular flaw in the Internet was — or was not — in the secret library it keeps at Fort Meade (…), the headquarters of the agency and Cyber Command.





Trad à la rache : il n’y a aucune preuve que la NSA ait joué un rôle quelconque dans la création de Heartbleed, ni même qu’elle en ait fait usage. Lorsque vendredi après-midi la Maison Blanche a nié avoir eu préalablement connaissance de Heartbleed, c’était apparemment la toute première fois que la NSA disait si une faille précise dans l’internet était - ou n’était pas - dans la bibliothèque secrète qu’elle maintient à Fort Meade, QG de l’agence et du Cyber Command.



<img data-src=" />


Concernant l’exploitation de la faille cette publication de l’EFF me semble un peu troublante (le second log).

Pour la NSA, soit ils savaient et on fait courir des risques à tout le monde, soit ils ne savaient pas ce qu’on leur reprochera également.











picoteras a écrit :



Vincent Hermann, NxI :





David E. Sanger, New York Times :





<img data-src=" />







Merci pour la trad <img data-src=" /><img data-src=" />









TaigaIV a écrit :



Concernant l’exploitation de la faille cette publication de l’EFF me semble un peu troublante (le second log).

Pour la NSA, soit ils savaient et on fait courir des risques à tout le monde, soit ils ne savaient pas ce qu’on leur reprochera également.





Merci pour le lien. On va voir ce que donne leur appel à l’analyse des logs et au traçage du botnet soupçonné.



Quant à la NSA, bien d’accord avec toi. Elle est dans la situation damn if you did, damn if you didn’t. Sans compter qu’avec le patch de la faille et le renouvellement massif des certificats, pas mal d’entrées dans ses bases de données de clés viennent brutalement et simultanément de passer la date de péremption.









razcrambl3r a écrit :



Merci pour la trad <img data-src=" /><img data-src=" />





My pleasure… heuh… avec plaisir !









sr17 a écrit :



Avec Internet, il est maintenant admis que tout appareil qui ne reçoit pas régulièrement des mises à jour de sécurité est un danger pour ses utilisateurs et pour le réseau tout entier.



On a beaucoup parlé de l’arrêt des mises à jour de Windows XP (après une durée de vie très très longue). Mais que fait t’on de tout ces smartphones dont les mises à jour ne durent souvent que pendant quelques mois ?



Pourquoi faut t’il toujours attendre qu’il arrive une catastrophe pour que l’on suive ce que le bon sens et la sagesse nous auraient commandé de faire ?







Dans le cas present, c’est totalement faux, puisque les plus vieilles versions d’openssl ne sont pas touchees.



C’est bien la derniere version qui etait touchee, donc tous les appareils mis a jours.



Maintenant que le correctif est la, c’est un peu facile de dire que ceux qui ne mettent pas a jour sont un danger, alors qu’une grosse partie du reseau internet etait troue jusqu’alors.









picoteras a écrit :



My pleasure… heuh… avec plaisir !







Lol, j’aurais quand même compris ça <img data-src=" />









carbier a écrit :



désolé, mais Google est au sommet de la pyramide Android





Et la fondation OpenSSL est au sommet de la pyramide OpenSSL. Après tout, ils avaient qu’à imposer une licence plus restrictive concernant les mises à jour des produits basés sur leur ogiciel, donc c’est aussi leur faute si android n’est pas à jour, non, si on suit ta logique…







carbier a écrit :



Si Google n’a pas su ou voulu imposer des conditions plus restrictives de mises à jour, c’est bien lui le responsable non ?





Je disconviens donc respectueusement. M’est d’avis que c’est bien au distributeur final de l’OS d’assumer la charge des mises à jour. S’ils ne le voulaient pas, libre à eux de distribuer Android Vanilla (sans modif, donc).









Vellou a écrit :



Dans le cas present, c’est totalement faux, puisque les plus vieilles versions d’openssl ne sont pas touchees.



C’est bien la derniere version qui etait touchee, donc tous les appareils mis a jours.



Maintenant que le correctif est la, c’est un peu facile de dire que ceux qui ne mettent pas a jour sont un danger, alors qu’une grosse partie du reseau internet etait troue jusqu’alors.







Sauf que c’est un cas particulier. Et contrairement aux idées reçues, les patchs de sécurité ne consistent pas forcément à intégrer la dernière version.



De plus, il ne faut pas oublier les correctifs de sécurité ne se limitent pas aux quelques failles médiatisées par la presse : Une bonne distribution Linux reçoit des correctifs de sécurité presque tous les jours.



Dans n’importe quel programme, il peut y avoir des failles. Tant qu’elles ne sont pas découvertes, elles sont dormantes. Tant qu’elles sont ignorées de tous, le danger est relativement faible. (Le “relativement” est à comprendre de manière nuancé).



Mais elles deviennent particulièrement dangereuses à partir du moment ou elles sont découvertes et révélées. Parce qu’a ce moment la, les pirates n’ont plus qu’a se servir.



C’est pourquoi un OS ou un logiciel qui ne reçoit pas de patch de sécurité au fur et à mesure que ses failles sont révélées devient un vrai danger.



Tous les experts s’inquiètent pour la fin du support de Windows XP. Mais ce qui est vrai pour XP est vrai pour tous les OS, même pour ceux basés sur Linux.



Demandez vous simplement combien de failles sont corrigées tous les ans sur un OS et ses logiciels. Et vous comprendrez pourquoi c’est une absolue nécessité que TOUS les appareils potentiellement connectés au réseau reçoivent des patchs de sécurité régulièrement.



Est ce que ça coûtera plus cher pour certains appareils ? La réponse est oui.



Mais il n’y a pas d’autre alternative.



La seule question, c’est de savoir s’il faudra des lois pour l’imposer ou si la sagesse suffira.






Je me permets une légère digression.

Avec cette histoire et les potentiels changements de mot de passe à effectuer, je commence à étudier la question d’un outil de gestion des mots de passe simple et sécurisé (et dans l’idéal, synchronisable entre différents support, typiquement, Smartphone et PC)



A nos amis de NEXT INpact (ça fait bizarre de plus parler de PC INpact ;-) ), envisagez-vous un dossier sur ce thème, avec un petit comparo des différentes solutions du marché ?



Merci !


Question à propos des comptes steam :

ont-ils été vulnérables à la faille ?

Si oui, comment changer son mot de passe ?

(je viens d’essayer, je trouve pas le moyen de le changer)








Arkaniis a écrit :



Je me permets une légère digression.

Avec cette histoire et les potentiels changements de mot de passe à effectuer, je commence à étudier la question d’un outil de gestion des mots de passe simple et sécurisé (et dans l’idéal, synchronisable entre différents support, typiquement, Smartphone et PC)





keepas, avec son extension/firefox = keefox ( le tout étant portable et disponible sous liberkey ) , avec la version android keepassdroid. Base en local. ( c’est un petit fichier en fait ).

L’option “synchroniser” permet de synchroniser tes différentes versions de ta base ( fichierfichier, ou fichier avec une URL mais ça, j’ai pas testé ) , c’est à dire en conservant les mots de passe mis à jour de part et d’autre…

J’ai un exemplaire de ma base sur clé USB, un sur le PC du boulot, un sur le PC@home, et un sur mon tél android.












sr17 a écrit :



Sauf que c’est un cas particulier. Et contrairement aux idées reçues, les patchs de sécurité ne consistent pas forcément à intégrer la dernière version.



De plus, il ne faut pas oublier les correctifs de sécurité ne se limitent pas aux quelques failles médiatisées par la presse : Une bonne distribution Linux reçoit des correctifs de sécurité presque tous les jours.



Dans n’importe quel programme, il peut y avoir des failles. Tant qu’elles ne sont pas découvertes, elles sont dormantes. Tant qu’elles sont ignorées de tous, le danger est relativement faible. (Le “relativement” est à comprendre de manière nuancé).



Mais elles deviennent particulièrement dangereuses à partir du moment ou elles sont découvertes et révélées. Parce qu’a ce moment la, les pirates n’ont plus qu’a se servir.



C’est pourquoi un OS ou un logiciel qui ne reçoit pas de patch de sécurité au fur et à mesure que ses failles sont révélées devient un vrai danger.



Tous les experts s’inquiètent pour la fin du support de Windows XP. Mais ce qui est vrai pour XP est vrai pour tous les OS, même pour ceux basés sur Linux.



Demandez vous simplement combien de failles sont corrigées tous les ans sur un OS et ses logiciels. Et vous comprendrez pourquoi c’est une absolue nécessité que TOUS les appareils potentiellement connectés au réseau reçoivent des patchs de sécurité régulièrement.



Est ce que ça coûtera plus cher pour certains appareils ? La réponse est oui.



Mais il n’y a pas d’autre alternative.



La seule question, c’est de savoir s’il faudra des lois pour l’imposer ou si la sagesse suffira.







Je suis presque d’accord avec toi. Mais a la base, tu sors une generalite qui, dans le cas present, ne s’applique absolument pas. Cas particulier ou pas, c’est rate <img data-src=" />



Mais le plus dangereux dans Heartbleed, c’est que ce n’est pas vraiment detectable, et que la faille est restee presente durant un long moment : IMPOSSIBLE de savoir l’etendue des degats.



Surtout que vu la tronche de la “faille”, elle a pu etre introduite malicieusement, et alors les degats sont deja enormes et doivent remettre en question le fonctionnement meme d’Open SSL et de ses mechanismes d’audit.



Les constructeurs et les personnes qui integrent open SSL ne sont pas vraiment en faute, du moins pas encore.



Et je le repete : un systeme mis a jour a l’heure pres n’aurait pas echappe a cette faille : ce n’est pas la solution infaillible.









sksbir a écrit :



keepas, avec son extension/firefox = keefox ( le tout étant portable et disponible sous liberkey ) , avec la version android keepassdroid. Base en local. ( c’est un petit fichier en fait ).

L’option “synchroniser” permet de synchroniser tes différentes versions de ta base ( fichierfichier, ou fichier avec une URL mais ça, j’ai pas testé ) , c’est à dire en conservant les mots de passe mis à jour de part et d’autre…

J’ai un exemplaire de ma base sur clé USB, un sur le PC du boulot, un sur le PC@home, et un sur mon tél android.





J’avais bien pensé à Keepass (Je l’utilise déjà au boulot) mais dans mon cas, à associer à un dropbox ou équivalent pour conserver une disponibilité en toutes circonstances.

ça me paraissait un peu lourd.

Je vais cependant étudier cette solution un peu plus sérieusement et voir ce que je peux en faire.



Merci.





En outre, la sandbox, mécanisme de sécurité qui consiste à isoler un ou plusieurs composants dans une zone de mémoire spécifique, empêche théoriquement ce genre de fuite de données.





Chaque processus est isolé en mémoire et ne peux lire dans la mémoire des autres (sauf cas particulier/autorisation spéciale comme du partage de mémoire explicitement autorisé par les process consentants), sandbox ou pas, c’est la base de l’isolation des process dans tous les OS.



Le sandboxing ne change strictement rien pour ce point là.


Bon je viens de passer un coup de heartbleed detector sur mon cink peax 2 et à priori j’ai une version vulnérable mais le heartbleed n’est pas activé sur ma lib ssl.



Donc téléphone pas vulnérable.








Vellou a écrit :



doivent remettre en question le fonctionnement meme d’Open SSL et de ses mechanismes d’audit.



Les constructeurs et les personnes qui integrent open SSL ne sont pas vraiment en faute, du moins pas encore.





http://www.zdnet.com/openssl-needs-corporate-funding-to-avoid-heartbleed-repeat-…



OpenSSL c’est un gars à plein temps pour le moment. Je suis sûr qu’ils adoreraient revoir le fonctionnement d’OpenSSL et mettre en place des mécanismes d’audit, mais ils n’ont clairement pas les moyens pour.



Ce truc est utilisé par 60% des sites web de part le monde, ça touche à la sécurité des données, la base de tout le commerce électronique (un tout petit business au niveau mondial…) et niveau argent ils ont juste de quoi payer un gars à plein temps?









Khalev a écrit :



http://www.zdnet.com/openssl-needs-corporate-funding-to-avoid-heartbleed-repeat-…



OpenSSL c’est un gars à plein temps pour le moment. Je suis sûr qu’ils adoreraient revoir le fonctionnement d’OpenSSL et mettre en place des mécanismes d’audit, mais ils n’ont clairement pas les moyens pour.



Ce truc est utilisé par 60% des sites web de part le monde, ça touche à la sécurité des données, la base de tout le commerce électronique (un tout petit business au niveau mondial…) et niveau argent ils ont juste de quoi payer un gars à plein temps?







https://www.openssl.org/about/



Une seule ou 150 personnes, peu importe.



Si tu pretends developper des outils de securite, alors tu dois le faire avec beaucoup d’attention.



C’est pas parceque c’est libre (je suis moi meme libriste) que ca doit etre la fete du slip.



L’erreur est humaine, et elle est excusable. En revanche, si elle peut etre repetee car on ne se donne pas les moyens d’y remedier, alors c’est un vrai probleme de fonctionnement, et c’est moins excusable.









Vellou a écrit :



https://www.openssl.org/about/



Une seule ou 150 personnes, peu importe.



Si tu pretends developper des outils de securite, alors tu dois le faire avec beaucoup d’attention.



C’est pas parceque c’est libre (je suis moi meme libriste) que ca doit etre la fete du slip.



L’erreur est humaine, et elle est excusable. En revanche, si elle peut etre repetee car on ne se donne pas les moyens d’y remedier, alors c’est un vrai probleme de fonctionnement, et c’est moins excusable.





Le problème c’est que des boites utilisent un truc founi gratuitement et librement sans :




  • lui donner les moyens d’auditer lui-même son code

  • faire eux-même les audits de code.



    Dans ma boite on fait du code proprio (on bosse dans la sécurité aussi) pourtant nos clients payent pour qu’on puisse certifier notre code et pour venir faire des audits de nos process (on a aussi droit à des visites des agences gouvernementales & co qui nous payent aussi) et ils seraient idiots de nous faire une confiance aveugle.

    Je vois pas pourquoi d’un coup parce que c’est libre il n’y a pas besoin de faire d’audit alors que justement il est facile de se rendre compte si dans leur process il y a des étapes de relectures/audit & co.



    Quand tu fais du commerce en ligne la sécurité des transaction c’est LE truc le plus important puisque c’est ce qui fait que tes clients vont te faire confiance et te payer. Installer un truc qu’on te fourni sans garanties sans même le vérifier et faire reposer tout ton business dessus c’est un peu… con con quand même.





    Si tu pretends developper des outils de securite, alors tu dois le faire avec beaucoup d’attention.



    Ils font attention, mais avec les moyens qu’ils ont. C’est ça qui est bien avec le libre justement c’est que tu peux savoir exactement les moyens qu’ils ont et évaluer le risque que tu encours à utiliser leur solution tel-quel.

    Une boite proprio je peux juste faire confiance à ce qu’ils te disent.

    Dans ma boite sur certains projet on a un dév et un testeur débutant et c’est tout. Et ça le client ne le saura jamais sauf s’il vient auditer en interne. De l’extérieur on est des milliers d’employés.









Arkaniis a écrit :



J’avais bien pensé à Keepass (Je l’utilise déjà au boulot) mais dans mon cas, à associer à un dropbox ou équivalent pour conserver une disponibilité en toutes circonstances.

ça me paraissait un peu lourd.

Je vais cependant étudier cette solution un peu plus sérieusement et voir ce que je peux en faire.



Merci.







J’ai jamais testé, mais disponible partout, y’a aussi “teampass” mais par contre, il faut trouver un moyen de mitiger la sécurité (service web toussa toussa).









Khalev a écrit :



Le problème c’est que des boites utilisent un truc founi gratuitement et librement sans :




  • lui donner les moyens d’auditer lui-même son code

  • faire eux-même les audits de code.



    Dans ma boite on fait du code proprio (on bosse dans la sécurité aussi) pourtant nos clients payent pour qu’on puisse certifier notre code et pour venir faire des audits de nos process (on a aussi droit à des visites des agences gouvernementales & co qui nous payent aussi) et ils seraient idiots de nous faire une confiance aveugle.

    Je vois pas pourquoi d’un coup parce que c’est libre il n’y a pas besoin de faire d’audit alors que justement il est facile de se rendre compte si dans leur process il y a des étapes de relectures/audit & co.



    Quand tu fais du commerce en ligne la sécurité des transaction c’est LE truc le plus important puisque c’est ce qui fait que tes clients vont te faire confiance et te payer. Installer un truc qu’on te fourni sans garanties sans même le vérifier et faire reposer tout ton business dessus c’est un peu… con con quand même.





    Ils font attention, mais avec les moyens qu’ils ont. C’est ça qui est bien avec le libre justement c’est que tu peux savoir exactement les moyens qu’ils ont et évaluer le risque que tu encours à utiliser leur solution tel-quel.

    Une boite proprio je peux juste faire confiance à ce qu’ils te disent.

    Dans ma boite sur certains projet on a un dév et un testeur débutant et c’est tout. Et ça le client ne le saura jamais sauf s’il vient auditer en interne. De l’extérieur on est des milliers d’employés.







    Alors au final je suis d’accord avec ton message.



    Et tu as l’air de me voir contre le libre, mais j’utilise des distrib GNU/Linux chez moi depuis environ 10 ans <img data-src=" />

    Je suis fan du libre, mais pas fan du “faire nawak parce que c’est libre”.



    Effectivement, les gros utilisateurs ont un interet a ameliorer l’outil, surtout quand il est libre.









Vellou a écrit :



Alors au final je suis d’accord avec ton message.



Et tu as l’air de me voir contre le libre, mais j’utilise des distrib GNU/Linux chez moi depuis environ 10 ans <img data-src=" />

Je suis fan du libre, mais pas fan du “faire nawak parce que c’est libre”.



Effectivement, les gros utilisateurs ont un interet a ameliorer l’outil, surtout quand il est libre.





Je ne te voyais nullement contre le libre (en fait j’y avais même pas pensé). Mais c’est juste que je critiquais le fait que les boites agissent avec le libre comme elles le feraient avec du proprio, les brouzoufs en moins.

C’est à dire qu’elles font confiance aveuglément aux solutions quand bien même c’est marqué en gros dans la licence qu’il n’y a aucune garantie dans le logiciel qu’il fasse ce qu’il soit censé faire et qu’il ne casse pas tout.

Sauf que quand dans le cas du proprio il y a souvent les moyens de se retourner vers la boite en cas de soucis (souvent en payant pour un conseil où une update d’ailleurs) quand c’est du libre tout le monde attend que les choses évoluent mais sans bouger le petit doigt, par contre les dév se retrouvent responsables de tout alors qu’aucun contrat ne les lie ou ne les engage.



Pendant la faille heartbleed, faille qui touche des milliers de sites chez des milliers de boites, qui a mis en danger le business de boite d’e-commerce, de webmail & co, OpenSSL a touché… 9k\(. Par contre tout le monde a bien déployé le correctif, ou est en train de le faire <img data-src=">.



C'était pareil avec OpenBSD, alors que le résultat de leur taff est utilisé et intégré dans plein de produit (routeur, serveur, & co) ils ont galéré à lever 150k\)
. Il a fallu que ça soit (principalement) Google et un donnateur Roumain qui se bougent pour les faire atteindre la somme demandée…

Et encore parce que Theo de Raadt avait menaçé de couper les serveurs…



Moi ce qui me choque un peu dans cette histoire, c’est que je n’ai reçu aucune message demandant à changer de mot de passe d’aucun site suite à cette faille (juste eu de la part du devnet de Sony mais ca peut se comprendre). Ni Google, ni Facebook, rien.



Alors que ça fait peut-être 2 ans que mes infos ou mes identifiants se baladent dans la nature…



Soit tous les sites sur lesquels j’ai un compte sont super secure, ne sont pas impacté ou quoi (mais je doute franchement), soit tout ce beau monde essaie de faire passer ça sous le tapis sans faire de vague…








cactusbidon a écrit :



Moi ce qui me choque un peu dans cette histoire, c’est que je n’ai reçu aucune message demandant à changer de mot de passe d’aucun site suite à cette faille (juste eu de la part du devnet de Sony mais ca peut se comprendre). Ni Google, ni Facebook, rien.



Alors que ça fait peut-être 2 ans que mes infos ou mes identifiants se baladent dans la nature…



Soit tous les sites sur lesquels j’ai un compte sont super secure, ne sont pas impacté ou quoi (mais je doute franchement), soit tout ce beau monde essaie de faire passer ça sous le tapis sans faire de vague…





2° solution. Et c’est clairement une honte.









Vellou a écrit :



Je suis presque d’accord avec toi. Mais a la base, tu sors une generalite qui, dans le cas present, ne s’applique absolument pas. Cas particulier ou pas, c’est rate <img data-src=" />







Le problème, c’est que tu t’avances un peu vite en disant que cela ne s’applique pas au cas présent.



Cette faille existe depuis suffisamment longtemps pour qu’il soit possible que certains smarphones(ou tablettes) affectés soient déjà sortis des périodes de mise à jour.



C’est d’ailleurs forcément le cas de certains appareils issus de petits fabricants asiatiques qui ne reçoivent jamais la moindre mise à jour.



Mais tu as raison sur un point, c’est que mon propos est d’ordre général et vise à une prise de conscience de l’importance des problèmes de sécurité et du fait que des mises à jour couvrant la durée de vie effective de tous les appareils devraient être rendues obligatoires.





Mais le plus dangereux dans Heartbleed, c’est que ce n’est pas vraiment detectable, et que la faille est restee presente durant un long moment : IMPOSSIBLE de savoir l’etendue des degats.





Rien d’exceptionnel pourtant : C’est le cas de beaucoup de failles de sécurité.



Mais pour le coup, cette hyper médiatisation autour de cette faille particulière semble produire une prise de conscience des dangers. Et cela ne peut être que bénéfique.





Surtout que vu la tronche de la “faille”, elle a pu etre introduite malicieusement, et alors les degats sont deja enormes et doivent remettre en question le fonctionnement meme d’Open SSL et de ses mechanismes d’audit.





Malheureusement, on ne peut pas faire la différence dans la mesure ou ce genre de faille est typique des erreurs d’inattention qu’on peut trouver au quotidien dans n’importe quel programme.



Et la, par contre, je suis d’accord qu’il faudra tirer les leçons de cette faille. Et elles sont multiples.



Pour ce qui est d’auditer le code de ce genre d’application, pour faire simple, il faudrait que les états et/ou les grandes entreprises réalisent qu’il faut y consacrer des budgets.





Les constructeurs et les personnes qui integrent open SSL ne sont pas vraiment en faute, du moins pas encore.





Faute ?



Même le meilleur programmeur du monde produit en moyenne 4 à 5 bugs par 1000 lignes de code.



Nous sommes à des niveaux de complexité tels dans l’informatique que la question n’est pas de savoir s’il y a des failles, mais combien il y en a. <img data-src=" />



Si on ne veut pas de logiciels avec des failles, il ne faut pas utiliser d’ordinateur.



C’est aussi simple que cela.



Après, il est évident qu’il y a des moyens pour diminuer le nombre de failles tout autant que leur impact. Il faut s’en servir.





Et je le repete : un systeme mis a jour a l’heure pres n’aurait pas echappe a cette faille : ce n’est pas la solution infaillible.





C’est un mauvais raisonnement.



Parce que le niveau de danger est relativement faible tant qu’une faille reste inconnue. C’est un peu comme si tu oubliais un jour de verrouiller ta porte, mais que personne ne le sait.



Le danger devient par contre extrêmement important à partir du moment ou la faille est découverte et rendue publique et que tous les hackers de la planète vont s’en servir.



Donc oui, la miser un jour rapide est un point absolument capital. Le chrono tourne entre le moment ou les failles sont divulguées et le moment ou les patchs sont déployés. Parce que c’est précisément pendant ce délai que la majorité des attaques se produiront.