Drown : un tiers des serveurs HTTPS est vulnérable à une nouvelle faille critique
Vous vous souvenez de Heartbleed ?
En effet, OpenSSL, via les algorithmes cryptographiques qu'il utilise, a pour seul et unique but d'assurer la confidentialité et l'intégrité des données circulant entre l'utilisateur et le service sur lequel celui-ci veut se rendre.
Aussi est-il tout à fait primordial de déceler et de corriger les brèches au plus vite, afin de préserver la protection des échanges sur le net. Par ricochet, cela explique aussi pourquoi la détection d'une faille critique, comme Heartbleed ou Poodle (qui est vulnérabilité située non pas dans OpenSSL, mais dans l'un des protocoles mis en œuvre par la bibliothèque, à savoir SSL3.0), provoque un tel émoi. C'est en effet à chaque des millions de sites web et d'internautes qui sont menacés.
À cette liste, il faut maintenant inclure l'attaque Drown (Decrypting RSA using Obsolete and Weakened eNcryption), qui concerne de nombreux sites web de premier plan comme Yahoo, Alibaba, Dailymotion, BuzzFeed, Flickr, MediaFire, Groupon, Samsung, 4Shared, Asus ou encore Le Monde, pour ne citer que les exemples les plus parlants. Mais il ne faut pas croire que les sites les plus fréquentés sont les seuls affectés. En réalité, ce sont des millions de sites web qui sont affectés.
La vulnérabilité Drown
Concrètement, Drown est une brèche qui exploite les faiblesses du protocole SSL 2.0 (ou SSLv2) que certains serveurs utilisent pour établir une connexion sécurisée. Exploitée par une personne malveillante, cette brèche peut potentiellement servir à déchiffrer presque instantanément des communications chiffrées en HTTPS et ainsi permettre à l'assaillant d'intercepter des informations sensibles, comme des mots de passe ou des indications bancaires (un numéro de carte bancaire, par exemple).
Les chercheurs expliquent en effet qu'ils ont été capables d'exécuter l'attaque contre des versions OpenSSL qui sont vulnérables à la faille CVE-2016-0703 [Divide-and-conquer session key recovery in SSLv2] en moins d'une minute et en utilisant un seul PC. « Même pour les serveurs qui ne disposent pas de ces bugs particuliers, la variante générale de l'attaque, qui fonctionne contre n'importe quel serveur SSLv2, peut être réalisée en moiis de 8 heures pour un coût total de 440 dollars », en déplaçant la procédure de calcul sur des solutions de cloud computing, comme Amazon EC2.
D'après eux, il n'y a pas de raison de penser que l'attaque Drown était utilisée avant la publication de leur papier. En revanche, maintenant que la vulnérabilité est publique, il faut craindre que celle-ci commencera à être exploitée dans les heures et les jours à venir, par des personnes mal intentionnées, par des groupes ou, pourquoi pas, des agences de renseignement (rien ne dit toutefois que certaines d'entre elles, comme la NSA, n'était pas déjà au courant de cette vulnérabilité).
Des millions de serveurs en péril
Les auteurs de la publication précisent que certaines variantes de l'attaque Drown peuvent être utilisées pour réaliser des attaques de type homme du milieu contre TLS et que la confidentialité persistante (PFS), qui est une propriété en cryptographie qui garantit que la découverte par un adversaire de la clé privée d'un correspondant ne compromet pas la confidentialité des communications passées, ne fonctionne pas.
« La forme active de l'attaque de l'homme du milieu concernant cette attaque permet à un assaillant de viser les serveurs et les clients qui préfèrent des méthodes d'échange de clé non-RSA », précisent les chercheurs.
Au total, plus de 2,3 millions de serveurs supportant le chiffrement (HTTPS) avec des certificats électroniques sont vulnérables à un certain type d'attaque (« special Drown »), tandis que 3,5 millions de serveurs HTTPS sont quant à eux exposés à l'autre type d'attaque (« general Drown »). Selon les évaluations de l'équipe derrière le site dédié à cette faille, un tiers de l'ensemble des serveurs HTTPS est vulnérable à l'attaque. C'est considérable.
Comment ça marche ?
L'affaire, sérieuse, a conduit Matthew Green, un professeur de cryptographie travaillant auprès de l'université Johns-Hopkins, à consacrer un long article de blog pour détailler sur le plan technique les tenants et les aboutissants de cette découverte. À cette occasion, il n'a pas manqué de décocher quelques flèches en direction de ceux qui ont contribué à faire émerger un tel bug.
« En bref, en raison d'une série d'erreurs stupides de la part d'un grand nombre de personnes, Drown signifie que les connexions TLS d'une énorme et déprimante part du web (et des serveurs de mail, des VPN, etc) sont fondamentalement exposés à une attaque provenant d'adversaires relativement modestes », écrit-il.
« Drown est un exemple classique d'attaque cross-protocoles. Ce type d'attaque exploite des bugs dans une implémentation de protocole (SSLv2) pour attaquer la sécurité des connexions établies avec un protocole entièrement différent -- en l'occurrence, TLS ». Rien d'étonnant, d'une certaine façon : SSLv2 a été conçu au milieu des années 90. Depuis, plusieurs progrès ont été accomplis, avec l'apparition de SSLv3 mais surtout l'émergence du protocole TLS (versions 1.0, 1.1 et 1.2, la version 1.3 étant en cours d'élaboration).
« Plus concrètement, l'attaque Drown est basée sur l'observation déterminante que si SSLv2 et TLS supportent chacun le chiffrement RSA, TLS se défend correctement contre certaines attaques bien connues contre ce chiffrement, alors que les suites d'exportation de SSLv2 ne le font absolument pas », continue Matthew Green.
Ce qu'il est possible de faire
Il existe toutefois plusieurs solutions pour contre la menace que pose Drown. Il est possible par exemple de configurer son pare-feu de façon à filtrer le trafic chiffré avec SSLv2. Il est aussi recommandé de veiller à ce que les clés privées des gestionnaires de serveurs ne sont pas utilisées ailleurs avec le logiciel serveur qui permet des connexions SSLv2. Mais le plus sûr reste de procéder à la mise à jour d'OpenSSL, Microsoft IIS (Windows Server), Network Security Services (NSS), Apache, Postfix ou Nginx, en fonction du cas de figure qui se présente.
Quant aux internautes ou aux éditeurs de navigateurs, ces derniers n'ont rien à faire si ce n'est espérer que les gérants de serveurs ne tardent pas à prendre les mesures qui s'imposent. « Il n'y a rien, concrètement, que les navigateurs web ou les autres logiciels du côté de l'internaute peuvent faire pour empêcher Drown. Seuls les responsables de serveurs sont en mesure d'agir pour se protéger contre l'attaque ». Il reste à savoir si le message sera entendu.