Article de fond: comment se protéger contre le bug Heartbleed en expansion

© Computable.nl

Heartbleed défraie la chronique depuis un petit temps déjà, et son impact semble encore et toujours s’étendre. Dans quelle mesure doit-on le prendre au sérieux? Et que doit-on faire pour s’en protéger?

Heartbleed, un bug présent depuis deux ans déjà et qui a peut-être fait en sorte que vos données de comptes sur des sites web tels Facebook et Gmail ont été dévoilées, défraie la chronique depuis un petit temps déjà, et son impact semble encore et toujours s’étendre. Mais qu’est-ce que Heartbleed en fin de compte? Dans quelle mesure doit-on le prendre au sérieux? Et surtout: que doit-on faire pour s’en protéger?

Divers sites continuent d’envoyer des mises à jour de la procédure de login, afin de rassurer les utilisateurs quant à la protection de leurs données. D’autres sites indiquent qu’ils en ont été la victime, et qu’un autre mot de passe s’avère donc nécessaire.

Les avis sur Heartbleed divergent: cela va d’un “problème de sécurité révolutionnaire” à “simplement une nouvelle lacune dans la défense” qui n’a touché ‘que’ 17 pour cent des sites.

Mais il y a aussi l’impact sur les gadgets et les appareils, dont l’on ne se rend pas rapidement compte. Nombre de smartphones, téléphones IP, commutateurs et routeurs sont qualifiés de vulnérables. Les routeurs internet à usage domestique et les e-thermostats branchés sont tous des victimes potentielles du bug. Et alors que l’internet des choses combine toujours plus d’appareils, cette liste ne fait que s’allonger. Beaucoup parmi ces appareils ne seront pas actualisés, ce qui fait que les entreprises qui travaillent et communiquent avec eux, sont menacées. Elles nécessitent donc une solution de sécurisation indépendamment de la mise à jour ou non de l’appareil proprement dit.

Comme l’on y consacre beaucoup d’attention, les fournisseurs auront tendance à rivaliser avec des offres spécialement conçues pour protéger les utilisateurs contre Heartbleed. L’équipement réseautique sera programmé pour détecter et rejeter les requêtes exploitant le bug.

Il existe plusieurs endroits dans le trafic de données, où il est possible d’organiser la défense contre ce bug et d’autres brèches comparables. Les entreprises doivent choisir le point le plus stratégique dans le réseau. Pour déterminer ce point, il faut se demander comment et dans quelle situation le point faible sera détecté. Pour ce faire, il est important de résumer quelque peu et d’examiner comment Heartbleed fonctionne.

Fonctionnement de Heartbleed
Heartbleed exploite un contrôle de longueur manquant dans le traitement du code OpenSSL d’une extension relativement anodine du protocole TSL/SSL (définie dans RFC 6520). Il s’agit de deux messages simples: une requête et une réponse. Cette requête peut être envoyée tant par le client que par le serveur, pour maintenir la connexion en état. L’expéditeur envoie un message Heartbeat avec un petit paquet de données, dans l’attente que le destinataire renvoie ces mêmes données. L’important ici, c’est que celui qui envoie le message, détermine la taille de la réponse. L’expéditeur indique au destinataire la quantité envoyée et celle qu’il attend donc en retour.

Le code OpenSSL devrait veiller à ce que la longueur que l’attaquant déclare envoyer, soit réellement disponible. Mais le code ne le fait donc pas. Il fait simplement confiance à l’expéditeur et prélève simplement la quantité de données de la mémoire. Ce faisant, un attaquant peut accéder à des données dans la mémoire et donc à des informations comme des mots de passe et des clés.
Protection
Comme Heartbleed exploite une brèche dans des trajets de communication cryptés, la solution doit y être appliquée aussi. Il existe trois points, où c’est possible.

1. Client: l’on peut contrôler le système d’exploitation client et le type d’équipement et y empêcher l’utilisation connue de versions OpenSSL infectées. Une fois détecté, un client peut être continuellement éconduit, de sorte que la requête malfaisante ne soit de toute façon pas envoyée. Attention cependant car éconduire un client parce qu’il est potentiellement malfaisant, peut se traduire par des utilisateurs, clients ou autres relations légitimes furieux.

2. Request: inspectez les requêtes client et rejetez-les, dès qu’un message Heartbeat est découvert. Cela évitera que ces requêtes soient transférées vers des systèmes et serveurs vulnérables.

3. Response: examinez les réponses et dès qu’un message Heartbeat y est repéré, contrôlez-en la longueur. Si celle-ci est supérieure à ce qui est attendu ou habituel, ignorez-le. De cette manière, les assaillants ne recevront pas vos données, mais vos serveurs et données seront entre-temps bel et bien exposés.

L’endroit idéal pour mettre en oeuvre la protection est celui qui vous offre un choix entre plusieurs solutions. Ou aux trois points susmentionnés, si vous voulez vraiment tout barricader. Dans la plupart des cas, l’application delivery firewall ou l’application delivery controller sera l’endroit le plus stratégique. La solution ad hoc ne se trouvera cependant pas uniquement au bon endroit dans le réseau. Elle veillera aussi à la visibilité et à la programmabilité de la pile réseautique et sera capable de trouver les données révélant une fuite, sciemment ou non.

Un bon outil établit une distinction entre le trafic client et le trafic serveur et y applique la logique requise. La logique que Heartbleed décèle du côté client, est différente de celle du côté serveur. Dans le cas du client, l’outil doit rechercher un message spécifique axé sur une requête Heartbleed ou examiner l’environnement de l’appareil client. Côté serveur, il doit contrôler la longueur de la réponse. Chaque cas exige un code personnel unique. L’outil doit donc disposer d’un environnement programmable, capable d’appliquer très précisément la logique adéquate au moment voulu.

A présent que Heartbleed est connu depuis une bonne semaine, les organisations doivent raisonnablement avoir une vision de son impact en leur sein. Il faut évidemment des correctifs et des mises à niveau pour serveurs, et il convient d’attribuer de nouvelles clés et de nouveaux mots de passe. Entre-temps, les serveurs (et donc les utilisateurs) restent vulnérables. Les entreprises doivent directement agir, tout en préparant une solution à plus long terme.

En collaboration avec Computable

Vous avez repéré une erreur ou disposez de plus d’infos? Signalez-le ici

Contenu partenaire