sebdelkil

Vol par Cookies

Introduction:
Depuis leur apparition, les cookies ont été contestés. Cela a débuté par les problèmes de violation de la vie privée, suivi de prêt par le non-anonymat que cela a engendré.
Maintenant, de nouveaux évènements ont démontré la faiblesse des cookies au niveau de la sécurité. Nous allons vous expliquer de quoi il retourne.

Qu'est-ce que c'est ?
Un cookie est un petit fichier texte, qui est stocké par un site web sur votre disque dur. Ce stockage est réalisé par votre navigateur. Cela est utilisé par le site web que vous visitez pour vous "reconnaître". Aussi, quand plusieurs jours après votre visite, vous revenez sur le même site, celui-ci demandera votre cookie, et s'il est encore présent sur votre disque dur, le site web lira les informations contenues dans le cookie et vous "reconnaîtra". Je mets le verbe reconnaître entre guillemets, car il s'agit d'une pseudo-authentification...

La sécurité:
Les cookies contiennent des données personnalisées de votre compte, de votre ordinateur. Les cookies sont donc des données sensibles d'un point de vue de la sécurité. Ils faut donc les considérer comme des données personnelles que personne ne doit obtenir. Ce n'est donc pas un hasard s'ils sont stockés dans C:\Documents and Settings sous Windows 2000.
Nous allons donc faire le tour de l'aspect sécurité des cookies.

Vol de cookies:
Le but du hacker, est donc généralement de voler le cookie de sa victime pour en exploiter le contenu.
Comme nous l'avons vu, en théorie, un cookie associé à un site web ne peut pas être envoyé à un autre site web. Malheureusement, un certain nombre de failles permettent de voler des cookies.

Vol par accès physique à la machine:
Si le hacker a accès physiquement à la machine, rien de plus simple que de récupérer les cookies ! Il va dans le répertoire de stockage des cookies en fonction du système d'exploitation (voir tableau plus haut) et copie les cookies sur disquette...
La station est vérouillée ? L'attaquant n'a pas les droits d'admin ? Trinux permet de prendre la main sur la machine locale en rebootant sur disquette ou CD. Il ne reste plus qu'à "mounter" la partition et récupérer les cookies qui vont bien :)

Vol par sniffing / man in the middle:
Comme nous l'avons vu, les cookies passent par les requêtes HTTP. Si l'attaquant peut intercepter les requêtes HTTP, soit à l'aide d'un sniffer, soit par attaque par le milieu, il peut donc récupérer tous les cookies sans aucun problème. A condition bien sur que le flux HTTP ne soit pas chiffré (HTTPS, VPN...).

Vulnérabilité du navigateur:
Cette usine à gaz qu'est le navigateur, de plus en plus compliqué à chaque nouvelle version, comporte un nombre de failles impressionnant. Parmi toutes ces failles, il y en a certaines qui concernent tout particulièrement les cookies.

Mozilla
Mozilla permet à l'attaquant de voler les cookies de l'internaute. Le navigateur se connecte sur un site et envoie le cookie associé à un autre site (pirate celui-ci) qui récupère le cookie.
Référence : http://www.securiteam.com/securitynews/5GP0T0U60M.html

Internet Explorer
Internet Explorer peut lire vos cookies par injection de script. L'attaquant monte un server pirate et, au détour d'une URL malformée, lit et stocke vos cookies.
Référence : http://www.securiteam.com/windowsntfocus/6S00C0A35W.html

Cross Site Scripting

Une vulnérabilité de type Cross Site Scripting sur le site web Mail.com permet à l'attaquant de voler le cookie Mail.com de sa victime.
Référence : http://www.securiteam.com/securitynews/5YP0E0A61Q.html

Une vulnérabilité dans Pforum version 1.14 permet de récupérer le cookie d'un autre internaute par Cross Site Scripting
Référence : http://www.securiteam.com/unixfocus/5IP050A6KS.html

Exploitation des cookies volés:
Une fois qu'un hacker a votre cookie, il peut l'exploiter. Voici un petit panorama de ce qu'il peut faire...

Récupération des données d'authentification:

