ClickCease Protéger les serveurs contre HeartBleed. Oui, HeartBleed. - TuxCare

Rejoignez notre populaire bulletin d'information

Rejoignez 4 500+ professionnels de Linux et de l'Open Source !

2 fois par mois. Pas de spam.

Protéger les serveurs contre HeartBleed. Oui, HeartBleed.

3 novembre 2020 - L'équipe de relations publiques de TuxCare

Protéger les serveurs contre HeartBleedHeartBleed... ça ressemble à une chanson d'amour des années 70. Ce n'est pas le cas. HeartBleed est une sérieuse vulnérabilité (CVE-2014-0160) affectant la bibliothèque partagée OpenSSL. Elle existe depuis 2014, mais contrairement aux vieilleries que l'on entend de temps en temps à la radio, cette cyberfaiblesse est bien présente aujourd'hui. L'équipe de NTT Rapport 2020 sur les menaces mondiales révèle que HeartBleed contribue à faire d'OpenSSL la deuxième technologie logicielle la plus ciblée dans le monde, ce qui représente 19% des activités hostiles dans le monde.

HeartBleed est une attaque qui tire parti d'un bogue de gestion de la mémoire dans les versions 1.0.1 à 1.0.1f d'OpenSSL. Avec HeartBleed, les attaquants sont capables de décoder 64 kilo-octets de données cryptées pendant chacun des "battements de cœur" du logiciel OpenSSL. Ils peuvent exploiter le "saignement" des données pour monter une attaque de type "man-in-the-middle" ou accéder à des informations sensibles telles que des mots de passe et des identifiants d'utilisateur.

Contenu :

  1. La solution est le rafistolage. Le problème, c'est aussi le rafistolage
  2. L'application de correctifs en direct comme moyen d'atténuer les effets de Heartbleed en cas de redémarrage de l'ordinateur
  3. Conclusion

 

La solution est le rapiéçage. Le problème, c'est aussi le rapiéçage

La solution est le rapiéçage. Le problème, c'est aussi le rapiéçage.

L'atténuation de HeartBleed et des menaces comparables implique l'application de correctifs aux bibliothèques OpenSSL vulnérables ainsi qu'à celles de la bibliothèque GNU C (glibc). Le processus de mise à jour des bibliothèques peut prendre la forme du cadre ATT&CK (Adversarial Tactics, Techniques and Common Knowledge) de MITRE. ATT&CK recommande à que les organisations "analysent régulièrement les vulnérabilités des systèmes tournés vers l'extérieur et établissent des procédures pour corriger rapidement les systèmes lorsque des vulnérabilités critiques sont découvertes par l'analyse et par la divulgation publique".

Ensuite, après avoir identifié les vulnérabilités critiques, les administrateurs système programment généralement un temps d'arrêt pour exécuter le processus de correction lui-même. Cela a toujours signifié l'arrêt de la pile, l'application du correctif au système d'exploitation et le redémarrage de la pile. Ce processus nécessite également du temps et de l'attention de la part de nombreuses personnes, telles que les administrateurs Linux, les administrateurs de bases de données (DBA), les administrateurs de middleware et les utilisateurs professionnels. En supposant qu'il n'y a pas de problème (ce qui n'est pas toujours une hypothèse fiable), l'administrateur système valide ensuite la pile mise à jour et la remet en production.

