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.
Commentaires (71)
#1
La tablette Android Lenovo que je viens de prendre est vulnérable..
#2
Je trouve ca un peu étrange qu’on dise “homme du milieu” et pas “homme au milieu” pour “man in the middle”
Généralement quand on parle “du milieu” c’est pour supposer un attachement à un groupe, environnement etc. alors que “au milieu” est bien la position.
#3
Oui, comme précisé dans l’actu Chrome sur Android est vulnérable " />
#4
C’est le navigateur qui est vulnérable, essaye Firefox ;)
#5
Hum… Mon Firefox 36 est annoncé comme vulnérable.
#6
#7
Super nouvelle, apparemment, tous mes navigateurs sont vulnérables…
Chrome me dit qu’il y a une mise à jour, on verra après… Mise à jour faite, toujours vulnérable…
Firefox, bah lui, non, pas de mise à jour, mais vulnérable.
IE est vulnérable, mais je m’attends pas à ce que ce soit corrigé avant mardi prochain…
#8
#9
Oui mais dans ce cas Gandalf ne devrait pas laisser passer ce genre d’attaque " />
#10
#11
je confirme
#12
#13
J’ai bien un firefox 36 aussi, mais ça l’indique vulnérable…
Chrome Version 41.0.2272.76 m est indiqué vulnérable aussi…
#14
Il est pourtant annoncé que la dernière version de Firefox est sûre… S’entends dernière version stable, et non bêta/Aurora.
Chromium, dans sa dernière build (319006) a le même problème.
A Contrario, Opera, dans sa dernière version stable (27.0.1689.76) est safe.
Edit : IE 11 est vulnérable aussi chez moi.
Hypothèse : l’antivirus qui analyse à la volée le HTTPS ?
#15
A priori d’après le test IE 11 et ff36 que j’ai dessus sont OK.
#16
firefox 37 - canal beta - windows 7 x64
#17
#18
Selon le test : sur mon Mac Yosemite :
Opéra : Vulnérable
Firefox : non vulnérable
Chrome : non vulnérable
Safari : vulnérable
#19
Possible car ni mon Firefox 36, ni mon IE11 (sous Win8.1) ne sont vulnérables.
#20
Du coup, si certains pouvaient m’expliquer pourquoi certains ont un resultat OK et d’autre non pour un meme navigateur (meme version)
OS?
#21
#22
un pirate peut décrypter les échanges de données sécurisées entre un serveur et navigateur web.
Tu voulais dire “déchiffrer” non ? " />
#23
De même que FF 36 sous Fedora 21
#24
#25
Précisions :Selon le test : sur mon Mac Yosemite : Opéra 27.0 : Vulnérable Firefox 36.0 : non vulnérable Chrome 41.0 : non vulnérable Safari 8.0.3 : vulnérable
#26
Test fait avec Firefox 36 et Avast.
Ça semble confirmé ton hypothèse.
#27
Y’a une MAJ Avast, j’installe, redémarre et teste.
#28
Non, c’est la bonne utilisation qui est faite ici.
#29
peut etre que l’OS compte aussi ?
Par exemple FF36 sous Win 7 est vulnérable (c’est mon cas) alors que sous Win8, il ne l’est pas ?
#30
Sous Windows 8.1 :
Chrome 40.0.2214.115 m : Non vulnérable
FireFox 36.0 : Non vulnérable
IE 11.0.9600.17631 : Non vulnérable
C’est étrange que pour ces mêmes versions certaines personnes n’ont pas le même résultat. Le test de freakattack.com est-il vraiment fiable ? :s
Edit: Ah oui effectivement, avec une suite de sécurité installée ça peut jouer… Je n’ai que le parefeu Windows et Windows Defender sur ma machine, pas de suite tierce.
#31
#32
FF 36 non vulnérable chez moi :)
Sinon, le bouton “Signaler” étant introuvable à son emplacement habituel , voila une petit coquille :
“nos constations”
Pour casser une clef 512 il suffit de quelques ordinateurs actuels du calcul distribué , des outils comme GGNFS / MSIEVE et d’un peu de temps (semaines).
#33
#34
Quand tu scroll, le bouton apparaît juste à coté de l’icone NXI, en haut à gauche.
Mais faut scroller un peu.
#35
Firefox 38a2 ne l’est pas
#36
c’est encore un petard mouillé ce truc
un serveur web bien configuré n’autorise plus cet algorithme depuis bien longtemps
donc, seul les serveur web mal configuré et/ou pas du tout à jour seront concerné
bref, un gros problème de compétence des admin reseau dans ce cas
#37
#38
#39
La preuve que non, tu actives Avast et paf!, tu as la faille !
Donc pour les navigateurs peut-être, mais il existent des milliers de logiciels qui utilisent des connexions SSL qui ont potentiellement le problème !
#40
comme le dis un des lien de l’article : openssl s_client -connect www.akamai.com:443 -cipher EXPORT
ou faire un check sur https://www.ssllabs.com/
et voir si le export rsa est dans la liste des ciphers
#41
si le serveur n’accepte pas l’export rsa, aucun problème –> les admin reseau doivent aurait du le desactiver depuis longtemps
#42
Perso sur linux Mint :
-Chrome 40.0.2214.115 non vulnérable
-Firefox 36 non vulnérable
#43
Apparemment la dernière màj d’Avast résout le soucis.
Certains logiciel de sécurité ont des retards dans leur mise-à-jour on dirait " />
#44
#45
comme je suis sur nginx pour le SSL termination et que j’ai limité pas mal les CIPHERS, je pense que ça joue pas mal sur la sécurité du bouzin à la base. " />
pour apache, je sais pas.
edit : vérifie surtout ta version d’openssl, c’est ça qui doit jouer!
#46
#47
Le site de la NSA est vulnérable ? j’attaque de suite.
#48
#49
#50
Non, c’est une attaque man in the middle - c’est le client qu’il faut vérifier.
#51
#52
J’ai failli le dire, sauf qu’en y réfléchissant, ce n’est pas juste une attaque de type MITM qu’il faudrait mettre en place pour y parvenir, mais posséder la clé de chiffrement d’un certificat racine accepté par le client, puisque si le serveur n’émet pas ce genre de certificat, il faudra en générer un correctement/suffisamment signé pour que le client n’y voie que du feu.
Le premier qui pense à SuperFish, il peut sortir… Bon bah je suis dehors si vous me cherchez… " />
#53
si il y a aucun algorithme en commun –> connection refusée
laisser des vieux algorithme sous pretexte d’un très vieux client en aurait besoin, c’est de la pure connerie. meme ie6/windowsxp a de meilleure algorithme, alors faut le laisser pour qui ?
meme mozilla, dans son guide en version “Old_backward_compatibility” l’a supprimé depuis longtemps
https://wiki.mozilla.org/Security/Server_Side_TLS#Old_backward_compatibility
c’est comme çà qu’on arrive à des problème de sécurité sans raison
#54
Ah mais je ne dis pas non plus qu’il faut le laisser côté serveur pour autant. Je dis juste que du point de vue utilisateur, il vaut mieux utiliser un client qui n’accepte pas ce genre de certificat plutôt que de juste faire confiance à la bonne configuration du serveur, sachant qu’il en restera toujours une partie qui n’est pas correctement configurée.
Donc à mon sens, la mise à jour des clients vulnérables est prioritaire, bien que la désactivation côté serveur soit elle aussi indispensable pour tout bon SysAdmin qui se respecte.
#55
Chez moi sous FF35 et Avast activé c’est OK… Très étrange effectivement.
#56
Une curiosité ? ? ? :
FF 36 nickel sous MacOs Mountain Lion mais
FF 36 vulnérable sous windows 7-32bits …
Pas encore essayé sous Nuxe.
Je ne comprends pas comment est réalisé le test. Quelqu’un a une idée ?
#57
il verifie juste la liste des ciphers que le navigateur propose
tu peux voir la liste simplement en testant ton navigateur ici :
https://www.ssllabs.com/ssltest/viewMyClient.html
#58
T’avais peut être installé sans le savoir la dernière MAJ Avast en arrière plan (maintenant, il ne demande plus de redémarrage, il attends).
Et effectivement, avec la nouvelle MAJ, c’est bon (enfin, sous FF36, pas encore testé les autres).
#59
ben c’est sur, faut aussi que les navigateur se décide à supprimer de leur liste les different cypher completement obsolète
le problème, c’est qu’ils le laissent pour une raison de compatibilité …
enfin, pour savoir se connecter au site qui ne propose rien de mieux, mais à un moment, faut dire stop quitte a supprimer l’acces a quelques site dont la securité est pourrie
#60
Le site lance deux requêtes vers deux serveurs distincts, l’un pour obtenir la liste des modes de chiffrement acceptés par le navigateur et le second spécialement adapté pour forcer l’utilisation du mode EXPORT. Si dans le premier cas, il un mode blacklisté est autorisé, le test échoue. Et si dans le second cas, la requête aboutie, ça veut dire que le navigateur est vulnérable à la faille FREAK, et donc le test échoue aussi.
Le plus probable dans ton cas, c’est que tu as un antivirus ou autre qui intercepte les données en HTTPS qui est lui-même vulnérable — voir précédents commentaires.
Édit : Oups, partiellement grillé… " />
#61
#62
Ok, merci pour ces informations …
" />
#63
Entièrement d’accord. " /> J’en ai profité pour faire un bon coup de nettoyage dans les options de mon navigateur d’ailleurs. " />
Le mieux, ça serait peut-être qu’ils bloquent d’office toutes les vieilles méthodes de chiffrement, tout en offrant la possibilité de pouvoir les réactiver temporairement pour un serveur non compatible après avoir affiché un gros message d’erreur, comme la plupart le font déjà pour les certificats non signés par une autorité de confiance… Sauf qu’au lieu de parler de confiance, il faudrait que le bouton indique clairement « J’ai bien conscience que cette connexion pourra être déchiffrée par un tiers malveillant », ça devrait suffisamment faire peur. " />
#64
#65
#66
Je ne peux pas m’en rendre compte. La Yoga que j’ai acheté en novembre à déjà passé 3 mois en réparation. Je l’attends toujours…." />
#67
Pluzun
Win7_FF36.0 " />
#68
Non absolument aucun rapport…
Firefox n’est pas vulnérable, ces faibles modes de chiffrement ne sont plus activés par défaut depuis la version 2 et le retrait total doit remonter à quelques années maintenant. Du côté d’Opera, ils ont même carrément été supprimés depuis la version 9.50, donc la faiblesse est bien connue depuis très longtemps.
En plus, Firefox n’utilise pas OpenSSL donc il n’est même pas concerné par la CVE 2015-0204.
Et le comble dans tout ça, c’est que Safari est justement vulnérable, comme dit dans l’article. Alors je ne sais pas s’il utilise son propre mécanisme pour SSL/TLS, mais s’il y a un navigateur qui a de grandes chances d’utiliser la bibliothèque native du système, c’est bien lui ! Et en général, ces bibliothèques ne font pas l’impasse sur certains modes, c’est le logiciel qui l’exploite qui va autoriser tels modes plutôt que d’autres.
Comme cela a déjà été dit dans les précédents commentaires, la véritable raison est que quelque chose d’autre intercepte les flux HTTPS et que ce quelque chose est justement vulnérable, typiquement un antivirus. Et comme ce n’est pas trop le genre de protection que l’on retrouve sous Linux ou Mac OS X, bah forcément on ne retrouve ce problème quasiment que sur Windows.
#69
La version 36.0.1 de Firefox corrige le pb sous Windows 7
#70
Apparament le problème est un poil plus compliqué, et le test fourni ici n’est pas complet. MS considère que cette faille touche d’une manière ou d’une autre à peu près tout le monde : https://technet.microsoft.com/en-us/library/security/3046015?f=255&MSPPError=-2147217396
Y a du patch qui va tomber à priori, OpenSSL ou pas…
#71
J’avais encore la 35.0.1 il n’y a pas longtemps et cette version n’était pas plus vulnérable. ;) Voir mon précédent commentaire où j’explique que la suppression de l’EXPORT ne date pas d’hier pour certains navigateurs.