Vulnérabilité "POODLE" dans SSL3

Question

Question canonique concernant la vulnérabilité d'Oracle padding récemment révélée dans SSL v3. Les autres questions identiques ou sensiblement similaires doivent être fermées en double de celle-ci.

• Qu'est-ce que la vulnérabilité POODLE?
• J'utilise [product/browser]. Suis-je affecté?
• [product] est-il vulnérable à l'attaque POODLE?
• Que dois-je faire pour sécuriser mon [product] par rapport à cette vulnérabilité?
• Comment détecter les attaques POODLE sur mon réseau?
• Y a-t-il des attaques POODLE connues?

Références:

• Annonce de sécurité Google
• Livre blanc POODLE (PDF)

Answer 1

Qu'est-ce que la vulnérabilité Poodle?

La vulnérabilité "Poodle", publiée le 14 octobre 2014 , est une attaque contre le protocole SSL 3.0. C'est une faille , pas un problème d'implémentation; chaque implémentation de SSL 3.0 en souffre. Veuillez noter que nous parlons de l'ancien SSL 3.0, pas TLS 1.0 ou version ultérieure. Les versions TLS ne sont pas affectées (ni DTLS).

En résumé: lorsque SSL 3.0 utilise un chiffrement par bloc en mode CBC, le processus de chiffrement d'un enregistrement utilise - padding de sorte que la longueur des données est un multiple de la taille du bloc. Par exemple, supposons que 3DES soit utilisé, avec des blocs de 8 octets. Un MAC est calculé sur les données d'enregistrement (et le numéro de séquence d'enregistrement, et quelques autres données d'en-tête) et ajouté aux données. Ensuite, 1 à 8 octets sont ajoutés, de sorte que la longueur totale est un multiple de 8. De plus, si n octets sont ajoutés à cette étape, le dernier de ces octets doit avoir la valeur n-1. Ceci est fait pour que le décryptage fonctionne.

Considérons le déchiffrement d'un enregistrement: le déchiffrement 3DES-CBC est appliqué, puis le dernier octet est inspecté: il doit contenir une valeur comprise entre 0 et 7, et cela nous indique combien d'autres octets ont été ajoutés pour le remplissage. Ces octets sont supprimés et, surtout, leur contenu est ignoré. C'est le point important: il y a des octets dans l'enregistrement qui peuvent être modifiés sans que le destinataire ne s'en soucie le moins du monde.

L'attaque Poodle fonctionne dans un contexte de texte en clair choisi, comme BEAST et CRIME avant elle. L'attaquant s'intéresse aux données protégées par SSL et il peut:

• injecter ses propres données avant et après la valeur secrète qu'il souhaite obtenir;
• inspecter, intercepter et modifier les octets résultants sur le fil.

Le scénario principal et à peu près plausible dans lequel de telles conditions sont remplies est un contexte Web: l'attaquant exécute un faux point d'accès WiFi et injecte son propre Javascript dans le cadre d'une page Web (HTTP, pas HTTPS) que la victime parcourt. Le Javascript malveillant fait que le navigateur envoie des demandes à un site HTTPS (par exemple, un site Web bancaire) pour lequel le navigateur de la victime a un cookie. L'attaquant veut ce cookie.

L'attaque se poursuit octet par octet. Le Javascript de l'attaquant fait en sorte que la demande soit telle que le dernier octet de cookie se produise à la fin d'un bloc de chiffrement (l'un des blocs de 8 octets de 3DES) et que la longueur totale de la demande implique un remplissage de bloc complet. Supposons que les 8 derniers octets de cookie aient des valeurs c, c₁, ... c₇. Lors du cryptage, CBC fonctionne comme ceci:

Donc, si le bloc chiffré précédent est e, e₁, ... e₇, alors ce qui entre dans 3DES est c XOR e, c₁ XOR e₁, ... c₇ XOR e₇. Le e_je les valeurs sont connues de l'attaquant (c'est le résultat chiffré).

Ensuite, l'attaquant, de l'extérieur, remplace le dernier bloc de l'enregistrement chiffré par une copie du bloc qui contient le dernier octet de cookie. Pour comprendre ce qui se passe, vous devez savoir comment fonctionne le déchiffrement CBC:

