Menaces de délégation : analyse approfondie du correctif Microsoft de la vulnérabilité CVE-2020-17049 KCD
Décembre 13th, 2020 Dor Segal
*****Par Dor Segal, chercheur en sécurité chez Silverfort*****
Le 11 novembre 2020, Microsoft a divulgué CVE-2020-17049, un nouveau Kerberos Vulnérabilité de contournement de la fonctionnalité de sécurité. Alors que la vulnérabilité elle-même ne sera pas corrigée avant le 8 février 2021, Microsoft a publié des correctifs les 8 novembre et 8 décembre afin d'atténuer son exploitation dans l'intervalle. Très peu de choses ont été divulguées sur le fonctionnement interne de la vulnérabilité, sans POC public ni analyse technique.
Ce message tente de combler une partie de cette lacune en mettant en lumière la délégation Kerberos en général et en approfondissant le correctif que Microsoft a publié pour la vulnérabilité CVE-2020-17049 KCD elle-même.
Table des matières
Délégation Kerberos 101
La délégation Kerberos est l'un des concepts les plus compliqués de Kerberos authentification processus. Cette extension du protocole standard a été créée à l'origine pour fournir des services, et le les comptes de service qu'ils utilisent, accèdent aux ressources sans leur accorder réellement aucune sorte d'autorisations.
Depuis son introduction initiale, la délégation a subi quelques changements importants jusqu'à ce qu'elle devienne la délégation contrainte basée sur les ressources que nous utilisons aujourd'hui (alias KCD). Donc, avant d'aborder la vulnérabilité elle-même, passons en revue les différents types de délégation et leurs avantages et inconvénients respectifs.
Étape 1 : Délégation sans contrainte
La délégation sans contrainte a été introduite dans Windows Server 2000 et a été la première à permettre aux services de se faire passer pour un utilisateur avec des autorisations d'accès. Comme son nom l'indique, ce type de délégation donne à un service le pouvoir d'utiliser les informations d'identification de l'utilisateur pour accéder à n'importe quelle ressource à tout moment.
Le processus nécessite que l'utilisateur demande un TGT transmissible et le joigne au ticket de service. Ensuite, le service prend le TGT et l'injecte dans le cache local lsass.exe pour une utilisation ultérieure.
De nos jours, nous savons que cette méthode est très risquée car elle accorde un accès illimité aux services délégués, ce qui, dans le cas d'un compromis, permettrait à l'attaquant de récolter tous les tickets mis en cache et d'obtenir un accès complet à tous ses privilèges.
Ce type de délégation existe toujours aujourd'hui, principalement pour prendre en charge la rétrocompatibilité, et peut être détecté en interrogeant l'indicateur ADS_UF_TRUSTED_FOR_DELEGATION dans l'attribut userAccountControl. Ce drapeau est également surveillé par Silverfort, qui génère des rapports sur les services utilisant une délégation sans contrainte.
Étape 2 : Délégation contrainte
La prochaine génération de délégation est plus limitée et permet au service de se faire passer pour un accès uniquement à des ressources définies avec l'indicateur "Le compte est sensible et ne peut pas être délégué" sur Active Directory pour limiter l'usurpation d'identité d'utilisateurs spécifiques.
Ce type de délégation est l'endroit où le service effectue l'authentification à l'aide des extensions S4U2Self et S4U2Proxy (MS-SFU).
Alors, comment ça marche?
Notre compte de service doit avoir l'indicateur TRUSTED_TO_AUTH_FOR_DELEGATION activé et l'attribut ms-AllowedToDelegateTo qui inclut le SPN de la ressource.
Un utilisateur s'authentifie comme d'habitude auprès du service à l'aide de la négociation Kerberos (TGT et TGS).
Maintenant, cela commence à se compliquer : un compte de service délégué demande un TGT transférable à lui-même. Nous avons utilisé ce ticket pour demander un ticket de service en utilisant S4U2SELF en utilisant le nom d'utilisateur usurpé pour notre champ cname PA-DATA.
Le service prend ce ticket, le joint au ticket de service de ressource (S4U2Proxy) avec l'indicateur de délégation contrainte.
Le ticket reçu est une usurpation de l'identité de l'utilisateur actuel par notre service.
Étape 3 : Délégation contrainte basée sur les ressources
La différence majeure dans cette délégation est surtout administrative.
Au lieu de permettre au service de se voir déléguer l'accès à une ressource, nous donnons le pouvoir au propriétaire de la ressource de définir quel service est autorisé à effectuer la délégation.
Ceci est configurable par PowerShell en utilisant le DirecteursAllowedToDelegateToAccounparamètre t ou simplement en éditant l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity
Correctif de sécurité Microsoft pour CVE-2020-17049 – Analyse technique
Les vulnérabilités de protocole sont toujours plus difficiles à atténuer en raison de la prise en charge de la rétrocompatibilité requise.
Nous avons commencé à regarder le patch de Microsoft en lisant les informations publiées sur le site officiel.
Nous avons compris que la vulnérabilité concerne les "tickets de falsification" et qu'elle se situe quelque part dans le processus de délégation contrainte Kerberos.
Nous avons choisi de simuler la délégation sur un Domain Controller vulnérable et de la reproduire sur un patché pour vérifier la différence :
Le premier changement notable se situe au niveau de la longueur de chaque paquet, on peut voir que la requête du ticket auto-signé (S4U2Self) est la même mais sa réponse est plus longue de 40 octets.
Cela s'applique également à la prochaine demande et réponse S4U2Proxy, alors qu'est-ce qui a changé ?
Une comparaison textuelle n'a pas été utile car le texte modifié est crypté à l'intérieur du ticket.
Après avoir déchiffré le chiffrement à l'aide du keytab du service, le texte est lisible mais doit encore être compris.
En regardant le champ AuthorizationData, nous pouvons voir un nouveau champ Inconnu, commençant au décalage 840 avec la taille de 20.
D'où vient ce nouveau domaine ? Comment KDC gère-t-il cela ?
Ce que j'aime le plus dans les protocoles, c'est que la plupart d'entre eux ont régulièrement maintenu et mis à jour des RFC - et Kerberos ne fait pas exception.
Visiter MS-SFU remarqué qu'il a été mis à jour le 11/23/2020. Lorsque nous avons ouvert le Document de différence nous avons appris à la section 3.2.5.2.2 qu'il existe une nouvelle signature qui est utilisée pour valider l'intégrité du ticket. De plus, le patch de Microsoft laisse entendre que le premier ticket modifié est le S4U2Self.
Nous avons extrait quelques informations supplémentaires de la RFC en examinant la référence de Ticket Signature - MS-PAC 2.8.3 :
"Le KDC utilisera la clé KDC (krbtgt) [RFC4120], afin que les autres KDC puissent vérifier cette signature lors de la réception d'un PAC."
« La signature du ticket est utilisée pour détecter la falsification des tickets par des parties autres que le KDC. La signature du ticket DEVRAIT être incluse dans les tickets qui ne sont pas chiffrés sur le compte krbtgt (y compris le service de changement de mot de passe) ou sur un compte de confiance.
"correspondant à la signature du ticket contiendra la valeur 0x00000010"
La RFC MS-PAC a dévoilé le mystère derrière le champ inconnu dans l'offset 840 - c'est une nouvelle signature de ticket, chiffrée à l'aide de la clé krbtgt pour valider son intégrité.
Mors en bronze Kerberos
Le 8 décembre, une mise en œuvre de CVE-2020-17049 Vulnérabilité KCD dans Kerberos attaque au mors de bronze a été publié plus en détail, éclairant un peu plus la manipulation du ticket S4U2Self.
L'exploit traite du déchiffrement et de l'édition du bit du champ transférable à l'intérieur de la encRepPart du ticket.
Un service avec capacité de délégation peut produire des tickets S4U2Self pour tous les utilisateurs même ceux dont l'indicateur "Le compte est sensible et ne peut pas être délégué" est activé.
Ce drapeau définit le drapeau transférable sur False mais le ticket n'est jamais validé par KDC en cas de modification.
Mot de la fin
La divulgation de nouvelles vulnérabilités suscite toujours l'intérêt des chercheurs en sécurité. Typiquement, une telle divulgation n'implique pas une description détaillée des bits et octets impliqués. Bien que cela puisse avoir un sens du point de vue opérationnel, il est tout aussi important de tirer parti de ces divulgations pour obtenir de meilleures informations sur la mise en œuvre du logiciel - dans ce cas, le mécanisme de délégation Kerberos. Si la connaissance est le pouvoir, j'espère que cette analyse nous a rendus un peu plus forts.
