Détournement d'une infrastructure classique de ses fonctions initiales – Les dangers de Windows UI Automation
Commentaires éditoriaux et additionnels de Tricia Howard
Synthèse
Tomer Peled, chercheur en sécurité chez Akamai, a exploré de nouvelles façons d'utiliser à bon et à mauvais escient l'infrastructure UI Automation de Microsoft. Il a ainsi mis à jour une technique d'attaque qui échappe aux solutions de détection et de réponse aux points de terminaison (EDR).
Pour exploiter cette technique, il faut convaincre un utilisateur d'exécuter un programme qui utilise UI Automation. Cela peut conduire à une exécution de commande furtive susceptible de collecter des données sensibles, de rediriger les navigateurs vers des sites Web d'hameçonnage, ou autres.
La détection de cette technique est difficile à plusieurs égards, y compris pour l'EDR. Aucune des technologies EDR que nous avons testées contre cette technique n'a réussi à détecter une activité malveillante.
Cette technique peut être utilisée sur tous les points de terminaison Windows dotés d'un système d'exploitation XP ou ultérieur.
Dans ce billet de blog, nous expliquons en détail comment utiliser (à mauvais escient) l'infrastructure UI Automation (y compris les attaques possibles qui pourraient l'exploiter), et présentons une démonstration de faisabilité pour chaque vecteur d'abus évoqué. Nous proposons également des options de détection et d'atténuation.
Introduction
Ceux d'entre nous qui gagnent leur vie par l'écriture adorent les logiciels de dictée et de correction grammaticale. Ceux d'entre nous qui font de la recherche sur la sécurité pour gagner leur vie aiment démanteler des systèmes et écrire à ce sujet. Ainsi, après avoir vu pendant des mois des publicités pour ces assistants d'écriture, nous avons décidé de nous pencher sur la question et de voir ce que nous pouvions trouver.
Plus précisément, nous voulions comprendre comment une application permettait de manipuler à distance l'interface utilisateur d'une autre application. Ce que nous avons découvert était aussi choquant que d'apprendre que certaines personnes utilisent encore XP : le traitement est effectué par une infrastructure très ancienne dénommée UI Automation.
Cette infrastructure a été conçue à l'époque de Windows XP comme un moyen de faciliter l'utilisation de l'ordinateur par des personnes handicapées. Elle dispose d'autorisations élevées pour faciliter des tâches telles que l'agrandissement du texte, la lecture à haute voix et même la simulation de clics (dans certaines situations). Pour ce faire, UI Automation requiert l'autorisation de manipuler presque tous les éléments de l'interface utilisateur présents à l'écran, ce qui est logique compte tenu de l'objectif visé : la technologie fera uniquement ce qu'on lui dit qu'elle peut ou ne peut pas faire.
C'est à partir de là que nous avons entamé nos recherches pour déterminer l'impact possible d'attaquants qui utiliseraient UI Automation à mauvais escient.
Nous avons découvert que les attaquants peuvent se servir d'UI Automation pour exfiltrer des données, manipuler la navigation Internet, exécuter des commandes et même lire et écrire des messages à partir d'applications de chat telles que WhatsApp ou Slack. Et aucun des fournisseurs d'EDR que nous avons testé n'a détecté ces activités..
Cet article de blog vous indiquera tout ce que vous devez savoir sur cette infrastructure, de son fonctionnement à la manière dont ses fonctionnalités peuvent être utilisées à des fins malveillantes. Nous terminerons par des options de détection et d'atténuation destinées à l'équipe de défense.
Interaction avec UI Automation via COM
Pour interagir avec les éléments d'autres applications, l'infrastructure UI Automation (UIA) s'appuie sur le Component Object Model (COM) comme mécanisme de communication interprocessus (IPC).
COM est une infrastructure conçue par Microsoft pour permettre à différents programmes de communiquer entre eux, quel que soit le langage dans lequel ils ont été écrits ou compilés. L'infrastructure COM permet aux développeurs de créer des composants appelés objets COM. Ces objets sont enregistrés sur un point de terminaison Windows avec leur nom, un identifiant universel unique (UUID) et un binaire qui contient leur logique et d'autres valeurs configurables.
Pour interagir avec UIA, les utilisateurs créent son objet COM en appelant la fonction « CoCreateInstance » avec l'UUID de la classe CUIAutomation et l'UUID de l'interface UIAutomation, comme indiqué dans le tableau.
UUID CUIAutomation |
ff48dba4-60ef-4201-aa87-54103eef594e |
UUID de l'interface UIAutomation |
30cbe57d-d9d0-452a-ab13-7ac5ac4825ee |
Lors de la création de l'objet COM, le système charge la DLL spécifiée dans le registre, qui dans ce cas est « UIAutomationCore.dll ».
Cela vous rappelle-t-il quelque chose ? Le lecteur attentif aura peut-être remarqué que tout cela ressemble à notre examen approfondi de MS-RPC. COM utilise RPC comme base, d'où les similitudes.
UI Automation — Hello World
Avant d'examiner la façon dont les attaquants pourraient utiliser cette infrastructure à mauvais escient, il peut être utile de revoir la manière d'interagir avec UIA en général (avec C++). Cela vous donnera le contexte nécessaire pour comprendre où les choses ont mal tourné dans son implémentation. Pour revoir comment interagir avec UIA, consultez notre GitHub.
Une fois l'objet UIA créé, sa DLL est chargée dans l'application de l'utilisateur, ainsi que dans tous les autres processus qui possèdent des éléments d'interface utilisateur.
Rien d'autre ne se produira jusqu'à ce que nous ajoutions des gestionnaires d'événements pour les changements d'interface utilisateur de processus distants. L'exemple ci-dessous indique comment mettre en place un gestionnaire pour toute modification de l'infobulle qui est actuellement ouverte pour un utilisateur.
ppAutomation->AddAutomationEventHandler(UIA_ToolTipOpenedEventId, pTargetElement, TreeScope_Subtree, NULL, (IUIAutomationEventHandler*)whatsappEventHandler);
Une fois cette étape franchie, UIA ouvre un « serveur » sur le processus distant qui communique avec notre application (Figure 1). Les données transférées entre les deux sont des informations sur tous les éléments de l'interface utilisateur du processus distant.
Figure 1 : Chargement de la dll UIA dans tous les processus comportant des éléments d'interface utilisateur
Selon la documentation de Microsoft, le prototype de gestionnaire suivant est le gestionnaire standard attendu par UIA :
HRESULT HandleAutomationEvent(
[in] IUIAutomationElement *sender,
[in] EVENTID eventId
);
Nous pouvons identifier l'application exacte qui a été placée au premier plan de l'interface utilisateur (en l'ouvrant ou par tout autre moyen) en invoquant la fonction « sender.get_CurrentName » depuis l'intérieur du gestionnaire. Maintenant que nous savons quelle application est au premier plan, nous pouvons tenter d'y lire/écrire.
Pour ce faire, nous devons trouver un élément à partir duquel nous voulons lire/écrire en parcourant tous les éléments (qui sont des descendants de l'élément sender ) et soit en lisant leur valeur d'interface utilisateur et en modifiant leur valeur de texte, soit en récupérant leur élément invocable et en appelant sa fonction « Invoke » (Figure 2).
Figure 2 : Processus de recherche et de manipulation d'un élément de haut niveau
Utilisation abusive d'UI Automation à des fins malveillantes
Dans la section précédente, nous avons expliqué comment utiliser UIA à mauvais escient ; nous allons maintenant parler des activités malveillantes rendues possibles par cette utilisation abusive. La meilleure façon de présenter ces activités est de les illustrer par des exemples, et nous en avons trois :
- Lecture et écriture de messages
- Vol de données sensibles
- Exécution de commandes
Lecture et écriture de messages
Chaque application de messagerie dispose d'une interface utilisateur graphique (GUI) qui contient différents types d'éléments d'interface utilisateur auxquels nous pouvons accéder à l'aide d'UIA. La Figure 3 est un exemple de l'interface utilisateur graphique de Slack, qui vous semble probablement familière.
Figure 3 : Aspect habituel de Slack
Les actions disponibles dans une interface graphique vont de la sélection de conversations (qui sont mises en œuvre sous forme de boutons en coulisses) à la lecture de messages (blocs de texte), de sorte que nous disposons d'une pléthore d'éléments avec lesquels nous pouvons interagir.
Une fois qu'un attaquant est en mesure de se « connecter » à la fenêtre de l'interface utilisateur d'une telle application, il peut simuler un clic sur la conversation qu'il souhaite (par le biais de l'élément de bouton de l'interface utilisateur) et y entrer. À partir de là, il peut choisir de lire la conversation et d'exfiltrer les données et/ou de trouver l'élément de l'interface utilisateur responsable de la rédaction d'un message, de modifier la valeur du texte dans son élément TextArea et de simuler un clic sur le bouton d'envoi.
Bien entendu, ce type de manipulation se reflète également à l'écran, ce qui laisse beaucoup de place au hasard du côté de l'attaquant. Une approche plus discrète consiste à lire uniquement la conversation en cours et à collecter des données sur une période plus longue (Figure 4).
Figure 4 : Lecture de messages depuis Slack
Une autre option pour maintenir la furtivité sans adopter une approche passive consiste à utiliser le mécanisme de mise en cache d'UIA. Outre les éléments de l'interface utilisateur actuellement affichés à l'écran et avec lesquels nous pouvons interagir, d'autres éléments sont chargés à l'avance et placés dans un cache. Nous pouvons également interagir avec ces éléments, par exemple en lisant des messages qui ne sont pas affichés à l'écran, ou même en définissant la zone de texte et en envoyant des messages sans que cela ne se reflète à l'écran.
Bien que nous n'ayons pas pu le vérifier avant la mise en ligne de cet article de blog, le mécanisme de mise en cache pourrait également nous permettre d'interagir avec ces éléments lorsque l'ordinateur est verrouillé,ce qui nous permet de nous livrer à des interactions incontrôlées sans que l'utilisateur ne s'en aperçoive.
Vol de données sensibles
L'une des façons les plus préjudiciables d'utiliser (abusivement) UIA est de dérober des informations de cartes de crédit.
Lorsqu'un utilisateur accède à un site marchand en ligne, un attaquant peut enregistrer par programme les modifications apportées aux éléments de l'interface utilisateur en mettant en œuvre un gestionnaire. Lorsqu'une modification a été effectuée (c'est-à-dire lorsque des informations de carte de crédit ont été saisies), l'attaquant peut récupérer le texte des éléments de l'interface utilisateur en vue d'une exfiltration ultérieure (Figure 5).
Figure 5 : Collecte d'informations de carte de crédit à partir du navigateur
Exécution de commandes
L'hameçonnage et les redirections de navigateur constituent un autre vecteur d'attaque courant sur les navigateurs.
En filtrant les fenêtres de l'interface utilisateur firefox/chrome/edge, les attaquants peuvent simplement rechercher l'élément de l'interface utilisateur de leur barre de recherche et lui attribuer la valeur qu'ils souhaitent pour simuler un clic (Figure 6). Pour rendre leur action encore plus furtive, ils peuvent attendre le rafraîchissement ou la modification de la page Web actuellement affichée, de sorte que le passage à un autre site Web soit moins visible.
Cela permet aux attaquants de rediriger les utilisateurs vers des sites malveillants qu'ils contrôlent. À partir de là, les possibilités sont effectivement infinies : exploitation du navigateur (par exemple, utilisation de Browser Exploitation Framework [BeEF]), attaques de type « drive-by », usurpation d'un site légitime à des fins d'hameçonnage ou de collecte d'informations d'identification, etc.
![Cela permet aux attaquants de rediriger les utilisateurs vers des sites malveillants qu'ils contrôlent. À partir de là, les possibilités sont effectivement infinies : exploitation du navigateur (par exemple, à l'aide de Browser Exploitation Framework [BeEF]), attaques de type « drive-by », usurpation d'un site légitime à des fins d'hameçonnage ou de collecte d'informations d'identification, etc.](/site/fr/images/blog/2024/2024-december-windows-ui-automation-attack-technique-evades-edr-six.gif)
Figure 6 : Redirection d'un utilisateur vers BeEF
Impact potentiel d'UI Automation
Les attaques évoquées dans les sections précédentes existent depuis des décennies avec des implémentations différentes, et la plupart des outils de défense savent comment les détecter et y répondre.
Cependant, tout ce dont nous avons parlé ci-dessus est considéré comme une fonctionnalité d'UI Automation. Cela nous ramène à l'objectif visé par l'application : ces niveaux d'autorisation doivent exister pour pouvoir être utilisés. C'est pourquoi UIA est capable de contourner Defender : l'application ne trouve rien d'anormal. En fait, aucun EDR testé n'a été en mesure de détecter ces actions comme malveillantes, probablement pour la même raison. Si un élément est considéré comme une fonctionnalité plutôt que comme un bug, la logique de la machine suivra la fonctionnalité.
Cette infrastructure est donc potentiellement très lucrative pour les attaquants, et c'est pourquoi nous pensons qu'une sensibilisation accrue est essentielle pour traiter ce vecteur d'attaque.
Recherches supplémentaires
UIA sur DCOM
Distributed COM (DCOM) est un moyen d'appeler des objets COM à distance entre machines. Théoriquement, il devrait être possible d'accéder à distance à l'UIA via DCOM, ce qui permettrait d'exécuter toutes les attaques que nous avons évoquées sans avoir à recourir à l'hameçonnage ou à l'accès local.
Dans le cadre de notre analyse, nous avons réalisé que l'objet COM d'UIA n'est pas configuré pour autoriser DCOM par défaut. Cela réduit considérablement le potentiel d'attaque sauf en cas de mauvaise configuration.
Bien qu'UIA ne soit pas disponible via DCOM, nous avons trouvé un élément connexe : l'objet COM/DCOMUIAutomationCrossBitnessHook . L'activation et l'exécution à distance de cet objet ne requièrent pas de privilège.
En inversant sa DLL, nous avons découvert que son interface contient deux fonctions : l'une pour définir le gestionnaire d'interface utilisateur et l'autre pour le désactiver. Il semble qu'il ne comporte aucune autre fonctionnalité à distance, nous n'avons donc pas pu l'utiliser pour lire ou écrire des données, mais il pourrait constituer une cible de recherche intéressante à l'avenir.
Canaux nommés UIA
Précédemment dans cet article, nous avons mentionné qu'UIA ouvre un « serveur » sur un processus distant. En arrière-plan, ces serveurs et clients sont implémentés à l'aide de canaux nommés. La convention de nommage comprend la chaîne constante UIA_PIPE suivie de l'ID du processus et d'un autre identifiant (Figure 7).
Figure 7 : Canaux nommés de l'interface utilisateur dans l'application de l'attaquant
C'est là que les choses prennent une tournure inquiétante : les canaux nommés peuvent accepter des connexions à distance. Le danger est important, car cela signifie qu'un attaquant pourrait être en mesure de manipuler des éléments de l'interface utilisateur sur le réseau. Cependant, lorsque nous avons essayé de nous connecter à partir d'un serveur distant, nous avons rencontré le message d'erreur ACCESS_DENIED .
Cela s'explique par le fait que Microsoft a défini l'indicateur PIPE_REJECT_REMOTE_CLIENTS lors de la création du canal nommé. De ce fait, nous ne pouvons pas accéder à l'UIA à distance via ces canaux, qui restent cependant disponibles localement. Il est possible d'énumérer ces canaux (sans deviner l'ID ou l'identifiant du processus) et d'y accéder, ce qui pourrait ouvrir la voie à une sorte d'attaque par élévation de privilèges ou par usurpation d'identité, même si cette option n'a pas fait étudiée dans cette analyse.
Détection/atténuation
Microsoft a reconnu que cette infrastructure ne devrait pas interagir avec des applications à privilèges plus élevés. Par conséquent, et par défaut, les applications qui utilisent l'infrastructure UI Automation s'exécutent à un niveau de confiance moyen et ne sont pas autorisées à accéder à des processus à privilèges plus élevés. Il est possible de contourner ce problème en utilisant une application signée avec un fichier manifeste contenant la clé requestedExecutionLevel.uiAccess définie sur true :
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="highestAvailable"
uiAccess="true" />
</requestedPrivileges>
</security>
</trustInfo>
En matière de détection, les administrateurs peuvent surveiller l'utilisation de la bibliothèque UIAutomationCore.dll. Le chargement de ce fichier dans un processus inconnu devrait susciter des inquiétudes légitimes.
De même, les administrateurs réseau peuvent surveiller les canaux nommés ouverts sur un point de terminaison par UIA, comme autre indicateur de son utilisation, ce que vous pouvez faire à l'aide des requêtes suivantes :
SELECT DISTINCT pid, name, proc.path FROM process_memory_map AS pmm JOIN processes AS proc USING(pid) WHERE pmm.path LIKE '%uiautomationcore.dll'
Processus qui chargent UIAutomationCore.dll
WITH uia_pipes AS (SELECT name AS pipe_name, SUBSTR(name, 10, INSTR(SUBSTR(name, 10), '_')-1) AS pid FROM pipes WHERE name LIKE 'UIA_PIPE_%' ) SELECT DISTINCT pid, name AS process_name, path, pipe_name FROM uia_pipes JOIN processes USING(pid)
Processus qui ont ouvert le canal nommé UI Automation
Conclusion
Cette analyse est un exemple malheureux de la façon dont une technologie créée à des fins utiles peut être détournée à des fins malveillantes. Bien que l'infrastructure UI Automation puisse être utile aux personnes handicapées, elle offre également aux attaquants la possibilité d'imiter des logiciels espions.
Si l'exploitation d'UIA peut être plus difficile que d'autres attaques, le fait que l'EDR ne puisse pas la détecter peut faire d'UIA une surface d'attaque très attrayante. Afin de réduire son attrait pour les acteurs de la menace, Microsoft a placé certaines restrictions sur UIA. Toutefois, les attaquants peuvent toujours en tirer parti s'ils disposent des compétences nécessaires. Nous espérons que cet article de blog sensibilisera les membres de la Blue Team à cette technique d'attaque et les aidera à se défendre contre un tel vecteur d'attaque.
