Un peu de vulgarisation pour comprendre la faille de sécurité Heartbleed
Voila quelques jours qu’on nous fait flipper avec un bug décrit parfois comme apocalyptique (je n’ai pas encore vu les émeutes, pillages, morts, zombies d’une apocalypse digne de ce nom)… Pire que le bug de l’an 2000 à ce qu’il parait (souvenons nous que ce fameux bug de l’an 2000 nous en a touché une sans faire bouger l’autre comme dirait Chichi… Je paris qu’il en sera de même pour l’XPocalypse, qui a fait les choux gras de la presse spécialisée ces dernières semaines ;-).
Pour en revenir à Heartbleed… Bien compliqué cette histoire… Un bug qui existerait depuis 2012 sans qu’on le sache, sans que les grosses têtes en sécurité informatique ne donnent l’alerte.
Bref, si cette actu a été largement commentée dans les sites hightech/geek c’est sur Wikipedia qu’elle est le mieux vulgarisée et que j’ai le mieux compris comment fonctionne cette faille de sécurité.
image via : lemagit.fr
Ainsi, il est possible de se faire piquer nos identifiants et données personnelles enregistrées sur un service web que l’on utilise si ce service web est hébergé sur un serveur qui présente la faille Heartbleed. Il suffit à un bonhomme mal attentionné d’attaquer le serveur en question pour récupérer ces données…
Attaquer le serveur? Ça veut dire quoi ça?
Pour vulgariser, disons que la faille de sécurité touche la librairie Open SSL, un truc qui permet notamment d’effectuer des connexions dites “sécurisées” avec un site web (vous savez quand l’URL commence par HTTPS). Une fonctionnalité appelée Heartbeat, permet d’envoyer des messages en permanence au serveur tant qu’on est connecté à son site web sécurisé préféré pour garder la connexion active : le client (votre ordinateur) envoi un paquet de données pour interroger le serveur et lui signifier qu’on est encore connecté en indiquant dans ces paquets des infos telles que la taille du paquet de manière à ce que le serveur réponde par des paquets de données identiques et équivalents… comme un ping quoi…
Et bien que se passe-t-il si le client prétend avoir envoyé pleins de bytes alors qu’il en a envoyé qu’1? La réponse et con, comme le serveur doit envoyer des paquets équivalents à ceux reçu, il complète avec d’autres infos présentes sur ses disques quitte à renvoyer des infos confidentielles… CQFD.
Vous l’aurez compris, cela ne sert à rien de changer vos identifiants sur vos services web préférés tant que les serveurs de ces sites ne sont pas encore sécurisés car ils seront toujours récupérables par un hacker. Par contre, dès que le bug est corrigé les dits serveurs, il faut vite modifier des fois qu’ils auraient été piqués et avant qu’ils n’aient été utilisés.
Voila pourquoi certains se sont amusés à recenser les sites qui ont déjà mis à jour leur système et sur lesquels on peut/doit pertinemment et sans risques modifier nos identifiants.
Pas évident de vulgariser un truc pareil. Voila en BD, le principe de ce genre d’attaque si mes explications restent encore floues :
via : XKCD
"Vous l’aurez compris, cela ne sert à rien de changer vos identifiants sur vos services web préférés tant que les serveurs de ces sites ne sont pas encore sécurisés"
RépondreSupprimerNon seulement cela ne sert à rien, mais c'est même franchement déconseillé !
Le problème avec cette faille, c'est qu'elle permet de récupérer jusqu'à 64K de la RAM du serveur web exécutant SSL sans laisser la moindre trace.
Autant dire qu'il est plus prudent de ne pas vous connecter à votre compte sur les sites n'ayant pas encore remédié au problème afin d'éviter que vos informations de connexion ne circulent en RAM.
merci de la précision WIL
Supprimer