DROWN : quand des failles SSLv2 permettent de décrypter des connexions TLS

Des chercheurs viennent de publier les détails d'une importante faille de sécurité baptisée DROWN. En utilisant des faiblesses de SSLv2, elle permet de décrypter des connexions chiffrées utilisant TLS. De plus, une brèche d'OpenSSL peut accélérer grandement les calculs. Dans certains cas, l'opération prend moins d'une minute.

Au cours des derniers mois, la découverte et la publication de failles critiques se font à un rythme relativement soutenu, et ce n'est pas fini. En effet, après Heartbleed, Ghost, POODLE, FREAK et Logjam (entre autres), c'est au tour de DROWN de faire parler d'elle (c'est la mode de donner un petit nom et un logo aux failles de sécurité). Les conséquences peuvent être fâcheuses puisqu'il est question de décrypter rien de moins que « toutes les communications entre les utilisateurs et un serveur », ce qui comprend notamment les mots de passe et les coordonnées bancaires. Selon l'équipe de chercheurs à l'origine de cette découverte, 33 % des serveurs HTTPS dans le monde seraient vulnérables, une paille.

Encore une histoire qui remonte aux années 90

Pour commencer, DROWN est l'acronyme de Decrypting RSA with Obsolete and Weakened eNcryption, ou bien décrypter RSA avec un chiffrement faible et obsolète, dans la langue de Molière. Comme dans le cas de FREAK et de Logjam, le cœur du problème remonte aux années 90, une époque où les États-Unis limitaient volontairement la taille des clés de chiffrement pour l'exportation afin de se laisser la possibilité de décrypter un message si besoin. Le fautif est en effet le protocole SSLv2 qui date de 1995 et n'offre pas une sécurité suffisante. Même si on le savait depuis longtemps, l'ensemble prend une autre tournure aujourd'hui.

Ce protocole a d'ailleurs été officiellement abandonné en mars 2011 par l'IETF (une décision qui arrivait déjà très tard). Même son de cloche chez Olivier Levillain de l'ANSSI qui, en 2012, indique sans détour que « la version SSLv2 est dangereuse et ne doit pas être employée ». Aujourd'hui, SSLv3 doit également être abandonné au profit de TLS, qui est d'ailleurs généralement utilisé. 

Quand SSLv2 permet de casser une connexion TLS

Toutefois, « en raison d'erreurs de configurations, de nombreux serveurs prennent toujours en charge SSLv2 » expliquent les chercheurs. Ils ajoutent que « cela n'a pas d'importance dans la pratique, car aucun navigateur à jour n'utilise SSLv2. Par conséquent, même si SSLv2 est connu pour être mal sécurisé, continuer à le supporter n'était pas considéré comme un problème de sécurité jusqu'à maintenant ». Mais conserver une technologie obsolète n'est jamais une bonne idée, l'histoire va nous le prouver une fois de plus.

En effet, c'est justement sur l'omniprésence de ce maillon faible (SSLv2) que repose la faille DROWN : « Elle permet à un attaquant de décrypter les connexions TLS modernes entre des navigateurs à jour et des serveurs par l'envoi de "sondes" à un serveur qui prend en charge SSLv2 et qui utilise la même clé privée ».

Pour simplifier, un pirate n'a besoin que de « casser » du SSLv2 pour ensuite accéder aux données échangées via le protocole TLS. Tous les détails techniques se trouvent par ici.

@cabusar @gcouprie La nouveauté de DROWN, c’est l’usage d’un serveur tiers et non du serveur cible.

— Aeris (@aeris22) March 1, 2016

Une variante de l'attaque de Bleichenbacher

L'équipe de chercheurs explique que DROWN est une nouvelle version de l'attaque cryptographique du suisse Daniel Bleichenbacher. Dans son état des lieux et recommandations sur le SSL/TLS (page 8), Olivier Levillain de l'ANSSI la décrit assez simplement.

Sans entrer dans tous les détails, un attaquant établit de très nombreux échanges SSL avec un serveur et analyse les codes d'erreurs retournés par le serveur afin de décrypter le ClientKeyExchange du serveur et ainsi trouver le Pre-master secret. « Il pourra alors obtenir les clés de session et déchiffrer la totalité du trafic capturé » explique le chercheur de l'ANSSI.

Dans le cas de DROWN, un pirate devra commencer par observer « plusieurs centaines d'échanges » (voir des dizaines de milliers) entre un utilisateur et un serveur, ce qui peut prendre beaucoup de temps. Afin d'accélérer cette opération, il est possible de créer un site web spécialement conçu pour établir de nombreuses connexions en arrière-plan.

