Journal La fin du monde est (une fois de plus) pour demain : SSL crime

Posté par  .
Étiquettes : aucune
43
20
sept.
2012

Sommaire

Si vous n'habitez pas au fond de l'océan, il y a des chances que vous sachiez déjà ce qui va suivre.
Demain, c'est la fin du monde car SSL, le dernier bastion de la sécurité sur internet (oui, c'est ironique) va sombrer corps et biens et disparaître dans un grand geyser catclysmique.

Bref, si on redevient sérieux deux minutes, qu'est ce qui se passe demain?
Deux chercheurs réputés, Juliana Rizzo et Thai Duong, bien connus pour avoir travaillé sur l'attaque BEAST#TLS_1.0) annoncent une nouvelle attaque portant sur une spécificité de SSL combiné à la manière dont le protocole HTTP fonctionne. Etant donné leur renommée, beaucoup d'octets ont coulés dans les RJ45 et une hypothèse audacieuse, vraisemblablement celle qui sera exposée demain, a été proposé sur un site web:
http://zoompf.com/2012/09/explaining-the-crime-weakness-in-spdy-and-ssl
La conf à lieu là-bas.

Alors de quoi s'agit-il?

Tout d'abord, un bref rappel sur la manière dont les données s'échangent en HTTP.

Les échanges HTTP sont séparés en deux; tout d'abord on trouve les en-têtes, ensuite les données. Les en-têtes contiennent un certain nombre d'informations comme la date, la version du navigateur lorsqu'il s'agit d'une requête client, et la version du serveur lorsqu'il s'agit de la réponse, etc.. Les données, c'est le HTML bien connu, ainsi que pleins d'autres choses (images, sons, flash etc..) qui fait que le web est ce qu'il est aujourd'hui.

Deux points vont nous intéresser particulièrement dans les en-têtes. Tout d'abord, il faut savoir que les en-têtes ne sont jamais compressés, au contraire du data qui peut l'être. Ensuite, un en-tête est très intéressant, il s'agit du champ "Cookie" qui permet (entre autre) d'authentifier un utilisateur. Ainsi, si vous surfez sur linuxfr en tant qu'anonyme, vous n'avez pas de cookie d'authent. Si vous vous êtes authentifié, alors un cookie permet au serveur de savoir qui vous êtes. Si quelqu'un vous vole votre cookie d'authent, alors il peut se faire passer pour vous, et écrire des journaux sous votre nom, vous connecter à votre messagerie, etc… Le vol du cookie d'authent permet de voler votre identité.

Comme vous le savez sans doute, HTTP existe en version sécurisée, HTTPs qui a comme mérite de chiffrer les messages. Ainsi, un pirate écoutant vos connexions sur linuxfr ne pourra pas déchiffrer les en-têtes HTTP, et ne pourra pas lire le cookie d'authent, préservant ainsi votre identité. Et c'est ainsi sur tous vos sites webs important: banques, faceplook, gmail, poneyz.com, etc..

On comprend pourquoi les pirates tentent de voler ce Cookie, et pourquoi HTTPS permet de surfer l'esprit tranquille. Ceux qui surfent en clair peuvent s'attendre à voir firesheep utilisé contre eux, attaque automatisant le procédé de collecte de cookie.

Un petit rappel sur SSL

Les deux chercheurs cités ont découvert que certains sites proposent la compresion au niveau de SSL. Dans le cas d'HTTP, il n'y a pas beaucoup d'intérêt à le faire puisque la couche HTTP sait quoi compresser et comment le compresser. Mais l'option est là. Donc l'en-tête HTTP, précédemment non compressé, le devient grâce à la couche SSL. Et de fait, beaucoup de choses deviennent possible.

On sait que le chiffrement ne modifie pas la taille des données. 1.5Mo à chiffrer vont faire 1.5Mo. La compression, elle, réduit les données.
Si un attaquant parvient à ajouter des données dans un échange HTTP, alors le paquet chiffré devient plus gros, forcément. Mais si la couche SSL compresse avant de chiffrer, alors une propriété intéressante se profile.

