Coup de semonce sur Internet. La faille « Heartbleed » identifiée dans la librairie OpenSSL permet de récupérer à distance des données présentes en mémoire depuis un serveur vulnérable.
une belle fuite de données
La faille « Heartbleed » est provoquée par une erreur au niveau de la fonction de « heartbeat » entre un client et un serveur SSL. Cette fonction de « heartbeat » a été introduite afin de permettre à un client et serveur de maintenir active une connexion SSL même dans le cas où aucune donnée n’est à transmettre.
Dans cette fonction de « heartbeat », le client envoie un certain volume de données vers le serveur ; ce dernier les renvoie ensuite vers le client. Cet « aller-retour » permet de vérifier que la connexion est bien opérationnelle.
La faille se trouve du côté du serveur. Celui-ci ne vérifie pas que le nombre de données indiqué par le client correspond effectivement à celui envoyé… un client peut donc envoyer 2000 octets de données et indiquer en avoir envoyé 64.000…. le serveur renverra vers le client les 2000 octets reçus du client + 62.000 octets récupérés de sa mémoire…
Dans ces 62.000 octets, il peut y avoir des données sensibles comme des cookies, des mots de passe, ….
Pour ceux qui veulent plus d’explications, ils ont l’article de Naked Security (très clair), celui de ARS Technica mais aussi celui de Existentialize (détaillé). Les curieux pourront aller voir sur GitHub le commit qui a inséré le bug.
des services et scripts pour tester si un site est vulnérable
Pour tester si vos sites et serveurs sont vulnérables à la faille « heartbleed », il y a des services en ligne comme celui de Filippo.io ou alors ; pour un test plus complet ; le SSL Labs de Qualys. Dans la catégorie des services simples il y aussi SubMeet et Possible.lv (…).
Des scripts sont aussi disponibles. Sous GitHub, on trouve des scripts en langage Python (« mitsuhiko », « takeshixx » et surtout « mothran ») mais aussi en langage Go ( « titanous »).
autres outils de détection et d’identification
Des signatures permettant de détecter si quelqu’un tente d’attaquer vos serveurs web sont disponibles à cette page. Il y a aussi l’outil Masscan qui permet de scanner un ensemble de serveurs pour identifier ceux qui sont vulnérables. Des signatures pour des scanners de détection de vulnérabilité comme Tenable ou OpenVAS sont aussi disponibles.
pas uniquement les serveurs web
Attention à ne pas faire l’erreur de ne prendre en compte que les serveurs Web. En effet, la librairie OpenSSL est utilisée pour sécuriser de nombreux services comme les emails (SMTPS/SMTP +STARTTLS, POPs/IMAPS) mais aussi les messageries instantanées (XMPP). On la retrouve dans les équilibreurs de charge (Load-Balancers) et les passerelles d’accès distant (VPN-SSL) et dans encore plus d’autres systèmes et logiciels.
que faut-il en retirer sur le long terme ?
Eviter la monoculture en utilisant d’autres librairies que OpenSSL : Il y a Botan et GNUTLS. Les entreprises devraient financer les projets OpenSource comme OpenSSL. C’est un enjeu business que d’avoir des librairies de chiffrement performantes et exemptes de failles de sécurité. Se reposer sur « la communauté » pour sécuriser ses services, ses données et celles de ses clients n’est-elle pas un peu « cavalier », voire même inconscient ?
Le financement pourrait être effectué de façon directe (typiquement en passant via une fondation comme la fondation GNU, ….), en proposant des « bug-bounties » comme le font les grands acteurs comme Google ou Microsoft afin d’encourager les chercheurs en sécurité. Ou alors, en dégageant du temps auprès de leurs employés pour qu’ils puissent travailler sur ces librairies durant leur temps de travail.
Jean-François Audenard (aka Jeff)
Crédit photo : © veroji - Fotolia.com
Au sein de la direction sécurité du Groupe Orange, je suis en charge de la veille sécurité et de la sensibilisation à la sécurité. Franchise, optimisme et bonne-humeur sont mes moteurs quotidiens