Le dernier bloc de texte chiffré est ainsi déchiffré, ce qui donne une valeur se terminant par c₇ XOR e₇. Cette valeur est ensuite XORed avec le bloc chiffré précédent. Si le résultat se termine par un octet de valeur 7 (qui fonctionne avec la probabilité 1/256), l'étape de suppression du remplissage supprimera les 8 derniers octets et se retrouvera avec le texte en clair et le MAC intacts, et le serveur sera content. Sinon, soit le dernier octet ne sera pas dans la plage 0..7, et le serveur se plaindra, soit le dernier octet sera compris entre 0 et 6, et le serveur supprimera le mauvais nombre d'octets, et le MAC ne le fera pas. correspond et le serveur se plaindra. En d'autres termes, l'attaquant peut observer la réaction du serveur pour savoir si le résultat du déchiffrement CBC a trouvé un 7 ou autre chose. Lorsqu'un 7 est obtenu, le dernier octet de cookie est immédiatement révélé.

Lorsque le dernier octet de cookie est obtenu, le processus est exécuté à nouveau avec l'octet précédent, etc.

Le point central est que SSL 3.0 est défini comme ignorant les octets de remplissage (sauf le dernier). Ces octets ne sont pas couverts par le MAC et n'ont aucune valeur définie.

TLS 1.0 n'est pas vulnérable car dans TLS 1.0, le protocole spécifie que tous les octets de remplissage doivent avoir la même valeur, et les bibliothèques implémentant TLS vérifient que ces octets ont les valeurs attendues. Ainsi, notre attaquant ne peut pas avoir de chance avec une probabilité 1/256 (2^-8), mais avec probabilité 1/18446744073709551616 (2^-64), ce qui est nettement pire.

---

J'utilise [product]. Suis-je affecté? Est [product] vulnérable à l'attaque du caniche?

Le scénario d'attaque nécessite que l'attaquant puisse injecter ses propres données, et pour intercepter les octets chiffrés. Le seul contexte plausible où une telle chose se produit est un navigateur Web, comme expliqué ci-dessus. Dans ce cas, Poodle est, comme BEAST et CRIME, une attaque sur le client, pas sur le serveur.

Si [product] est un navigateur Web, vous pourriez être affecté. Mais cela dépend aussi du serveur. La version de protocole utilisée est une négociation entre le client et le serveur; SSL 3.0 ne se produira que si le serveur est d'accord. Ainsi, vous pourriez-vous considérer que votre serveur est "vulnérable" s'il autorise l'utilisation de SSL 3.0 (c'est techniquement incorrect, car l'attaque est côté client dans un contexte Web, mais je m'attends à ce que Des compteurs de sécurité SSL pour fonctionner de cette façon).

Conditions pour que la vulnérabilité se produise: SSL 3.0 pris en charge, et sélection d'une suite de chiffrement basée sur CBC (le chiffrement RC4 n'a pas de remplissage, n'est donc pas vulnérable à cette attaque spécifique - mais RC4 a d'autres questions, bien sûr).

Solutions de contournement:

• Désactivez la prise en charge de SSL 3.0 dans le client.
• Désactivez la prise en charge de SSL 3.0 sur le serveur.
• Désactivez la prise en charge des suites de chiffrement basées sur CBC lors de l'utilisation de SSL 3.0 (sur le client ou le serveur).
• Implémentez cette nouvelle extension SSL/TLS pour détecter quand un attaquant actif coupe les connexions pour forcer votre client et votre serveur à utiliser SSL 3.0, même si les deux connaissent TLS 1.0 ou mieux. Le client et le serveur doivent l'implémenter.

Chacune de ces quatre solutions évite la vulnérabilité.

---

Que dois-je faire pour sécuriser mon [product] par rapport à cette vulnérabilité?

Comme toujours. Votre fournisseur publie des correctifs de sécurité; installez-les. Installez les correctifs. Tous les patchs. Faites ça. Pour Poodle et pour toutes les autres vulnérabilités. Vous ne pouvez pas vous permettre de ne pas les installer, et ce n'est pas nouveau. Vous devriez déjà le faire. Si vous n'installez pas les patchs, Níðhöggr dévorera votre rate.

---

Comment détecter les attaques Poodle sur mon réseau?

Non! Étant donné que la configuration d'attaque la plus probable implique que l'attaquant attire la victime sur le réseau leur, pas le vôtre.

Bien que, côté serveur, vous souhaitiez peut-être réagir à un nombre excessif de demandes qui échouent en cas d'erreur de déchiffrement. Tous les logiciels de serveur n'enregistreront pas les événements pour de tels cas, mais cela devrait être dans les possibilités de tout système IDS décent.

