Ce que vous devez savoir sur Heartbleed| NETSCOUT

Ce que vous devez savoir sur Heartbleed

Les fournisseurs et les administrateurs de sites essaient désespérément de combler le trou béant ouvert par Heartbleed, une faille exploitable à distance dans la bibliothèque de cryptographie OpenSSL communément utilisée pour activer les sessions TLS. Mais Heartbleed n'affecte pas seulement les serveurs Web. Compte tenu de l'utilisation généralisée de OpenSSL dans un large éventail de produits de mise en réseau et de l'existence de ce bug de mise en œuvre TLS au cours des deux dernières années, la surface d'attaque de Heartbleed et son incidence potentielle sont très importantes.
 
Heartbleed, de quoi s'agit-il ?
Heartbleed fait référence à une vulnérabilité récemment découverte dans la sécurité de la couche de transport (TLS) du protocole de mise en œuvre Heartbeat contenu dans l'OpenSSL. Lorsqu'un serveur TLS utilisant une version vulnérable de OpenSSL (1.0.1 à 1.0.1f) reçoit un message d'extension Heartbeat qui a été conçu pour provoquer une lecture excessive de la mémoire tampon, le serveur répond avec 64 Ko de contenu de mémoire vive.
 
Selon CVE-2014-0160, il a été observé que des réponses Heartbeat pouvaient contenir des données sensibles, y compris des clés de certificats de serveur privé, des clés de session TLS, des identifiants de connexion utilisateur/mots de passe et contenus de messages. Un attaquant pourrait envoyer de nombreuses requêtes Heabeat afin de récolter une partie importante de la mémoire d'un serveur sans éveiller de soupçons. La demande est cryptée et pas enregistrée par OpenSSL. Cependant, il pourrait être possible pour un scanneur de prévention d'intrusions de détecter/de bloquer des réponses TLS Heartbeat trop longues et fréquentes.
 
Plus d'informations sur le bogue Heartbleed, les versions affectées d'OpenSSL, et des correctifs se trouvent à cet emplacement :
 
 
Pourquoi devrais-je me soucier de la faille Heartbleed ?
Les dommages potentiellement causés par Heartbleed sont vastes, en partie parce que les clients et serveurs TLS traitent une quantité importante d'informations sensibles, les assaillants ont pu récupérer des données qui sont potentiellement utiles sur le long terme.
 
Par exemple, si Heartbleed a été utilisé pour récupérer des numéros de clés principales associés à un certificat de serveur X.509, on ne peut plus se fier à ce certificat pour l'authentification du serveur. Renouveler le certificat ne permet pas d'atténuer ce risque - le certificat doit être révoqué, émis de nouveau et réinstallé.
 
Si Heartbleed a été utilisé pour récupérer des mots de passe administratifs, ou des informations d'identification envoyées sur une session TLS cryptée, ces informations d'identification volées pourraient être utilisées pour compromettre des comptes d'utilisateurs et des profils associés et des données stockées. Si Heartbleed a été utilisé pour récupérer des clés de session TLS, ces clés peuvent être utilisées pour décrypter le trafic de session capturé à n'importe quel moment. Et ainsi de suite.
 
En outre, le bogue Heartbleed a été présent au sein du code OpenSSL pendant environ deux ans, ce qui a créé de vastes opportunités pour une exploitation par le passé. Les développeurs peuvent maintenant prendre des mesures pour éliminer le bogue - soit par une mise à jour de l'OpenSSL ou en recompilant le code affecté avec l'option de configuration -DNO_OPENSSL_HEARTBEATS. Cependant, rien ne peut être fait maintenant pour identifier de façon rétroactive les données déjà récupérées. Au lieu de cela, nous allons devoir supposer que les implémentations qui utilisent des versions vulnérables d'OpenSSL ont probablement été exploitées par quelqu'un, quelque part.
 
Pourquoi ? Selon http://www.heartbleed.com, les serveurs web open source omniprésents comme Apache et nginx utilisent des versions vulnérables d'OpenSSL ; ensemble, ces logiciels fonctionnent maintenant sur plus de 66 % des sites Web actifs. En outre, OpenSSL est utilisé par de nombreux serveurs SMTP / POP / IMAP, les passerelles VPN SSL, et les appareils réseau, y compris des routeurs WLAN, points d'accès, contrôleurs et infrastructures connexes.
 
Comment Heartbleed a-t-il pu affecter ma sécurité WLAN ? 
Pour commencer, les produits WLAN qui sont gérables via HTTPS peuvent être vulnérables à Heartbleed. Cela inclut probablement de nombreux routeurs sans fil résidentiels gérés par l'intermédiaire d'interfaces web sécurisées sous OpenSSL. Cela peut également inclure des points d'accès à distance gérés et contrôleurs WLAN qui utilisent les bibliothèques OpenSSL, soit pour obtenir des interfaces d'administration ou pour sécuriser des portails d'accès client intégrés. Portez donc attention aux avis de sécurité et aux mises à jour de micrologiciel émis par vos fournisseurs de produits WLAN, et prenez des mesures pour minimiser les risques d'exploitation de la faille en attendant, comme la désactivation de la gestion WLAN à distance ou l'application des listes de contrôle d'accès.
 
En outre, des certificats de serveur X.509 et de client produits utilisant OpenSSL et utilisés pour l'authentification de WPA2-Enterprise 802.1X peuvent devoir être retirés et révisés. Regardez le système d'accès conditionnel ou le service utilisé pour les générer pour évaluer la vulnérabilité à Heartbleed, et également les systèmes vulnérables où ces certificats auraient été utilisés avec la clé privée du certificat.
 
En outre, à mesure que des périphériques réseau vulnérables sont identifiés, examinez les informations d'identification et les paramètres qui pourraient avoir été récupérés par le passé et prenez des mesures pour dissuader de futures mauvaises utilisations de ces informations. Par exemple, un contrôleur de point d'accès ou WLAN vulnérables pourraient également laisser fuiter d'autres identifiants/mots de passe administrateur ou des détails de configuration stockés dans la mémoire, comme les modulations par déplacement de phase utilisées pour l'authentification personnelle WPA2.
 
Dans la mesure où votre organisation développe des logiciels qui utilise la bibliothèque OpenSSL, agissez rapidement pour passer à une version fixe de l'OpenSSL et/ou compilez les protocoles de sécurité de la couche transport (TLS) Heartbeat comme décrit ci-dessus. Des outils sont maintenant distribués pour vérifier votre propre code/serveur et voir si vous êtes vulnérable à Heartbleed (voyez http://www.heartbleed.com).
 
Enfin, tirez parti de vos systèmes de sécurité et de surveillance pour garder un oeil sur le trafic - et pas seulement le trafic TLS inhabituel ou de longs TLS Hearbeat, mais des identifiants utilisateur ou administrateur inhabituels ou d'autres comportements qui pourraient signaler l'utilisation d'informations déjà récupérées. En bref, mettez-vous et votre réseau en état d'alerte jusqu'à ce que les choses reviennent à la normale et que plus de détails sur les impacts et les conséquences possibles soient connus.

 

 
 
Powered By OneLink