web-dev-qa-db-fra.com

Qu'est-ce que DROWN et comment ça marche?

Il y a un nouveau attaque récente"sur TLS"nommé"DROWN" . Je comprends qu'il semble utiliser de mauvaises demandes SSLv2 pour récupérer des clés statiques (certificat).

Ma question est: Comment?

Comment pouvez-vous récupérer le chiffrement statique ou les clés de signature à l'aide de SSLv2?

Questions bonus: Comment puis-je empêcher l'attaque de s'appliquer à moi en tant qu'administrateur de serveur? Comment l'attaque a-t-elle pu apparaître en premier lieu?

tlsopensslattack-prevention
162
SEJPM

Pour comprendre l'attaque, il faut rappeler l'attaque de Bleichenbacher de la fin du 20e siècle. Dans cette attaque, l'attaquant utilise le serveur cible comme un Oracle. Lors de l'utilisation d'un échange de clés basé sur RSA, le client est censé envoyer une valeur secrète (le "secret pré-maître") chiffrée avec la clé publique du serveur, en utilisant PKCS # 1 remplissage v1.5 (appelé "type 2"). L'attaque de Bleichenbacher reposait sur l'envoi de valeurs soigneusement conçues à la place d'un message correctement chiffré et observait la réaction du serveur. Le serveur peut répondre (la plupart du temps) avec une erreur indiquant "J'ai traité cela mais cela n'a pas produit un remplissage correct PKCS # 1 v1.5 type 2"; mais parfois, le déchiffrement semble fonctionner et le serveur procède à tout ce qu'il a obtenu. L'attaquant voit cette différence de comportement et gagne ainsi un tout petit peu d'informations sur la clé privée. Après environ un million de connexions, l'attaquant en sait suffisamment pour effectuer un déchiffrement arbitraire et ainsi interrompre une session précédemment enregistrée.

Cette attaque est du même type, mais avec une nouvelle technique qui s'appuie sur les spécificités de SSL 2.0. SSL 2.0 est une ancienne version de protocole qui présente plusieurs défauts graves et ne doit pas être utilisée. Il est obsolète depuis plus de 15 ans. Il a même été formellement interdit en 2011. Néanmoins, certaines personnes prennent toujours en charge SSL 2.0. Pire encore, ils le prennent en charge avec des suites de chiffrement dites "d'exportation" où la force de chiffrement est réduite à environ 40 bits.

Donc l'attaque fonctionne un peu comme ceci:

  1. L'attaquant observe une session SSL/TLS cryptée (une session moderne et robuste, par exemple TLS 1.2) qui utilise l'échange de clés RSA, et il souhaite la décrypter. Toutes les sessions SSL/TLS ne se prêtent pas à l'attaque comme décrit; il y a une probabilité d'environ 1/1000 que l'attaque fonctionne. L'attaquant devra donc rassembler environ un millier de sessions cryptées et finira par percer l'une d'entre elles. Les auteurs soutiennent que dans une configuration qui ressemble à celles de CRIME et BEAST (Javascript hostile qui déclenche des connexions invisibles en arrière-plan), cette collecte peut être automatisée.

  2. Le serveur utilise négligemment la même clé privée RSA pour un système SSL 2.0 (peut-être le même serveur, peut-être un autre système logiciel qui peut implémenter un autre protocole, par exemple un serveur de messagerie). L'attaquant a la possibilité d'essayer de parler à cet autre système.

  3. L'attaquant commence une prise de contact SSL 2.0 avec ce système, en utilisant comme ClientMasterKey message une valeur dérivée de celle que l'attaquant veut décrypter. Il demande également l'utilisation d'une suite de chiffrement d'exportation 40 bits.

  4. L'attaquant observe la réponse du serveur et force brutalement la valeur 40 bits fournie par le serveur lorsqu'il a déchiffré la valeur envoyée par l'attaquant. À ce stade, l'attaquant connaît une partie du résultat du traitement de sa valeur artificielle par le serveur avec sa clé privée. Cela donne indirectement un peu d'informations sur le message chiffré qui intéresse vraiment l'attaquant.

  5. L'attaquant doit effectuer les étapes 3 et 4 environ plusieurs milliers de fois, afin de récupérer le secret pré-maître chiffré de la session cible.