« Les connexions peuvent utiliser n'importe quelle version du protocole SSL/TLS, y compris TLS 1.2, tant qu'ils utilisent la méthode d'échange de clés RSA » expliquent les chercheurs à l'origine de la découverte de DROWN. Le pirate se connecte ensuite au serveur SSLv2 (soit sur la même machine, soit sur un autre serveur qui utilise le même certificat) et envoie des demandes de prises de contacts basées sur les messages qui viennent d'être interceptés (ils sont modifiés d'une certaine manière, mais le détail n'est pas précisé pour le moment afin de limiter les risques). Le serveur SSLv2 renverra alors un message différent selon qu'il arrive ou non à déchiffrer ce message. À ce moment-là, le pirate ne peut pas encore connaitre le contenu exact du message, mais il engrange des détails sur la clé utilisée. En répétant l'opération de nombreuses fois, le contenu d'une connexion peut être décrypté. 

Moins d'une minute pour déchiffrer une connexion à cause d'une faille OpenSSL

Cette fuite de données peut prendre deux formes suivant la configuration du serveur. « Dans la variante la plus générale de DROWN, l'attaque exploite une faiblesse fondamentale du protocole SSLv2 sur l'exportation cryptographie introduite dans les années 90 afin de se conformer aux restrictions du gouvernement des États-Unis ». Le chiffrement des clés de sessions RSA n'est alors plus que de... 40 bits, ce qui laisse un nombre considérable de possibilités, sans rien d'insurmontable.

« Environ 40 000 connexions de la sonde et 2^50 opérations sont nécessaires pour déchiffrer 1 connexion TLS de la victime sur 900 ». D'après les estimations des chercheurs, cela prendrait moins de 8h et coûterait environ 440 dollars pour mener à bien ce genre de calcul sur des instances EC2 d'Amazon. Bien évidemment, une organisation disposant d'une grosse capacité de calcul peut également se servir de ses propres infrastructures.

Mais il est possible de grandement accélérer les opérations dans certains cas. En effet, si le serveur utilise une version d'OpenSSL plus ancienne que les 1.0.2a, 1.0.1m, 1.0.0r ou 0.9.8zf, alors l'attaque prendra « moins d'une minute à l'aide d'un seul PC » (il n'est plus question que de 17 000 connexions pour obtenir la clé de 1 connexion TLS sur 260). En cause, une faille d'OpenSSL identifiée pour la référence CVE-2016-0703 et qui vient d'être corrigée. Notez que ce ne sont pas les seuls changements dans OpenSSL puisque pas moins de huit correctifs sont référencés dans la fournée du 1er mars.

Dans ce second cas, la rapidité d'exécution permet de mettre en place une attaque de type homme du milieu, ce qui autorise le pirate à se faire passer pour le serveur auprès du client. Il accède alors à toutes les informations envoyées par ce dernier et peut lui même renvoyer ce qu'il veut en se faisant passer pour le serveur. Là encore, les chercheurs annoncent qu'ils ont « été en mesure d'exécuter une attaque de ce type en moins d'une minute sur un seul PC ».

On notera tout de même un point qui pourrait presque faire office de bonne nouvelle : « DROWN ne permet à un attaquant de décrypter qu'une connexion à la fois. Le pirate ne récupère pas la clé privée du serveur ». Il n'est donc pas nécessaire de changer de certificat.

Comment savoir si un serveur est vulnérable ?

Pour qu'un serveur puisse être attaqué via la faille DROWN, il suffit que l'une des deux possibilités suivantes soit vérifiée :

• Il autorise les connexions SSLv2 (ce qui représenterait 17 % des serveurs HTTPS selon les chercheurs)
• Il partage le même certificat qu'un autre serveur qui supporte SSLv2 (16 % des serveurs HTTPS selon les chercheurs)

Problème, il n'est pas toujours facile de savoir si SSLv2 est pris en charge ou non par un serveur. Un outil comme SSLLabs permet d'obtenir un premier retour, mais uniquement sur le HTTPS. Or, si un autre serveur (type SMTP, IMAP, POP, etc.) utilise le même certificat et supporte SSLv2, le serveur principal est lui aussi vulnérable, même si ce dernier n'accepte que tu TLS 1.2 par exemple.

@Xowap SSLlabs ne permet pas de tester https://t.co/dLDulCxH5P, seulement https://t.co/iCy4fnvVlJ pile la faille courante avec Drown.

— Stéphane Bortzmeyer (@bortzmeyer) March 1, 2016