Imaginons un fichier contenant uniquement des 0. La compression est excellente, le chiffrement de la forme compressée aura donc une petite taille. Si j'ajoute à ce fichier d'autres zéros, alors la taille finale ne bougera pas. Si j'ajoute d'autres caractères, alors la taille compressée augmentera ainsi que celle du chiffré. Je constate donc que je récupère de l'information sur le fichier initial grâce à la seule information que le chiffré me donne: sa taille! Je peux donc déduire que le fichier initial contient beaucoup de zéros puisque en ajouter d'autres ne modifie que peu la taille du compressé chiffré!

L'attaque

L'idée consiste donc à envoyer plusieurs paquets au serveur en activant la compression au niveau de SSL. Le paquet normal est donc:
GET /page.html HTTP/1.1
Host: victim.net
Cookie: Monsupercookiedauthent

Et l'attaquant va ajouter un second entête cookie:

GET /page.html HTTP/1.1
Host: victim.net
Cookie: Monsupercookiedauthent
Cookie: A

La couche de compression va donc constater une répétition de caractères: "Cookie: " et va donc les compresser, résultant en une certaine taille, puis le A qui ne se compresss pas. L'attaquant regarde la taille chiffrée, puis il réessaye avec Cookie: B. La taille résultante ne bouge pas. Puis avec C, etc..
Lorsqu'il arrive à "Cookie: M", alors la compression est meilleure, du fait d'une plus grande répétition de caractères! Et donc le chiffré est plus petit, et donc l'attaquant sait que le cookie démarre par un M. On itère sur le deuxième caractère, etc.. et l'attaquant découvre le Cookie! Phun and Profit!

Note: les auteurs semblent dire qu'ils ont trouvé d'autres manières plus rapides que d'itérer char par char, mais l'idée derrière reste la même: comparer les chiffrés résultant.

HTTPS est donc complètement défait et la seule solution aujourd'hui consiste à désactiver la compression SSL!

Et dans la vraie vie?

Cette attaque est très belle. Néanmoins, pas mal de zones d'ombres subsistent.

  • Comment envoyer pleins de requêtes au serveur? Il faut que la requête contienne le vrai cookie, ainsi que la ligne d'entête rajoutée. On entend parler de javascript, mais si javascript sait lire le cookie, pourquoi ne pas tout simplement l'envoyer à l'attaquant? Ce point n'est pas du tout clair. On lit aussi que l'attaquant peut fournir une page remplie de balise IMG, mais comment ajouter par la suite le faux Cookie?
  • Comment lire les paquets chiffrés? Apparemment, l'attaque prend comme acquis que l'attaquant est sur le routeur mais que ce n'est pas obligatoire. A la manière de firesheep, on peut imaginer que l'attaquant est dans un cybercafe et qu'il sniffe les réponses.
  • SSL n'est pas cassé, c'est SSL lorsqu'il protège les cookie d'authent HTTP et que la compression est possible.

