HeartBleed : 200 000 serveurs et appareils toujours vulnérables

HeartBleed : 200 000 serveurs et appareils toujours vulnérables

Trois ans après le correctif

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

24/01/2017 4 minutes
18

HeartBleed : 200 000 serveurs et appareils toujours vulnérables

La faille HeartBleed, qui touchait la bibliothèque OpenSSL, n’a pas fini de faire parler d’elle. À l’heure actuelle, presque 200 000 serveurs et appareils seraient encore vulnérables, alors même que les correctifs ont été déployés il y aura bientôt trois ans.

En avril 2014, le monde de la sécurité était en effervescence. L’extension Heartbeats, dans la bibliothèque OpenSSL, était victime d’une brèche critique. Elle existait depuis décembre 2011, ce qui laissait de nombreuses versions vulnérables. Cette bibliothèque étant utilisée par une bonne part des distributions Linux, des systèmes Unix et par OS X, la situation était sérieuse, au point que des sites avaient momentanément fermé. Exploitée, la faille permettait de révéler une partie des informations circulant sur une connexion chiffrée.

Toujours 200 000 installations vulnérables

La révélation de la faille s’était faite en même temps que la diffusion d’une nouvelle version d’OpenSSL. Estampillée 1.0.1g, elle avait été reprise immédiatement et placée dans les mécanismes de mise à jour de tous les produits concernés. Pourtant, presque trois ans plus tard, il reste de nombreux serveurs encore vulnérables, même si l’ensemble s’est considérablement amenuisé.

Ainsi, selon les chiffres fournis par le moteur de recherche Shodan (qui permet de scanner les ports réseau en masse sur Internet), presque 200 000 serveurs et appareils seraient ainsi encore touchés par HeartBleed. Pourquoi ? Tout simplement parce que les administrateurs concernés n’ont pas mis à jour la bibliothèque OpenSSL, quelle que soit l’implémentation dans le système utilisé. Notez que le nombre d'installations touchées en 2014 était estimé à 600 000.

Mais il est étonnant que seulement deux tiers des serveurs soient sortis de l’équation en presque trois ans. Critique et largement médiatisée, la faille aurait en effet dû recevoir une attention immédiate. Pourtant, le problème est similaire à celui de l’attaque contre les bases de données MongoDB : des instances créées chez des prestataires comme Amazon Web Services et laissées en l’état pendant des années.

Un grand nombre d'installations situées aux États-Unis

Comme indiqué dans le rapport de Shodan, près de 52 000 serveurs Apache HTTPD restent exposés à Heartbleed. Les instances ont été créées avec des versions vulnérables, dans la grande majorité les 2.2.22 et 2.2.15. Une bonne majorité des connexions supportent TLS 1.2. Pour John Matherly, fondateur de Shodan, cela traduit un chiffrement correct, mais de vieilles dépendances. Pour information, TLS 1.3 existe bien, mais encore sous forme de brouillon.

Les serveurs vulnérables sont également nombreux à être situés aux États-Unis. Là encore, ce n’est pas étonnant : de nombreux prestataires de services y sont situés, notamment Amazon et Verizon. Près d’un quart des soucis détectés concernent ainsi des serveurs américains. On en compte également plus de 15 000 en Corée du Sud, environ 14 000 en Chine et en Allemagne, ou encore 8 700 environ en France.

Sur l’ensemble des installations vulnérables détectées, les trois quarts concernent avant tout les connexions HTTPS, qui ne sont, pour rappel, pas spécifiques à des sites web. Viennent ensuite HTTPS sur le port 8443 et webmin, mais loin derrière. Idem, une immense majorité des connexions vulnérables se négocient en HTTP/1.1, suivies par plusieurs versions du protocole SPDY. Dans la plupart des cas, les systèmes vulnérables sont des distributions Linux équipées d’une mouture 3.x du noyau.

Le tiers des irréductibles 

Sur les 600 000 serveurs concernés lors des premières révélations autour de HeartBleed, environ deux tiers ont donc été corrigés. Ce dernier tiers pose problème, car le simple fait que ces instances n’aient pas encore reçu de correctif souligne l’inquiétude de leur relatif « abandon » : si personne n’a géré la situation depuis presque trois ans, y a-t-il des chances qu’elle le soit à l’avenir ?