Pour les détails mathématiques, lisez l'article .

Conditions d'application:

  • La connexion doit utiliser l'échange de clés RSA. L'attaque, comme décrit, ne peut pas faire grand-chose contre une connexion qui utilise l'échange de clés DHE ou ECDHE (ce qui est recommandé de toute façon pour secret avancé ).

  • La même clé privée doit être utilisée dans un système qui implémente SSL 2.0, accessible à l'attaquant, et qui accepte en outre de négocier une suite de chiffrement "d'exportation".
    Remarque : Si OpenSSL est utilisé et non corrigé pour CVE-2015-3197 , même si "exporter "Les suites de chiffrement sont désactivées, un client malveillant peut toujours négocier et effectuer une prise de contact avec ces suites de chiffrement désactivées.

  • L'attaquant doit pouvoir établir quelques milliers de connexions à ce système SSL 2.0, puis exécuter une force brute de 40 bits pour chacun; le coût informatique total est d'environ 250 opérations.

Il faut bien comprendre que le 250 l'effort est pour chaque connexion que l'attaquant essaie de décrypter. S'il veut, par exemple, lire les numéros de carte de crédit à partir des connexions qu'il observe, il devra effectuer un travail non négligeable pour chaque numéro de carte de crédit. Bien que l'attaque soit très grave, elle n'est pas vraiment pratique dans cette configuration de capture de CCN.

La solution: n'utilisez pas SSL 2.0. Bon sang. Vous devriez avoir cessé d'utiliser SSL 2.0 au cours du millénaire précédent. Quand nous avons dit "ne l'utilisez pas, c'est faible", nous le voulions vraiment. Il est grand temps de vous réveiller et de faire votre travail.

La prise en charge de suites de chiffrement faibles ("export") n'était pas non plus une décision judicieuse. Devine quoi ? La crypto faible est faible.

La désactivation de SSL 2.0 est le seul bon moyen de résoudre le problème. Pendant que vous y êtes, désactivez également SSL 3. .

(Et cette façon d'utiliser des acronymes tout en majuscules pour les attaques est vraiment ridicule.)

239
Thomas Pornin

La réponse de Thomas est merveilleuse. Il y a juste une chose qui semble sous-estimée: les serveurs de messagerie sont cassés en termes de sécurité ... par défaut et par conception.

  • par défaut: il suffit de regarder la configuration par défaut postfix par exemple (indice: SSLv2 et les chiffres 40-56 bits sont toujours une chose, et "pas de cryptage" aussi).

  • par conception: avez-vous déjà entendu parler de la merveille StartSSL? Eh bien, c'est le seul moyen non obsolète de réaliser le chiffrement avec SMTP (le protocole "e-mail"). Ce qui est merveilleux avec StartSSL, c'est qu'il est généralement fort lorsque personne n'écoute, mais peut facilement être réglé par défaut sur texte clair si quelqu'un veut lire ... ou SSLv2 si quelqu'un veut lire HTTPS à la place ...

    ¯\_ (ツ) _/¯

Voir là pour un exemple de l'état d'esprit des gens dans le domaine SMTP et quelques aperçus de configuration. Veuillez noter qu'il n'existe pas de drapeau unique pour désactiver SSLv2 dans postfix (eh bien, il y en a un, mais ne soyez pas surpris si le serveur accepte toujours et répond à SSLv2 ensuite).

Comment est-ce même lié à la question?

Vous pouvez durcir votre serveur Web autant que vous le souhaitez, si vous avez un serveur SMTP exécuté sur un certificat valide, il y a de fortes chances que vous soyez vulnérable à cette même attaque "DROWN". Pire encore, votre serveur Web le sera aussi ... eh bien en général: vous seriez surpris du nombre de serveurs SMTP qui partagent leur certificats avec le serveur HTTP. Vous seriez également surpris par le domaine de validité de certains certificats "autonomes" SMTP.

Solutions?

  1. Configurez correctement votre serveur SMTP (et vérifiez la configuration avec des outils externes tels que sslyze )
  2. Ou désactivez complètement SMTP.
  3. Ou utilisez un certificat auto-signé/spécifique au sous-domaine avec SMTP.
44
JPatta