SecurityInsider
Le blog des experts sécurité Wavestone

MS14-068 : comment Kerberos a permis la compromission totale de votre domaine Windows


Cette année, le protocole d’authentification Kerberos aura été à l’honneur. Déjà en août, le français Benjamin Delpy présentait à la BlackHat US les terrifiantes techniques de post-exploitation permises par Kerberos sur un domaine Microsoft Windows (over-pass-the-hash, pass-the-ticket, golden et silver tickets…). Quelques semaines avant Noël, c’est la correction par Microsoft d’une vulnérabilité critique présente dans la couche Kerberos des contrôleurs de domaine qui fait parler d’elle. Retour sur cette vulnérabilité et les techniques employées pour son exploitation.

L’annonce officielle : quand Microsoft prend la parole

Le 18 novembre dernier, Microsoft publie le bulletin de sécurité MS14-068 [1] qui dévoile l’existence d’une vulnérabilité critique dans le composant Kerberos Key Distribution Center (KDC) des contrôleurs de domaine Windows. La firme indique dans son communiqué que l’exploitation de cette vulnérabilité peut permettre à n’importe quel compte utilisateur du domaine disposant de privilèges standards d’obtenir ceux d’un administrateur du domaine.
Le bulletin de sécurité précise qu’un accès distant au contrôleur de domaine est suffisant pour réaliser cette attaque et que l’ensemble des versions supportées de la gamme Windows Server sont affectées (de WS2003 à WS2012R2). Microsoft a sorti en parallèle du bulletin le correctif de sécurité KB3011780 [2] et recommande à ses clients son déploiement prioritaire sur les contrôleurs de domaine.

Kerberos 101, un bref rappel du fonctionnement

Kerberos est un protocole d’authentification inventé par le MIT. Sa sécurité repose sur des clés secrètes partagées entre un service central d’une part, le Key Distribution Center (KDC), et l’ensemble des utilisateurs et services du domaine d’autre part. Dans un domaine Microsoft Active Directory, les serveurs KDC sont les contrôleurs de domaine.

Tickets

