Hier, Microsoft a livré 129 correctifs pour colmater des failles dans plusieurs de ses logiciels, depuis Windows et Office jusqu’à Visual Studio, Azure DevOps et Microsoft Apps for Android. Onze de ces failles sont qualifiées de « critiques » et doivent être corrigées immédiatement. Mais une vulnérabilité particulière pourrait être facilement négligée et permettre à des pirates ayant un accès local de prendre le contrôle total des systèmes Windows d’entreprise. La faille, référencée CVE-2020-1317, affecte l'un des mécanismes les plus fondamentaux de gestion centralisée des paramètres des machines Windows et des utilisateurs dans les environnements Active Directory : la Stratégie de groupe ou Group Policy. Plus important encore, la faille est ancienne et existe dans toutes les versions desktop de Windows et dans toutes les versions serveurs à partir de Windows Server 2008.

Microsoft estime que la faille est sérieuse. « La faille d’élévation de privilèges est exploitable quand la vérification de l’accès par la Stratégie de groupe est incorrecte. Si un attaquant parvient à exploiter cette vulnérabilité avec succès, il peut exécuter des processus dans un contexte élevé. Pour exploiter la vulnérabilité, l’attaquant doit d'abord se connecter au système, et exécuter ensuite une application spécialement conçue pour prendre le contrôle du système affecté ». L'avis de sécurité de Microsoft ne contient pas d'autres informations, mais, selon les chercheurs de CyberArk qui ont découvert la vulnérabilité, celle-ci est assez grave.

Exploitation de la vulnérabilité de Stratégie de groupe

Dans les systèmes Windows, les paramètres de la Stratégie de groupe ou Group Policy sont stockés sous forme de Group Policy Objects (GPO). Ces GPO peuvent être distribués par l'administrateur de domaine sur le réseau à partir du contrôleur de domaine. Cependant, les mises à jour de la Stratégie de groupe ne sont pas instantanées par défaut et prennent généralement du temps à se propager sur un réseau. C’est pour cette raison que Windows inclut un outil appelé GPUpdate.exe que les utilisateurs peuvent exécuter pour demander des mises à jour des GPO au contrôleur de domaine au lieu d’attendre. « Il est intéressant de noter qu’un utilisateur local sans privilèges peut demander manuellement une mise à jour de la Stratégie de groupe », ont déclaré les chercheurs en sécurité de CyberArk dans un article de blog. « Donc, si vous arrivez à trouver un bogue dans le processus de mise à jour de la Stratégie de groupe, vous pouvez le déclencher vous-même à votre gré, ce qui facilite une attaque potentielle ».

Les mises à jour de la Stratégie de groupe sont gérées par un service appelé GPSVC qui fonctionne sous le processus svchost.exe, lequel gère de nombreux services dans Windows. Comme prévu, ce service fonctionne avec les plus hauts privilèges possibles, dans le contexte du NT AUTHORITY\SYSTEM. Les mises à jour de la Stratégie de groupe peuvent être liées à une machine, un site, un domaine ou une unité organisationnelle et le service les enregistre dans un fichier appelé Applied-Object.xml, qui est ensuite renommé en fonction du type d'objet auquel la politique s'applique. Par exemple, une politique sur les imprimantes sera traduite en Printers\Printers.xml. Les chercheurs ont découvert que les mises à jour des Group Policy Objects (GPO) liées à une unité organisationnelle - ces mises à jour ciblent tous les utilisateurs et ordinateurs du domaine - sont enregistrées dans un emplacement de l'ordinateur sous le répertoire %localappdata%, accessible à tout utilisateur local.

De plus, en effectuant cette opération, le service ne transfère pas son contexte et ses privilèges à l'utilisateur local qui a demandé la mise à jour - transfert connu sous le nom d'usurpation d'identité en langage API Windows - mais il effectue l'opération d'écriture de fichier avec les privilèges du système local. Par conséquent, ce mécanisme prévoit une situation dans laquelle un utilisateur sans privilège peut utiliser GPUpdate.exe pour déclencher des opérations d'écriture de fichiers avec les privilèges LocalSystem dans un répertoire auquel il a accès.

La dernière étape de cette chaîne d'exploitation consiste, pour l'utilisateur, à créer un lien symbolique qui relie l'emplacement du fichier cible qui sera écrit - par exemple, Printers.xml - à un fichier système situé dans un répertoire Windows protégé comme C:\Windows\System32\ où se trouvent de nombreux fichiers exécutés par le noyau du système d'exploitation. Cela signifie que lorsque le GPSVC tente d'écrire le fichier Printers.xml à l'endroit accessible à l'utilisateur, il sera en réalité dirigé vers un fichier dans le répertoire C:\Windows\System32\, ce qu'il peut faire, car il fonctionne avec des privilèges système.