Ces 200 000 installations, quelles qu’elles soient, pourraient rester vulnérables pendant encore un bon moment, laissant les services liés exposés à des risques de fuites d’informations.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Toujours 200 000 installations vulnérables

Un grand nombre d'installations situées aux États-Unis

Le tiers des irréductibles 

Fermer

Commentaires (18)


Faut voir ou sont les serveurs vulnérables, si c’est dans une boite ou il n’y a qu’un gars pour le gérer et qu’il doit faire du support interne en plus et le café, ça ne risque pas d’être patché.








darkbeast a écrit :



Faut voir ou sont les serveurs vulnérables, si c’est dans une boite ou il n’y a qu’un gars pour le gérer et qu’il doit faire du support interne en plus et le café, ça ne risque pas d’être patché.





Effectivement, comme dit en fin d’article, si le serveur n’a pas été patché en 3 ans il y a peu de chance qu’il le soit à l’avenir…

200000 c’est énorme



Vincent l’évoque pour MongoDB, mais des équipes de hackeurs sont en train de nettoyer les bases de données exposées sur Internet dont des comptes admin sont sans mot de passe, ou avec mot de passe non modifié.

On a donc  MongoDB, mais depuis quelques jours CouchDB, Elasticsearch, Hadoop, et des suspicions sur d’autres BdD à priori.

les hackeurs demandent en général une rançon, mais les chercheurs en Sécu semblent penser que les datas n’ont pas été exfiltrés avant suppression : du pire vandalisme donc.



Le truc, c’est qu’il y a quand même des IT pour utiliser une BdD, sans changer les mots de passe des comptes builtin, et sans lire la doc qui fait que la configuration de leur base les rend accessibles depuis Internet. En 2017. Et on parle de milliers, voire de dizaines de milliers d’instances…



Sur le fond, c’en est presque marrant à lire :

https://twitter.com/0xDUDE

https://twitter.com/Plazmaz1

&nbsphttps://nakedsecurity.sophos.com/2017/01/11/thousands-of-mongodb-databases-compr…

http://www.informationsecuritybuzz.com/expert-comments/mongodb-ransom-attack-jus…


Etonnant d’ailleurs qu’il n’y ait pas de ‘white hats’ qui te changent le mot de passe et t’informent du changement :-p


  Le coup des système configurer par défaut sans mot de passe c’est quand même fort les admin ne peuvent s’en prendre qu’a eux même, encore une fois, RTFM!

 J’imagine même pas le matériel qui utilise les biblios de openssl et qui ne sont pas mis a jour par le constructeur.

Remarque ce serait pas la première fois.



Pendant que j’y suis











  Vincent a écrit :



Cette bibliothèque étant utilisée par une bonne part des distributions Gnu/Linux





<img data-src=" />

&nbsp;

Bon d’accord je m’en vais.









bagofgnutea a écrit :



&nbsp; Le coup des système configurer par défaut sans mot de passe c’est quand même fort les admin ne peuvent s’en prendre qu’a eux même, encore une fois, RTFM!

&nbsp;J’imagine même pas le matériel qui utilise les biblios de openssl et qui ne sont pas mis a jour par le constructeur.

Remarque ce serait pas la première fois.



Pendant que j’y suis







<img data-src=" />

&nbsp;

Bon d’accord je m’en vais.





D’un autre côté c’est quoi ces bases de données qu’on peut installer sans être forcés de changer le mot de passe par défaut, voire pire qui n’ont pas du tout d’authentification comme Elasticsearch (sauf si tu raques) ?&nbsp;