Plusieurs problèmes se posent dans ce processus :

  • Incertitude quant aux bibliothèques à mettre à jour - Les administrateurs systèmen'ont généralement pas une idée précise des bibliothèques qui doivent être mises à jour. Par conséquent, ils procèdent généralement à un redémarrage de l'ensemble du système.
    Les cycles de redémarrage entraînent des dégradations et/ou des interruptions de service. Après un redémarrage, il faut parfois un certain temps pour que les performances du serveur se stabilisent. Parfois, les serveurs ne reviennent pas correctement après un redémarrage. 
  • Fenêtres de vulnérabilitéEn raison de la main-d'œuvre requise pour un redémarrage, ainsi que des perturbations potentielles, les entreprises planifient souvent les redémarrages pendant des périodes d'arrêt préétablies, comme les week-ends. Ce retard laisse leurs serveurs ouverts aux attaques. Même si un administrateur système effectue un redémarrage tous les 30 jours pour se conformer aux normes de sécurité, les serveurs peuvent être vulnérables pendant deux semaines ou plus.
  • Corrections incomplètes - Lorsqueles serveurs sont corrigés manuellement, sans redémarrage, les bibliothèques partagées peuvent encore contenir des vulnérabilités. Par exemple, lorsque les bibliothèques sont mises à jour sur le disque, les anciens fichiers non corrigés peuvent persister dans la mémoire d'un serveur. Et les scanners de vulnérabilité ne détectent pas ces anciens fichiers de bibliothèque non corrigés en mémoire. 

 

Utilisation de UChecker pour atténuer les vulnérabilités de HeartBleed et d'autres bibliothèques partagées

Utilisation de UChecker pour atténuer les vulnérabilités de HeartBleed et d'autres bibliothèques partagées

Lorsque les serveurs sont corrigés manuellement, sans redémarrage, les bibliothèques partagées peuvent encore contenir des vulnérabilités. Par exemple, lorsque les bibliothèques sont mises à jour sur le disque, les anciens fichiers non corrigés peuvent persister en mémoire. Et, les scanners de vulnérabilités ne détectent pas ces anciens fichiers de bibliothèques non patchés résidant en mémoire. Il est maintenant possible d'identifier si le système est toujours sensible à HeartBleed ou à des vulnérabilités similaires en analysant les bibliothèques en mémoire avec Uchecker de KernelCare

 Voici comment cela fonctionne :

  • UChecker obtient les derniers BuildIDs actuels à partir d'une ressource sur notre site, par ex. https://patches04.kernelcare.com/userspace.json
  • Il prend un processus en cours en itérant sur /proc/
  • It then gets a linked shared library from /proc/<pid>/maps
  • À ce stade, l'outil vérifie si la bibliothèque partagée a été remplacée ou supprimée.
  • Selon l'état du processus, l'outil analyse le format exécutable et lisible (ELF) à partir du système de fichiers ou de la mémoire mappée.
  • L'outil recueille le BuildID à partir de .note.gnu.build-id
  • L'outil répète ensuite ce cycle pour analyser d'autres bibliothèques, si nécessaire.

UChecker : comment ça marche ?

Figure 1 : Comment fonctionne Uchecker

Visitez la page Github d'Uchecker et regardez la démonstration de son fonctionnement.

UChecker permet de rechercher gratuitement les bibliothèques vulnérables ; toutefois, pour les mettre à jour, un redémarrage est nécessaire. Si vous avez besoin de rechercher les vulnérabilités et de mettre à jour les bibliothèques sans redémarrer les processus ou redémarrer les serveurs, essayez KernelCare+: il vérifie si des processus en cours d'exécution utilisent des bibliothèques périmées en mémoire, puis met à jour les bibliothèques partagées vulnérables sans les redémarrer.

 

Conclusion

Les bibliothèques partagées restent une source sérieuse d'exposition aux risques de sécurité pour les entreprises qui utilisent des logiciels libres et open source (FOSS). Uchecker et la technologie Live Patching de KernelCare permettent la mise à jour des bibliothèques partagées sans les perturbations et les risques étendus d'un redémarrage du serveur. Ensemble, Uchecker et KernelCare permettent une mise à jour plus rapide et plus efficace des bibliothèques partagées. HeartBleed et d'autres vulnérabilités similaires peuvent désormais être traitées sans ralentir l'ensemble de l'organisation. Pour en savoir plus, consultez https://lp.kernelcare.com/kernelcare-early-access

Vous cherchez à automatiser la correction des vulnérabilités sans redémarrage du noyau, temps d'arrêt du système ou fenêtres de maintenance programmées ?

Découvrez le Live Patching avec TuxCare

Devenez rédacteur invité de TuxCare

Commencer

Courrier

Rejoindre

4,500

Professionnels de Linux et de l'Open Source
!

S'abonner à
notre lettre d'information