Contournement de l'authentification multifacteur avec l'attaque Pass-the-Cookie

Comment fonctionne l'attaque Pass the Cookie

Si l'authentification multifacteur est activée, l'utilisateur doit fournir une preuve supplémentaire de son identité, par exemple en acceptant une notification push sur son appareil mobile. Une fois que l'utilisateur a réussi l'authentification multifacteur, un cookie de navigateur est créé et stocké pour votre session web.

Bien que les cookies simplifient l'expérience utilisateur, ils présentent une vulnérabilité évidente : si quelqu'un parvenait à extraire les bons cookies du navigateur, il pourrait s'authentifier en tant qu'un autre utilisateur dans une session de navigateur web totalement séparée sur un autre système. En bref, il pourrait utiliser le cookie pour contourner l'authentification via MFA. (Cela est analogue à l'attaque Pass the Hash dans Active Directory.)

Comment un adversaire peut extraire les cookies du navigateur.

Voyons comment un attaquant pourrait extraire des cookies en utilisant l'exemple du navigateur Google Chrome. Chrome stocke les cookies dans l'emplacement suivant dans une base de données SQLite :

      %localappdata%GoogleChromeUser DataDefaultCookies

The cookies for a given user are encrypted using keys tied to that user via the Microsoft Data Protection API (DPAPI). To access the cookie database and decrypt the cookies, an adversary can use the following mimikatz command:

dpapi::chrome /in:"%localappdata%GoogleChromeUser DataDefaultCookies" /unprotect

Alternatively, they could execute the following from the command line:

mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%googlechromeUSERDA~1defaultcookies /unprotect" exit
      

L'utilisation de l'une ou l'autre de ces options fournira les cookies du navigateur :

Scénario d'attaque Pass-the-Cookie

Voyons comment une attaque Pass-the-Cookie se déroulerait dans un scénario réel.

Supposons que l'utilisateur Tobias soit un administrateur IT. L'une des applications web que Tobias utilise régulièrement est le portail de gestion Microsoft Azure. Étant donné que MFA est activé, lorsque Tobias se connecte à Azure, il doit fournir un code provenant de l'application d'authentification sur son appareil mobile, comme indiqué ci-dessous.

Alors, tant que personne ne vole son iPhone, ses identifiants Azure devraient être en sécurité, n'est-ce pas ? Pas si vite. Supposons que Tobias ait cliqué sur un e-mail de phishing ou que son système ait été compromis par d'autres moyens, et maintenant un attaquant est capable d'exécuter du code dans le contexte utilisateur de Tobias. Tobias n'est PAS administrateur sur son ordinateur portable, donc les dégâts devraient être limités, n'est-ce pas ?

Voyons voir.

Étape 1. Extrayez les cookies.

Comme nous l'avons vu précédemment, tout ce que nous avons à faire pour obtenir les cookies du navigateur de Tobias est d'exécuter cette commande lorsque nous sommes connectés en tant que Tobias :

      mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%googlechromeUSERDA~1defaultcookies /unprotect" exit
      

Dans ce cas, nous nous intéressons aux cookies d'authentification Azure, y compris ESTSAUTH, ESTSAUTHPERSISTENT et ESTSAUTHLIGHT. Ces cookies sont facilement accessibles car Tobias a été actif sur Azure récemment :

Étape 2. Transmettez les cookies.

Il peut sembler que puisque nous ne connaissons pas l'identifiant utilisateur ou le mot de passe de Tobias et que nous n'avons pas accès à son appareil mobile, nous ne pouvons pas nous connecter à des applications web comme Azure en tant que Tobias.

Mais puisque nous avons ses cookies, il suffit de les transférer dans une autre session pour prendre le contrôle du compte de Tobias. C'est assez simple à faire : nous ouvrons simplement Chrome sur un autre serveur et utilisons l'interface « Inspecter » pour insérer un cookie.

2.1. Tout d'abord, nous inspectons la session volée :

2.2. Ensuite, nous naviguons vers Application > Cookies. Comme vous pouvez le voir, les cookies actuels n'incluent pas ESTSAUTH ou ESTSAUTHPERSISTENT :

2.3. Nous ajoutons le cookie ESTSAUTH ou If ESTSAUTHPERSISTENT. (Si ESTSAUTHPERSISTENT est disponible, il est préféré car il est généré par l'option « Rester connecté ».)

2.4. Nous rafraîchissons la page et maintenant nous sommes connectés à Azure en tant que Tobias — aucune authentification multifacteur requise !

Atténuer vos risques

Les attaques Pass-the-Cookie représentent une menace sérieuse pour plusieurs raisons. Premièrement, une attaque Pass-the-Cookie ne nécessite pas de droits administratifs ; tous les utilisateurs ont accès pour lire et déchiffrer leurs propres cookies de navigateur, qu'ils aient ou non des droits privilégiés sur leurs postes de travail. Deuxièmement, l'attaquant n'a pas besoin de connaître l'ID utilisateur ou le mot de passe du compte compromis, donc cette attaque est possible avec un minimum d'informations. Troisièmement, nous avons même réussi à réaliser des attaques Pass-the-Cookie après la fermeture du navigateur.

Une manière de minimiser le risque de vol de cookies est de supprimer plus souvent les cookies des utilisateurs. Cependant, cela les obligera à se réauthentifier chaque fois qu'ils accèdent à un site, ce qui les frustrera et les incitera à ne jamais fermer leur navigateur pour éviter de perdre leurs cookies.

Une meilleure stratégie consiste à mettre en œuvre des produits de surveillance de l'authentification et de détection des menaces comme ceux-ci. Netwrix Threat Manager peut détecter rapidement les comptes utilisés de manière inattendue afin que vous puissiez rapidement mettre fin à l'activité malveillante.