Poodle – Menace de sécurité SSL explorée

Caniche est une race de chien dont les pattes ressemblent à des barbes à papa. Il est intelligent et constitue un incontournable des expositions canines. Même les chiens les plus amicaux ont tendance à mordre. Maintenant, nous voyons toutes sortes d'alertes de sécurité et de snafus comme les saignements de cœur et les chocs d'obus !!! Le dernier en date est POODLE.

Tout a commencé lorsqu'une équipe de Google a développé et testé une attaque nommée CANICHE (Padding Oracle On Downgraded Legacy Encryption) qui a découvert une vulnérabilité dans le protocole Secure Sockets Layer (SSL) version 3 ou en abrégé SSLv3.

SSLv3 est un cryptage obsolète mais toujours utilisé dans les navigateurs Web plus anciens et plus récents. (SSLv3 est un protocole vieux de 18 ans qui a été remplacé par le protocole TLS)

POODLE essaie de forcer la connexion entre votre navigateur Web et le serveur à passer à SSLv3. L'attaque POODLE profite de la fonctionnalité de négociation de version de protocole intégrée à SSL/TLS pour forcer l'utilisation de SSL 3.0, puis utilise cette nouvelle vulnérabilité pour décrypter certains contenus au sein de la session SSL. Le décryptage se fait octet par octet et générera un grand nombre de connexions entre le client et le serveur.

Comment font-ils?

Un attaquant peut exécuter un agent JavaScript sur un site Web pour que le navigateur de la victime envoie un cookie avec des requêtes HTTPS à https://xyz.com, interceptez et modifiez les enregistrements SSL envoyés par le navigateur de telle sorte qu'il y ait une chance non négligeable que xyz.com accepte l'enregistrement modifié. Si l'enregistrement modifié est accepté, l'attaquant peut décrypter un octet des cookies. Biscuits

TLS 1.0 et les versions plus récentes effectuent une validation plus robuste des données déchiffrées et ne sont donc pas sensibles au même problème. Mais pour SSLv3, il n'y a pas de solution.

À quel point est-ce grave et comment cela vous affecte-t-il ?

Les connexions sécurisées utilisent principalement TLS (le successeur de SSL), la plupart des utilisateurs deviennent vulnérables car les navigateurs Web et les serveurs rétrograderont vers SSLv3 en cas de problèmes pour négocier une session TLS. La plupart des implémentations SSL/TLS restent rétrocompatibles avec SSL 3.0 pour interopérer avec les systèmes existants dans l'intérêt d'une expérience utilisateur fluide. Un attaquant effectuant une attaque de l'homme du milieu pourrait déclencher une rétrogradation du protocole vers SSLv3 et exploiter cette vulnérabilité pour déchiffrer un sous-ensemble de la communication cryptée et en extraire des informations. La vulnérabilité POODLE ne fonctionne que si le navigateur du client et la connexion du serveur prennent tous deux en charge SSLv3.

Comment tester si mon navigateur est vulnérable ?

Allez sur le site Web poodletest.com pour tester cela. Si vous voyez un caniche, vous êtes vulnérable. Si vous voyez un Springfield Terrier, vous êtes en sécurité.

http://www.bolet.org/TestSSLServer/
http://code.google.com/p/sslaudit/

Que puis-je faire pour éviter cela ? Vaccin caniche ?

En tant qu'utilisateur final, désactivez la prise en charge SSLv3 dans votre navigateur Web. S'il est désactivé, POODLE ne peut PAS rétrograder votre navigateur vers celui-ci. Pour encourager les meilleures pratiques de sécurité, je recommande fortement d'utiliser la version la plus élevée de TLS. Pour la plupart des navigateurs, cela devrait être TLS 1.2.

Cela affectera-t-il mon expérience de navigation ?

Cela aura un impact sur certains navigateurs plus anciens. Les sites Web qui ont déjà mis fin à la prise en charge de SSLv3 deviendront incompatibles avec les anciens navigateurs et systèmes d'exploitation. Les anciens navigateurs comme Internet Explorer 6 fonctionnant sous Windows XP ou les versions antérieures verront une erreur de connexion SSL.

SSLv3 sera désactivé par défaut dans les futures versions de nombreux navigateurs Web.

Comment désactiver cela sur le serveur ?

CloudFlare a annoncé qu'il désactivait SSLv3 par défaut sur ses serveurs. De nombreux prestataires de services l’ont également fait.

Si vous utilisez Apache, effectuez simplement cette modification dans votre configuration parmi les autres directives SSL :

Protocole SSL Tous -SSLv2 -SSLv3

Cela désactive les versions 2 et 3 du protocole SSL.

Comment les développeurs peuvent-ils empêcher cela ?

.FILET

Utilisez la propriété SecurityProtocol pour activer TLS.

Pour plus de détails sur l’utilisation de la propriété SecurityProtocol, visitez :

http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.securityprotocol(v=vs.110).as…

http://msdn.microsoft.com/en-us/library/system.net.securityprotocoltype(v=vs.110).aspx

À titre d'exemple, pour forcer TLS 1.2 dans une implémentation C# .NET, vous utiliseriez :

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

JAVA

REMARQUE : TLS 1.2 a été pris en charge pour la première fois dans JDK 7 et sera celui par défaut dans JDK 8 : https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls

Utilisez la méthode SSLContext.getInstance pour activer TLS.

Pour plus de détails sur l'utilisation de la méthode SSLContext.getInstance, visitez :

http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance(java.lang.String)

http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance(java.lang.String,…

http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SSLContext

Par exemple, pour utiliser le fournisseur de couche de sécurité par défaut pour activer TLS, vous utiliserez :

objet = SSLContext.getInstance("TLS");

Pour forcer TLS 1.2 tout en utilisant l'extension Java Secure Socket Extension (JSSE) de Sun, vous devez utiliser :

objet = SSLConnect.getInstance("TLSv1.2", "SunJSEE");

boucle

Utilisez l'option CURLOPT_SSLVERSION pour activer TLS.

Pour plus de détails sur l'utilisation de l'option CURLOPT_SSLVERSION, visitez :

http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html

À titre d'exemple, pour forcer cURL à utiliser TLS 1.0 ou version ultérieure, vous utiliseriez :

C/C++/C# :

curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);

PHP :

curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);

Dans cURL 7.34.0 ou version ultérieure, pour forcer TLS 1.2, vous utiliseriez :

C/C++/C# :

curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);

PHP :

curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);

RailsCarma L'équipe s'est préparée en mode défense complète pour boucher tous les trous laissés ouverts par cette vulnérabilité. Nous avons appliqué les correctifs nécessaires à nos applications pour désactiver les options SSL/TLS non sécurisées.

Les références

http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Important-POODLE-Information-Updated/ba-p/48163

http://arstechnica.com/security/2014/10/ssl-broken-again-in-poodle-attack/

https://zmap.io/sslv3/

https://www.imperialviolet.org/2014/10/14/poodle.html

http://blog.cryptographyengineering.com/2014/10/attack-of-week-poodle.html

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

http://www.theregister.co.uk/2014/10/16/poodle_analysis/

http://www.theregister.co.uk/2014/10/14/google_drops_ssl_30_poodle_vulnerability/

http://www.pcworld.com/article/2834015/security-experts-warn-of-poodle-attack-against-ssl-30.html

http://www.alertlogic.com/blog/poodle-man-middle-attack-sslv3/

https://www.us-cert.gov/ncas/alerts/TA14-290A

https://www.openssl.org/~bodo/ssl-poodle.pdf

http://www.makeuseof.com/tag/stop-poodle-from-biting-your-browser/

https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack

Désactiver le caniche

https://www.linode.com/docs/security/security-patches/disabling-sslv3-for-poodle

http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566

Prenez contact avec nous.