[windows] The Lord of the Token

Doublé remarqué ces derniers jours : deux papiers ont en effet été publiés à propos des jetons d'accès ("access tokens"), pièces maîtresses du modèle de sécurité de Windows.

Je vais commencer par celui publié en deuxième (raison : il s'agit d'un article et non de slides, donc plus facile à suivre off-line :), intitulé Security Implications of Windows Access Tokens Whitepaper, écrit par Luke Jennings de MWR InfoSecurity. Les résultats du "paper" ne sont pas à proprement parler nouveaux puisqu'ils ont déjà été présentés à la Defcon 15 et au CCC en 2007, mais c'est l'occasion d'un petit rafraîchissement. Rappelons qu'un jeton d'accès contient le contexte de sécurité d'un processus ou d'un thread (SIDs, privilèges, niveau d'usurpation, etc). Le noyau s'en sert pour vérifier les droits d'accès lorsque ce processus ou thread interagit avec un objet sécurisable ou demande à effectuer une action privilégiée. Un processus possède un jeton primaire, qui sera par défaut celui de ses fils et de ses threads ; un thread a cependant la possibilité, à condition de posséder le privilège SeImpersonate, d'obter pour un niveau de sécurité différent du processus qui l'a créé : il reçoit alors un jeton d'"impersonation" (usurpation). Ce jeton possède un niveau d'usurpation parmi 4 :

• Anonymous
• Identity
• Impersonate
• Delegate

Les niveaux les plus intéressants sont les deux derniers car ils permettent de réellement changer le contexte de sécurité du thread : en local pour Impersonate et local+distant pour Delegate (typiquement lors d'une connexion interactive à un système en console ou TSE). Ces jetons sont présents en mémoire sous la forme de structures noyau accessibles en userland via des handles. Après l'exploitation réussie d'un composant du serveur visé, l'idée est donc de parcourir la mémoire à leur recherche, puis de les réutiliser afin d'augmenter ses privilèges soit localement (pour passer de NETWORK SERVICE à SYSTEM par exemple), soit sur le domaine (pour passer d'admin local à maître du monde).

La première étape consiste donc à énumérer les jetons d'accès. Jenning propose pour cela d'utiliser l'API NtQuerySystemInformation. En passant une InformationClass à SystemHandleInformation, on peut lister tous les handles du système. Il suffit alors d'appeler NtQueryObject sur chaque objet pour déterminer s'il s'agit d'un jeton d'accès. Pour récupérer les informations qu'il contient, il ne reste plus qu'à utiliser GetTokenInformation. La création d'un nouveau processus avec les droits de ce jeton peut alors être réalisée avec CreateProcessAsUser.

Le "paper" présente Incognito qui n'est autre qu'une implémentation de ces concepts dans une optique pentest (disponible en standalone ou en tant qu'extension de Meterpreter). Je n'ai pas encore eu le temps de le tester mais il a l'air plutôt sympa. Il permet de lister les jetons d'un système, puis de lancer des processus dans le contexte de l'un d'entre eux. Pour résumer : vous vous connectez en tant qu'admin local d'une machine, vous recherchez le jeton de délégation de l'admin du domaine en mémoire puis vous lancez cmd.exe avec ce jeton. Donc ça c'est fait.

Cerise sur le gâteau, Jennings indique que les jetons ne sont pas effacés de la mémoire lorsque l'utilisateur ciblé, en l'occurrence l'administrateur (pour combien de temps ?) du domaine, se déconnecte. Ils ne le seront qu'au prochain reboot (ce n'est plus le cas à partir de 2003 SP1).

La question est donc : quelles machines dois-je exploiter pour trouver le jeton magique ? Deux méthodes sont proposées :

• via le Messenger Service, mais il est désactivé par défaut sur 2003 et XP SP2
• via l'API NetWkstaUserEnum, ce qui nécessite un compte utilisateur du domaine (shouldn't be a problem)

Le deuxième (enfin, le premier...) papier a été écrit par Cesar Cerrudo d'Argeniss (vous savez, les gens qui ont vendu leurs 0-days à Gleg) et s'intitule Token Kidnapping. Il présente cette fois-ci une vulnérabilité d'élévation de privilèges qui a été reconnue par Microsoft dans son bulletin 951306. Elle permet par exemple à un attaquant pouvant créer ses propres pages pour IIS (typiquement un client d'un système mutualisé) ou un administrateur MSSQL d'exécuter du code avec les droits SYSTEM.

Sous Windows XP/2003, la vulnérabilité repose sur la combinaison de deux failles :

1. en appelant une API communiquant avec un service, il est possible d'obtenir le jeton d'usurpation de ce service (tous les services ont le privilège SeImpersonate). Par exemple, en appelant DtcGetTransactionManagerEx, on obtient un jeton NETWORK SERVICE.
2. une fois obtenu un tel jeton, on peut interagir via un APC avec les threads du service RpcSS qui lui possède un jeton d'usurpation SYSTEM (c'est donc une cible de choix)

Pour Vista et 2008 :

1. en interagissant avec des pools de threads, il est possible de contourner la protection induite par le fait d'avoir un SID distinct par service (nouvelle fonctionnalité de Vista et 2008)
2. la protection des services par SID distincts ne s'applique pas aux processus non services s'exécutant en tant que NETWORK SERVICE ou LOCAL SERVICE, par exemple WmiPrvSE qui usurpe un jeton SYSTEM. Il devient donc lui aussi une cible de choix avec laquelle on peut interagir via les fonctionnalités WMI.
3. seuls quelques services utilisent les jetons de protection en écriture (c'est aussi une nouveauté)

Happy tokening :)