Retour sur l'édition 2023 de l'Insomni'hack

XMCO a pu assister à l’édition 2023 d’Insomni’hack qui s’est tenu au SwissTech Convention Center de Lausanne du 20 au 25 mars dernier.

L’évènement proposait une variété d’activités permettant aux professionnels autant qu’aux passionnés de sécurité informatique d’y trouver leur compte. Ainsi, en plus des conférences variées qui s’étalaient sur 3 scènes différentes, une compétition ainsi que des workshops se sont tenus en parallèle. Le CTF (de type Jeopardy) s’est déroulé du vendredi soir au samedi matin tandis que les workshops s’étalaient sur 2 jours (le 21 et le 22).

Breaking and Fixing Azure AD Device Identity Security

Dans cette première présentation, Dirk-jan Mollema revient sur son analyse du processus d’enrôlement des appareils joints au sein d’Azure AD et des différents scénarios de contournement de sécurité qu’il a pu identifier. La conférence est précise et détaille de manière globale le fonctionnement de ce service d’Azure AD.

Son analyse lui a notamment permis de répondre aux questions suivantes :

  • Comment les appareils sont-ils reliés à Azure AD ?
  • Comment les secrets sont-ils protégés (côté hardware) ?
  • Est-il possible d’extraire les secrets ou d’en contourner le besoin ?
  • Peut-on contourner l’exigence de conformité des appareils ?

Pour cela, Dirk-jan commence par revenir sur de grands principes tels que le Zero Trust, les identités au sein d’Azure AD ou encore le fonctionnement global d’Intune (MDM Azure).

Une fois ces différents points évoqués, une analyse du processus d’enrôlement de Windows Autopilot (outil permettant le déploiement d’appareils avec préconfiguration) est présentée.

Les différentes étapes sont introduites à l’audience au sein de slides détaillées mettant en avant de manière claire les éléments importants.

On apprend ainsi que le mécanisme d’enrôlement se base sur 2 types de clés : les « device key » et les « transport key », les parties publiques étant envoyés à Azure AD au sein d’une requête HTTP tandis que les parties privées restent sur l’appareil à enrôler au sein du TPM.

La description de ce processus est importante pour comprendre la suite de la recherche qui met en avant les scénarios de contournement identifiés par le présentateur.

Un autre concept majeur présenté au sein de cette conférence est le jeton PRT (pour Primary Refresh Token). Ce dernier permet aux utilisateurs de s’authentifier une fois sur leur appareil connecté à Azure AD et de se connecter ensuite automatiquement aux ressources connectées à Azure AD.

Dirk-jan revient donc sur son obtention ainsi que sur la manière dont ce dernier est stocké et utilisé.

C’est notamment sur ce PRT stocké localement que plusieurs scénarios ont été identifiés :

  • En tant qu’utilisateur classique sur l’appareil : demande de PRT en utilisant un jeton de SSO
  • En tant qu’administrateur sur l’appareil : vol du PRT si non stocké au sein d’un TPM et interaction avec les clés PRT au sein du processus LSASS

La recherche sur le vol de PRT en tant qu’administrateur de l’appareil a été effectuée en coordination avec Benjamin Delpy et le scénario final était instrumentalisé à l’aide de mimikatz et de roadrecon. La vulnérabilité reposait sur le fait que les cookies PRT utilisés par les applications web étaient générés à l’aide de « derived keys » reposant sur des « session key » (stockée au sein du TPM) ayant une durée de vie illimitée, rendant possible les attaques par force brute.

Le scénario identifié en tant qu’utilisateur classique permet quant à lui d’obtenir un PRT en enregistrant un nouvel appareil.

Pour ce faire, un jeton de SSO peut être demandé à l’aide de la session utilisateur sans droit administrateur. Cette méthode est extrêmement pratique, car même si l’ancien appareil est désactivé, le PRT sera toujours valide. Néanmoins, pour exploiter ce scénario, l’utilisateur doit posséder le droit d’enregistrer un nouvel appareil et l’appareil nouvellement créé ne sera pas forcément enrôlé au sein d’Intunes pour des raisons de compliance.

La présentation continue sur un scénario permettant de contourner les restrictions apportées par Intunes. Pour cela, le chercheur a identifié une vulnérabilité au sein du processus d’enregistrement. En effet, l’attribut « MSA-DDID » envoyé au serveur via une requête HTTP lors de l’enregistrement peut être réutilisé pour un autre appareil. Cet attribut qui est en réalité un « device ticket » permet d’authentifier un appareil et est récupérable à l’aide d’une session utilisateur sur l’appareil souhaité. Lors de la réutilisation de ce « device ticket » pour l’enrôlement d’un autre appareil, le nouvel appareil viendra écraser l’ancien tout en conservant son statut de compliance au sein d’Intunes, outrepassant ainsi les restrictions apportées par Intunes.

