CVE-2020-0753-and-CVE-2020-0754

Writeup et POC pour CVE-2020-0753, CVE-2020-0754 et six vulnérabilités DOS corrigées de Windows

Exploitation du bug de condition de concurrence dans le système de fichiers - analyse de CVE-2020-0753 et CVE-2020-0754

Le service Windows Error Reporting a corrigé 2 bugs d'élévation de privilèges lors du dernier Patch Tuesday, ces deux bugs sont assignés aux CVE-2020-0753 et CVE-2020-0754. Les deux bugs exploitent un bug de condition de concurrence dans les opérations du système de fichiers du service. Cependant, ces deux bugs ne sont pas si faciles à exploiter en raison de petites fenêtres de concurrence et d'emplacements de dépôt de fichiers incertains. Nous partageons ici nos techniques pour les exploiter.

La cause racine des deux bugs de concurrence est donnée dans nos rapports, la cause réelle peut être exprimée comme Prédictible est Vulnérable. Lorsque le service WER traite des fichiers temporaires, il manipule l'emplacement de fichier C:\ProgramData\Microsoft\Windows\WER\Temp, qui est un répertoire en lecture/écriture pour les utilisateurs authentifiés. Cela signifie qu'un utilisateur normal de niveau moyen (medium-IL) peut écraser un fichier créé par le service WER, et même le transformer en lien du système de fichiers pour endommager/supprimer d'autres fichiers qu'il n'aurait pas pu toucher.

Pour sécuriser les opérations sur les fichiers, le service WER s'appuie sur une API standard nommée GetTempFileNameW et l'enveloppe avec wersvc.dll->UtilGetTempFile, cette API aide WerSvc à générer un nom de fichier aléatoire inoccupé sous la forme "WER****.tmp",

la partie aléatoire du nom de fichier est générée avec un nombre hexadécimal de 4 octets, de 0000 à FFFF, si un nombre a déjà été utilisé pour créer un fichier, l'API prendra un autre nom de fichier aléatoire.

La stratégie présente clairement une faille si l'on crée 65535 fichiers nommés de WER0000.tmp à

WERFFFE.tmp, l'API choisira un nombre aléatoire et testera si le nom de fichier existe, par exemple WERA560.tmp, elle constatera que le fichier existe déjà, donc elle continuera à tester de WERA560.tmp jusqu'à WERFFFF.tmp, pendant que le test se poursuit, une fenêtre de préparation apparaît car nous avons trouvé un moyen de faire bloquer WerSvc sur l'appel GetTempFileNameW pendant 4 à 5 secondes, ce qui constitue un écart de timing assez important. Pendant ce temps, nous forçons le service à déposer un fichier temporaire avec un nom de fichier fixe, à savoir

WERFFFF.tmp.

Après que le service a créé le fichier temporaire nommé WERFFFF.tmp, l'API ferme automatiquement

le handle qu'elle détient sur le fichier, et renvoie le nom du fichier au service pour des opérations ultérieures sur le fichier, c'est exactement à ce moment que le bug est introduit. Trois conditions sont réunies :

1. Le fichier créé par le service se trouve dans une position contrôlable par un utilisateur normal.

2. Le service ferme tous les handles sur le fichier

3. Le service utilisera le fichier plus tard (écriture ou suppression)

Ici, le service va écrire du contenu dans le fichier et le supprimer. L'écriture et la suppression peuvent toutes deux entraîner une élévation de privilèges en exploitant les liens du système de fichiers et certaines techniques d'exploitation.

Afin de transformer le bug en suppression arbitraire de fichiers, nous exploitons de manière créative plusieurs jonctions de répertoires pour finaliser l'exploitation. Notre exploit comprend les étapes suivantes :

• nous plaçons tous les WER***.tmp dans $pwd\1\, et créons une jonction $pwd\2\ -> $pwd\1\;
• nous créons un processus pour déclencher continuellement cette fonction avec le chemin $pwd\2\. et nous créons un autre processus pour exécuter en continu la commande SetOplock $pwd\1\WERFFFF.tmp;
• Une fois l'Oplock déclenché, nous créons une jonction $pwd\2\ -> \RPC CONTROL\, puis nous créons un lien symbolique d'objet \RPC CONTROL\WERFFFF.tmp -> $target et \RPC CONTROL\WERFFFF.tmp.etl -> $target
• Libérez l'oplocks , le fichier cible sera supprimé avec les privilèges système.

L'exploitation détaillée et le POC sont fournis dans WERReport-CVE-2020-0753.

En exploitant la faille dans GetTempFileNameW, nous obtenons un emplacement prévisible où le service opérera ; en utilisant des jonctions de système de fichiers à plusieurs niveaux, nous rendons la condition de concurrence exploitable de manière fiable.

En attendant, nous avons remarqué que ce type de bug de concurrence peut également entraîner un possible problème d'écrasement de fichier, ce qui pourrait conduire à des bugs d'élévation de privilèges dans certaines circonstances.

De la corruption arbitraire de fichier avec contrôle partiel à l'élévation de privilèges

Pour expliquer pourquoi une corruption arbitraire de fichier (si vous pouvez contrôler une très petite partie du contenu du fichier : moins de 63 octets) peut être transformée en EoP, nous devons prêter attention au mécanisme de fonctionnement de Windows Defender.