Voilà comment les chercheurs de CyberArk décrivent les différentes étapes :

- Listez les identificateurs globaux uniques (GUID) de la Stratégie de groupe présents dans C:\Users\user\AppData\Local\Microsoft\Group Policy\History\.

- Si vous avez plusieurs GUID, vérifiez quel répertoire a été mis à jour récemment.

- Allez dans ce répertoire et dans le sous-répertoire, qui est l’identificateur de sécurité SID de l'utilisateur.

- Regardez le dernier répertoire modifié. Celui-ci varie en fonction de l’environnement. Dans l’exemple choisi ici, il s’agissait du répertoire Printers.

- Supprimez le fichier Printers.xml dans le répertoire Printers.

- Créez un point de montage NTFS vers \RPC Control + un lien symbolique Object Manager avec Printers.xml pointant sur C:\Windows\System32\whatever.dll.

- Ouvrez votre terminal préféré et lancez gpupdate.

La raison pour laquelle la possibilité, pour des utilisateurs sans privilèges, d’écrire des fichiers dans des répertoires protégés du système d'exploitation est dangereuse, c’est qu'elle peut être utilisée pour une attaque dite de détournement de DLL. Le répertoire C:\Windows\System32\ est l'un des premiers endroits dans lequel de nombreuses applications, ou le système d'exploitation, effectuent des recherches quand ils veulent charger une DLL particulière. Si un utilisateur malveillant peut placer une DLL avec un nom spécifique et un code malveillant dans ce répertoire, elle sera exécutée par un service ou une application ayant des privilèges LocalSystem, attribuant à ce code le contrôle total sur l'ordinateur.

La valeur des failles par élévation de privilèges

En général, les vulnérabilités facilitant l’augmentation de privilèges ne sont pas considérées comme « critiques », car, pour les exploiter, les attaquants doivent déjà avoir un accès, même limité, à l'ordinateur local. Cependant, les attaquants ont plusieurs solutions pour accéder à un système : utiliser des courriels de phishing contenant des pièces jointes malveillantes, provoquer des téléchargements de type « drive-by download », exploiter des vulnérabilités dans n'importe quelle application. C'est pourquoi, en matière de sécurité, la pratique de base veut que les utilisateurs d'un système Windows aient des privilèges limités et que les applications qu'ils exécutent aient des privilèges limités, c'est-à-dire le moins de privilèges possibles pour pouvoir fonctionner.

Du fait des améliorations apportées à l'architecture de sécurité des systèmes d'exploitation modernes et des efforts des développeurs pour réduire leur surface d'attaque, il est assez rare de trouver une vulnérabilité exploitable à distance sans authentification sur un réseau ou sur Internet, qui donne un accès direct et complet au système. Aujourd’hui, la plupart des attaques utilisent des chaînes d'exploitation combinant plusieurs vulnérabilités, et les failles d'escalade de privilèges sont un élément important de ces chaînes, et souvent la dernière étape avant que l'attaquant ne prenne le contrôle de la totalité du système.

Malheureusement, les vulnérabilités d'escalade de privilèges sont encore courantes. Pour preuve, dans le cadre d'un projet de recherche mené sur une période d’un an par les chercheurs de CyberArk, ces derniers ont trouvé 60 failles de ce type dans les produits des principaux fournisseurs de logiciels. Sous Windows, des failles d'escalade de privilèges sont couramment découvertes dans le noyau et les pilotes tiers, mais également dans divers services système, comme c’est le cas ici. « Ces types de bogues sont très courants », a déclaré Eran Shimony, un chercheur de CyberArk Labs. « Pendant notre projet de recherche, nous avons trouvé beaucoup de vulnérabilités de nature similaire, ce qui signifie que les développeurs ne sont pas pleinement conscients de ces vulnérabilités, mais elles sont faciles à éviter, donc ce serait formidable s'ils y prêtaient attention ».

Pour remédier à la vulnérabilité Group Policy Objects (GPO), Microsoft a dû corriger la façon dont Group Policy contrôle l'accès, ce qui n'était probablement pas très simple, étant donné qu'il s'agit d'un mécanisme fondamental de gestion de Windows. CyberArk a signalé le problème à Microsoft pour la première fois en juin de l'année dernière. Il a donc fallu un an à l’éditeur pour mettre au point la mise à jour livrée hier. Microsoft a dû également développer des correctifs pour tous les systèmes d'exploitation concernés désormais hors support, mais pour lesquels les clients peuvent encore disposer de contrats d’abonnements étendus pour certains produits qui leur donnent droit à des mises à jour de sécurité. C’est le cas notamment de Windows Server 2008, de Windows Server 2012 et de Windows 7.