Après le douloureux épisode HeartBleed d'OpenSSL, le chiffrement des connexions SSL/TLS est une nouvelle fois mis à mal avec FREAK (Factoring RSA EXPORT Attack Keys). Via une attaque de type « homme du milieu », un pirate peut décrypter les échanges de données sécurisées entre un serveur et navigateur web.

Il y a quelques mois, la faille Heartbleed d'OpenSSL faisait largement parler d'elle. Il faut dire que les conséquences pouvaient être fâcheuses puisqu'il était possible d'accéder à des données chiffrées stockées dans la mémoire des serveurs. Plus récemment, c'était au tour de la faille POODLE de SSLv3 de faire les gros titres, et c'est maintenant FREAK qui entre en piste.

FREAK : une attaque basée sur un reliquat des années 90 avec « export RSA »...

Sur leur principe de fonctionnement, les failles POODLE et Freak ne sont pas très éloignées l'une de l'autre. Dans les deux cas, il s'agit en effet d'une attaque de type « homme du milieu » où il faut empêcher autant que possible le navigateur et le serveur de se connecter via un protocole de sécurité récent, et donc normalement plus robuste. Alors que POODLE exigeait une « downgrade dance » pour passer de TLS à SSLv3, FREAK court-circuite la négociation du système de chiffrement qui sera utilisé entre le navigateur et le serveur.

En temps normal, ils se mettent d'accord sur le système de chiffrement le plus fort possible qu'ils prennent tous les deux en charge, et ce, afin d'assurer un maximum de sécurité. Problème, dans certains cas il est possible de forcer un chiffrement relativement faible : « export RSA » qui exploite une clé RSA de 512 bits seulement. Il date des années 90, une période durant laquelle les États-Unis limitaient l'exportation des systèmes de chiffrement à 512 bits maximum. Un palier qui était jugé plus ou moins suffisant pour l'époque, tout en laissant la possibilité aux services de renseignements de décrypter un message si besoin. À titre de comparaison, même le RSA 1024 bits n'est plus jugé comme sécurisé, et on a pu voir Mozilla en supprimer le support dans Firefox 36.

Downgrade attack: "Enter your 20-digit password" "Oh, darn, I've forgotten it" "Then what's your mother's maiden name?" "Smith" "Come in!"

— Martijn Grooten (@martijn_grooten) 3 Mars 2015

Depuis, cette limitation a été levée, mais « export RSA » continue d'exister dans certains serveurs et navigateurs. C'est notamment le cas de ceux qui utilisent OpenSSL (CVE 2015 - 0204). Des correctifs sont déjà en ligne depuis le mois de janvier (mais tous les détails n'étaient alors pas dévoilés) et les versions 1.0.1k, 1.0.0p et 0.9.8zd d'OpenSSL corrigent ce souci.

On retrouve également le même problème dans Safari (iOS et OS X) et Apple serait en train de plancher sur une mise à jour selon Reuters, qui cite un porte-parole de la société. Il devrait être proposé aux clients la semaine prochaine, sans plus de détails pour l'instant. Nos confrères se sont également entretenus avec un porte-parole de chez Google qui précise qu'un patch a été développé pour Chrome sur Android et qu'il est proposé aux partenaires du géant du web, sans autres détails sur le calendrier de diffusion.

... et hop la connexion est chiffrée avec une clé de 512 bits seulement

Comme l'expliquent nos confrères de Cryptography Engineering, via une attaque « homme du milieu » le pirate se place donc entre le serveur et un navigateur (via un réseau Wi-Fi par exemple) afin de court-circuiter les négociations. Alors que le navigateur demande à utiliser un système de chiffrement RSA fort, le pirate modifie la demande en « export RSA » (faible). Le serveur répond avec une clé RSA de 512 bits, qui est ensuite acceptée par le navigateur « à cause d'un bug », même si ce n'était pas sa demande initiale. La connexion est donc chiffrée via RSA en 512 bits seulement. Pour rappel, l'ANSSI recommande une clé d'au moins 2048 bits pour un chiffrement asymétrique (comme le RSA) et même 4096 bits à partir de 2030.

Il suffit alors de factoriser cette clé de 512 bits (voir cette actualité pour plus de détail) pour décrypter la connexion. Toujours selon Cryptography Engineering, en utilisant le cluster EC2 d'Amazon et un algorithme spécialement conçu pour, il serait possible de factoriser un tel nombre en 7h30 environ, pour un coût d'un peu plus d'une centaine de dollars. Une fois les clés privées trouvées, le pirate peut alors lire et modifier toutes les données comme s'il était dans la Matrice : il a un accès total aux données échangées et peut modifier à loisir l'apparence du site alors que la connexion est toujours sécurisée pour le navigateur. 

Le coût annoncé n'est pas négligeable (100 dollars environ par clé), mais les choses se gâtent puisque, par défaut, Apache générerait une clé de chiffrement « export RSA » et le conserverait tout le temps où le serveur est démarré, sans la renouveler. Conséquence directe de cette situation, une fois cette clé factorisée par un pirate, attaquer d'autres utilisateurs sur un même serveur serait un jeu d'enfant.

Qui est concerné ? 

Selon les chercheurs à l'origine de cette découverte, Chrome sur Android et Safari (sur iOS et OS X) seraient vulnérables à FREAK. Un test a été mis en ligne afin de vous permettre de vérifier ce qu'il en est. D'après nos constations, Chrome, Firefox et Internet Explorer dans leur dernière version pour Windows ne sont pas concernés. Il en est de même pour Firefox sur Android et Chrome sur iOS.

Safari sur iOS et Chrome sur iOS

Du côté des sites internet, la situation serait plus grave puisque, si l'on en croit Freakattack, 12,2 % des sites les plus visités selon Alexa seraient touchés. On y trouve par exemple ceux de la NSA, de la Maison-Blanche, du FBI ainsi que la page de Facebook Connect, bien que cette dernière ait déjà été mise à jour selon Cryptography Engineering. De son côté, Akamai a mis en ligne un billet de blog afin d'indiquer que son réseau avait d'ores et déjà été mis à jour, mais qu'il restait encore des risques sur ceux de certains de ses clients. On y retrouve également une commande permettant de tester son serveur.

Interrogé sur le sujet par nos confrères de Dark Reading, Ivan Ristic, directeur de l'ingénierie chez Qualys, indique que « l'attaque semble assez facile, conceptuellement [...] Dans la pratique, je ne pense pas que ce soit un très gros problème de sécurité » ajoute-t-il. Il faut en effet réunir plusieurs éléments en même temps : serveurs et clients vulnérables, casser la clé, et le tout avec une attaque « homme du milieu » qui n'est pas toujours facile à mettre en place.