alfarom256/cve-2022-45451PoC for Acronis Arbitrary File Read - CVE-2022-45451
Le pilote anti-malware "ngscan" d'Acronis souffre d'un contrôle d'accès incorrect / inapproprié sur le port de communication du filtre. Le pilote minifilter prend en charge les fonctionnalités suivantes qui peuvent être exploitées :
L'analyse du pilote ngscan.sys a commencé par le décompiler avec Ida Pro. Le chercheur a noté que, bien qu'un objet périphérique ait été créé, aucun lien symbolique n'a été créé pour interagir avec le pilote via DeviceIoControl.
Par conséquent, l'analyse s'est poursuivie en observant les capacités du Filter Communication Port.
Lors de l'initialisation, le pilote crée cinq (5) ports de communication pour prendre en charge l'interaction depuis d'autres processus.
Fig. 1 : Routine prenant en charge la création de jusqu'à cinq (5) ports de communication de filtre (FCP)
Cette fonction a été observée en cours d'appel, initialisant chacun des 5 FCP avec un dacl par défaut, le dernier FCP étant créé avec un dacl NULL.
Fig. 2 : Création de FCP avec DACL par défaut/NULL
L'analyse s'est poursuivie en observant les fonctions CreateNotifyCallback et MessageNotifyCallback spécifiées par le pilote de filtre. Ces fonctions de rappel sont invoquées chaque fois qu'un processus ouvre une connexion et envoie un message au port de communication.
L'inspection initiale de MessageNotifyCallback a montré que le tampon du message entrant doit satisfaire aux exigences suivantes :
Une fois les vérifications effectuées, un numéro de fonction est extrait du InputBuffer et utilisé dans les cas switch suivants pour sélectionner la fonction à exécuter avec l'entrée fournie.
Fig. 3 : Sous-ensemble de fonctions prises en charge par MessageNotifyCallback
L'inspection de chacune des fonctions prises en charge a révélé deux fonctions d'intérêt pour une éventuelle utilisation abusive menant à une lecture arbitraire de fichiers.
Fig. 4 : Fonctions prenant en charge la création d'un contexte de scan et le retour du handle de fichier du contexte de scan (Lignes 206, 233)
Bien que la fonctionnalité exacte d'un "contexte de scan" ne soit pas entièrement connue, l'analyse a montré qu'un contexte de scan de fichier peut être créé pour tout fichier donné spécifié dans le InputBuffer de l'utilisateur. Une fois un contexte de scan créé, l'ID du contexte de scan est renvoyé à l'utilisateur dans le tampon de sortie.
Fig. 5 : Routine de création de contexte de scan renvoyant les données du contexte de scan à l'utilisateur
Fig. 6 : Données envoyées au pilote minifilter demandant l'accès au fichier de registre SAM protégé (\??\C:\Windows\System32\config\SAM)
Fig. 7 : Réponse du pilote minifilter incluant l'ID du contexte de scan (0x3aaf)
Une fois qu'un contexte de scan a été créé et que l'ID a été récupéré, un handle vers le fichier pour lequel le contexte de scan a été créé peut être ouvert dans l'application demandeuse en envoyant à nouveau un message au port de communication.
Fig. 8 : Récupération du handle de fichier du contexte de scan créé
La fonction désignée sous le nom CreateFileReturnHandle0 n'était appelée que si la fonction précédente SearchScanContextsByID renvoyait un contexte de scan valide.
Par exemple, uniquement si le processus demandeur fournissait un ID de contexte valide précédemment créé en appelant la fonction de création de scan susmentionnée.
Le programme demandeur a ouvert avec succès un handle vers le fichier privilégié en fournissant l'ID du contexte de scan à la fonction spécifiée dans la Figure 8 (Figure 4, Ligne 233).
Fig. 9 : Récupération réussie du handle de fichier pour le fichier SAM
À l'aide de processhacker, l'accès au handle de fichier a été confirmé en visualisant les handles du processus demandeur :
Fig. 10 : Processus contenant un handle vers le fichier SAM
Fig. 11 : Accès en lecture accordé au handle obtenu
Une exploration plus approfondie des fonctions prises en charge a montré le contrôle de trois clés de registre qui pourraient être exploitées pour obtenir une exécution de code.
Fig. 12 : Fonctions prenant en charge l'ouverture de handles vers des clés de registre
Fig. 13 : Ouverture des clés de registre spécifiant la dll du moniteur de hook à injecter dans un processus
Fig. 14 : Fonction OpenKey démontrant la capacité de modifier une clé de registre avec des données contrôlées par l'utilisateur
Les circonstances de l'injection de dll pour le hooking par la suite Acronis n'ont pas été déterminées, bien que si la surveillance des hooks est activée, on pense que la dll spécifiée par les clés de registre x64HookLib et x86HookLib serait injectée dans un processus désigné.
Fig. 15 : x64HookLibKey spécifiant la dll de hooking C:\ProgramData\Acronis\NGMP\shared\acr_protect.x64.dll
Le processus d'ouverture d'un contexte de scan a été omis dans l'analyse pour la lecture arbitraire de fichiers.
Un processus peut, au lieu de créer un contexte de scan, forcer les ID de contexte de scan par force brute en émettant des requêtes répétées à la fonction GetScanContextByID, en bouclant sur les valeurs ContextID jusqu'à ce qu'un ou plusieurs contextes de scan valides soient trouvés.