Un site bien connu a stocké le couple login/mot de passe de l'authentification, en clair dans le cookie ! Nul besoin donc d'être un hacker hors du commun pour comprendre qu'il est enfantin d'exploiter ces informations. Il parait incroyable que des concepteurs de sites web mettent des données confidentielles en clair dans un cookie ! Webmasters, arrêtez le massacre ! Ne stockez plus d'informations confidentielles dans des zones non protégées/non chiffrées !

Un autre superbe exemple d'une absence totale de protection des données sensibles : PHPNuke stocke le mot de passe Admin encodé en base 64 ! Rappelons que "base 64" n'est pas un algorithme de chiffrement, mais un algorithme d'encodage de données. Rien de plus simple donc, pour décoder ce mot de passe.
Référence : http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2002-08/0226.html

Replay attacks:
Les cookies sont en général utilisés pour reconnaître l'internaute qui visite le site (je n'ose pas parler d'authentification). Un exploit très classique et très facile est le replay attack. Il s'agit de rejouer la session de connexion au site. Si le cookie n'est pas écrit pour empêcher cette attaque, alors l'attaquant peut utiliser le cookie de sa victime pour être reconnu comme celle-ci par le site web. En général, le simple fait de reprendre tel quel le cookie de sa victime et de le mettre dans ses propres cookies permet à l'attaquant de se faire passer pour elle.

C'était le cas d'Hotmail, la célèbre messagerie de Microsoft.
Référence : http://www.securiteam.com/securitynews/3N5QDQAPPW.html

Une autre attaque exploite un bug d'IIS 4.0 et 5.0. Ces deux versions de serveurs web utilisent le même cookie entre une zone non sécurisée (publique) et une zone HTTPS. En sniffant le cookie dans la zone non sécurisée, on obtient le cookie de session permettant d'accéder à la zone sécurisée.
Référence : http://www.securiteam.com/windowsntfocus/6H00N200KK.html

Modification de cookies pour prendre l'identité de la victime:
Quelque fois, une attaque par replay ne fonctionne pas telle quel. Il faut modifier quelque peu le cookie pour voler la session.

C'est le cas de Bluestone Sapphire/Web. Celui-ci utilise un numéro de session pour "authentifier" le visiteur. Le problème est que ce numéro de session est incrémenté de 1 à chaque nouvelle session ! Pour voler la session de la personne qui s'est connectée juste avant vous, il suffit de modifier le cookie : repérer où est stocké le numéro de session, le décrémenter de 1, sauvegarder la modification.
Référence : http://www.securiteam.com/exploits/2QUQ4QASAM.html

Modification de cookies pour obtenir des droits privilégiés:
La modification du cookie peut être effectuée pour ne pas prendre l'identité de la victime, mais prendre directement les droits de la victime.

C'est le cas par exemple pour le livre d'or AlGuest.
Référence : http://www.securiteam.com/unixfocus/5YP0O1P6KE.html

Les solutions:

Côté client:

Désactiver les cookies. Mais beaucoup de sites web ont besoin de cette fonctionnalité pour leur propre fonctionnement, pénalisant l'internaute qui ne supporte pas les cookies.

Côté site web:
La sécurité au niveau des cookies est à la charge du webmaster. Lui seul doit prendre en compte la sécurité de son site et des internautes qui le visite.

Ne jamais stocker les informations concernant l'authentification de l'internaute en clair ou encodé.

Si vous utilisez un ID de session, ne jamais faire un ID incrémenté "simplement".

Utilisez un ID de session aléatoire.

Utilisez un ID de session a chaque requête HTTP.

Utiliser un système de dé-login qui efface le cookie.

Vérifiez que vos cookies ne sont pas sensible à une replay attack.

Chiffrer les cookies : Un cookie peut être chiffré en partie ou en totalité. Mais attention, utilisez un chiffrement fort !

Utilisez des protocoles sécurisés comme HTTPS.

En aucun cas, un cookie ne doit être utilisé pour reconnaître automatiquement un internaute. Au mieux, un internaute devra, à chaque visite de votre site, s'authentifier pour recevoir un nouveau cookie.