Sur un habr déjà il y a des
nouvelles de cette vulnérabilité , mais, malheureusement, sans détails techniques. Je vous suggère de regarder à l'intérieur des
archives publiées (auteur -
SandboxEscaper ).
Sous le cutter se trouve la traduction du document de description dans l'archive.
Description de la vulnérabilité
Le service Planificateur de tâches possède une interface RPC (accessible via le transport ALPC) qui prend en charge la méthode SchRpcSetSecurity.
Voici le prototype de cette méthode:
long _SchRpcSetSecurity( [in][string] wchar_t* arg_1,
Les tâches créées par le planificateur de tâches créent le répertoire / fichier correspondant dans c: \ windows \ system32 \ tasks. Probablement, cette méthode est destinée à enregistrer les tâches DACL'a qui s'y trouvent. Mais l'enregistrement aura lieu après l'emprunt d'identité. Cependant, pour une raison quelconque, l'implémentation de la méthode vérifie également la présence d'un fichier .job dans c: \ windows \ tasks et y écrit une DACL
sans usurpation d'identité . Étant donné que l'utilisateur (même l'utilisateur du groupe invité) peut créer des fichiers dans ce répertoire, nous pouvons simplement créer un lien physique vers tout autre fichier que nous pouvons lire. En utilisant un tel lien, nous pouvons forcer le service du planificateur (exécutant avec les privilèges SYSTEM) à écrire un DACL arbitraire (voir le deuxième paramètre SchRpcSetSecurity) dans un fichier de notre choix.
Ainsi: pour tout fichier lisible, vous pouvez modifier la DACL, ce qui vous permet de l'écraser complètement.
Exploitation de la vulnérabilité
Cette vulnérabilité nous donne une primitive vraiment forte! Le problème principal est qu'après l'installation (par défaut), de nombreux fichiers importants ne peuvent être modifiés que par l'utilisateur TrustedInstaller (mais pas par l'utilisateur SYSTEM).
L'archive contient un script PowerShell pour répertorier les fichiers que vous pouvez contrôler. Exécutez simplement:
./enumerate.ps1 >output.txtLe système a de nombreux objectifs. Vous pouvez contrôler les fichiers programme et si votre fichier cible est utilisé par un administrateur / autre utilisateur, les fichiers que vous avez remplacés peuvent être lancés avec les privilèges requis.
Le deuxième problème est que même si nous pouvons prendre le contrôle de nombreux fichiers, leur écriture est souvent impossible, car ces DLL sont déjà chargées quelque part pour l'exécution. Tenter d'écrire un DACL pour un fichier téléchargé pour exécution entraînera une erreur d'accès partagé. Mais la vulnérabilité peut être utilisée pour d'autres types de fichiers, qui peuvent être une meilleure cible qu'une DLL.
Pour le fonctionnement, le fichier C: \ Windows \ System32 \ DriverStore \ FileRepository \ prnms003.inf_amd64_4592475aca2acf83 \ Amd64 \ printconfig.dll a été sélectionné (le nom du répertoire peut varier, cela est pris en compte dans PoC). Il semble que ce fichier appartient à l'imprimante XPS et n'est pas chargé par défaut dans le service d'impression (il peut arriver que le fichier soit déjà chargé ... mais le plus souvent il ne l'est pas).
Et lorsque nous démarrons le travail d'impression à l'aide de l'imprimante XPS, le service charge cette DLL, que nous pouvons réécrire au préalable. Un tel vecteur d'attaque (détournement) peut être facilement appliqué pour quelque chose de mieux. Je peux essayer de trouver les meilleures options ... faites le moi savoir.
Remarque : Sur un ancien ordinateur portable, où Windows 10 fonctionne depuis plusieurs années, il existe deux répertoires prnms003.inf_amd64_ *. La nouvelle version ne supprime pas l'ancienne, ce qui signifie qu'il n'y a aucune garantie que FindFirstFile (utilisé dans PoC) trouvera le répertoire actuel. Par conséquent, vous pouvez développer le code en écrasant tous les printconfig.dll trouvés ou vérifier l'attribut du dernier enregistrement du fichier et en sélectionner un plus récent.
Démo
Vous pouvez également trouver une vidéo avec une démonstration dans les archives: