Mises à jour 2014-04-11
Cloudflare a mis en place un défi pour vérifier que l'extraction de clés privées était effectivement possible. Cela a été fait avec environ 100 000 requêtes, et cela vérifie les craintes. Ce n'est plus théorique, mais prouvé . Vous pouvez aller aquí pour le lire.
Aussi, Bloomberg a signalé que le NSA connaissent cet exploit depuis au moins deux ans . C'est logique puisque la NSA a les moyens d'engager des analystes dont le seul travail est de trouver des exploits dans des logiciels comme celui-ci. Maintenant que nous savons que le gouvernement américain l'exploite depuis si longtemps, la probabilité que d'autres États le sachent et l'exploitent est importante.
TL;DR Surveillez les annonces des organisations concernant l'état de leurs systèmes, les changements TOUTES de vos mots de passe, et surveillez les activités frauduleuses/suspectes sur les comptes importants tels que les systèmes bancaires ou autres systèmes financiers.
Pour comprendre pourquoi la situation est si dangereuse, il faut d'abord comprendre ce que fait réellement cette attaque. CVE-2014-0160, alias Heartbleed, est un bogue de dépassement de tampon qui permet à un attaquant d'obtenir jusqu'à 64 kB de mémoire d'un serveur exécutant une version vulnérable d'OpenSSL.
Ça a l'air vraiment mauvais. Comment cela fonctionne-t-il en pratique
Vous avez raison, c'est un défaut grave, mais nous y reviendrons un peu plus tard. Pour l'instant, parlons de la raison pour laquelle l'exploit fonctionne. Sécurité de la couche transport (TLS) est utilisé pour sécuriser les informations par de nombreuses applications, notamment HTTP ( HTTPS ) ou pour sécuriser SMTP si elle est activée, par exemple. Dans la RFC 5246, qui établit les normes pour TLS, il y a une fonction connue sous le nom de heartbeat. Le client et le serveur envoient des données dans les deux sens afin de maintenir la connexion en vie et de pouvoir l'utiliser ultérieurement. Dans la pratique, le client envoie des données et le serveur les renvoie, et tout va bien. Cependant, dans les versions d'OpenSSL concernées, il n'y a pas de vérification pour voir si le client a réellement envoyé la quantité de données qu'il a dit avoir envoyée. Ainsi, si j'envoie 1 octet et que je dis au serveur que j'ai réellement envoyé 64 kB, il va se contenter de me renvoyer 64 kB. Mais d'où viennent les autres octets ? C'est là que se trouve la clé du problème. OpenSSL va vous renvoyer 64 kB - 1 octet de mémoire auquel le processus a accès et que vous n'avez pas envoyé à l'origine, selon l'endroit où votre 1 octet est stocké. Ces octets supplémentaires de la mémoire sont le problème car ils peuvent contenir des informations précieuses telles que matériel de clé privée¹ et les informations que le serveur est en train de décrypter pour les utiliser. Il peut s'agir, par exemple, de mots de passe, d'informations relatives à une carte de crédit et/ou d'un numéro de téléphone. NIPs .
OK. Qu'est-ce que cela signifie pour la sécurité de l'information ? Si vous comprenez comment fonctionne la cryptographie asymétrique, vous savez déjà que c'est grave, car la divulgation fait que le cryptage n'est rien de plus qu'un obscurcissement. Cela signifie que même si les serveurs ont été corrigés et qu'ils ne fuient plus la mémoire, les sessions ne sont toujours pas sécurisées. Il est possible que ce problème ait été exploité avant qu'il ne soit connu du public ou pendant que Parcheando avait lieu, mais il n'y a actuellement aucune méthode prouvée pour montrer qu'une attaque a eu lieu. Il est possible que les règles de IDSs peut devenir disponible, mais pour l'instant ce n'est pas le cas. Les règles IDS ont été publiées . En soi, cela est extrêmement dangereux, car les opérateurs ne savent pas si leurs clés sont encore sûres.
Nous sommes obligés de supposer que les clés ont été divulguées, ce qui signifie qu'il est possible que tout ce que vous envoyez par voie électronique puisse être décrypté par un tiers. La seule façon d'atténuer ce problème est de régénérer les clés et de faire réémettre de nouveaux certificats tout en révoquant les anciens. Malheureusement, cela prend du temps car le CAs sont sans doute inondés de ces demandes en ce moment même. Cela laisse quand même la possibilité d'un attaque man-in-the-middle ou d'autres possibilités d'hameçonnage.
Quand sera-t-il sûr ? Il est difficile de savoir quand cela sera sûr. Je vous suggère de surveiller les annonces publiques expliquant que le bogue a été corrigé dans leur environnement ou qu'ils n'ont jamais été vulnérables, car ils n'ont jamais utilisé les versions concernées. Lorsqu'ils annoncent qu'ils ont adopté une nouvelle version d'OpenSSL, je m'assure qu'ils utilisent un nouveau certificat signé. après la date de diffusion publique de l'exploit, soit le 2014-04-07.
**Notez que le trafic précédemment enregistré peut être décrypté si la clé privée a été divulguée ultérieurement.
Que puis-je faire en tant qu'utilisateur pour me protéger ?
Pour les prochains jours, si vous pouvez éviter d'utiliser des sites critiques tels que les services bancaires en ligne ou l'accès aux dossiers médicaux en ligne, je vous suggère de le faire. Si vous devez le faire, sachez que votre session est potentiellement à risque et soyez prêt à en accepter les conséquences. En outre, lorsque les organisations annoncent qu'elles ne sont plus vulnérables, vous devriez changer votre mot de passe ; l'utilisation d'un gestionnaire de mots de passe peut être utile. Vous devez également vous préparer à modifier ou à contrôler toute autre information que vous avez utilisée, comme les coordonnées bancaires ou les numéros de carte de crédit.
Avis spécial aux militants
Tout ce qui est qui utilisent OpenSSL peuvent être affectés, notamment Tor . Il est possible que les gouvernements aient été en mesure d'utiliser cette faille depuis son inclusion dans les versions d'OpenSSL il y a plus de deux ans, car ils disposent des vastes ressources nécessaires à la recherche d'exploits tels que celui-ci, et vous devez donc vous préparer à ce que les informations ne soient plus privées.
**Notez que le trafic précédemment enregistré peut être décrypté si la clé privée a été divulguée ultérieurement, à moins qu'il n'y ait une fuite. une parfaite sécurité avant (PFS) a été mis en œuvre.
¹- Certains ont affirmé qu'il était probable que les clés privées ne soient pas en mémoire, mais en même temps, certains ont affirmé avoir réussi à extraire des clés. A ce stade, il n'est pas certain de savoir quel côté est correct.
