Support technique
Documentation
Connexion
Nous contacter
TuxCare BlogPourquoi vos serveurs peuvent encore souffrir de (a) Heartbleed - et ce qu'il faut faire
par
Le 22 mars 2023 - L'équipe de relations publiques de TuxCare
Une dizaine d'années se sont écoulées depuis la découverte de Heartbleed, un dangereux exploit OpenSSL qui a affecté des millions de systèmes - et une vulnérabilité qui a fait son chemin dans les médias populaires.
L'histoire, n'est-ce pas ? La technologie évolue rapidement... dix ans, c'est long... et cette vulnérabilité a disparu depuis longtemps, n'est-ce pas ?
C'est faux.
Nous publions un nouvel article sur Heartbleed parce que, devinez quoi, il est toujours d'actualité. Oui, étant donné la rapidité avec laquelle un correctif a été publié et compte tenu de la rapidité du développement technologique, Heartbleed aurait déjà dû être relégué à l'arrière-plan.
Et si vous avez patché vos systèmes à temps, à chaque fois, vous n'avez aucune raison de vous inquiéter.
Mais que se passe-t-il si vous avez oublié un correctif quelque part ? Que se passe-t-il si votre entreprise a récemment fusionné avec une autre où les correctifs n'étaient pas à la hauteur ? Ou si cette toute nouvelle solution technologique contient un morceau de code obsolète ?
Il s'avère qu'il est encore courant que des systèmes soient vulnérables à Heartbleed. Dans cet article, nous donnons un aperçu rapide de Heartbleed et de son histoire. Nous vous indiquerons également des recherches récentes qui montrent qu'un nombre incalculable de systèmes sont toujours exposés au risque d'une attaque activée par un exploit Heartbleed.
Nous expliquons également comment vous pouvez facilement vérifier si vos bibliothèques OpenSSL sont vulnérables à Heartbleed, et ce que vous pouvez faire pour vous assurer que vous disposez d'une protection étanche contre cette dangereuse vulnérabilité.
Qu'est-ce que le "bug Heartbleed" ? Vue d'ensemble
En 2014, des chercheurs ont découvert que les versions 1.0.1 à 1.0.1f d'OpenSSL comportaient un type de bogue de gestion de la mémoire appelé vérification de limites manquante. En d'autres termes, le code d'OpenSSL ne vérifie pas que les données entrées dans la mémoire ne dépassent pas la taille de la mémoire tampon allouée.
Un pirate peut donc tromper le service OpenSSL en lui allouant une mémoire tampon de 64 Ko, pour ensuite envoyer des données qui dépassent la taille de la mémoire tampon. Ce faisant, l'attaquant peut faire fuir (ou saigner) les données de la machine de la victime par incréments de 64 Ko. Il ne s'agit là que d'une brève description - pour plus de détails sur l'exploit, vous pouvez lire l'article approfondi de CSO Magazine de CSO Magazine ici.
La faille a été appelée Heartbleed en raison de la nécessité de "saigner" les données bit par bit et parce que l'attaque se produit pendant ce que l'on appelle un "battement de cœur" - le message d'impulsion qui est envoyé entre deux serveurs pour confirmer que le serveur connecté est toujours en vie.
Les possibilités d'exploitation de la vulnérabilité Heartbleed étaient vastes et sérieuses. Les attaquants peuvent voler tout ce qu'ils veulent, depuis les clés de cryptographie et les identifiants des utilisateurs jusqu'aux documents et communications privés. Un attaquant peut accomplir tout cela sans être en possession d'identifiants d'accès - et sans même laisser de traces.
Même si 64 Ko ne semblent pas beaucoup, ils ouvrent la porte à des brèches importantes. Dans un exemple surprenant de piratage Heartbleed, un attaquant a a réussi à voler 4,5 millions de dossiers de patients de la société Community Health Systems en 2014.
Heartbleed est toujours dans la nature
D'accord, c'était en 2014. Pourquoi Heartbleed mérite-t-il encore qu'on en parle ? Tout simplement en raison du grand nombre d'applications et de serveurs qui reposent sur OpenSSL, ce qui, combiné à la tendance à appliquer des correctifs de manière incohérente, nous laisse avec un grand nombre de services qui sont encore vulnérables.
Au moment où Heartbeat a été découvert, Netcraft a indiqué qu'environ 17 % des serveurs web sécurisés étaient vulnérablesy compris certains des services les plus populaires au monde. Cela représente un nombre considérable de serveurs.
Des correctifs pour OpenSSL ont été publiés dès l'annonce de la vulnérabilité, mais cela ne veut pas dire que Heartbleed est passé à l'histoire.
Les chercheurs en sécurité continuent d'attirer l'attention sur les risques liés à Heartbleed. Récemment, le géant japonais de la technologie NTT a signalé dans un rapport de recherche que Heartbleed est l'une des principales raisons pour lesquelles OpenSSL reste l'un des services les plus fréquemment ciblés par les pirates.
De même, en novembre 2020, un chercheur du SANS Internet Storm Center a utilisé le moteur de recherche Shodan pour découvrir que plus de 200 000 machines sont encore vulnérables à la norme CVE-2014-0160l'identifiant officiel de la vulnérabilité Heartbleed. Grâce à un processus de validation, le chercheur a constaté que Shodan était en grande partie correct dans ses évaluations.
Il est clair que même si des mesures d'atténuation sont disponibles, Heartbleed reste un problème. Si vous utilisez le service de correction des bibliothèques de TuxCare, LibraryCarede TuxCare, vous n'avez pas à vous inquiéter, car vos bibliothèques seront toujours à jour. Mais, en l'absence d'une solution automatisée et sans redémarrage, vous devez examiner comment vos opérations peuvent encore être vulnérables à Heartbleed en raison d'une vulnérabilité de la bibliothèque OpenSSL.
Les correctifs sont la solution... mais aussi le problème
La raison pour laquelle Heartbleed est toujours en circulation n'est en aucun cas due à un manque de correctifs. La plupart des services reposant sur OpenSSL disposent d'un correctif pour éliminer la menace Heartbleed. Appliquez le correctif et la menace Heartbleed disparaît, c'est aussi simple que cela, dit la théorie.
Pourtant, ce n'est pas aussi simple, et ce pour plusieurs raisons. Dans l'environnement de l'entreprise, il ne suffit pas de déclencher un correctif et de redémarrer un service ou un appareil pour que les correctifs soient appliqués. L'application des correctifs nécessite un temps d'arrêt planifié et des ressources importantes, impliquant le temps de toute une série d'experts, y compris les administrateurs système, les administrateurs de bases de données et les administrateurs Linux. De nombreux problèmes surviennent au cours du processus :
- Incertitude quant aux bibliothèques mises à jour: L'exécution d'un processus de correction implique souvent un certain degré d'automatisation, ce qui peut laisser les administrateurs système dans l'incertitude quant aux bibliothèques qui ont été corrigées au cours du processus. Cela peut conduire à des redémarrages importants et inutiles et à des temps d'arrêt supplémentaires, ce qui peut constituer un frein à l'application de correctifs complets.
- Ne pas patcher de manière cohérente: Un autre risque est que certaines bibliothèques ne soient pas corrigées simplement parce que les administrateurs ne savent pas qu'elles doivent l'être. Il peut être difficile d'établir un catalogue complet et exhaustif des bibliothèques et il suffit d'une seule bibliothèque non corrigée pour qu'une brèche se produise. L'application manuelle de correctifs peut également conduire rapidement à l'oubli de bibliothèques.
- Fenêtre de vulnérabilité: Les correctifs sont souvent publiés rapidement, mais appliqués moins rapidement. Cela s'explique par la difficulté de planifier les temps d'arrêt et de réunir tous les éléments techniques nécessaires à l'application d'un correctif. Il reste donc une fenêtre entre le moment où une vulnérabilité a été signalée et le moment où cette vulnérabilité est corrigée par l'utilisateur final. Pendant cette période, les systèmes de votre organisation seront vulnérables aux attaques.
Il est clair que l'application de correctifs peut rapidement devenir une affaire aléatoire. Des années après la découverte de Heartbleed, il n'est pas du tout impossible que votre organisation ait négligé d'appliquer les correctifs nécessaires pour s'en protéger.
Il est également possible qu'entre-temps, vous ayez acquis une technologie qui comporte toujours la faille critique OpenSSL.
Vérification des bibliothèques non corrigées avec Uchecker
Si vous êtes un administrateur système et que vous vous demandez si vos bibliothèques sont régulièrement patchées, l'un des outils que vous devriez envisager d'utiliser est uChecker - un outil gratuit, sous licence GNU, développé par l'équipe à l'origine de TuxCare.
uChecker vous aide à vérifier si vos bibliothèques sont protégées contre la vulnérabilité Heartbleed, en générant un rapport facile à lire détaillant les bibliothèques qui ne sont pas à jour. uChecker peut analyser les bibliothèques en mémoire ainsi que les bibliothèques stockées sur le disque.
C'est un avantage par rapport à d'autres scanners qui ne parviennent pas à repérer les bibliothèques non corrigées en mémoire. Il est facile d'installer uChecker - il suffit de consulter la page GitHub ici.
$ curl -s -L https://kernelcare.com/uchecker | sudo python
Une fois que vous avez effectué un scan avec uChecker, vous pouvez procéder à la correction de tous les services OpenSSL qui sont encore vulnérables à Heartbleed.
Par mesure de sécurité, vous devez vérifier minutieusement le code que vous téléchargez sur Internet avant de l'exécuter dans vos systèmes. La commande ci-dessus peut, et devrait, être séparée en deux - une pour télécharger le code que vous voulez vérifier, et une autre pour l'exécuter. La commande ci-dessus n'est qu'un moyen pratique d'exécuter uChecker, et non la meilleure pratique de sécurité.
Il vaut la peine de revérifier Heartbleed
Des années après l'apparition de Heartbleed, il vaut sans aucun doute la peine de vérifier que vos serveurs sont bien protégés contre cette dangereuse menace. Nous avons mis en évidence deux exemples de recherches récentes qui montrent que les organisations ont encore des lacunes dans leur réponse à Heartbleed.
Si vous ne déployez pas actuellement un outil automatisé de correction en direct, nous vous recommandons d'exécuter uChecker - il s'agit d'un outil gratuit et facile à utiliser qui vous indiquera rapidement si vos serveurs sont toujours vulnérables à Heartbleed.
Quoi qu'il en soit, il est essentiel de garder un œil sur OpenSSL. Il s'agit d'une couche de sécurité importante, mais en même temps, c'est l'un des logiciels les plus exposés, avec 202 vulnérabilités découvertes depuis sa sortie jusqu'au moment de la rédaction de cet article, dont Heartbleed n'est que l'une d'entre elles.
Et n'oubliez pas - LibCare de TuxCare gardera vos bibliothèques, y compris OpenSSL, à jour - sans tracas. Pour en savoir plus sur LibCare, cliquez ici.