Le rôle du KDC est de distribuer des tickets aux utilisateurs. On en distingue 2 types :
  • Le premier type est le TGT (Ticket-Granting-Ticket). Il s’agit du ticket principal de l’utilisateur. Il est délivré par le KDC après authentification de l’utilisateur, notamment lors d’une ouverture de session. Le rôle du TGT est d’être par la suite présenté au KDC afin d’obtenir des tickets du deuxième type.
  •  Le deuxième type de ticket est le TGS (Ticket-Granting-Service) qui permet l’authentification de l’utilisateur auprès des services du domaine.

    Les TGT sont chiffrés et signés cryptographiquement à l’aide d’une clé secrète connue uniquement des serveurs KDC. Les TGS sont également chiffrés et signés à l’aide d’une clé partagée entre le service cible et les serveurs KDC. L’utilisateur n’ayant pas connaissance de ces clés secrètes, il n’est pas en mesure de lire ou d’altérer le contenu de ses propres tickets.

    PAC


    La structure du contenu des tickets est complexe. Elle prévoit notamment une section appelée données d’autorisation, dont la structure est propre à chaque implémentation de Kerberos. Windows y stocke les informations d’annuaire relatives à l’utilisateur telles que son identifiant et ceux des groupes de domaine auxquels il appartient. Le format de ces données est spécifique à Microsoft (MS-PAC). On appelle communément cette zone le PAC du ticket.
    C’est sur le PAC que repose le contrôle d’accès dans un domaine Windows. Le service y récupère l’identifiant de l’utilisateur et ceux de ses groupes, qu’il compare à ses propres listes de contrôle d’accès (ACL) pour déterminer les droits et privilèges. On retiendra par exemple qu’il est légitime que n’importe quel utilisateur du domaine puisse obtenir un TGS valide pour un service d’administration. Ce n’est qu’au moment d’utiliser le ticket pour s’authentifier auprès du service que l’accès lui sera refusé ou restreint si le PAC de son ticket indique qu’il n’appartient à aucun groupe autorisé.
    Enfin, Microsoft stipule que le PAC doit lui-même être signé cryptographiquement à l’aide de la clé secrète partagée entre le service et le KDC et que la validité de cette signature doit être vérifiée par le service.

    La faille : un hash en guise de signature

    Les premiers indices sur la nature de la vulnérabilité sont fournis par Microsoft dans son bulletin de sécurité. La formulation est volontairement vague. On apprend que les contrôleurs de domaine vulnérables peuvent échouer à valider correctement une signature numérique permettant la contrefaçon par un attaquant de « certains aspects » des tickets Kerberos. On devine qu’il s’agit du PAC.
    Cette information peut être confirmée et complétée par une analyse statique du correctif de Microsoft. Le plugin patchdiff2 du désassembleur IDA permet d’effectuer la comparaison des versions de la bibliothèque kdcsvc.dll avant et après application du patch.
    Parmi les fonctions altérées par le correctif, on retrouve une fonction au nom bien explicite KdcVerifyPacSignature() :
    On découvre en comparant les codes désassemblés des deux versions qu’un contrôle effectué juste après un appel à la fonction CDLocateCheckSum() a été changé.
    Dans les deux versions, le contrôle s’opère sur un champ d’une structure dont un pointeur est situé à l’adresse ebp+0x48. L’adresse de ce pointeur est préalablement passée en 2ème argument de l’appel à la fonction CDLocateCheckSum(). Cette dernière est importée depuis la bibliothèque cryptdll.dll, qu’il est possible de désassembler dans IDA.
    Alternativement, on peut choisir de profiter du travail de Benjamin Delpy, qui pour développer son outil mimikatz a déjà réalisé la rétroingénirie d’une partie des procédures de cryptdll.dll. On trouve ainsi dans les sources publiques de mimikatz le prototype suivant pour la fonction CDLocateCheckSum() :
    La définition de la structure de son 2ème argument est la suivante :


    En recoupant ces informations avec le code désassemblé de la fonction KdcVerifyPacSignature(), on comprend que le contrôle était initialement :
    checksum->Size <= 20
    Suite à l’application du correctif, il est devenu :
    checksum->Type == -138
    La liste des types de checksum gérés par Kerberos est documentée par Microsoft :
    Le correctif s’assure donc que la signature du PAC a été générée grâce à l’algorithme de signature HMAC-MD5. Avant son application, la seule condition sur l’algorithme utilisé était que celui-ci produise une signature de 20 octets ou inférieur. Un simple algorithme de hash sans clé comme MD5 ou CRC32 pouvait donc produire une signature de PAC considérée comme valide par le contrôleur de domaine. Il s’agit d’une vulnérabilité puisque aucune connaissance de la clé secrète n’est nécessaire pour produire un tel hash.
    Une analyse similaire avait été publiée par l’équipe de chercheurs BeyondTrust [3] deux jours seulement après le bulletin de sécurité de Microsoft.

    MS11-013, la grande sœur méconnue de MS14-068

    Une fois cette vulnérabilité identifiée, une contrainte subsiste : le PAC est une donnée générée et incluse dans le ticket par le KDC. Le ticket étant lui-même signé et chiffré avec une clé secrète, il n’est pas possible pour l’utilisateur de l’altérer.
    Une solution à cette problématique peut être trouvée dans les fonctionnalités avancées de Kerberos : la RFC 4120 prévoit la possibilité pour un utilisateur de fournir lui-même des données d’autorisation dans une demande de TGS.

    Les contrôleurs de domaine Windows ajoutent systématiquement ces données dans le TGS généré pour l’utilisateur, sans les vérifier. Cette fonctionnalité ne constitue pas en soi une vulnérabilité : l’intégrité du PAC est assurée par sa signature, qui est validée par le service.
    La combinaison des deux précédents points (signature d’un PAC sans clé et injection d’un PAC dans une demande de ticket) permet l’élaboration d’un scénario complet d’exploitation de la vulnérabilité… MS11-013 ! En effet, l’attaque implique une faiblesse dans la validation du PAC par le service (et non par le KDC). Il s’avère que cette faille était bien présente dans les services Microsoft jusqu’à la sortie du bulletin de sécurité MS11-013 [4].
    On remarquera que cette première attaque reste utilisable contre un serveur ou poste qui n’aurait reçu aucune mise à jour depuis 2011, et qu’elle réussira même si les contrôleurs du domaine ont été mis à jour.

    Saupoudrez de délégation

    Pour exploiter MS14-068 sur des services déjà patchés contre MS11-013, il n’est pas seulement nécessaire de soumettre un PAC au KDC : on souhaite que le KDC remplace sa signature par une nouvelle, valide, qui sera acceptée par les services du domaine. Un moyen d’obtenir ce résultat est de soumettre le PAC dans un TGT lors d’une demande de TGS. Le PAC est alors extrait par le KDC, sa signature est vérifiée avec la clé secrète du KDC, le PAC est re-signé avec la clé du service et finalement inclut dans le TGS. À ce stade, il ne reste plus pour mettre en place l’attaque qu’à trouver un moyen d’injecter un PAC dans un TGT.
    En temps normal, la soumission d’un PAC par l’utilisateur est réservée aux demandes de TGS et ne s’applique pas aux demandes de TGT. Il existe cependant une exception à cette règle : la délégation de tickets. Il s’agit d’un mécanisme permettant l’obtention d’un nouveau TGT via une demande de TGS. Il suffit pour cela d’indiquer le KDC comme service cible de la demande de TGS. Cela est notamment utilisé pour les relations d’approbations inter-domaine (le service cible est alors le KDC d’un autre domaine).

    De la théorie à la pratique : Python Kerberos Exploitation Kit

    Un premier script d’exploitation de cette faille a pu être publié le vendredi 5 décembre par Sylvain MONNÉ, collaborateur de Solucom. Il permet d’obtenir des privilèges d’administration pour n’importe quel compte utilisateur dans un domaine vulnérable.
    Le prérequis à sa réalisation était la possibilité de manipuler plusieurs formats de données et protocoles (Kerberos v5, ASN.1, MS-PAC). Or, les bibliothèques et API système qui implémentent déjà ces formats ont été conçus uniquement dans le but de permettre une utilisation légitime de Kerberos. Elles n’offrent pas la flexibilité nécessaire pour envoyer des requêtes malicieuses.
    Pour cette raison, le choix retenu a été de ré-implémenter le protocole Kerberos et les formats liés dans le langage de programmation Python à travers une nouvelle bibliothèque baptisée Python Kerberos Exploitation Kit (PyKEK). La bibliothèque a été développée à la hâte pour les besoins de ce script d’exploitation mais sera amenée à être étoffée pour permettre d’autres usages.
    La bibliothèque PyKEK et le script d’exploitation de la faille MS14-068 sont publiquement disponibles sur le github personnel de son auteur [5].

    Conclusion

    À travers la publication de l’outil PyKEK comme de cet article, nous souhaitons démontrer les dangers d’une telle vulnérabilité sur un domaine Windows ainsi que la relative facilité avec laquelle une personne mal intentionnée pourrait en tirer profit. Maintenir Windows à jour des derniers correctifs de sécurité Microsoft apparaît une fois de plus comme une nécessité.


    [5] https://github.com/bidord/pykek

    Sylvain MONNÉ

    Aucun commentaire:

    Enregistrer un commentaire