La présentation se termine par une chronologie des différents correctifs apportés par Microsoft. On apprend ainsi que le dernier correctif s’assurant de la suppression du statut de « compliance » au sein d’Intunes a été appliqué… la veille de la présentation.

Toutefois, la méthode d’enregistrement des appareils semble inchangée, laissant encore la possibilité d’écraser un appareil au sein d’Azure AD.

Lien vers les slides : https://dirkjanm.io/assets/raw/Insomnihack%20Breaking%20and%20fixing%20Azure%20AD%20device%20identity%20security.pdf

Attacking and Defending GraphQL: The Ultimate Guide

Cette conférence qui a conclu la première journée présentait GraphQL du point de vue d’un développeur (intérêt, fonctionnement, etc.), d’un attaquant (différents types d’attaque sur la technologie) et d’un défenseur (comment se prémunir des attaques classiques). Elle était présentée par Leo Juszkiewicz, AppSec Architect pour DarioHealth.

Leo commence par s’intéresser à l’historique de la technologie et le pourquoi de sa création (avantages et désavantages par rapport à une API REST). Il fait également le point sur quelques terminologies nécessaires à la compréhension de la suite de la présentation.

Il revient ensuite sur le fonctionnement de GraphQL avec les opérations principales qui sont les suivantes :

  • Query : lecture
  • Mutation : lecture et écriture (création, modification et suppression)
  • Subscription : lecture (contrairement aux queries, les subscriptions sont des opérations de longue durée qui peuvent modifier leur résultat au fil du temps en maintenant une connexion active avec le serveur)

Ainsi que sur certaines particularités du langage comme les fragments qui permettent de réutiliser des champs sans se répéter ou encore les directives qui permettent de configurer de manière plus spécifique les requêtes.

S’ensuit alors la partie offensive de la présentation où est présenté différents « quick win » permettant d’obtenir plus d’informations sur l’API représenté. Léo présente le principe d’introspection qui, si activé (ce qui est le cas par défaut), permet d’obtenir les informations sur les schémas, les queries ou encore les types définis. La présentation met également bien en avant le fait qu’en Java et en Go, il est impossible de la désactiver.

Une liste des routes les plus utilisées est également mise en avant dans le but de souligner le fait que GraphQL repose sur un endpoint unique. Ainsi, une fois ce dernier identifié, il est possible d’effectuer tout type de requêtes. Différents outils tels que « GraphQL voyager » sont également mis en avant afin de faciliter le débogage (côté développeur), mais également l’exploitation de GraphQL (côté attaquant).

Pour conclure cette partie offensive, le présentateur a choisi de décrire un cas d’exploitation réel sur le framework Shopify. En effet, une mutation existait pour changer la configuration du mail d’un utilisateur. Aucun token ou mot de passe n’était nécessaire pour cette mutation. Ainsi, il était donc possible de changer l’email d’un utilisateur via cette mutation, permettant par la suite de créer un nouveau magasin en ligne apparaissant comme appartenant aux magasins de la victime. Une fois la partie offensive terminée, le conférencier s’est penché sur le côté défensif, soit comment protéger son API GraphQL. Pour cela, il propose un ensemble de points à vérifier tels que désactiver l’introspection, utiliser uniquement des requêtes POST, limiter la profondeur des requêtes et les timeout afin d’éviter les attaques par déni de service ou encore, de manière plus classique, s’assurer que les champs soient correctement assainis et validés.

A Ticket Worth Waiting 65 Years For

Lors de cette présentation, Charlie Bromberg (alias Shutdown) a présenté un nouveau type d’attaque visant le protocole Kerberos permettant d’obtenir le ticket d’un utilisateur privilégié (Administrateur de domaine) tout en étant plus furtif qu’avec les autres méthodes déjà existantes (Silver Ticket, Golden Ticket, Diamond Ticket). Il a ainsi nommé ce nouveau ticket « Sapphire Ticket ».

Avant de rentrer dans le vif du sujet, Charlie Bromberg fait d’abord un bref récapitulatif des protocoles NTLM et Kerberos. Succinctement, il explique ainsi que l’authentification avec le protocole NTLM est basée sur un « 3-way handshake » tandis que le protocole Kerberos est basé sur des tickets qui expirent dans le temps. Les attaques à l’encontre des 2 protocoles sont ensuite mises en avant, semblant montrer que le protocole Kerberos est plus vulnérable que le protocole NTLM. Cependant, le présentateur enjoint fortement à ne pas utiliser NTLM, mais uniquement Kerberos, car celui-ci est présenté comme étant beaucoup plus sécurisé malgré les attaques plus nombreuses contre celui-ci (dues à des défauts de configuration pour la majorité et non au protocole en lui-même).

L’une des raisons qui nous a fait apprécier cette conférence et pourquoi nous vous conseillons de la voir concerne la présentation du protocole Kerberos et des exploitations possibles contre celui-ci. Ce protocole est en effet assez complexe et il est agréable de le découvrir via des slides claires et simples.