---

Y a-t-il des attaques connues de Poodle?

Pas à ma connaissance. En fait, lorsque vous contrôlez toutes les E/S externes de la victime, il est encore beaucoup plus facile d'attirer simplement le pauvre gazon sur une fausse copie de son site bancaire. Les attaques cryptographiques sont soignées, mais elles impliquent plus d'efforts que l'exploitation du puits sans fond de la crédulité de l'utilisateur.

Answer 2

Pour désactiver la prise en charge de SSL v3.0:

Chez les clients:

Mozilla Firefox

Soit

• Installez le module complémentaire Mozilla appelé " SSL Version Control "

Ou

• Tapez about:config dans la barre de navigation et appuyez sur [Enter]
• Acceptez l'avertissement et continuez
• Rechercher tls
• Modifiez la valeur de security.tls.version.min de 0 à 1 (0 = SSL 3.0; 1 = TLS 1.0)

Chrome

• Exécutez Chrome avec l'indicateur de ligne de commande suivant: --ssl-version-min=tls1

Internet Explorer

• Allez dans Paramètres -> Options Internet -> Onglet Avancé -> Décochez "SSLv3" sous "Sécurité"

Dans les serveurs Web:

Apache v2

• Ajoutez la ligne suivante à votre fichier de configuration SSL ou modifiez la ligne existante pour lire: SSLProtocol All -SSLv2 -SSLv3
• Redémarrez le serveur Web avec Sudo Apache2ctl restart

Serveur Web Zeus

(%ZEUSHOME est l'emplacement d'installation, généralement /usr/local/zeus)

• Mettre à niveau vers Zeus Web Server 4.3r5
• Ajoutez la ligne suivante à %ZEUSHOME%/web/global.cfg: tuning!ssl3_allow_rehandshake never
• Redémarrez le serveur Web avec Sudo %ZEUSHOME%/restart-zeus

Références:

1. "Attaques POODLE sur SSLv3", ImperialViolet, ImperialViolet - Attaques POODLE sur SSLv

2. "SSLv3 POODLE Vulnerability Official Release", Blog du journal des gestionnaires d'InfoSec,> Internet Storm Center - Internet Security | SANS ISC

Answer 3

J'ai publié un blog sur la façon de désactiver SSLv3 dans certains des bowsers et des plates-formes de serveurs les plus courants ( https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills- hors protocole / ). Cela devrait au moins aider à répondre à la question sur la façon d'atténuer complètement POODLE, que vous soyez un client ou un serveur.

Voici les principaux détails.

Comment protéger votre serveur

La solution la plus simple et la plus robuste à POODLE est de désactiver la prise en charge SSLv3 sur votre serveur. Cela apporte cependant quelques mises en garde. Pour le trafic Web, il existe des systèmes hérités qui ne pourront pas se connecter à autre chose que SSLv3. Par exemple, les systèmes utilisant IE6 et Windows XP installations sans SP3, ne pourront plus communiquer avec aucun site qui abandonne SSLv3. Selon les chiffres publiés par CloudFlare, qui ont complètement désactivé SSLv3 sur leur l'ensemble de la clientèle, seule une infime fraction de leur trafic Web sera affectée, car 98,88% des utilisateurs de Windows XP se connectent avec TLSv1.0 ou mieux.

Apache

Pour désactiver SSLv3 sur votre serveur Apache, vous pouvez le configurer à l'aide de ce qui suit, à la fois dans la section de configuration SSL et dans tous les SSL-enabled hôtes virtuels explicitement:

SSLProtocol All -SSLv2 -SSLv3

Cela vous donnera un support pour TLSv1.0, TLSv1.1 et TLSv1.2, mais supprime explicitement le support pour SSLv2 et SSLv3. Vérifiez la configuration, puis redémarrez Apache.

apachectl configtest

Sudo service Apache2 restart

NginX

La désactivation de la prise en charge SSLv3 sur NginX est également très simple.

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Semblable à la configuration Apache ci-dessus, vous obtiendrez le support TLSv1.0 + et aucun SSL. Vous pouvez vérifier la configuration et redémarrer.

Sudo nginx -t

Sudo service nginx restart

IIS

