De nombreuses mises en œuvre de TLS permettent d’extraire des clés RSA

De nombreuses mises en œuvre logicielles de TLS contiennent des vulnérabilités qui permettent aux pirates d’obtenir les clés RSA en utilisant un minimum de ressources informatiques.

Florian Weimer, chercheur chez Red Hat, a publié la semaine dernière un rapport intitulé « Factoring RSA Keys With TLS Perferct Forward Secrecy » dans lequel il expose des vulnérabilités dans plusieurs périphériques, dont un célèbre répartiteur de charge de Citrix et des équipements de production d’Hillstone Networks, Nortel, Viprinet, etc.

D’après Florian Weimer, la mise en œuvre de TLS dans ces produits ne possède pas une protection suffisante contre les attaques Lenstra contre le « théorème des restes chinois » ou RSA-CRT.

« En cas d’échec pendant le calcul de la signature (à l’aide d’une optimisation de RSA-CRT), l’individu malintentionné peut récupérer la clé privée au départ de la signature (« fuite de clé RSA-CRT »). A l’époque, le recours au chiffrement sur Internet était inhabituel et même dix ans plus tard, la majorité des connexions TLS (ou HTTPS) n’était pas concernée par ce problème car elles n’utilisaient pas de signatures RSA. Cela a changé peu à peu lorsque la confidentialité persistante pour TLS a été recommandée et adoptée par de nombreux sites Internet. » écrit Florian Weimer dans sa description de l’attaque Lenstra.

Lenstra est décrit comme une attaque de contournement et Florian Weimer a déclaré que l’algorithme RSA en lui-même est protégé contre cette attaque et que la vulnérabilité n’existe que dans certains mises en œuvre non protégées.

« Nous avons observé quelques fuites de clés RSA-CRT là où elles n’auraient pas dû se produire » écrit-il, non sans ajouter que les mises en œuvre dans OpenSSL et NSS sont protégées et qu’Oracle a diffusé un correctif pour OpenJDK dans CVE-2015-0478 après avoir consulté Florian Weimer. « Tous les certificats PKI de navigateur pour lesquels nous avons observé une fuite ont été remplacés et révoqués. »

Les pirates peuvent utiliser cette attaque hors ligne à un coût relativement inférieur par rapport aux autres attaques contre le chiffrement. Mais le vol d’une clé de chiffrement privée est dangereux uniquement pour les données que TLS doit protéger. D’après Florian Weimer, l’individu malintentionné doit s’introduire dans le réseau via une attaque de l’homme du milieu ou une compromission de serveur en vue d’organiser une deuxième attaque de ce type et se faire passer pour le serveur en question.

« Cette fuite est visible pour le client qui réalise la poignée de mains TLS ou un observateur passif qui intercepte le trafic réseau » écrit Florian Weimer. « Cette fuite de clés permet également de déchiffrer l’échange de données qui n’utilise pas la confidentialité persistance sans organise une attaque d’homme du milieu ».

Les attaques menées hors ligne ne sont pas faciles à identifier. D’après Florian Weimer, le système de prévention des intrusions peut détecter une fuite de clés s’il a été configuré pour vérifier toutes les poignées de main TLS.

Florian Weimer explique que « dans les cas de fuites de clés que nous avons observé, l’attaquant à distance ne peut pas organiser une fuite de clés à la demande étant donné qu’il n’est pas en mesure de manipuler le serveur du réseau d’une manière qui augmenterait la probabilité d’une fuite de réseau dans une poignées de main TLS. L’individu malintentionné peut uniquement intercepter un maximum de poignées de main, probablement en initialisant une multitude de poignées ».

La confidentialité persistante intervient dans de nombreux systèmes critiques. Dans le cadre de la confidentialité persistante, une nouvelle clé de chiffrement est générée pour chaque session. Cela signifie que même si le pirate parvient à intercepter les données de plusieurs sessions, il ne pourra pas les déchiffrer toutes s’il trouve une clé, mais bien une seule session. D’après le chercheur, la désactivation de la confidentialité persistante est une mauvaise stratégie.

« La désactivation de la confidentialité persistante permettrait aux observateurs passifs qui auraient voler des clés, de déchiffrer les sessions TLS à venir dans le trafic réseau intercepté, sans devoir rediriger la connexion du client. Autrement, la désactivation de la confidentialité persistante ne contribue qu’à la détérioration de la situation. (la désactivation de la confidentialité persistance et le remplacement du certificat du serveur, quant à eux, fonctionnent) » écrit Florian Weimer.

Source: Threatpost

Posts similaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *