-354 Membres 1338 Contributions

Open Community

CRIME : une attaque contre SSL

Publiée par Anonyme dans technique


Le 21 septembre 2012 a eu lieu une conférence de sécurité qui présenta entre autre une faille de sécurité appelée CRIME visant les sites webs protégés par SSL/TLS.

Les auteurs de l'attaque, Juliana Rizzo et Thai Duong, réputés pour avoir travaillé l'année dernière sur l'attaque BEAST ont prévenu depuis longtemps les principaux sites et éditeurs de navigateurs webs afin de pouvoir colmater la faille. Le serveur le plus utilisé sur Internet, Apache, est impacté, ainsi que les navigateurs Firefox et Google Chrome.

Techniquement, comment cela fonctionne t'il ?

  • Les sessions protégées par SSL/TLS sont chiffrées, permettant ainsi à un attaquant de ne pas pouvoir lire le contenu des échanges. Il faut savoir que SSL permet de compresser l'intégralité des données, quelle qu'elles soient (cette compression est diférente de la compression pour le protocole HTTP).
  • Plusieurs sites demandent une authentification (Facebook, Gmail, votre banque...). Une fois l'authentification réalisée, le serveur envoie un cookie d'authentification qui permet à l'utilisateur d'accéder à son espace personnel. Ce cookie correspond à une ligne d'en-tête HTTP et ressemble à: Cookie: YXJrb29uNjkhCg==
  • A chaque nouvelle requête vers le site, le navigateur ajoute donc ce cookie permettant ainsi d'authentifier les transactions (cookie de session).
  • Si un attaquant parvient à récupérer ce cookie, il peut usurper l'authentification et se faire passer pour le possesseur du compte. Ce cookie joue donc un rôle très important. La protection de ce cookie est assuré par le chiffrement HTTPS, et c'est pour cette raison que l'on conseille toujours d'utiliser des services HTTPS.

Mais alors comment le pirate peut lire le cookie puisqu'il est chiffré ?

Comme nous avons vu précedemment, le pirate ne peut que lire des données chiffrées, mais il connaît leur taille. L'attaque va se faire en deux temps :

  • tout d'abord, il faut attendre que la victime s'authentifie sur un site afin que le navigateur ait connaissance du cookie.
  • Ensuite, il va pousser la victime à consulter une page web contenant un code Javascript. Ce code va envoyer une requête HTTPS vers le site visé et contenir la suite de caractère "Cookie: A". Lorsque la compression SSL est utilisée les données sont compressées via l'algorithme DEFLATE. Le navigateur va donc générer une requête vers le site cible, contenant le cookie d'authentification pour ce site, ayant comme donnée "Cookie: A". Nous observons une certaine redondance uniquement sur le mot "Cookie: " présent deux fois (8 lettres successives identiques). Le pirate écoute l'envoi chiffré et note la taille de celle-ci. Il recommence avec "Cookie: B", et la compression ne sera pas meilleure, faisant la même taille, provoquant un chiffré de même taille. Et ainsi de suite jusqu'à "Cookie: Y" ou la compression sera meilleure du fait de la meilleure redondance "Cookie: Y" et "Cookie: YXJrb29uNjkhCg==" contenant 9 caractères à la suite identique. Le pirate observera donc un chiffré plus petit ! Et saura donc que le cookie de session démarre par un Y. Il lui suffit de continuer avec "Cookie: YA" et d'itérer. Caractère après caractère, le cookie sera révélé !

Et quelle solution ?

Actuellement, la meilleure solution si vous hébergez un serveur Web est de désactiver la compression SSL au niveau du serveur. Cela existe depuis la version 2.4.3 d'Apache. En SSL, le client propose, le serveur dispose. Ainsi, les communications ne seront jamais compressées et le pirate ne pourra plus utiliser la compression.

Si vous êtes utilisateur, utilisez un navigateur web à jour qui ne proposera pas la compression. Ainsi, même si vous téléchargez un Javascript malicieux forçant à ouvrir des requêtes vers un site vulnérable, alors le navigateur ne proposera pas la compression au serveur.

Etant donné qu'il s'agit d'un flux chiffré, il n'est pas possible pour un équipement intermédiaire de modifier à la volée la proposition de compression du client.

Chrome version 14.0.835.163, et Firefox 15.0.1 n'utilisent plus la compression au niveau de SSL et Apache permet de la désactiver depuis la version 2.4.3.

Kevin D, ingénieur sécurité R&D FAST360

Anonyme

Ah ben oui... J'ai pas pris le temps de re-regarder le handshake TLS dans l'intégralité. Il y a donc bien un contrôle d'integrité.

Merci Laurent.

Anonyme

Bonjour Mathieu,

non, à priori ce n'est pas possible de modifier la proposition de compression du ClientHello lors du handshake SSL.

En effet, une fois le handshake client/serveur effectué en clair, lorsque le client envoye le message "ChangeCipherSpec" et passe en mode chiffré, il envoye un record authentifié et chiffré de type "Finished" contenant hash + MAC des messages précédents du handshake.

Le serveur vérifie alors ce hash/MAC; si celle-ci échoue, la connection SSL est coupée. Voir le détail des échanges SSL ici : https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail

En conséquence, si on modifie le message "ClientHello" avec le module FAST SSL/TLS, lors de l'envoi chiffré du hash/MAC, le serveur va détecter que le record envoyé par le client, a été modifié et refusé la suite de l'échange SSL.

Anonyme

Le module FAST SSL/TLS ne peut-il pas supprimer la proposition de compression du ClientHello ? Ce message n'est pas chiffré et n'a (à priori) pas de contrôle d'intégrité.

Pour publier un commentaire, merci de vous authentifier.

Messages d'alerte