The Power in Power Users

Publié pour la première fois sur TechNet en mai 01, 2006

Placer des comptes d’utilisateurs Windows dans le groupe de sécurité des utilisateurs expérimentés est une approche courante adoptée par les organisations informatiques pour amener les utilisateurs dans un environnement à moindre privilège tout en évitant les nombreuses difficultés liées à l’exécution en tant qu’utilisateur limité. Le groupe Power Users est capable d’installer des logiciels, de gérer les paramètres d’alimentation et de fuseau horaire et d’installer des contrôles ActiveX, des actions refusées aux utilisateurs limités.
Ce que de nombreux administrateurs ne réalisent pas, cependant, c’est que ce pouvoir se fait au prix d’une véritable sécurité pour les utilisateurs limités. De nombreux articles, y compris cet article de la Base de connaissances Microsoft et cet article de blog du spécialiste de la sécurité Microsoft Jesper Johansen, soulignent qu’un utilisateur appartenant au groupe Power Users peut facilement s’élever à des administrateurs à privilèges complets, mais je n’ai pas pu trouver une description détaillée des mécanismes d’élévation auxquels ils se réfèrent. J’ai donc décidé d’enquêter.
Avant de pouvoir commencer l’enquête, j’ai dû définir le problème. En l’absence d’une faille de sécurité telle qu’un dépassement de privilège de dépassement de tampon, l’escalade n’est possible que si un compte peut configurer du code arbitraire à exécuter dans le contexte d’un compte plus privilégié. Les comptes par défaut qui ont plus de privilèges que les utilisateurs expérimentés comprennent les administrateurs et le compte système local, dans lequel plusieurs processus de service Windows s’exécutent. Ainsi, si un membre Power Users peut modifier un fichier exécuté par l’un de ces comptes, configurer l’un de ses exécutables pour charger une DLL arbitraire ou ajouter un démarrage automatique exécutable à ces comptes, il peut obtenir des privilèges d’administration complets.
Ma première étape a été de voir quels fichiers et répertoires le groupe d’utilisateurs expérimentés a un accès en écriture, mais pas les utilisateurs limités. Les systèmes que j’ai considérés étaient Windows 2000 Professional SP4, Windows XP SP2 et Windows Vista. Je ne vais pas prendre la peine de regarder les systèmes de serveurs car le scénario le plus courant pour les utilisateurs expérimentés est sur un poste de travail.
La méthode de la force brute pour voir quels objets du système de fichiers Les utilisateurs expérimentés peuvent modifier nécessite de visiter chaque fichier et répertoire et d’examiner ses autorisations, ce qui n’est clairement pas pratique. L’utilitaire Cacls en ligne de commande que Windows inclut vide les descripteurs de sécurité, mais je n’ai jamais pris la peine d’apprendre le Langage de description des descripteurs de sécurité (SDDL) et d’analyser la sortie nécessiterait l’écriture d’un script. L’utilitaire AccessEnum que Bryce a écrit semblait prometteur et il peut également examiner la sécurité du registre, mais il vise à montrer les faiblesses potentielles des autorisations, pas les accès disponibles pour des comptes particuliers. De plus, je savais que je devais également examiner la sécurité appliquée aux services Windows.

