Attaque de noyade

L' attaque DROWN ( Decrypting RSA with Obsolete and Weakened eNcryption ) est un bug de sécurité interprotocole qui attaque les serveurs prenant en charge les suites de protocoles SSLv3/ TLS modernes en utilisant leur prise en charge du protocole SSL v2 obsolète et non sécurisé pour exploiter une attaque sur les connexions utilisant des protocoles à jour qui seraient autrement sécurisés. DROWN peut affecter tous les types de serveurs qui offrent des services chiffrés avec SSLv3/TLS tout en prenant en charge SSLv2, à condition qu'ils partagent les mêmes informations d'identification de clé publique entre les deux protocoles. De plus, si le même certificat de clé publique est utilisé sur un autre serveur prenant en charge SSLv2, le serveur TLS est également vulnérable en raison de la fuite par le serveur SSLv2 d'informations clés qui peuvent être utilisées contre le serveur TLS.

Les détails complets de DROWN ont été annoncés en mars 2016, ainsi qu'un correctif qui désactive SSLv2 dans OpenSSL ; la vulnérabilité a reçu l'ID CVE - 2016-0800. Le correctif seul ne suffira pas à atténuer l'attaque si le certificat peut être trouvé sur un autre hôte SSLv2. La seule contre-mesure viable est de désactiver SSLv2 sur tous les serveurs.

Les chercheurs ont estimé que 33 % de tous les sites HTTPS étaient affectés par cette vulnérabilité au 1er mars 2016.

DROWN est l'acronyme de « Decrypting RSA with Obsolete and Weakened eNcryption » (Décryptage RSA avec un chiffrement obsolète et affaibli). Il exploite une vulnérabilité dans la combinaison des protocoles utilisés et la configuration du serveur, plutôt qu'une erreur d'implémentation spécifique. Selon les découvreurs, l'exploit ne peut pas être corrigé en apportant des modifications aux logiciels clients tels que les navigateurs Web.

L'exploit comprend une attaque par texte chiffré choisi avec l'utilisation d'un serveur SSLv2 comme oracle de Bleichenbacher . SSLv2 fonctionnait en chiffrant le secret principal directement à l'aide de RSA, et les suites de chiffrement d'exportation de 40 bits fonctionnaient en chiffrant uniquement 40 bits du secret principal et en révélant les 88 bits restants sous forme de texte brut. Le texte chiffré RSA chiffré SSLv3/TLS de 48 octets est « découpé » en parties de 40 bits et est ensuite utilisé dans le message ClientMasterKey SSLv2, que le serveur traite comme la partie de 40 bits du secret principal SSLv2 (les 88 bits restants peuvent être n'importe quelle valeur envoyée par le client sous forme de texte brut). En forçant brutalement le chiffrement de 40 bits, le message ServerVerify peut être utilisé comme oracle. L'attaque de preuve de concept a démontré comment les configurations multi-GPU et le cloud computing commercial pouvaient effectuer une partie des calculs de décryptage, pour un coût d'environ 18 000 $ pour la configuration du GPU et un coût par attaque de 400 $ pour le cloud. Une attaque réussie fournira la clé de session pour une négociation TLS capturée.

Les enquêteurs, qui ont décrit l'attaque ci-dessus comme une attaque DROWN générale, ont également découvert une faiblesse spécifique dans l'implémentation OpenSSL de SSLv2 qui a permis ce qu'ils ont appelé une attaque DROWN spéciale . Cela a considérablement réduit l'effort requis pour casser le chiffrement, rendant possibles des attaques de type man-in-the-middle en temps réel qui ne nécessitaient que des ressources informatiques modestes. L'implémentation OpenSSL de SSLv2 jusqu'en 2015 ne vérifiait pas que les longueurs de clé claires et chiffrées étaient correctes, ce qui permettait par exemple de chiffrer seulement 8 bits du secret maître. Jusqu'en 2015, OpenSSL écrasait également les mauvais octets dans le secret maître SSLv2 lors de sa tentative de contre-mesure de Bleichenbacher. Jusqu'en 2016, OpenSSL négociait également avec plaisir des suites de chiffrement SSLv2 désactivées. Contrairement à SSLv3 et aux versions ultérieures, dans SSLv2, le client était censé choisir dans une liste de suites de chiffrement proposées par le serveur, mais OpenSSL autorisait l'utilisation de suites de chiffrement non répertoriées.

Les premiers rapporteurs du bug étaient les chercheurs en sécurité Nimrod Aviram et Sebastian Schinzel.

Pour se protéger contre DROWN, les opérateurs de serveur doivent s'assurer que leurs clés privées ne sont utilisées nulle part avec un logiciel serveur qui autorise les connexions SSLv2. Cela inclut les serveurs Web, les serveurs SMTP, les serveurs IMAP et POP et tout autre logiciel prenant en charge SSL/TLS.

Le groupe OpenSSL a publié un avis de sécurité et un ensemble de correctifs destinés à atténuer la vulnérabilité en supprimant la prise en charge des protocoles et chiffrements obsolètes. Cependant, si le certificat du serveur est utilisé sur d'autres serveurs prenant en charge SSLv2, il reste vulnérable, tout comme les serveurs corrigés.

De nombreuses sources ont recommandé que la vulnérabilité soit corrigée dès que possible par les opérateurs du site.