Comment expliquer Heartbleed sans termes techniques?
La plupart de mes amis qui n'ont pas d'expérience en informatique veulent savoir ce qu'est Heartbleed et comment cela fonctionne. Comment expliquer Heartbleed à une personne sans formation technique?
L'analogie de la banque et de l'employé de banque
Vous appelez la banque pour demander un nouveau compte bancaire, pour prendre rendez-vous - peu importe. D'une manière ou d'une autre, vous et la banque vous assurez que vous êtes bien qui vous êtes, et la banque est en fait la banque. Il s'agit du processus TLS qui sécurise la connexion entre vous et la banque, et nous supposons que cela est géré correctement.
Les rôles dans cette pièce
- La banque: un serveur web
- L'employé de banque: le service OpenSSL pour ce serveur
- Vous (le voleur de banque): un bot qui récupère tout ce qu'il peut obtenir de ce serveur
Rester connecté - le rythme cardiaque
Un employé de banque répond à votre appel. Vous demandez des informations. L'employé dit d'attendre une minute et désactive son microphone. Il peut vous entendre, vous ne pouvez pas l'entendre. Ensuite, c'est calme. Pendant longtemps. Vous commencez à vous demander s'il a raccroché. Alors tu dis "bonjour?" L'employé est invité à faire écho à tout ce que vous dites et répond par "bonjour". C'est le battement de cœur pour vérifier s'il y a toujours une connexion.
Maintenant, avec cet employé de banque particulier, vous devez d'abord dire combien de mots vous allez utiliser avant de demander si l'employé est toujours en ligne. Donc, au lieu de dire "bonjour", vous devez dire "un: bonjour" ou "deux: bonjour là". L'employé sait maintenant qu'il peut répondre en répétant ces (premiers) deux mots, puis peut continuer à travailler sur votre demande. Ceci est le protocole du rythme cardiaque.
Le problème - le cœur perdu - aucun contrôle sur ce qui est retourné
OK, vous vous ennuyez et vous faites une blague. Vous dites "mille: bonjour". L'employé ne vérifie pas que vous n'avez dit qu'un seul mot (bonjour) et commence à répondre avec "bonjour" plus les 999 mots suivants qu'il dit, pense ou a en mémoire avant de mettre le micro hors tension. C'est le bogue qui cause le problème.
Ces 999 mots sont sans rapport. La plupart seront inutiles, des remarques sur la météo, une demande de café, des rendez-vous pour le déjeuner, etc. Certaines peuvent être des informations importantes sur la banque ou d'autres clients. Un transport d'or, un client va rapporter 1 million de dollars, le code d'accès à la banque ou au coffre-fort, etc.
Il n'y a pas de vérification s'il y a réellement 1000 mots à répondre. De plus, vous pouvez faire cette demande encore et encore - l'employé ne se plaindra pas et personne d'autre ne remarquera ce qui se passe.
Il y a une limite. Vous obtiendrez uniquement des informations de cet employé de la banque, et uniquement les choses dont il parle ou pense. Les autres employés ne sont pas concernés. Vous ne pouvez pas voir ce qu'il y a sur son bureau ou dans son rolodex. (Analogie: seules les données en mémoire (RAM) sont en danger; les données du disque dur qui ne sont pas lues en mémoire et les données d'autres programmes et processus sont en sécurité.)
En faisant cela, vous ne savez pas quelles informations vous obtiendrez, mais en le faisant encore et encore et encore, vous obtiendrez suffisamment d'informations pour enfin pouvoir pénétrer sans que personne ne le remarque. Vous pouvez entrer dans la banque après les heures d'ouverture, ouvrir le coffre-fort, etc. C'est le risque encouru.
La solution - vérifier la demande et renouveler les codes
Si l'employé réfléchissait un instant, il ne répondrait qu'avec un seul mot, puis désactiverait le microphone pour que vous n'entendiez plus de quoi il parle. En effectuant cette vérification, vous resterez connecté et vous saurez que l'employé n'a pas raccroché, mais n'entendra plus d'informations aléatoires. En effet, l'employé a besoin de nouvelles instructions sur ce qu'il doit faire écho. Ce problème est résolu avec la mise à jour vers la dernière version d'OpenSSL.
La banque devra renouveler les clés de sécurité pour entrer dans la banque et le coffre-fort, car on ne sait pas si quelqu'un a les anciens codes.
Je vais devoir utiliser quelques termes techniques, mais j'essaierai de les garder au minimum et de les décrire.
Introduction de base à TLS et au chiffrement
Vous (un client) accédez à un site Web (appelé serveur) qui utilise le cryptage (l'adresse commence par https://) Pour que personne d'autre que vous et le site Web à l'autre bout ne puissent connaître le contenu de les messages que vous envoyez ou recevez. Ainsi, lorsque vos messages sont transportés sur des ordinateurs sur Internet, ils sont chiffrés - ils appellent cette sécurité de couche de transport (TLS) et il s'agit d'un type de protocole chiffré. Une bibliothèque qui implémente TLS est OpenSSL (TLS est le nom le plus récent de SSL, mais les deux ont la même intention - crypter le trafic réseau sur Internet).
Qu'est-ce que Heartbeat - la fonctionnalité TLS compromise?
Pour configurer une connexion TLS, une négociation est relativement coûteuse (cela prend du temps). Plusieurs messages doivent être échangés entre le client et le serveur avant de pouvoir se faire mutuellement confiance et envoyer en toute sécurité des données chiffrées dans les deux sens. Pour avoir une expérience rapide et réactive (et minimiser la charge du serveur), vous souhaitez effectuer cette négociation rarement lorsque cela est possible, plutôt que de le faire avant chaque demande unique (car vous effectuerez souvent des centaines de demandes en quelques minutes avec des sites Web interactifs modernes). Pour compliquer les choses, les paquets sur Internet sont souvent perdus ou corrompus. Le serveur peut être submergé par trop de demandes et doit abandonner sa fin de connexion TLS. Ou le client peut avoir fermé sa fenêtre de navigateur, de sorte que le serveur n'a pas besoin de continuer à stocker sa fin de connexion cryptée.
Ainsi, en 2012, une proposition a été mise en œuvre dans OpenSSL (appelée Heartbeats) pour envoyer des messages "persistants" entre le client et le serveur afin de réduire le nombre de négociations, lorsque les deux extrémités utilisent toujours la connexion. Le client demande périodiquement au serveur Web "Êtes-vous toujours là?" et le serveur Web (s'il est toujours là), des réponses indiquant s'il est toujours là ou si les demandes futures nécessitent une nouvelle négociation TLS.
Fonctionnement de l'extension Heartbeat
Le client envoie un message Heartbeat composé d'une charge utile choisie par le client, ainsi qu'un bref en-tête contenant la taille de la charge utile. Par exemple, vous pouvez envoyer une demande Heartbeat de taille 18 Et de texte This is my payload (Bien que ce soient généralement des données choisies au hasard). Le serveur Web obtient cette demande, enregistre le contenu de la charge utile dans la mémoire du serveur Web, ainsi que la taille de la charge utile 18 Que le client lui a indiquée.
Ensuite, lorsque le serveur renvoie une réponse "keep-alive" au client, la bibliothèque lit les caractères de mémoire 18 Suivants à partir de l'endroit où elle a stocké la charge utile et la renvoie au client (qui vérifie qu'ils reçu les bonnes données) et la connexion est maintenue.
La faille Heartbleed dans OpenSSL
La faille fatale (qui a été nommée Heartbleed) est que la bibliothèque OpenSSL n'a jamais vérifié que la taille de la charge utile Heartbeat correspond à la longueur réelle de la charge utile envoyée . Un utilisateur est autorisé à saisir n'importe quel nombre jusqu'à 65 535 (64 kilo-octets) quelle que soit la taille réelle de la charge utile. Si un attaquant envoie une demande Heartbeat disant que la taille est 65535, Mais qu'une charge utile de seulement 18 octets, le serveur vulnérable ne stockera que 18 octets en mémoire. Cependant, la réponse commencera avec les 18 octets stockés, mais continuera à renvoyer les données des 64 Ko de mémoire suivants au client. Ces données peuvent être des noms d'utilisateur et des mots de passe, des clés privées, un nom d'utilisateur, des pages HTML, des fichiers indésirables ou même le secret privé que le serveur Web utilise pour établir son identité. (Le correctif pour OpenSSL implémenté dans 1.0.1g et les versions ultérieures consiste essentiellement à effectuer des vérifications d'intégrité sur la taille de la charge utile comme indiqué par le client).
L'attaque peut être répétée plusieurs fois et en général, elle révélera à chaque fois différentes parties de la mémoire du serveur Web. L'attaque peut être effectuée de manière anonyme de manière indétectable pour les configurations de serveur Web typiques. En règle générale, vous ne connectez les adresses IP que lorsque vous diffusez une page Web, mais cette attaque peut se produire au début du processus de négociation dans les versions vulnérables, avant la diffusion d'une page Web.
Attaque sur les clients
Il existe également une version inverse de cela, où un utilisateur se connectant à un serveur TLS malveillant fera confiance à la demande de maintien en vie envoyée à partir d'un serveur malveillant où le serveur a menti sur la taille de sa charge utile persistante. Cela entraînerait une fuite jusqu'à 64 Ko d'informations du navigateur Web sur le serveur Web. (Certes, il serait beaucoup plus difficile d'en obtenir des informations utilisables et ne peut pas être fait de manière anonyme et doit être initié par le client choisissant d'accéder à cette page Web. Cependant, il est toujours logique de patcher OpenSSL rapidement si vous naviguez sur le Web avec un version affectée.)
Remède
Le remède pour les clients et serveurs qui utilisent OpenSSL est de le mettre à jour. Les administrateurs système qui exécutent des serveurs Web qui utilisent la bibliothèque OpenSSL vulnérable doivent révoquer leurs clés TLS secrètes et en générer de nouvelles (ainsi qu'invalider les jetons de session longue durée). Les clients doivent modifier leurs mots de passe sur les sites Web concernés, qui peuvent avoir été divulgués. Pour les clients, lastpass a publié un Heartbleed checker tool qui teste si un site est (1) actuellement vulnérable, (2) précédemment testé pour être vulnérable, ou (3) probablement vulnérable (en utilisant un serveur web unix/linux et TLS, indiquant probablement l'utilisation d'OpenSSL qui est principalement utilisé sur les systèmes unix/linux), ce qui peut aider à déterminer si vous devez mettre à jour votre mot de passe sur un site Web donné.
SSH n'est pas TLS donc les clés SSH sont sûres
SSH (qui signifie Secure Shell) est un outil courant sur les machines Unix et Linux, permettant aux utilisateurs de se connecter à distance à une machine et d'émettre des commandes qui sont transportées sur le réseau cryptées. SSH est un protocole entièrement différent de TLS (la réponse dit SSL, mais ce n'est que l'ancien nom de TLS - les termes sont souvent utilisés de manière interchangeable) . Même si OpenSSH (l'implémentation la plus courante de SSH) et OpenSSL ont des noms similaires, vos clés SSH ne sont pas vulnérables en raison de l'attaque Heartbleed.
Seule la mémoire du processus qui effectue le chiffrement TLS peut être divulguée par l'attaque Heartbleed. (Un processus est le terme informatique pour une instance en cours d'exécution d'une application.) Les systèmes d'exploitation modernes implémentent isolation de processus qui empêche les processus de lire ou d'écrire la mémoire affectée à d'autres processus sur le même système. Donc contrairement à xkcd.com/135 vous n'avez pas à vous soucier de la mémoire de votre ordinateur qui soit compromise, juste la mémoire du processus du serveur web (ou le navigateur web pour la forme inverse). Les secrets comme les clés SSH utilisées par d'autres processus (ssh, sshd, ssh-agent) ne sont pas divulgués car vous avez également utilisé TLS dans un serveur Web.
Pour être complet, je dois mentionner que cette vulnérabilité devrait affecter tout ce qui peut utiliser la bibliothèque OpenSSL pour exécuter TLS, qui n'est pas limité aux serveurs Web; Par exemple, les serveurs FTPS (mais pas SFTP), les serveurs de messagerie, les serveurs de base de données peuvent tous être vulnérables en fonction de la configuration.
Plus d'informations sur le commit vulnérable
Il convient également de noter que la même personne qui a écrit le code vulnérable qui ne vérifie pas la taille de la charge utile était le même auteur de l'extension Heartbeat à TLS (décrite dans RFC 652 ). Notez que le protocole n'a pas spécifié de taille maximale de réponse Heartbeats (tout en spécifiant une taille minimale), mais lui a permis d'être de longueur arbitraire et de laisser la taille de la charge utile être décrite par un en-tête de deux octets (lui permettant d'aller jusqu'à 65 535 au lieu de seulement 255 avec un en-tête de 1 octet, qui n'aurait exposé que sous 255 octets de la RAM des processus du serveur Web). Honnêtement, je ne peux pas penser à une raison raisonnable d'exiger une charge utile de battements de cœur qui dépasse 16 octets (128 bits), et si vous vouliez être super paranoïaque, vous pourriez la laisser être 32 octets (256 bits). Avec ces limites, il serait très peu probable de divulguer beaucoup d'informations utilisables.
Il est également curieux que le code vulnérable soit daté du soir du réveillon du Nouvel An 2011, ce qui semble être un moment probable pour passer quelque chose sous le radar ou avec moins de contrôle en raison des vacances.
En anglais très simple: l'attaquant dit qu'il envoie un paquet de taille "x" et demande au serveur de le renvoyer, mais envoie en fait un paquet beaucoup plus petit. La bibliothèque OpenSSL fait confiance à l'attaquant, renvoie le petit paquet réel au début de la réponse, puis récupère les données de la mémoire pour remplir la réponse à la taille attendue. Il peut s'agir de toutes les données que le serveur a traitées récemment et qui contiennent souvent des informations sensibles.
Cet exemple de dialogue - vous êtes peut-être tous les deux des personnages, ou vous leur demandez de vous poser les questions suivantes:
Q1: Quelle est votre couleur préférée (1 mot)
A1: BleuQ2: Où êtes-vous allé en vacances pour la dernière fois (2 mots)
A2: En FranceQ3: Quelle voiture conduisez-vous (1000 mots)
A3: Opel Astra. Cheeseburger. Demain, je conduis à Londres. J'aime le gâteau. Ohhh un écureuil. Mon PIN est 1234. J'aime les poulets. SPAAAACEEEE. Hier soir, j'ai mangé des spaghettis. BUD WEIS EEEEERRRR. Etc etc etc
Ce dernier morceau est principalement des ordures, mais il pourrait y avoir quelques bonnes choses là-dedans.
Voici une tentative d'utiliser presque aucun jargon.
Lorsque vous vous connectez à un site Web "sécurisé" (un avec une barre verte et une icône de cadenas), votre navigateur et le site Web effectuent un peu de mise au point mathématique et vous vous retrouvez tous les deux avec une clé secrète - comme un mot de passe aléatoire très long - avec lequel vous pouvez vous envoyer des messages cryptés.
Lorsque vous parcourez le site et cliquez sur des liens, il serait très coûteux de refaire tout le hocus-pocus à chaque fois, de sorte que le site Web et le navigateur continuent à utiliser la même clé pendant un certain temps. Étant donné que le site Web ne souhaite pas conserver une liste de toutes les clés que chaque visiteur a jamais utilisées, un protocole appelé battement de cœur a été inventé. Tant que vous naviguez toujours, votre navigateur envoie de temps en temps un message au site Web disant HEARTBEAT, ce qui signifie "Je suis toujours là, gardez ma clé". Le site Web répond quelque chose à l'effet de "roger cela". Si le site Web n'entend aucun battement de cœur de votre part pendant un certain temps, il suppose que vous êtes allé sur un autre site et jette votre clé pour faire de la place pour de nouveaux.
En fait, les battements cardiaques font encore une chose. Vous pouvez envoyer n'importe quel texte que vous aimez avec eux et le site Web vous répondra exactement avec le même texte. La raison pour laquelle cela est fait de cette façon n'est pas très claire pour moi, je suppose que c'est pour que votre navigateur puisse vérifier si quelque chose de drôle se passe (comme le mauvais texte qui revient, ou les textes qui reviennent dans le mauvais ordre) et vous faire savoir que quelqu'un peut faire quelque chose de méchant.
Votre navigateur envoie donc de temps en temps un message comme "HEARTBEAT, texte à 5 lettres, BONJOUR" et le site Web répond "roger that, 5 lettres, BONJOUR". Le texte peut être à peu près n'importe quoi, comme la date et l'heure actuelles. Vous pouvez envoyer un poème si vous le souhaitez.
Le bug de cœur est que si vous envoyez un message comme "HEARTBEAT, 1000 lettres, CHEESE", alors si le site Web utilise un programme appelé OpenSSL pour faire le cryptage, il se passe très mal. Et OpenSSL est en quelque sorte le programme le plus couramment utilisé pour effectuer le cryptage sur Internet. Ce qu'il doit faire, c'est remarquer que CHEESE a 6 lettres, pas 1000, et se plaindre. Au lieu de cela, il lit votre message et l'écrit quelque part dans sa mémoire. Ensuite, il répond "roger that, 1000 lettres, ..." et commence à lire les 1000 lettres suivantes de sa mémoire à partir de l'endroit où il a stocké votre FROMAGE. Vous pouvez donc entendre quelles que soient les 994 prochaines lettres dans sa mémoire, et cela pourrait être n'importe quoi. Il pourrait s'agir des clés secrètes du site Web. Ce pourrait être un poème. Il peut s'agir des mots de passe et des détails de carte de crédit d'autres clients. Ce pourrait être une photo d'un chat. C'est complètement aléatoire, mais chaque fois que vous envoyez un message HEARTBEAT comme celui-ci, vous pouvez voir une partie aléatoire différente de la mémoire du site Web, donc si vous répétez juste assez souvent vos HEARTBEATs, vous risquez de frapper quelque chose d'intéressant tôt ou tard.
Le pire qui puisse arriver est que vous récupériez les clés principales du site Web, celles utilisées pour démarrer le hocus-pocus chaque fois qu'un nouveau visiteur arrive sur le site. Si vous faites cela, vous pouvez en théorie lire tout ce que tout le monde fait sur le site, comme s'il n'y avait aucun chiffrement. Chaque fois que quelqu'un se connecte, vous pouvez voir son mot de passe en clair. Ce n'est pas une bonne chose à se produire.
Je vais utiliser unedeux trois termes techniques, "battement de cœur", "bogue" et "serveur Web". J'espère que cela ne fera pas peur à vos amis non techniques.
Lorsque les ordinateurs échangent des données sur Internet, il est parfois utile de savoir si l'autre écoute toujours. Dans de nombreux endroits, il existe des dispositions pour faire l'équivalent de demander "Hé, tu écoutes? Pouvez-vous me dire ce que je viens de dire?" Dans différents contextes, il existe de nombreux noms différents pour de telles techniques qui apparaissent même parfois dans les médias grand public --- "écho" en est un, "cingle" un autre, et celui qui a un bug grave dans un logiciel très largement utilisé est "rythme cardiaque". Ce schéma particulier de "battement de coeur" n'est pas réellement utilisé dans de nombreuses applications, mais parce que l'idée générale peut être si utile, de nombreux ordinateurs le permettent.
Le problème est qu'un logiciel utilisé par la plupart des serveurs Web a un bogue: selon la façon dont le message "Qu'est-ce que je viens de vous dire?" est demandé, il peut être trompé en essayant de répéter plus que ce que l'autre partie avait réellement envoyé, en remplissant le reste avec des choses aléatoires que le serveur Web sait. En posant une question aussi délicate, on peut demander aux serveurs Web avec ce bogue de dire presque tout ce qu'ils savent, y compris les mots de passe des utilisateurs et (à partir des serveurs Web qui gèrent ces informations) des données sensibles comme les numéros de carte de crédit, le contenu des e-mails, etc. ne vous arrêtez pas là, même les secrets avec lesquels d'autres ordinateurs pourraient se faire passer pour ces serveurs Web sont en danger.
Ce n'est pas limité aux serveurs Web, mais c'est là que toute personne utilisant Internet entre en contact avec lui. Mais les gens de la sécurité informatique ont désormais les mains pleines avec de nombreux ordinateurs et de nombreux logiciels différents qui peuvent être affectés.
Lorsque vous visitez une page Web qui utilise "https", la connexion entre vous et le serveur Web est cryptée. Cette couche de protection est appelée SSL ou TLS. Un composant sous-jacent de cette implémentation présente un problème de sécurité - provoquant une fuite de données du serveur qui sert une page Web (c'est-à-dire divulgation du contenu de la mémoire à un attaquant). Il existe certaines contraintes sur la façon dont ces données sont divulguées, mais elles sont très graves et pourraient exposer toutes sortes de données sur le serveur vulnérable.
Voici une vidéo technique qui montre un exemple de fuite de données d'un serveur vulnérable et montre également comment empêcher la fuite de données: https://www.youtube.com/watch?v=UjkK22VBzjA
Nouvelle analogie:
Imaginez que vous appelez la banque pour lui demander si l'un de ses bureaux est ouvert. Vous obtenez une machine en ligne (l'infâme "pour l'anglais, appuyez sur 1" dame) et il vous demande combien de banques vous voulez connaître les heures et pour quelles banques. Vous dites ensuite que vous voulez les heures pour 65 000 banques, mais ne lui donnez que le code d'une seule banque. La machine pense qu'elle doit donner les heures pour 65 000 banques, mais comme vous ne donnez qu'un seul code bancaire, elle remplit le reste avec tout ce qu'elle peut trouver: relevés bancaires de comptes aléatoires, numéros et codes de carte de crédit, photo de la clé pour le coffre-fort, la discussion que le manager a eu à l'époque avec son médecin, ... Il ne se rend pas compte que ces autres données ne sont pas pertinentes, et que vous n'auriez dû avoir que les heures d'ouverture pour 1 banque.
Ancienne réponse:
Imaginez que votre banque dispose d'un système où vous pouvez envoyer une demande sécurisée pour le code PIN actuel de votre carte de débit, et le système renvoie un code PIN et un numéro de carte bancaire. Ce système obtient une mise à jour où vous pouvez envoyer une liste de cartes à réinitialiser.
Vous envoyez une demande de liste de 65 535 cartes de débit à réinitialiser, mais ne transmettez qu'un seul numéro de carte. Au lieu de renvoyer uniquement cette seule carte ou de renvoyer une erreur, votre banque renvoie les codes existants pour 65 534 autres cartes provenant d'autres utilisateurs aléatoires.
Imaginez un livre que vous n'avez jamais lu et dont vous ne connaissez pas le contenu, car le livre est fermé, le bug de cœur, n'est qu'un moyen d'ouvrir une page au hasard et de pouvoir lire le texte du livre. après avoir extrait suffisamment d'informations, vous pouvez reproduire le livre et le replacer dans un abri sans que personne ne puisse le remarquer. Le livre étant soit votre ordinateur, soit votre serveur.
Ce serait l'explication la plus simple que je donnerais aux personnes non techniques.
C'est comme ça.
Vous marchez le long de la rue et, en passant l'entrée d'une banque, vous rencontrez un savant autiste en sortant. Il semble être un gars sympa, mais vous ne l'êtes pas, et vous savez que vous pouvez l'utiliser à des fins néfastes, car vous avez regardé suffisamment de films pour avoir appris que les savants peuvent conserver et répéter des quantités incroyables de données et sont généralement assez observateurs, aussi.
Alors, vous lui demandez l'heure. Il vous indique l'heure, mais ne peut s'empêcher de continuer à parler. Il vous indique chaque numéro de compte bancaire et mot de passe qui lui sont passés par les yeux et les oreilles pendant qu'il y était.
Cette information est maintenant la vôtre. Tout ce que vous aviez à faire était de demander l'heure parce que, en raison de son état, le savant ne pouvait pas s'empêcher de vous dire plus qu'il n'était supposé le faire. Ce qu'il ne se rend pas compte, c'est qu'en demandant le temps avec vos objectifs néfastes, puisque vous saviez ce qui allait probablement se produire, vous demandiez plus que ce que vous étiez censé également.
Pauvre gars.