Stay tuned

  • # Réponse

    Posté par  . Évalué à 3.

    Comment envoyer pleins de requêtes au serveur?

    Javascript ne va pas pouvoir lire le cookie, mais il peut générer la requete HTTP, le navigateur va rajouter le cookie dans les headers.

    • [^] # Re: Réponse

      Posté par  . Évalué à 4. Dernière modification le 20 septembre 2012 à 16:29.

      Je ne suis pas persuadé, soit le script vient du site attaqué (ou est inclus depuis ses pages) auquel cas il a accès au cookie (il me semble) et l'attaque ne sert à rien, soit il vient d'un domaine tiers auquel cas non seulement il ne peut pas lire le cookie mais ne peut pas générer de requête non plus vers le domaine à attaquer (les navigateurs ont des protections contre ça, il me semble).

      Bon, après, c'est une réaction à chaud, je n'ai pas creusé le sujet.

      edit : au temps pour moi, il peut toujours générer & manipuler des iframes ou autres balises important du contenu.

      • [^] # Re: Réponse

        Posté par  . Évalué à 2.

        "le script vient du site attaqué (ou est inclus depuis ses pages) auquel cas il a accès au cookie"

        Un javascript n'a pas accès à un cookie avec l'attribut "httponly".

      • [^] # Re: Réponse

        Posté par  (site web personnel) . Évalué à 6.

        Je ne suis pas persuadé, soit le script vient du site attaqué (ou est inclus depuis ses pages) auquel cas il a accès au cookie (il me semble)

        Non, pas forcément, il existe un flag sur les cookies (httpOnly) et s'il est activé, le cookie en question ne sera pas accessible depuis le javascript.

        soit il vient d'un domaine tiers auquel cas non seulement il ne peut pas lire le cookie mais ne peut pas générer de requête non plus vers le domaine à attaquer

        Perdu, le javascript peut inclure une image provenant d'un autre domaine, le navigateur fera alors la requête vers cet autre domaine avec les cookies de l'utilisateur pour ce second domaine. Il existe même des techniques pour faire des requêtes POST vers d'autres domaines et pas juste des GET, on parle alors d'attaques CSRF.

        • [^] # Re: Réponse

          Posté par  . Évalué à 1.

          Oui, c'était l'objet de mon edit.

    • [^] # Re: Réponse

      Posté par  . Évalué à 2.

      Oui mais pour qu'il y ait ce genre de manip, il faut qu'il y ait déjà une faille du genre cross-site scripting, ou bien que l'OS ou le navigateur soit infecté par un programme qui injecte du javascript dans les pages du navigateur. Le second cas est déjà mal barré puisqu'un key logger fera bien plus de dégats et plus facile à mettre en oeuvre…
      Ensuite dans le cas du Cross-site scripting ou de d'une attaque similaire à distance, il faut qu'il y ait un proxy qui calcule la taille des paquets compressés… une sorte de man in the middle mais qui ne touche pas au contenu généré.
      Donc ce genre d'attaque ne sera exploitable que sur des réseaux sur lesquels on n'a aucune confiance comme un réseau wifi.

      • [^] # Re: Réponse

        Posté par  (site web personnel) . Évalué à 5.

        Pour effectuer l'attaque, il faut deux choses :

        • forcer le navigateur a faire des requêtes
        • recevoir les paquets réseau des connexions

        Pour le premier point, rien de bien compliqué, on crée une fausse page avec une vidéo youtube à la con (pour que la victime garde la page ouverte assez longtemps pour que l'attaque réussisse) et du javascript qui va générer les requêtes depuis une iframe cachée.

        Pour le second point, il faut être en mesure d'écouter le trafic, ce qui est trivial sur du wifi mais peut aussi se faire sur des réseaux filaires (un hub, un switch que l'on floode, ARP poisoning, les techniques ne manquent pas).

        • [^] # Re: Réponse

          Posté par  . Évalué à 6.

          Pour le premier point, rien de bien compliqué, on crée une fausse page avec une vidéo youtube à la con (pour que la victime garde la page ouverte assez longtemps pour que l'attaque réussisse) et du javascript qui va générer les requêtes depuis une iframe cachée.

          Ok, je commence à voir. Une page du genre:
          -iframe de taille 0
          --javascript : requête moi en boucle la page 'sitesecure.net' en ajoutant l'entête Cookie qui va bien. Ca, javascript doit savoir le faire sans trop de mal.
          -frame
          --video youtube de chats (sauf pour les freenautes, voir l'autre journal)

          Donc, même si le cookie est protégé par httponly et que le js ne peux pas le voir, le navigateur va l'ajouter.

          Par contre, j'ai du mal a voir comment utiliser les balises IMG ? Un truc de genre IMG SRC="Cookie: A" afin de faire de la redondance?

  • # Précisions

    Posté par  (site web personnel) . Évalué à 10.

    -SSL n'est pas cassé, c'est SSL lorsqu'il protège les cookie d'authent HTTP et que la compression est possible.

    Ce genre d'attaques peut s'effectuer sur d'autres protocoles que HTTPS, genre SMTPS. SSL n'est pas cassé mais utiliser sa compression est une erreur.

  • # Une protection possible

    Posté par  . Évalué à 1.

    Je suppose qu'on peut considérer comme une protection le fait de changer l'identifiant de la session à chaque appel au serveur. Et de manière générale, comme le but de l'attaque pésentée dans ce journal est de voler l'identifiant de session, toute protection contre ce type d'attaque (que SSL soit utilisé ou non) est bonne à prendre.

    Par exemple, quand j'ai besoin de sessions pour un script php, j'utilise cette fonction à chaque appel :

    session_regenerate_id(true);

    • [^] # Re: Une protection possible

      Posté par  (site web personnel) . Évalué à 5.

      Mais il est fréquent de faire plusieurs requête en même temps légitimement. Par exemple télécharger toutes les images d'une page, ou faire plusieurs requête AJAX en parallèles.
      Ça va pas être facile de supporter ça si l'identifient de session change tout le temps.

    • [^] # Re: Une protection possible

      Posté par  (site web personnel) . Évalué à 4.

      session_regenerate_id(true);

      Sur un site à fort trafic cela pose un problème évident de ressources. On passe de lire_session() à lire_session(); regenere_id(); update_session(); C'est un peu comme les statistiques temps réel intégrés aux CMS, tu te retrouves rapidement avec des problèmes de perf lié aux updates constants et donc un coût en IO beaucoup plus grand pour un service équivalent.

  • # ou pas toujours

    Posté par  . Évalué à 1.

    Le vol du cookie d'authent permet de voler votre identité

    Pas toujours. Certains sites permettent de limiter la session à une seule IP. Le problème est alors résolu… sauf pour ceux avec une IP public dynamique (derrière des proxies par exemple). C'est pour cela que ces sites proposent de désactiver cette sécurité supplémentaire.

    • [^] # Re: ou pas toujours

      Posté par  (site web personnel) . Évalué à 4.

      À partir du moment ou l'attaqueur à la capacité d'écouter le traffic, ça doit pas être difficile de prendre la même IP.

    • [^] # Re: ou pas toujours

      Posté par  . Évalué à 5.

      Mais comme cette attaque impose d'être "proche" de la victime pour écouter les réponses chiffrées, on peut imaginer qu'ils sont sur un réseau RFC1918, masqués par la même IP publique…
      L'hypothèse du wifi open dans un cybercafe rentre complètement dans le scope de l'attaque.

      • [^] # Re: ou pas toujours

        Posté par  . Évalué à 2.

        Une protection serait donc de passer à IPv6 ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: ou pas toujours

      Posté par  . Évalué à 1.

      Deux points :

      • Soit accepte le modèle d'attaque suivant : L'attaquant contrôle le réseau.
        Dans ce cas, l'attaquant n'a qu'à utiliser la même IP

      • Soit tu considère le réseau comme sûr, et je n'arrive pas bien à comprendre pourquoi tu utilises SSL.

  • # patch pour apache

    Posté par  (site web personnel) . Évalué à 6. Dernière modification le 20 septembre 2012 à 18:59.

    Pour apache la demande d'ajout traine dans le bugzilla depuis le mois de mai. En cause au départ : l'overhead crée par la compression.
    https://issues.apache.org/bugzilla/show_bug.cgi?id=53219
    Le patch est la.
    https://issues.apache.org/bugzilla/attachment.cgi?id=28804

    Ensuite Compression off dans le httpd.conf. Sans cela, la compression ssl ne peut-être désactivée et donc demandée par le client lors de la négociation.

  • # SSL ?

    Posté par  . Évalué à 7.

    Tout le monde utilise TLS maintenant.

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

  • # tabloid

    Posté par  . Évalué à 5.

    Bravo pour ce titre sensationnaliste qui ne résiste pas à la lecture sur contenu. Tu pourrais travailler pour the sun.
    L'ascenseur émotionnel à joué à plein pour moi: très excité de lire l'article puis reste sur ma faim quant à le fin du monde.

    Merci quand même pour la restitution, très claire.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.