Firesheep

Posté par  (site web personnel) . Édité par Benoît Sibaud. Modéré par baud123.
Étiquettes :
17
29
oct.
2010
Administration système
Ce bon vieux et néanmoins ami protocole HTTP fonctionne selon le principe très simple de "question-réponse" (ou requête-réponse). Rapidement les cookies ont été ajoutés au protocole afin de pouvoir garder un état lors d'une série de transactions, par exemple, d'un magasin en ligne, ou d'un site d'actualités tel LinuxFr.org. Depuis l'arrivée du cookie, c'est devenu le moyen de maintenir une session pour les utilisateurs des sites.

Personne n'est dupe et l'on sait très bien que ce cookie est un simple morceau de texte passant en clair dans les entêtes du protocole HTTP. Nous savons aussi qu'il suffit d'obtenir ce texte afin de voler l'identité de la personne. Nous savons que le meilleur moyen pour s'en protéger est d'utiliser la version sécurisée du protocole HTTP soit HTTPS.

Malheureusement, les sites comme Facebook ou Twitter utilisent le HTTP si rien d'autre ne leur est demandé. Pire, le site Facebook n'est pas entièrement fonctionnel via HTTPS (le seul que j'ai personnellement testé), le chat ne fonctionne pas.

C'est là qu'interviennent Eric Butler et Ian "craSH" Gallagher. "Comment faire réagir ces sites" a dû être la question de départ. Après maintes réflexions (je suppose), ils ont décidé d'amener la possibilité de détourner une session HTTP à un clic de souris de tous les utilisateurs de Firefox.

Et ils ont créé Firesheep, à utiliser sur tous vos wifi non-protégés. Cet outil va permettre de sniffer le réseau à la recherche de cookies se baladant et vous afficher, dans une interface simple et intuitive, la liste des personnes ayant un compte sur divers sites sociaux et sur le même réseau que vous. Il ne vous reste plus qu'à cliquer pour obtenir l'identité de cette personne sur le site en question.

Enfin, c'est ce que dit la publicité. Je ne l'ai pas testé, la version Linux n'est pas encore dehors, il y a uniquement la version Windows et la bêta pour Mac OS X. Mais comme c'est du logiciel Libre, vous pouvez rapidement adapter le code pour tourner sur Linux.

NdM : concernant LinuxFr.org, la liste des cookies utilisés est dans l'aide, et nous invitons à préférer l'accès par HTTPS (un cookie permet de forcer tous les accès suivants en HTTPS si quelqu'un se loggue en HTTPS). Voir aussi la discussion précédente sur Cadriciel d'espionnage/gestion de témoin de connexion evercookie 0.3.

Aller plus loin

  • # Le CERTA en parle

    Posté par  . Évalué à 10.

    Le CERTA mentionne Firesheep dans son bulletin d'actualité :
    http://www.certa.ssi.gouv.fr/site/CERTA-2010-ACT-043.pdf

    Je vous invite à lire la section 4. Pour les fainéants, je reproduit l'élément à mon sens le plus intéressant :
    Il n’est donc pas possible, avec cet outil, de simplement écouter le réseau sans commettre d’accès illégitime.

    Suivent, quelques rappels de la loi.

    • [^] # Re: Le CERTA en parle

      Posté par  . Évalué à 2.

      Enfin bon, quand on lit des trucs pareils :
      Tout d’abord, il s’agit d’un outil non testé et au mode de développement inconnu. On ne reviendra pas ici sur les risques qu’il y a à installer de tels logiciels.

      Ça fait peur, le truc est opensource, ils auraient pu faire un audit plutôt de se plaindre.

  • # Firesheep

    Posté par  . Évalué à 2.

    le code de Firesheep a été audité ? c'est pas un malware ?

    sinon, https roxor

    • [^] # Re: Firesheep

      Posté par  . Évalué à 3.

      D'autant plus que pour capturer le trafic (avec libpcap), l'exécutable doit tourner en tant que root (on peut se restreindre à CAP_NET_ADMIN et CAP_NET_RAW, mais en regardant vite fait le code j'ai l'impression qu'il vérifie un euid = 0).
      Après je ne connais pas le fonctionnement précis, mais l'idée d'un module Firefox qui tourne en tant que root, j'aime moyen.
      Sinon, ça fonctionne aussi avec un réseau sécurisé, tant qu'on est authentifié (mais il faut de toute façon que la carte wifi supporte le mode promiscuous, ce qui n'était pas toujours le cas il y a quelques années...).

  • # Historique des cookies

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

    À peine hors sujet, un excellent article sur l'historique des cookies :
    http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-(...)

    https://damien.pobel.fr

  • # Ce qui m'impressionne le plus...

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

    ... Ce sont les gens qui hurlent au respect de la vie privée, mettent un mot de passe super compliqué pour leur mail "pour pas que tu hacke", et... lance leur portable sur un WiFi non sécurisé en lançant leur Thunderbird en... IMAP! (et donc password en clair pour tous)

    Il n'y a pas que HTTP qui pose problème, mais les gens ne se rendent pas compte que tout passe en clair sur un WiFi partagé, et tous les protocoles de "warrior" ont le problème (IMAP, SMTP, FTP...).

    Dès que tu sors, tout dois être ne xxxxS. Donc tant qu'à faire et pour ne pas oublier, ben dès qu'il y a un login, les non sécurisé devrait être proscrit. Mais il y a du chemin à faire pour convaincre autant les fournisseurs de services que les utilisateurs :(.

    • [^] # Re: Ce qui m'impressionne le plus...

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

      lance leur portable sur un WiFi non sécurisé en lançant leur Thunderbird en... IMAP! (et donc password en clair pour tous)
      "donc"? En IMAP il y a possibilité d'utiliser un système de challenge avec un hash, non? (la dernière fois que j'ai regardé, Free ne supportait pas ce genre de truc, ni en IMAP, ni en POP)

      • [^] # Re: Ce qui m'impressionne le plus...

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

        La dernière fois que j'ai regardé la chose, les mots de passe passaient en clair par défaut.
        Ca doit se changer, mais la config par défaut (et celle acceptée par les hébergeur) en IMAP n'est pas sécurisée.

        De plus, après je ne sais pas si ensuite, tu ne peux pas récupérer la "session" vu que tu as la même adresse IP vu du serveur (NAT derrière un Wifi non sécurisé) et que tu as tout vu passer. Je ne m'y fierais pas trop.

      • [^] # Re: Ce qui m'impressionne le plus...

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

        Il est possible d'utiliser IMAPS (IMAP over SSL), mais ce n'est malheureusement pas supporté par beaucoup de serveurs.

        • [^] # Re: Ce qui m'impressionne le plus...

          Posté par  . Évalué à 3.

          Vous me faites peur.

          Même si je n'utilise pas de Wifi, je relève la plupart de mes mails en IMAP.

          Google et AOL. Pour les deux mon Thunderbird utilise « sécurité de connexion : SSL/TLS. »

          C'est bon ? Euh ? Je me sens ignare à cause du « pas supporté par beaucoup de serveurs. »

          • [^] # Re: Ce qui m'impressionne le plus...

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

            A priori si c'est IMAP par dessus SSL/TLS, c'est bon (modulo vérification de certificats). Tu peux vérifier ce qui passe avec tcpdump/Wireshark. Après, les mails sortant utilisent un protocole complètement différent (SMTP).

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

            • [^] # Re: Ce qui m'impressionne le plus...

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

              Après, les mails sortant utilisent un protocole complètement différent (SMTP).

              Qui lui aussi peut utiliser SSL/TLS.
              Tout hébergeur de mail qui ne gère pas SSL pour ses serveurs est à bannir!
              (et après, insulter l'utilisateur qui ne réfléchit pas quand son certificat SSL change à cause d'un Man In The Middle... Il y a encore du boulot)

              • [^] # Re: Ce qui m'impressionne le plus...

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

                Il suffit de faire la démonstration d'un proxy menteur dans une grosse boite qui, pour des "raisons de sécurité", utilise un proxy https pour en filtrer le contenu. Tu n'est prévenu qu'une seul fois avec un Firefox tout neuf qui ne connait pas le certificat. Mais si tu acceptes une fois, c'est toujours bon ensuite !

                D'ailleurs, les gros site devrait utiliser un autre moyen pour détecter ce genre de cas (un échange de certificat en js ?). C'est un peu la course à l'armement, mais qu'une boite laisse ses admin voir en clair tout ce qui passe sur un réseau, c'est un peu pas top (mail perso, compte banquaire, ...).

                "La première sécurité est la liberté"

  • # réponse de l'EFF

    Posté par  (Mastodon) . Évalué à 3.

    Réponse de l'EFF :
    https://www.eff.org/https-everywhere
    Fait en collaboration entre le projet Tor et l'EFF.

    Un extension qui semble appliquée la politique que linuxfr a toujours appliquée : si une session https a été initialisée, alors https sera toujours utilisé. Très bien. Ceci inclu un ensemble de règles déjà pré-définies (pour facebook par exemple), et ces règles sont extensibles par tous.

  • # ...

    Posté par  . Évalué à 3.

    Depuis l'arrivée du cookie, c'est devenu le moyen de maintenir une session pour les utilisateurs des sites.
    Il me semble qu'il y a d'autres moyens que les cookies. Notamment un n° de session dans l'url.

    • [^] # Re: ...

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

      Ce qui est encore pire et rend encore plus facile le vol de session.

      • [^] # Re: ...

        Posté par  . Évalué à 2.

        Et comment ?

        Sois tu es en http et c'est en clair comme les cookies.
        Sois tu es en https et c'est pas en clair

        • [^] # Re: ...

          Posté par  . Évalué à 5.

          C'est une question de facilité.

          Par exemple, l'url est souvent mis dans les logs d'un proxy, alors que ce n'est pas le cas pour les cookies.

          Envoyé depuis mon lapin.

        • [^] # Re: ...

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

          Ça ne me semble pas une bonne idée du tout que de vouloir mettre cet identifiant de session dans une URL. L'URL est quand même une donnée destinée à être publique.

          Par exemple, l'utilisateur ne doit pas oublié d'enlever cet identifiant quand il partage une URL avec d'autres utilisateurs. Utiliser HTTPS n'aide en rien dans ce cas.

          Plus vicieux, l'URL peut se retrouver dans les fichiers de logs, que ce soient ceux de proxys ou d'autres serveurs via le mécanisme du Referer. Et là, HTTPS a une légère influence (la RFC dit : « Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol »).

    • [^] # Re: ...

      Posté par  . Évalué à 4.

      Il faut le mettre en POST, c'est plus (mais juste à peine) discret.

      Le problème c'est que ça ne resiste pas non plus au sniff réseau et de plus, si tu fermes et rouvre le navigateur, il n'y a plus de session.

      Pendant un moment, j'essayais de faire un systeme de session qui resiste au sniff en http. C'est à dire que même en sniffant le réseau, tu ne peux pas "prendre" la session.

      J'ai fais un systeme de tchat à base de mots aléatoire envoyé à la creation de la 1ere page puis ensuite à chaque requette ajax, c'est un hash du mot+un mot connu. Le serveur renvoye un autre mot connu puis on recommence.

      Tu ne peux pas voler la session si tu ne connais pas le 1er mot.

      Mais bon, si la 1ere page est sniffé c'est foutu.

      Moralité : https, y a que ça de vrai !

      Moralité 2 : Création du compte en https, pose d'un cookie et ensuite systeme de numéro de session dynamique, ça peut le faire.

      Moralité 3 : https partout, quand on peut, y a que ça de vrai !

Suivre le flux des commentaires

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