Tout savoir sur la faille de sécurité Heartbleed​

/Tout savoir sur la faille de sécurité Heartbleed​

Tout savoir sur la faille de sécurité Heartbleed​

La faille de sécurité Heartbleed, découverte le 7 avril 2014, est qualifiée comme la plus importante découverte à ce jour. Il s’agit d’un bug présent dans la bibliothèque OpenSSL. Il permet à un utilisateur malveillant de récupérer des données auxquelles il ne devrait pas avoir accès, directement depuis la mémoire d’OpenSSL. L’implémentation de la fonctionnalité Heartbeat en est responsable.

​Une faille de sécurité critique​

La vulnérabilité a été introduite en décembre 2011 lors d’une mise à jour sensée mettre en place une fonction de « heartbeat ». Non découverte pendant près de quatre ans, elle pose bon nombre de questions quant aux données potentiellement tombées entre les mains de hackers.​

Les risques potentiels

La première chose à savoir est que les données récupérables par l’exploitation de cette faille sont aléatoires. Elles proviennent de la mémoire du serveur et peuvent être inutiles, ou au contraire hautement stratégiques. En effet, la mémoire du serveur contient des données d’identification, des cookies de session,  des clés de chiffrement et d’autres données confidentielles.​

Le risque associé à cette faille est d’autant plus important que la récupération de données de cette manière laisse très peu de traces. Les attaques sont donc difficiles à détecter.​

Des cas avérés

Les géants du Web Google, Yahoo et Facebook ont été vulnérables, tout comme le système d’exploitation Androïd, mais il est difficile de savoir si des données ont été piratées.​

En outre, l’administration fiscale canadienne a annoncé le vol de 900 numéros d’assurance social, ce qui peut porter directement préjudice aux victimes en facilitant le recoupement de données personnelles.​

La découverte tardive de cette faille rend son impact très incertain.​

Les systèmes concernés

Tous les serveurs utilisant les versions 1.0.1 et 1.0.2 d’OpenSSL sont touchés. Un nombre conséquent de sites Web, PC, tablettes et Smartphones sont concernés.​​

Le protocole SSL/TLS, largement utilisé sur Internet pour sécuriser les communications de tout type (pages Web, emails, messagerie instantanée et même certains VPN) est implémenté par la bibliothèque gratuite et très utilisée OpenSSL. D’autres bibliothèques implémentent ce protocole et ne sont pas concernées par la faille.​

 Il ne s’agit pas ici d’un défaut de conception du protocole mais d’une erreur d’implémentation.​

Que doit faire la DSI ?​​

En premier lieu, il faut procéder à l’identification des sites vulnérables. Des outils disponibles en ligne permettent d’identifier les sites affectés. Si le test est négatif (site non affecté), cela ne signifie pas qu’il ne l’a jamais été.​

A ce jour, la communauté OpenSSL a publié des correctifs à déployer sur les serveurs utilisant OpenSSL afin de combler la faille.​

Concrètement, trois cas de figure se présentent :​

  • Lorsque qu’OpenSSL est utilisée de manière spécifique dans l’infrastructure applicative,  il est nécessaire d’appliquer les correctifs et de relancer les services susceptibles d’employer une ancienne version de la bibliothèque.​
  • Dans le cas d’un progiciel, il convient de se rapprocher de l’éditeur.​
  • Enfin, dans le cas d’un service Cloud utilisant potentiellement cette bibliothèque, il faut contacter le fournisseur.​

En plus du déploiement des correctifs, parmi les mesures à envisager figurent, :

  • la révocation des clés de chiffrement et distribution de nouvelles clés,​
  • la réinitialisation des logins et mots de passe,​
  • l’invalidation des clés de session et des cookies.​

​La faille en détails​

La bibliothèque de cryptographie Open source OpenSSL est à l’origine de la faille. Très largement utilisée sur le Web, OpenSSL implémente la fonctionnalité heartbeat de la façon suivante.​

L’implémentation du mécanisme « heartbeat » en cause

OpenSSL utilise le principe de battements de cœur (« heartbeat ») qui permet de s’assurer  que  les deux machines (client et serveur) sont bien actives. Ce mécanisme permet de garder une session ouverte sans qu’il n’y ai d’opération spécifique d’envoi de données.​

Concrètement l’ordinateur client envoie une requête heartbeat au serveur avec deux paramètres : des données  et leur taille. En réponse, le serveur est sensé renvoyer ces mêmes données.​

Pour se faire, il charge en mémoire la quantité de données correspondant à la taille indiquée avant de les renvoyer. C’est ici que se situe la faille. Avec une telle implémentation, le serveur fait aveuglément confiance au client quant à la taille des données à renvoyer. Un client malveillant peut alors indiquer une taille qui ne correspond pas à celle des données réellement envoyées et ainsi simuler un envoi plus volumineux (jusqu’à 64k). Le client reçoit donc des données stockées en mémoire sur le serveur, qui ne lui appartiennent pas et dont il n’est pas sensé avoir connaissance.​

Ce procédé ne laisse aucune trace dans les logs puisqu’il n’y a pas d’intrusion. Cela est considéré comme étant un fonctionnement normal.​

Schema faille Heartbleed

Cinématique d’exploitation de la faille Heartbleed

Un « saignement de cœur »

Une telle manipulation répétée plusieurs fois consécutivement permet à un hacker de récupérer des données en masse et donc de faire « saigner » le serveur, d’où le nom « heartbleed ».

Une erreur classique en langage C

Il s’agit donc du non respect d’une règle fondamentale de développement qui consiste à ne jamais se fier aux informations reçues. Un oubli qui se transforme en faille critique, du fait de l’ampleur de déploiement d’OpenSSL dans le monde du Web.

By | 2018-05-03T18:29:11+00:00 avril 24th, 2018|Categories: Fiche Thématique, Sécurité|Tags: |0 Comments

About the Author:

Leave A Comment

Artik Consulting / Informations de contact

40 Rue d'Oradour-sur-Glane 75015 Paris

Phone: 01 84 06 36 09

Fax: 09 82 63 63 58