Drown : la faille qui met en danger un tiers des serveurs HTTPS

Comme l'ont déjà montré Freak, LogJam ou encore Sloth, le support de technologies de chiffrement dépassées expose les utilisateurs à des risques. En l'occurrence cette fois avec le protocole TLS, qui sécurise la plupart des connexions HTTPS sur le Web, mais aussi un grand nombre de serveurs mail. Une équipe de chercheurs vient en effet de montrer que le support de SSL v2 - un protocole sorti en 1995 et remplacé en 1996 en raison de. sa vulnérabilité - pouvait être exploité par des hackers pour espionner des sessions chiffrées par TLS.

Dans leur étude, les scientifiques démontrent la réalité d'une attaque baptisée Drown (pour Decrypting RSA with Obsolete and Weakened eNcryption) exposant en premier lieu les serveurs HTTPS supportant SSL v2 ou partageant une clef privée RSA avec un autre serveur le supportant (par exemple un serveur d'e-mail). Jusqu'à présent, les experts estimaient que le fait que les clients - comme les navigateurs - ne supportent plus ce protocole vieillissant écartait tout danger. La quinzaine de chercheurs, issus notamment de l'Université de Tel Aviv, de l'Université du Münster, de l'Université de la Ruhr, de celle de Pennsylvanie ou du Michigan, prouvent qu'il n'en est rien. Et que le simple support du protocole sur le serveur suffit à exposer des sessions chiffrées avec les dernières technologies, comme TLS. Un comble.

440 dollars sur AWS

Pour mener à bien l'attaque, un assaillant doit pouvoir observer plusieurs centaines de connexions TLS entre une victime et un serveur vulnérable, soit en monitorant les accès sur une longue période soit en forçant un navigateur à se connecter de façon répétée via un code Javascript malicieux. Pour que Drown puisse être employé, l'établissement de la communication chiffrée (le handshake en jargon) doit par ailleurs reposer sur une clef RSA : pas réellement une contrainte, RSA restant la technologie la plus populaire dans les implémentations TLS.

Ces prérequis en poche, l'assaillant pourra se connecter au serveur via SSL v2 et devra lui envoyer des messages d'établissement de connexion conçus spécifiquement sur la base des cryptogrammes RSA obtenus en espionnant les accès TLS. C'est la réponse du serveur à ces tentatives d'accès qui va permettre à l'assaillant de déduire la clef privée employée par le client lors de ses connexions TLS. L'attaque est facilitée par les restrictions à l'exportation sur la cryptographie qu'avait mises en place l'administration Clinton dans les années 90. « Comme Freak ou Logjam, nos résultats montrent les dégâts que produisent les technologies de cryptographie délibérément affaiblies pour l'export sur la sécurité des systèmes modernes, y compris des décennies après que ces régulations influençant le design originel aient été abolies », écrivent les chercheurs.

[A lire aussi. Déblocage de l'iPhone : John McAfee s'apprête à manger une chaussure]

Dans le pire des cas, les chercheurs calculent qu'ils ont besoin d'environ 1 000 handshakes TLS, de 40 000 connexions SSL v2 de test et de huit heures de puissance de calcul sur AWS (soit 440 dollars d'achat) pour déduire ladite clef. L'attaque est donc relativement sophistiquée - même si établir 10 000 requêtes SSL v2 sur un serveur Apache 2.4 demande moins de 10 secondes -, et limitée à la session d'un utilisateur, mais elle est loin d'être hors de portée d'organisations bien financées.

Drown facilitée par une faille OpenSSL

D'autant qu'elle est facilitée en cas d'usage d'une version dépassée de la librairie OpenSSL, une implémentation très répandue de TLS. Une vulnérabilité comblée en mars 2015 (CVE-2016-0703) réduit ainsi grandement le temps - et donc le coût - de mise en oeuvre de Drown. Les chercheurs calculent qu'il suffit alors d'un simple PC et de moins d'une minute pour mettre en place leur technique. Or, de nombreux administrateurs - y compris de sites en vue - n'ont toujours pas appliqué le correctif comblant cette faille.

Globalement, en additionnant les serveurs exposés directement et ceux qui le sont via le partage d'une clef privée avec un autre serveur Web ou d'e-mail, les universitaires calculent qu'un serveur HTTPS sur trois est exposé. S'y ajoutent plus de 930 000 serveurs d'e-mail (SMTP, POP, IMAP) vulnérables. Pour se prémunir de Drown - qui n'expose pas la clef privée du serveur, mais permet de déchiffrer des sessions, exposant potentiellement des mots de passe, des informations financières, etc. -, les administrateurs ne devront heureusement pas remplacer leurs certificats, mais simplement s'assurer de désactiver le support de SSL v2 sur leurs serveurs. Les chercheurs mettent à disposition des instructions pour y parvenir avec les librairies TLS et les serveurs Web les plus courants. Notons que les dernières versions d'OpenSSL (1.0.2g et 1.0.1s), développées en coordination avec l'équipe à l'origine de Drown, rendent impossible l'activation de SSL v2 sans accord explicite de l'administrateur.

Voyages-SNCF et les impôts dans le même wagon

Attention toutefois à bien vérifier que la vulnérabilité ne résulte pas d'un partage de la clef privée

du serveur HTTPS avec une autre machine, notamment un serveur d'e-mail supportant, lui, SSL v2. Une pratique courante dans les entreprises. Pour vérifier ce point, les chercheurs mettent à disposition un outil de test permettant aux administrateurs de scanner la perméabilité de leurs serveurs.

Une moulinette qui permet de vérifier l'exposition à Drown de certains domaines bien connus comme Yahoo.com, Voyages-SNCF.com (qui n'a pas corrigé la CVE-2016-0703 d'OpenSSL selon l'outil), Dailymotion.com (même remarque) ou Impots.gouv.fr (idem pour certains serveurs). Les chercheurs à l'origine de l'étude estiment que 25 % du million de sites HTTPS les plus fréquentés dans le monde (sur la base du classement Alexa) sont exposés à la faille.

[Ne loupez rien de l'actualité IT : abonnez-vous à nos newsletters]

Pour l'heure, les chercheurs indiquent n'avoir aucun indice leur permettant d'affirmer que la vulnérabilité est déjà exploitée par des assaillants.

A lire aussi :

Le chiffrement par TLS victime de. la paresse

LogJam : nouvelle faille dans le chiffrement des sites Web

Freak affaiblit le chiffrement des navigateurs Apple et Android

L'Inria et Microsoft publient une implémentation de référence de TLS

E. Thomé, Inria : « Les clefs de chiffrement de 768 bits ne suffisent plus »

Crédit Photo : Isak55-Shutterstock