J’ai conclu que je devais écrire un nouvel utilitaire pour le travail, j’ai donc créé AccessChk. Vous transmettez à AccessChk un nom de compte ou de groupe et un chemin d’accès au système de fichiers, une clé de registre ou un nom de service Windows, et il signale les accès effectifs du compte ou du groupe pour l’objet, en tenant compte des adhésions au groupe du compte. Par exemple, si le compte Mark avait accès à un fichier, mais que Mark appartient au groupe de développeurs auquel l’accès est explicitement refusé, alors AccessChk affichera Mark comme n’ayant aucun accès.
Afin de rendre la sortie facile à lire, AccessChk imprime ‘W’ à côté du nom de l’objet si un compte dispose d’autorisations lui permettant de modifier un objet, et ‘R’ si un compte peut lire les données ou le statut de l’objet. Divers commutateurs provoquent la récursion d’AccessChk dans des sous-répertoires ou des sous-clés de registre et le commutateur –v lui fait rapporter les accès spécifiques disponibles pour le compte. Un commutateur que j’ai ajouté spécifiquement pour rechercher des objets pour lesquels un compte a un accès en écriture est –w.
Armé de ce nouvel outil, j’étais prêt à commencer à enquêter. Ma première cible était une installation VMware Windows XP SP2 qui n’avait pas d’applications installées autres que les outils VMware. La première commande que j’ai exécutée était :
accesschk-ws “utilisateurs puissants” c:\windows
Affiche tous les fichiers et répertoires du répertoire \Windows que le groupe Power Users peut modifier. Bien entendu, de nombreux fichiers sous \Windows font partie du système d’exploitation ou des services Windows et s’exécutent donc dans le compte système local. AccessChk a signalé que les utilisateurs expérimentés peuvent modifier la plupart des répertoires sous \Windows, ce qui permet aux utilisateurs membres de créer des fichiers dans ces répertoires. Ainsi, un membre du groupe Power Users peut créer des fichiers dans le répertoire \Windows et \Windows\System32, ce qui est une exigence courante des applications héritées mal écrites. De plus, les utilisateurs expérimentés doivent pouvoir créer des fichiers dans le répertoire \Windows\Downloaded Program Files afin qu’ils puissent installer des contrôles ActiveX, car Internet Explorer les enregistre dans ce répertoire. Cependant, la simple création d’un fichier dans ces répertoires n’est pas un chemin vers l’élévation des privilèges.
Bien que les utilisateurs expérimentés puissent créer des fichiers sous \Windows et la plupart de ses sous-répertoires, Windows configure les autorisations de sécurité par défaut sur la plupart des fichiers contenus dans ces répertoires afin que seuls les membres du groupe Administrateurs et du compte système local aient un accès en écriture. Les exceptions incluent les fichiers de police (.fon), de nombreux fichiers journaux système (.log), quelques fichiers d’aide (.chm), des images et des clips audio (.jpg, .gif, et.wmv) et les fichiers d’installation (.inf), mais aucun de ces fichiers ne peut être modifié ou remplacé pour obtenir le privilège administratif. Les pilotes de périphériques dans \Windows\System32\Drivers permettraient une escalade facile, mais les utilisateurs expérimentés n’ont accès en écriture à aucun d’entre eux.

J’en ai vu un certain nombre.exe et.les dll sont dans la liste, donc je les ai examinées pour d’éventuels exploits. La plupart des exécutables pour lesquels les utilisateurs expérimentés ont un accès en écriture sont des utilitaires interactifs ou s’exécutent avec des privilèges réduits. Sauf si vous pouvez inciter un administrateur à se connecter de manière interactive au système, ceux-ci ne peuvent pas être utilisés pour élever. Mais il y a une exception flagrante: ntoskrnl.exe:

C’est vrai, les utilisateurs expérimentés peuvent remplacer ou modifier le fichier du système d’exploitation principal de Windows. Cependant, cinq secondes après la modification du fichier, Windows File Protection (WFP) le remplacera par une copie de sauvegarde qu’il récupère, dans la plupart des cas, dans \Windows\System32\Dllcache. Les utilisateurs expérimentés n’ont pas d’accès en écriture aux fichiers dans Dllcache, il ne peut donc pas subvertir la copie de sauvegarde. Mais les membres du groupe Power Users peuvent contourner le PAM en écrivant un programme simple qui remplace le fichier, vide les données modifiées sur le disque, puis redémarre le système avant que le PAM n’agisse.
J’ai vérifié que cette approche fonctionne, mais la question restait de savoir comment cette vulnérabilité pouvait être utilisée pour élever les privilèges. La réponse est aussi simple que d’utiliser un désassembleur pour trouver la fonction que Windows utilise pour les vérifications de privilèges, SeSinglePrivilegeCheck, et patcher son point d’entrée dans l’image sur disque afin qu’elle renvoie toujours TRUE, qui est le code de résultat qui indique qu’un utilisateur a le privilège en cours de vérification. Une fois qu’un utilisateur s’exécute sur un noyau modifié de cette manière, il semble avoir tous les privilèges, y compris Charger le pilote, s’approprier et Créer un jeton, pour ne citer que quelques-uns des privilèges qu’il peut facilement exploiter pour prendre le contrôle administratif total d’un système. Bien que Windows XP 64 bits empêche la falsification du noyau avec PatchGuard, peu d’entreprises fonctionnent sur Windows 64 bits.
Remplacement de Ntoksrnl.exe n’est cependant pas le seul moyen d’accéder aux privilèges administratifs via le répertoire \Windows. Au moins une des DLL pour lesquelles les autorisations par défaut autorisent la modification par un utilisateur expérimenté, Schedsvc.dll, s’exécute en tant que service Windows dans le compte système local. Schedsvc.dll est la DLL qui implémente le service de planificateur de tâches Windows. Windows peut fonctionner avec succès sans le service afin que les utilisateurs expérimentés puissent remplacer la DLL par une DLL arbitraire, telle que celle qui ajoute simplement leur compte au groupe Administrateurs locaux. Bien sûr, le PAM protège également ce fichier, donc le remplacer nécessite l’utilisation de la technique de contournement du PAM que j’ai décrite.