Afin d’arriver au cheminement permettant d’expliquer comment obtenir un « Sapphire Ticket », Charlie Bromberg est revenu sur la présentation du protocole Kerberos et de son fonctionnement global avec différents schémas.

Il explique ainsi que la phase d’authentification se déroule selon les étapes résumées suivantes :

  1. L’utilisateur demande un premier Ticket Granting Ticket (un TGT) au KDC (Key Distribution Center) en chiffrant un timestamp avec une clé connue par l’utilisateur (ces clés sont souvent le hash NT de l’utilisateur)
  2. Si les informations de l’utilisateur sont correctes, le KDC va envoyer à l’utilisateur le TGT. Au sein de ce ticket seront stockées les informations de l’utilisateur (privilèges, groupe … etc.) via le Privilege Attribute Certificate (PAC) qui est chiffré avec une clé connue de l’utilisateur KRBTGT.
  3. Enfin, l’utilisateur peut demander un Service Ticket (ST) en présentant son TGT au KDC. Le PAC est alors répliqué et chiffré cette fois-ci selon une clé connue uniquement par le service auquel l’utilisateur souhaite accéder. Le service décidera ensuite si l’utilisateur peut accéder à ce service ou non en analysant les informations contenues au sein du PAC du ticket présenté par l’utilisateur.

L’information importante à retenir ici est que les informations de l’utilisateur sont stockées au sein du PAC. Ainsi, si un attaquant parvient à le modifier, il pourra accéder aux services de son choix et compromettre le domaine cible de sa victime.

S’ensuit une présentation des attaques déjà existantes afin de mettre en contexte ce nouveau « Sapphire Ticket ». Charlie Bromberg explique alors que :

  • Le Silver Ticket est un ST contenant un PAC falsifié (forgé) avec la clé connue du service auquel l’utilisateur souhaite accéder
  • Le Golden Ticket est un TGT contenant un PAC falsifié (forgé) avec la clé connue de l’utilisateur KRBTGT

Cependant, le présentateur explique que ces méthodes sont généralement détectées, car les évènements relatifs aux demandes de tickets de service sont surveillés. De plus, étant donné que le PAC est entièrement forgé, ceux-ci ne parviennent pas toujours à imiter les vrais et la création du ticket souhaité peut plus facilement échouer.

C’est dans ce contexte que le Diamond Ticket fut inventé. Son obtention se fait via la demande d’un ticket (TGT ou ST). Ensuite, le PAC est déchiffré avec l’information connue de l’utilisateur (la clé du service ou du compte KRBTGT). Le PAC est ensuite uniquement modifié et non entièrement forgé.

Concernant cette méthode, elle est bien plus furtive que les 2 précédentes, car les demandes de ticket sont légitimes et ne lèvent donc aucune alerte. Cependant, l’outil présenté par Charlie Bromberg (ticketer de la suite Impacket) qui implémente la théorie derrière ce « Diamond Ticket » ne parvient pas à uniquement modifier le PAC, mais le forge entièrement comme c’était le cas au sein des deux premières méthodes présentées plus tôt.

Le présentateur dit qu’il est tout de même possible de réaliser cette méthode via l’outil Rubeus qui implémente correctement la théorie derrière le « Diamond Ticket ».

Cet outil n’est malheureusement utilisable que sur des systèmes Windows et Charlie Bromberg souhaitait pouvoir avoir un ticket correspondant à celui d’un utilisateur privilégié d’une manière furtive sur un système Unix-Like. C’est dans ce contexte qu’est né le « Sapphire Ticket ».

Les « Sapphire Tickets » sont similaires aux « Diamond Tickets » dans la mesure où le ticket n’est pas falsifié, mais est uniquement basé sur un ticket légitime obtenu à la suite d’une demande. La différence réside dans la manière dont le PAC est modifié. Pour le « Sapphire Ticket », le PAC d’un autre utilisateur privilégié est obtenu en exploitant un scénario de délégation Kerberos (S4U2Self + u2u). Ce PAC remplace alors celui présent dans le ticket légitime au lieu d’être forgé. Le ticket résultant est ainsi un assemblage d’éléments légitimes.

Enfin, tout comme le « Diamond Ticket », cette méthode est furtive du fait que les demandes de ticket sont légitimes. De plus, la modification du PAC peut cette fois-ci se faire via la suite d’outils « Impacket » disponible sur un système Unix-Like.

Lien vers les slides : https://drive.google.com/file/d/1QQ_Sn3rVdcCJ0cXOxFP_0wPGWhzvo3a_/view

Tom TRIBOULOT & Samuel CRETEUR

Samuel Creteur

Découvrir d'autres articles

  • Conférences

    Retour sur le PCI Community Meeting 2023 à Dublin

    Lire l'article
  • Conférences

    Retour sur Hack In Paris 2023

    Lire l'article
  • Conférences

    Retour sur la conférence Brucon 2023

    Lire l'article