Celui-ci nécessite quelques ajustements de registre et un redémarrage du serveur mais n'est toujours pas si mal. Microsoft a un article de support avec les informations requises, mais tout ce que vous avez à faire est de modifier/créer une valeur DWORD de registre.

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Dans les protocoles, vous aurez probablement déjà une clé SSL 2.0, alors créez SSL 3.0 à côté si nécessaire. Sous cela, créez une clé de serveur et à l'intérieur une valeur DWORD appelée Enabled avec la valeur 0. Une fois cela fait, redémarrez le serveur pour que les modifications prennent effet.

Comment vérifier votre serveur

La méthode la plus simple et probablement la plus utilisée pour tester quoi que ce soit en rapport avec votre configuration SSL est le Qualys SSL Test . Accédez simplement au site, entrez le domaine du site Web que vous souhaitez tester et appuyez sur Soumettre pour lancer le test.

Une fois le test terminé, vous obtiendrez un joli résumé de vos résultats et de nombreuses informations détaillées plus bas sur la page. Plus précisément, vous voulez regarder dans la section Configuration vos protocoles pris en charge.

Ce que vous voulez voir ici, c'est que vous n'avez aucun protocole SSL pris en charge. Vous devriez avoir depuis longtemps désactivé SSLv2.0 et maintenant nous venons de supprimer SSLv3.0 aussi. La prise en charge de TLSv1.0 ou supérieur est suffisante pour prendre en charge la grande majorité absolue des utilisateurs d'Internet sans exposer quiconque à des risques inutiles.

Comment protéger votre navigateur

Il est également possible de vous protéger de POODLE en désactivant la prise en charge SSLv3 dans votre navigateur. Cela signifie que même si le serveur offre la prise en charge de SSLv3, votre navigateur ne l'utilisera jamais, même pendant une attaque de déclassement de protocole.

Firefox

Les utilisateurs de Firefox peuvent taper about: config dans leur barre d'adresse puis security.tls.version.min dans la boîte de recherche. Cela fera apparaître le paramètre qui doit être changé de 0 à 1. Le paramètre existant permet à Firefox d'utiliser SSLv3 là où il est disponible et s'il est requis. En modifiant le paramètre, vous forcerez Firefox à n'utiliser que TLSv1.0 ou mieux, ce qui n'est pas vulnérable à POODLE.

Chrome

Les utilisateurs de Chrome n'ont pas d'option dans l'interface graphique pour désactiver SSLv3 car Google l'a supprimé en raison de la confusion quant à savoir si SSLv3 ou TLSv1 était meilleur avec un ayant une valeur numérique plus élevée. Au lieu de cela, vous pouvez ajouter l'indicateur de ligne de commande --ssl-version-min = tls1 pour appliquer l'utilisation de TLS et empêcher toute connexion utilisant le protocole SSL. Sous Windows, faites un clic droit sur votre raccourci Chrome, appuyez sur Propriétés et ajoutez l'indicateur de ligne de commande comme indiqué dans l'image ci-dessous.

Si vous utilisez Google Chrome sur Mac, Linux, Chrome OS ou Android, vous pouvez suivre ces instructions ici .

Internet Explorer

La réparation d'Internet Explorer est également assez simple. Allez dans Paramètres, Options Internet et cliquez sur l'onglet Avancé. Faites défiler la liste jusqu'à ce que vous voyiez la case Utiliser SSL 3.0 et décochez-la.

Comment vérifier votre navigateur

Si vous souhaitez vérifier que les modifications de votre navigateur ont définitivement supprimé la prise en charge de SSLv3.0, vous pouvez utiliser quelques sites. Si vous visitez https://zmap.io/sslv3/ avec SSLv3 activé dans votre navigateur, vous verrez le message d'avertissement que je reçois ici en Chrome où Je n'ai pas encore désactivé SSLv3. Pour vérifier que le site fonctionnait comme prévu, j'ai désactivé la prise en charge de SSLv3 dans Internet Explorer et y ai ouvert le site également. Ici vous pouvez voir la différence.

Vous pouvez également essayer https://www.poodletest.com/ aux côtés de Zmap.

Answer 4

Si vous ne souhaitez pas divulguer le nom de votre site à ces autres sites Web, vous pouvez également le tester avec ...

openssl s_client -ssl3 -Host <your Host name> -port 443

S'il ne se connecte pas, alors ça va.

Mais assurez-vous également que votre openssl fonctionne correctement avec votre site ...

openssl s_client -Host <your Host name> -port 443

La désactivation de sslv3 désactive également IE6 et Windows XP SP2 et ci-dessous. Peu ont IE6 mais beaucoup ont encore Windows XP.