J’avais déjà identifié plusieurs vecteurs d’élévation, mais j’ai poursuivi mon enquête en examinant l’accès des utilisateurs expérimentés au répertoire \Program Files où j’ai trouvé des autorisations par défaut similaires à celles du répertoire \Windows. Les utilisateurs expérimentés peuvent créer des sous-répertoires sous \Program Files, mais ne peuvent pas modifier la plupart des composants Windows préinstallés. Encore une fois, les exceptions, comme Windows Messenger (\Program Files\Messenger\Msmgs.exe) et Windows Media Player (\Program Files\Windows Media Player\Wmplayer.exe) s’exécute de manière interactive.
Cela ne signifie pas que \Program Files n’a pas de trous potentiels. Lorsque j’ai examiné la sortie la plus récente, j’ai vu que les utilisateurs expérimentés peuvent modifier n’importe quel fichier ou répertoire créé dans \Program Files après ceux créés lors de l’installation de Windows de base. Sur mon système de test \ Program Files \ Vmware \ Vmware Tools \ Vmwareservice.exe, le fichier image du service Vmware Windows qui s’exécute dans le compte système local, était un tel fichier. Un autre exemple quelque peu ironique est Microsoft Windows Defender Beta 2, qui installe son exécutable de service dans \Program Files \ Windows Defender avec les paramètres de sécurité par défaut. Le remplacement de ces fichiers image de service est un chemin rapide vers le privilège administrateur et est encore plus facile que le remplacement de fichiers dans le répertoire \Windows car le PAM ne se mêle pas des remplacements.
Ensuite, j’ai porté mon attention sur le Registre en exécutant cette commande:
accesschk-swk “utilisateurs puissants” hklm
La liste de sortie était énorme car les utilisateurs puissants ont un accès en écriture à la grande majorité de la clé logicielle HKLM\. Le premier domaine que j’ai étudié pour les élévations possibles était la clé HKLM\System, car l’accès en écriture à de nombreux paramètres en dessous, tels que les clés de configuration du service Windows et du pilote dans HKLM\System\CurrentControlSet\Services, permettrait une subversion triviale du compte système local. L’analyse a révélé que les utilisateurs expérimentés n’ont pas accès en écriture à quelque chose de significatif sous cette clé.
La plupart des utilisateurs expérimentés – zones inscriptibles sous l’autre branche majeure de HKLM, les logiciels, liés à Internet Explorer, Explorer et ses associations de fichiers, et la configuration de la gestion de l’alimentation. Les utilisateurs expérimentés ont également un accès en écriture à HKLM\Software\Microsoft\Windows\CurrentVersion\Run, ce qui leur permet de configurer des exécutables arbitraires pour qu’ils s’exécutent chaque fois que quelqu’un se connecte de manière interactive, mais l’exploitation de cela nécessite qu’un utilisateur disposant d’un privilège d’administration se connecte au système de manière interactive (ce qui, selon le système, peut ne jamais se produire ou se produire rarement). Et tout comme pour le répertoire \Program Files, les utilisateurs expérimentés ont un accès en écriture par défaut aux sous-clés non windows de HKLM\Software, ce qui signifie que les applications tierces qui configurent des chemins de code exécutables dans leurs clés de registre à l’échelle du système pourraient ouvrir des failles de sécurité. VMware, la seule application installée sur le système, ne l’a pas fait.

