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
[5] https://github.com/bidord/pykek
Aucun commentaire:
Publier un commentaire