Une petite application a été mise en ligne sur Github (elle ne peut détecter qu'un seul port à la fois), ainsi qu'un outil en ligne (pensez à vérifier tous vos serveurs sans exception) :

• Vérifier la vulnérabilité DROWN sur des serveurs

Comme le résume le spécialiste des réseaux Stéphane Bortzmeyer sur son blog, « bien des gens croient que, puisque leur serveur HTTPS n'accepte pas SSLv2, ils sont en sécurité. Rien n'est plus faux [...] pour effectuer cette attaque, il suffit que le certificat du site visé (et donc la clé privée) soit disponible sur un autre site, qui, lui, accepte SSLv2 ».

Il ajoute avoir été surpris car ce genre de situation est finalement assez fréquent, notamment parce que « le modèle de financement des autorités de certification encourage à acheter le moins de certificats possible, et donc à les utiliser sur plusieurs serveurs, ou bien sur le serveur de production et sur celui de développement ».

Comment se protéger ? Faut-il mettre à jour son navigateur ? 

DROWN est une faille côté serveur et mettre à jour son navigateur ne servira à rien pour se protéger. Côté client, il n'y a donc rien de particulier à faire.

Pour les serveurs, il faut éradiquer la prise en charge de SSLv2 et vérifier qu'aucun serveur partageant le même certificat n'autorise ce protocole complètement dépassé des années 90. Il faut également penser à vérifier sa version d'OpenSSL à cause d'une autre faille (CVE-2015-3197) qui a été corrigée dans les versions 1.0.1r et 1.0.2f. Elle permettait quand même de forcer l'utilisation de SSLv2 dans certains cas.

C'est également le bon moment pour changer sa politique de sécurité et arrêter de partager des certificats sur plusieurs serveurs. De plus amples détails sont donnés sur le site de DROWN.

Pas uniquement des serveurs de prod. Tout ce qui touche un bout de paquet IP dans sa vie doit être aussi sécurisé que votre prod. #LT

— Aeris (@aeris22) March 1, 2016

Faut-il paniquer tout de suite ? 

Comme à chaque fois qu'une faille de ce genre remonte à la surface, la question de sa dangerosité et de sa gravité se pose. Est-on face à une brèche du type Heartbleed qui laisse n'importe qui récupérer des données sensibles simplement en entrant l'adresse d'un serveur, ou plutôt dans une situation proche de FREAK qui nécessitait un gros effort pour accéder aux données ?

La dangerosité de Drown n'est pas facile à évaluer reconnait Stéphane Bortzmeyer sur son blog : « On est dans le cas classique en sécurité du verre que l'optimiste voit à moitié plein alors que le pessimiste le voit à moitié vide. L'optimiste va faire remarquer que l'exploitation effective de Drown est très difficile, dans les conditions du monde réel (en laboratoire, ça marche toujours mieux). Le pessimiste rétorquera que les attaques ne vont toujours qu'en s'améliorant ». La réalité se trouve probablement entre les deux.

De leur côté, les chercheurs expliquent qu'ils ne pensent pas que la faille soit activement exploitée pour le moment et ils n'ont pas publié de prototype permettant d'en tirer parti, car « il y a encore trop de serveurs vulnérables ». Nul doute que maintenant qu'elle est connue, des pirates vont s'engouffrer dans la brèche.

La charge des chercheurs contre le gouvernement américain

En guise de conclusion, les chercheurs s'en prennent directement au gouvernement américain et à sa gestion du chiffrement dans les années 90, qui a des répercussions importantes 20 ans plus tard :

Pour la troisième fois en un an, une faille de sécurité majeure d'Internet résulte de la façon dont la cryptographie a été affaiblie par les politiques gouvernementales américaines qui limitaient l'exportation cryptographique jusqu'à la fin des années 90.

Bien que ces restrictions, évidemment conçues pour faciliter le décryptage par la NSA de communications de personnes à l'étranger, aient été assouplies il y a près de 20 ans, la cryptographie affaiblie reste dans les spécifications des protocoles et continue aujourd'hui d'être prise en charge par de nombreux serveurs, ajoutant de la complexité - et une potentielle grave défaillance - à certaines des fonctionnalités de sécurité les plus importantes d'Internet.

Bien évidemment, en trame de fond il est question du débat actuel sur le chiffrement et sur l'instauration de portes dérobées pour permettre aux autorités d'accéder aux données. Pour les chercheurs, « l'affaiblissement de la cryptographie représente un risque énorme pour l'ensemble de notre sécurité » et DROWN en est l'un des exemples, avec FREAK et Logjam. En effet, avec une porte dérobée installée sur un logiciel, la question n'est pas de savoir si elle sera découverte et exploitée, mais quand.