La zone d’exploration restante était les services Windows. Les seules autorisations de service qu’AccessChk considère comme des accès en écriture sont SERVICE_CHANGE_CONFIG et WRITE_DAC. Un utilisateur avec SERVICE_CHANGE_CONFIG peut configurer un exécutable arbitraire à lancer au démarrage d’un service et, avec WRITE_DAC, il peut modifier les autorisations sur un service pour s’accorder l’accès SERVICE_CHANGE_CONFIG. AccessChk a révélé ce qui suit sur mon système Windows XP SP2 en stock:

J’ai ensuite exécuté PsService pour voir le compte dans lequel le service DcomLaunch s’exécute:

Ainsi, les membres du groupe Power Users peuvent simplement changer le chemin d’image de DComLauncher pour pointer sur leur propre image, redémarrer le système et bénéficier de privilèges d’administration.
Il peut y avoir potentiellement d’autres services qui introduisent des exploits dans leur sécurité. Les autorisations par défaut définies par Windows sur les services créés par des applications tierces n’autorisent pas l’accès en écriture des utilisateurs expérimentés, mais certaines applications tierces peuvent configurer des autorisations personnalisées pour leur permettre de le faire. En fait, sur ma production, AccessChk d’installation de Windows XP 64 bits révèle un trou que non seulement les utilisateurs expérimentés peuvent utiliser pour s’élever, mais que les utilisateurs limités peuvent également utiliser:

J’avais maintenant terminé la phase majeure de mon enquête et je viens de confirmer ce que tout le monde disait: un membre déterminé du groupe Power Users peut assez facilement se faire administrateur à part entière en utilisant des exploits dans le système d’exploitation et ceux créés par des applications tierces.
Ma dernière étape consistait à voir comment l’approche de Microsoft à l’égard du compte Power Users a évolué au fil du temps. Cet article de la Base de connaissances Microsoft de 1999 documente la fameuse vulnérabilité d’élévation de l’économiseur d’écran qui existait sur Windows NT 4, mais Microsoft a fermé ce trou avant la sortie de Windows 2000. L’article de KB montre également que Microsoft ignorait apparemment d’autres vulnérabilités qui existaient probablement. Windows 2000 SP4 comprend également des trous, mais est en fait légèrement plus sécurisé que la configuration par défaut de Windows XP SP2: Les utilisateurs expérimentés n’ont pas d’accès en écriture à Ntoskrnl.exe ou le fichier image du planificateur de tâches, mais au lieu d’accéder en écriture au service DComLauncher, ils peuvent subvertir le service WMI, qui s’exécute également dans le compte système local.
Windows XP SP1 a ajouté plus de faiblesses aux utilisateurs expérimentés, y compris l’accès en écriture à des fichiers système critiques tels que Svchost.exe, le processus d’hébergement des services Windows et des services supplémentaires, WMI et SSDPSRV, avec des autorisations exploitables. Plusieurs services ont même permis à des utilisateurs limités de s’élever comme décrit dans cet article de Microsoft KB de mars de cette année.
Le nouveau système d’exploitation de Microsoft, Windows Vista, ferme toutes les vulnérabilités que j’ai décrites en stérilisant les utilisateurs expérimentés afin qu’il se comporte de manière identique aux utilisateurs limités. Microsoft a ainsi fermé la porte aux utilisateurs expérimentés afin de forcer le personnel informatique à sécuriser leurs systèmes en déplaçant les utilisateurs vers des comptes d’utilisateurs limités ou vers des comptes administratifs où ils doivent reconnaître le contrôle de leurs systèmes par l’utilisateur final.
L’essentiel est que bien que Microsoft puisse corriger les vulnérabilités que j’ai trouvées dans mon enquête, elles ne peuvent pas empêcher les applications tierces d’en introduire de nouvelles tout en préservant la capacité des utilisateurs expérimentés à installer des applications et des contrôles ActiveX. La leçon est qu’en tant qu’administrateur informatique, vous ne devez pas vous tromper en pensant que le groupe Power Users est un compromis sûr sur la façon de fonctionner en tant qu’utilisateur limité.

Originellement par Mark Russinovich le 5/1/2006 11:01:00
Migré de l’original Sysinternals.com/Blog