Windows Defender dispose d'une base de données de signatures de malwares. Si un fichier contient une signature de malware, Defender considère qu'il s'agit d'un malware et le supprime. Cependant, cette fonctionnalité entraîne une surface d'attaque supplémentaire. Par exemple, lors du WCTF2019, @icchy de tokyowesterns a conçu un défi Windows CTF nommé "Gyotaku The Flag", qui utilise cette fonctionnalité comme oracle pour fuiter des informations.

Ici, nous exploitons cette fonctionnalité de Windows Defender pour supprimer un fichier arbitraire si nous avons une corruption arbitraire de fichier avec un contrôle partiel du contenu. Nous pouvons simplement écrire une signature de malware dans un fichier et déclencher une analyse par défaut de Windows Defender, le fichier sera mis en quarantaine par Defender, qui peut être supprimé par un utilisateur normal (c'est-à-dire un utilisateur non administrateur de niveau moyen) simplement en déclenchant l'analyse deux fois.

Ainsi, un bug de corruption arbitraire de fichier peut être transformé en suppression arbitraire de fichier tant qu'une chaîne de signature de malware peut être placée dans le fichier cible en utilisant le bug.

• Étape 1 :

Corrompre le fichier cible avec un bug, y placer une chaîne caractéristique reconnaissable par Windows Defender.

• Étape 2 :

Déclencher une analyse de Windows Defender sur le fichier cible, ce qui entraîne la mise en quarantaine du fichier.

• Étape 3 :

Déclencher à nouveau l'analyse, le fichier cible est supprimé.

En exploitant cette technique, nous obtenons une suppression arbitraire de fichier avec l'aide de Defender.

La suppression arbitraire de fichier peut être exploitée bien plus facilement pour obtenir des privilèges supplémentaires.

Six vulnérabilités DOS du système de fichiers corrigées dans Microsoft OneDrive

Microsoft OneDrive est l'ensemble d'applications fournissant un service de stockage cloud personnel,

cette application a été intégrée à Windows comme option d'installation par défaut depuis Windows 8. Au cours de nos recherches, 6 vulnérabilités dans les tâches planifiées de maintenance de OneDrive ont été trouvées et soumises à MSRC.

---

Voici un tableau des vulnérabilités que nous allons exposer dans les tâches planifiées pertinentes de Microsoft OneDrive :

Les 6 bugs sont tous causés par le fait que le service gère incorrectement les hardlinks et les symlinks, tout en opérant sur des emplacements qu'un utilisateur normal peut contrôler. Lors de l'exploitation de ces bugs, une difficulté vient du fait que le nom de fichier contient généralement le pid du processus en cours ou un horodatage marquant le moment où le fichier est opéré. Les deux peuvent être résolus en plaçant un oplock sur un fichier dll unique que le service tentera de charger lorsqu'il est déclenché, ce qui nous permet d'obtenir tout ce dont nous avons besoin pour prédire le nom de fichier que le service tentera d'opérer plus tard. Un exemple de POC est fourni dans le répertoire FileSyncConfigTemp_hardlink.

Impacts des vulnérabilités

Les 6 vulnérabilités mentionnées ci-dessus sont fournies avec un rapport complet et un programme POC, bien que la plupart des bugs provoquent principalement une corruption arbitraire de fichier, ce type de bug peut toujours entraîner un crash du système (en écrasant un fichier de configuration critique du système), et tous nécessiteraient une réinstallation de Windows. Cela répond donc au standard du type de bug de déni de service du système Windows.

De plus, ce type de bug peut en fait provoquer une élévation de privilèges dans certains contextes. Nous avons discuté de la technique d'exploitation qui peut tirer parti d'un problème d'écrasement arbitraire de fichier pour obtenir une primitive de suppression arbitraire de fichier, ainsi une élévation de privilèges est réalisable.

Crédits des vulnérabilités

Fangming Gu

Zhiniang Peng de Qihoo 360 Core Security

Chronologie

02 févr. 2020 : Vulnérabilités signalées

08 févr. 2020 : MSRC a enquêté et répondu à propos des 6 bugs dans OneDrive que nous avons soumis, leur conclusion est de ne pas corriger car Trop d'interaction utilisateur requise / trop difficile de construire un exploit fiable.

08 févr. 2020 : Nous avons répondu : Il n'y a pas besoin d'interaction utilisateur. Il suffit d'attendre que la tâche planifiée s'exécute. Ce scénario est donc typique.

11 févr. 2020 : MSRC a répondu : Comment obtenez-vous le fichier spécifique sur la machine de l'utilisateur ? Et placez-vous chaque permutation de ce fichier dans ce dossier ? Doit-il correspondre exactement à la Date/Heure/PID. C'est pour ces raisons que cela semble nécessiter trop d'effort de l'utilisateur.

11 févr. 2020 : Nous avons répondu : Notre POC est une version simplifiée. Pour réduire l'effort de prédiction du nom de fichier. En réalité, il suffit de mettre un oplock. Ensuite, vous pouvez obtenir tout le {pid},{hour},{data}. Donc, pas besoin d'interaction utilisateur.

12 févr. 2020 : Demande si nous pouvons publier le writeup pour ces 6 vulnérabilités.

13 févr. 2020 : MSRC a répondu : Vous pouvez publier un writeup.

22 févr. 2020 : Détails publiés

Mise à jour du statut : Les 6 vulnérabilités ont reçu un correctif lors du Patch Tuesday de mars 2020.