J’en ai fais les frais avec ElasticSearch sur ma DB de log pour mes tests. Rien de bien grave que c’est juste des logs NGINX de test mais c’est d’un chiant. En plus mine de rien installer un firewall devant Docker c’est hyper pénible à faire, j’en ai eu pour 20 commandes iptables pour avoir quelque chose de fonctionnel :(



Tout ca pour éviter qu’un petit rigolo me supprime mes données de test :(








&nbsp; Vincent a écrit :



Dans la plupart des cas, les systèmes vulnérables sont des distributions Linux équipées d’une mouture 3.x du noyau.





Peut-être des config trop moisie que personne ne veut se charger du patchwork, où alors continuent comme ça en attendant le clash pour aviser.

&nbsp;





Z-os a écrit :



Etonnant d’ailleurs qu’il n’y ait pas de ‘white hats’ qui te changent le mot de passe et t’informent du changement :-p





&nbsp;<img data-src=" />&nbsp;









bagofgnutea a écrit :



Le coup des système configurer par défaut sans mot de passe c’est quand même fort les admin ne peuvent s’en prendre qu’a eux même, encore une fois, RTFM!

 J’imagine même pas le matériel qui utilise les biblios de openssl et qui ne sont pas mis a jour par le constructeur.

Remarque ce serait pas la première fois.



Pendant que j’y suis







<img data-src=" />

 

Bon d’accord je m’en vais.







Pas forcément, le patron peut vouloir un accès au service, et peut trouver qu’un mot de passe c’est trop compliqué… vie de merde pour l’admin après..



Et proposer de stocker le mot de passe sur un stockage chiffré a été refusé car c’est “trop compliqué” ou “ça sert à rien” voir même “ça me fait plaisir que tu te préoccupes de la sécurité de l’entreprise, mais il n’y a pas besoin d’autant pour ça”.



C’est le même qui t’envoie appeler le support Ciel sans souscrire au contrat de maintenance, perte de temps.









trexmaster82 a écrit :



D’un autre côté c’est quoi ces bases de données qu’on peut installer sans être forcés de changer le mot de passe par défaut, voire pire qui n’ont pas du tout d’authentification comme Elasticsearch (sauf si tu raques) ?







+1. Ca devrait être une “bonne pratique” des produits qui installent un accès webadmin.



Installation par défaut = accès webadmin interdit, avec un message expliquant comment configurer un mot-de-passe pour autoriser l’accès.



Cela ne m’étonne guère…



Il y a une pléthore de commerciaux qui achètent des service web de la même manière qu’un produit dans un carton.



Souvent, ils pensent que tant que ça marche, c’est qu’il n’y a pas de problème. <img data-src=" />








trexmaster82 a écrit :



D’un autre côté c’est quoi ces bases de données qu’on peut installer sans être forcés de changer le mot de passe par défaut, voire pire qui n’ont pas du tout d’authentification comme Elasticsearch (sauf si tu raques) ?&nbsp;







1/ c’est quoi ces admins en cartons qui ne lisent pas la doc de ce qu’ils installent.



2/ T’accepterais de bosser gratuitement toi? Bon bah voilà ES est un produit développé par une vraie société, faut bien payer les employés.



Concernant ce chiffre, il faudrait voir la méthodologie utilisée pour déterminer si un serveur est vulnérable ou non…&nbsp; Selon que c’est basé sur un exploit où juste la version d’openssl détectée, ces résultats peuvent aller de très crédibles à pas trop crédible…

&nbsp;








trexmaster82 a écrit :



D’un autre côté c’est quoi ces bases de données qu’on peut installer sans être forcés de changer le mot de passe par défaut, voire pire qui n’ont pas du tout d’authentification comme Elasticsearch (sauf si tu raques) ?







Après tout dépend de l’utilisation. Dans mon entreprise j’ai installé Elasticsearch pour faire de l’aggrégation de logs. Elasticsearch, Logstash et Kibana tourne sur le même serveur, Kibana est protégé par une auth basic derrière un HTTPD. Ni Kibana, ni Elasticsearch n’écoutent sur l’exterieur, ils ne peuvent communiquer que en local. Dans ce cas, c’est pas forcément choquant de ne pas avoir d’authentification sur Elasticsearch.



J’ai également une base MongoDB, qu’on utilise que sur le réseau local, mettre en place l’authentification m’a pris 15 minutes, alors oui faut lire la doc, mais c’est pas compliqué, c’est de la négligence de ne pas le faire.



Quant à Heartbleed, tous ces Apache vulnérables, c’est de la négligence là encore, sur un Linux, n’importe quelle distribution suit les mises à jour de sécurité pendant des années, 5 ans pour une Ubuntu Server LTS, Debian a un suivi d’environ 5 ans, 10 ans même pour CentOS. Les gens ne font pas les mises à jour ?!









ForceRouge a écrit :



1/ c’est quoi ces admins en cartons qui ne lisent pas la doc de ce qu’ils installent.







Google: “hadoop install”



1ère réponse de Google:

“Apache Hadoop 2.7.2 – Hadoop: Setting up a Single Node Cluster.”

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/SingleCl…



Ce lien semble à la fois légitime à bien à propos.

Mais est-ce que ca te crée une installation sécurisée ?

et bhé… ptet bin qu’oui, ou ptet bin qu’non. J’attends ta réponse. <img data-src=" />










ForceRouge a écrit :



1/ c’est quoi ces admins en cartons qui ne lisent pas la doc de ce qu’ils installent.

2/ T’accepterais de bosser gratuitement toi? Bon bah voilà ES est un produit développé par une vraie société, faut bien payer les employés.





T’a pas mal de gens qui ne bossent pas au vrai prix surtout dans le web… Pas cool de “casser les prix” mais il faut bien manger et quelqu’un finira par faire le site alors bon… Quand tu vois que OVH te propose un hébergement à 15€ par mois pour un seul site et qu’il faut 15 minute pour créer une bdd… Qu’a côté de ça tu peut prendre un serveur chez online pour 10€ par mois et y installer 50 sites… Quand tu vois qu’un site coute 5k par une petite agence pour 3 pages, que les sites sont générés à tour de bras… Que tu peut avoir au moins aussi bien pour 3 fois moins cher par un indé…



Sans compter le fait qu’une personne qui à de très bonne compétence technique ira forcément voir le niveau du dessus… Un admin sys ne va pas s’amuser à ce mettre à son compte pour sécuriser des dédiés… Il n’ira pas non plus voir une petite agence mais une plus grosse boite “spécialisé”. Du coup dans chaque domaine tu web, t’aura souvent une personne moins qualifié qu’il le faudrait.

&nbsp;

Mais bon la “faille” est quand même limite il faut mieux une écoute des port purement local et ensuite débloquer une distante via la conf pour une seul ip pour au moins éviter des mauvaise surprises à ceux qui n’ont pas écrits de “bon tuto”.



ps : T’a aussi les installeurs qui peuvent être corrompues, ça arrive parfois chez online avec une faille béante à la clef <img data-src=" />









127.0.0.1 a écrit :



Google: “hadoop install”



1ère réponse de Google:

“Apache Hadoop 2.7.2 – Hadoop: Setting up a Single Node Cluster.”

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/SingleCl…



Ce lien semble à la fois légitime à bien à propos.

Mais est-ce que ca te crée une installation sécurisée ?

et bhé… ptet bin qu’oui, ou ptet bin qu’non. J’attends ta réponse. <img data-src=" />







Je ne “connais” pas hadoop. Dans le sens, je suis pas expert dans le domaine, mais c’est clairement pas sécurisé, y a déjà pas d’utilisateur dédié, ni de conf iptables. Et sans parler de la sécurisation même du soft.



Mais bon, “monter un cluster hadoop en 2mn chrono en spawnant des containers sur AWS”. Les gens y croient…



Pour faire la comparaison avec ce que je connais, le getting started d’Elasticsearch est juste du marketing “viendez voir comment c’est trop bien notre truc, toute la communauté le dis, et en plus c’et super facile” =&gt;https://www.elastic.co/guide/en/elasticsearch/reference/current/_installation.ht…



Après quand tu commences à t’en servir vraiment et que tu veux faire de la prod dessus, bah tu prends du support payant, ou tu lis la doc, ou les deux. Et c’est là où l’impasse est faite, avec les conséquence qu’on connait.



C’est une raison, mais elle est pas bonne dans le sens où quand on va à l’économie, bah faut pas s’attendre à des miracles :)