Ein altes Framework lernt neue Tricks: Die Gefahren der Automatisierung der Windows UI
Redaktion und weitere Kommentare von Tricia Howard
Zusammenfassung
Tomer Peled, Sicherheitsforscher von Akamai, hat neue Möglichkeiten erkundet, das UI Automation Framework von Microsoft zu nutzen und zu missbrauchen. Dabei entdeckte er eine Angriffstechnik, die die Endpunkt-Erkennung und -Reaktion (EDR) umgeht.
Um diese Technik nutzen zu können, muss ein Nutzer davon überzeugt sein, ein Programm auszuführen, das UI-Automatisierung verwendet. Dies kann zu einer versteckten Befehlsausführung führen, die vertrauliche Daten erhebt, Browser auf Phishing-Websites umleitet und vieles mehr.
Die Erkennung dieser Technik stellt in mehrfacher Hinsicht eine Herausforderung dar, auch für EDR. Keine der EDR-Technologien, die wir mit dieser Technik getestet haben, konnte schädliche Aktivitäten erkennen.
Diese Technik kann auf jedem Windows-Endpunkt mit Betriebssystem XP und höher verwendet werden.
In diesem Blogbeitrag geben wir einen vollständigen Überblick über Nutzung und Missbrauch des UI Automation Frameworks (einschließlich möglicher Angriffe, die es ausnutzen könnten) und stellen für jeden von uns diskutierten Missbrauchsvektor einen Proof of Concept (PoC) vor. Außerdem schlagen wir Optionen zur Erkennung und Abwehr vor.
Einführung
Wer sein Geld mit Schreiben verdient, liebt Diktier- und Grammatikprüfsoftware. Wer von der Sicherheitsforschung lebt, knackt gerne Systeme und schreibt dann darüber. Nachdem wir monatelang Anzeigen für diese Schreibassistenten gesehen hatten, beschlossen wir, uns damit auseinanderzusetzen.
Insbesondere wollten wir verstehen, wie eine Anwendung die Nutzeroberfläche (UI) einer anderen Anwendung aus der Ferne manipulieren kann. Was wir herausgefunden haben, war genauso schockierend wie die Tatsache, dass Menschen immer noch XP verwenden: Es wird von einem sehr alten Framework verarbeitet, das als UI Automation Framework bezeichnet wird.
Dieses Framework wurde in den Tagen von Windows XP als eine Möglichkeit konzipiert, Menschen mit Behinderung die Benutzung des Computers zu erleichtern. Es erhielt erhöhte Berechtigungen, um bei Dingen wie dem Vergrößern von Text, der Vorlesefunktion für Text und in einigen Situationen sogar der Simulation von Klicks zu helfen. Dafür benötigt die UI-Automatisierung die Berechtigung zur Bearbeitung fast jedes UI-Elements, das auf dem Bildschirm vorhanden ist. Dies ist in Anbetracht des beabsichtigten Zwecks sinnvoll: Die Technologie hält sich daran, was sie tun darf und was nicht.
Hier haben wir unsere Forschung begonnen, um herauszufinden, welche Auswirkungen Angreifer haben können, wenn sie die UI-Automatisierung missbrauchen.
Wir haben herausgefunden, dass Angreifer UI-Automatisierung missbrauchen können, um Daten zu exfiltrieren, das Surfen im Internet zu manipulieren, Befehle auszuführen und sogar Nachrichten aus Chat-Anwendungen wie WhatsApp oder Slack zu lesen und zu schreiben. Und all das blieb von allen von uns getesteten EDR-Anbietern unentdeckt..
In diesem Blogbeitrag erfahren Sie alles, was Sie über dieses Framework wissen müssen, von der Funktionsweise bis hin zur missbräuchlichen Nutzung seiner Funktionen. Abschließend befassen für uns mit Erkennungs- und Mitigationstechniken, die für Blue Teamer gelten.
Interaktion mit UI-Automatisierung über COM
Um mit Elementen in anderen Anwendungen zu interagieren, nutzt das UI Automation Framework (UIA) das Component Object Model (COM) als IPC-Mechanismus (Interprozesskommunikation).
COM ist ein Framework, das von Microsoft entwickelt wurde, um verschiedenen Programmen die Kommunikation untereinander zu ermöglichen – unabhängig von der Sprache, in der sie geschrieben oder kompiliert werden. Mit dem COM-Framework können Developer Komponenten erstellen, die als COM-Objekte bezeichnet werden. Diese Objekte werden auf einem Windows-Endpunkt mit ihrem Namen, einer UUID (Universal Unique Identifier) und einer Binärdatei registriert, die ihre Logik und andere konfigurierbare Werte enthält.
Um mit UIA zu interagieren, erstellen Nutzer deren COM-Objekt, indem Sie die Funktion„CoCreateInstance“aufrufen. Die UUID der CUIAutomation-Klasse und die UUID der UIAutomation-Schnittstelle sind in der Tabelle aufgeführt.
CUIAutomation UUID |
ff48dba4-60ef-4201-aa87-54103eef594e |
UIAutomation interface UUID |
30cbe57d-d9d0-452a-ab13-7ac5ac4825ee |
Während der Erstellung des COM-Objekts lädt das System die DLL, die bei der Registrierung angegeben wurde. In diesem Fall lautet sie„UIAutomationCore.dll“.
Kommt Ihnen das irgendwie bekannt vor? Vielleicht haben Sie bemerkt, dass das alles ähnlich klingt wie unsere ausführliche Untersuchung von MS-RPC. COM verwendet RPC als Grundlage, daher ihre Ähnlichkeiten.
UI-Automatisierung – Hello World
Bevor Sie sich mit der Frage befassen, wie Angreifer dieses Framework missbrauchen können, sollten Sie sich überlegen, wie Sie mit UIA im Allgemeinen (mit C++) arbeiten. Dies gibt Ihnen den erforderlichen Hintergrund, um zu verstehen, wo die Dinge bei der Implementierung dieses Frameworks schief gelaufen sind. Um zu erfahren, wie Sie mit UIA arbeiten, nutzen Sie unseren GitHub.
Sobald das UIA-Objekt erstellt wurde, wird seine DLL in die Anwendung des Nutzers geladen, ebenso wie in jeden anderen Prozess, der UI-Elemente enthält.
Es geschieht nichts weiter, bis wir Ereignis-Handler für Änderungen der Remote-Prozess-UI hinzufügen. Das folgende Beispiel zeigt, wie Sie einen Handler für Änderungen in der QuickInfo einrichten, die derzeit für einen Nutzer geöffnet ist.
ppAutomation->AddAutomationEventHandler(UIA_ToolTipOpenedEventId, pTargetElement, TreeScope_Subtree, NULL, (IUIAutomationEventHandler*)whatsappEventHandler);
Danach öffnet UIA einen „Server“ auf dem Remote-Prozess, der mit unserer Anwendung kommuniziert (Abbildung 1). Die Daten, die zwischen ihnen übertragen werden, sind Informationen zu allen UI-Elementen des Remote-Prozesses.
Abb. 1: UIA-DLL wird in alle Prozesse mit UI-Elementen geladen
Laut der Microsoft-Dokumentation ist der folgende Handler-Prototyp der Standard-Handler, den UIA erwartet:
HRESULT HandleAutomationEvent(
[in] IUIAutomationElement *sender,
[in] EVENTID eventId
);
Wir können die genaue Anwendung identifizieren, die in den Vordergrund der Nutzeroberfläche gebracht wurde (durch Öffnen oder auf andere Weise), indem wir die Funktion„sender.get_CurrentName“aus dem Handler aufrufen. Jetzt können wir herausfinden, welche Anwendung im Fokus steht und können versuchen, darin zu lesen/zu schreiben.
Dazu müssen wir ein Element finden, aus dem wir lesen/schreiben möchten, indem wir alle Elemente (die vom Senderelement abstammen) durchgehen und entweder ihren UI-Wert lesen, ihren Textwert ändern oder ihr aufrufbares Element abrufen und die Funktion „Invoke“ aufrufen (Abbildung 2).
Abb. 2: Der Prozess des Findens und Bearbeitens eines Elements auf hoher Ebene
Missbrauch der UI-Automatisierung für schädliche Aktivitäten
Im letzten Abschnitt haben wir darüber gesprochen, wie UIA missbraucht werden kann. Jetzt sprechen wir über die möglichen schädlichen Aktivitäten, die durch den Missbrauch verursacht werden. Dies wollen wir anhand von drei Beispielen veranschaulichen:
- Lesen und Schreiben von Nachrichten
- Diebstahl vertraulicher Daten
- Ausführen von Befehlen
Lesen und Schreiben von Nachrichten
Jede Messaging-Anwendung verfügt über eine grafische Nutzeroberfläche (GUI), die verschiedene Arten von UI-Elementen enthält, auf die wir mit der UIA zugreifen können. Abbildung 3 zeigt ein Beispiel für die GUI von Slack, die Ihnen wahrscheinlich vertraut erscheint.
Abb. 3: So sieht Slack normalerweise aus
Die verfügbaren Aktionen innerhalb einer GUI reichen von der Auswahl von Unterhaltungen (die als Schaltflächen im Hintergrund implementiert werden) bis zum Lesen von Nachrichten (Textblöcken), sodass wir mit einer Vielzahl von Elementen interagieren können.
Sobald ein Angreifer eine Verbindung zum UI-Fenster einer solchen Anwendung herstellen kann, kann er einen Klick auf die gewünschte Unterhaltung simulieren (über das UI-Schaltflächenelement) und sie öffnen. Von dort aus kann er entweder die Unterhaltung lesen und die Daten exfiltrieren und/oder das UI-Element suchen, das für das Schreiben einer Nachricht verantwortlich ist, den Textwert in seinem TextArea-Element ändern und einen Klick auf die Schaltfläche „Senden“ simulieren.
Natürlich wäre diese Art von Manipulation auch auf dem Bildschirm zu sehen, sodass auf der Seite des Angreifers viel dem Zufall überlassen bliebe. Ein unauffälligerer Ansatz wäre es, über einen längeren Zeitraum in der aktuell geöffneten Konversation nur zu lesen und Daten zu sammeln (Abbildung 4).
Abb. 4: Lesen von Nachrichten aus Slack
Eine weitere Option, um die Tarnung aufrechtzuerhalten und trotzdem aktiv zu handeln, ist die Verwendung des Caching-Mechanismus von UIA. Zusätzlich zu den derzeit auf dem Bildschirm angezeigten UI-Elementen, mit denen wir interagieren können, werden im Voraus weitere Elemente geladen und in einen Cache abgelegt. Wir können auch mit diesen Elementen interagieren, z. B. Nachrichten lesen, die nicht auf dem Bildschirm angezeigt werden, oder sogar das Textfeld festlegen und Nachrichten senden, ohne dass dies auf dem Bildschirm zu sehen ist.
Obwohl wir es nicht überprüfen konnten, bevor dieser Blogbeitrag veröffentlicht wurde, ermöglicht uns der Caching-Mechanismus möglicherweise auch, mit diesen Elementen zu interagieren, während der Computer gesperrt ist,sodass unsere Interaktionen durch den Nutzer überhaupt nicht erkennbar sind.
Diebstahl vertraulicher Daten
Eine der schädlicheren Möglichkeiten, UIA zu verwenden oder zu missbrauchen, ist der Diebstahl von Kreditkarteninformationen.
Nachdem ein Nutzer einen Onlinehändler besucht hat, kann ein Angreifer programmgesteuert Änderungen in den UI-Elementen abgreifen, indem er einen Handler einrichtet. Sobald eine Änderung vorgenommen wurde (d. h. Kreditkarteninformationen eingegeben wurden), kann der Angreifer den Text aus den UI-Elementen abrufen, um ihn später zu exfiltrieren (Abbildung 5).
Abb. 5: Abrufen von Kreditkarteninformationen aus dem Browser
Ausführen von Befehlen
Ein weiterer häufiger Angriffspfad auf Browser ist Phishing und Browserumleitung.
Durch Ausfiltern von UI-Fenstern in Firefox, Chrome oder Edge können Angreifer einfach in der Suchleiste nach UI-Elementen suchen, den gewünschten Wert eingeben und einen Klick simulieren (Abbildung 6). Für ein verdeckteres Vorgehen können sie auf den Moment warten, in dem die aktuell angezeigte Webseite aktualisiert oder geändert wird, sodass die Änderung auf eine andere Website weniger wahrnehmbar ist.
Dies würde es Angreifern ermöglichen, Nutzer auf schädliche Websites umzuleiten, die sich in der Kontrolle der Angreifer befinden. Von dort aus sind die Möglichkeiten praktisch endlos: Browserausnutzung (z. B. mit dem Browser Exploitation Framework [BeEF]),Drive-by-Angriffe, Tarnung als legitime Website für Phishing oder das Sammeln von Anmeldedaten und vieles mehr.
![Dies würde es Angreifern ermöglichen, Nutzer auf schädliche Websites umzuleiten, die sich in der Kontrolle der Angreifer befinden. Von dort aus sind die Möglichkeiten praktisch endlos: Browserausnutzung (z. B. mit dem Browser Exploitation Framework [BeEF]), Drive-by-Angriffe, Tarnung als legitime Website für Phishing oder für das Auslesen von Anmeldedaten und vieles mehr.](/site/de/images/blog/2024/2024-december-windows-ui-automation-attack-technique-evades-edr-six.gif)
Abb. 6: Umleitung eines Nutzers zu BeEF
Potenzielle Auswirkungen der UI-Automatisierung
Die Angriffe, die wir in den vorherigen Abschnitten besprochen haben, gibt es seit Jahrzehnten mit unterschiedlichen Implementierungen, und die meisten Verteidigungstools wissen, wie sie sie erkennen und darauf reagieren können.
Alles, was wir oben besprochen haben, wird jedoch als Funktion der UI-Automatisierung wahrgenommen.. Dies geht auf den beabsichtigten Zweck der Anwendung zurück: Diese Berechtigungsstufen müssen vorhanden sein, um sie verwenden zu können. Aus diesem Grund kann UIA Defender umgehen – die Anwendung findet nichts Auffälliges. Tatsächlich konnte keines der von uns getesteten EDR diese Aktionen als bösartig erkennen – wahrscheinlich aus demselben Grund. Wenn etwas als Funktion und nicht als Fehler gesehen wird, folgt die Logik des Rechners der Funktion.
Dies macht dieses Framework potenziell sehr attraktiv für Angreifer. Aus diesem Grund glauben wir, dass ein höheres Bewusstsein für den Umgang mit diesem Angriffsvektor entscheidend ist.
Weitere Untersuchungen
UIA über DCOM
Distributed COM (DCOM) ist eine Möglichkeit, COM-Objekte zwischen Computern remote aufzurufen. Theoretisch sollte es möglich sein, per DCOM auf die UIA zuzugreifen, sodass alle von uns besprochenen Angriffe ohne Phishing-/lokalen Zugriff ausgeführt werden können.
Im Rahmen unserer Analyse haben wir festgestellt, dass das COM-Objekt von UIA nicht standardmäßig für DCOM konfiguriert ist. Dadurch wird das Angriffspotenzial deutlich verringert und Fehlkonfigurationen werden ausgeschlossen.
Obwohl UIA selbst nicht über DCOM verfügbar ist, haben wir etwas Ähnliches gefunden: DasUIAutomationCrossBitnessHook COM/DCOM Objekt. Für dieses Objekt ist keine Berechtigung zur Remote-Aktivierung und -Ausführung erforderlich.
Durch die Umkehrung der DLL haben wir festgestellt, dass die Schnittstelle zwei Funktionen enthält: Eine für das Festlegen des UI-Managers und die andere für dessen Aufhebung. Offenbar sind keine weiteren Remote-Funktionen vorhanden, sodass wir sie nicht zum Lesen oder Schreiben von Daten verwenden konnten, aber es könnte ein schönes Forschungsziel für die Zukunft sein.
Benannte UIA-Pipes
Weiter oben haben wir erwähnt, dass UIA einen „Server“ auf einem Remote-Prozess öffnet. Im Hintergrund werden diese Server und Clients mithilfe benannter Pipes implementiert. Die Benennungskonvention besteht aus der konstanten Zeichenfolge UIA_PIPE gefolgt von der Prozess-ID und einer anderen ID (Abbildung 7).
Abb. 7: Benannte UI-Pipes innerhalb der Angreiferanwendung
An dieser Stelle wird es gruselig: Benannte Pipes können Remote-Verbindungen akzeptieren. Dies ist in diesem Fall sehr gefährlich, da es bedeutet, dass ein Angreifer in der Lage ist, UI-Elemente über das Netzwerk zu manipulieren. Als wir jedoch von einem Remote-Server aus eine Verbindung herstellen wollten, stießen wir auf einen Fehler der Kategorie ACCESS_DENIED.
Dies liegt daran, dass Microsoft beim Erstellen der benannten Pipe das Flag „PIPE_REJECT_REMOTE_CLIENTS“ gesetzt hat. Das bedeutet, dass wir über diese Pipes nicht remote auf die UIA zugreifen können, aber sie trotzdem lokal verfügbar sind. Es ist möglich, diese Pipes aufzuzählen (ohne die Prozess-ID oder ID zu erraten) und auf sie zuzugreifen, was den Weg für eine Art von Angriffen auf die Erhöhung von Berechtigungen oder Nachahmungen ebnen könnte, obwohl dies nicht Teil dieser Analyse war.
Erkennung/Abwehr
Microsoft hat anerkannt, dass dieses Framework nicht mit Anwendungen mit höheren Berechtigungen interagieren sollte. Daher werden Anwendungen, die das UI Automation Framework verwenden, standardmäßig auf mittlerer Vertrauensstufe ausgeführt und dürfen nicht auf Prozesse mit höheren Berechtigungen zugreifen. Dies kann mit einer signierten Anwendung mit einer Manifestdatei umgangen werden, die den auf „True“ gesetzten Schlüssel „RequestedExecutionLevel.uiAccess“ enthält:
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="highestAvailable"
uiAccess="true" />
</requestedPrivileges>
</security>
</trustInfo>
Bei der Erkennung können Admins die Verwendung des „UIAutomationCore.dll“überwachen. Wenn es in einen zuvor unbekannten Prozess geladen wird, sollte dies berechtigte Gründe zur Besorgnis geben.
Auf ähnliche Weise können Netzwerkadmins die benannten Pipes überwachen, die von der UIA auf einem Endpunkt geöffnet werden. Dies dient als weiterer Indikator für deren Verwendung. Dies wird durch die Verwendung der folgenden OsQuerys ermöglicht:
SELECT DISTINCT pid, name, proc.path FROM process_memory_map AS pmm JOIN processes AS proc USING(pid) WHERE pmm.path LIKE '%uiautomationcore.dll'
Prozesse, Folgendes laden: „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)
Prozesse, die die benannte Pipe für UI-Automatisierung geöffnet haben
Fazit
Diese Analyse ist ein unglückliches Beispiel dafür, wie Technologien, die mit guten Absichten entwickelt wurden, für böswillige Zwecke missbraucht werden können. Das UI Automation Framework kann zwar für Menschen mit Behinderung hilfreich sein, bietet Angreifern aber auch die Möglichkeit, Spyware nachzuahmen.
Obwohl der Missbrauch von UIA schwieriger sein mag als einige andere Angriffe, kann die Tatsache, dass EDR diese Angriffe nicht erkennen kann, UIA zu einer äußerst attraktiven Angriffsfläche machen. Um die Attraktivität für Angreifer zu verringern, hat Microsoft einige Einschränkungen für UIA eingerichtet. Mit dem entsprechenden Fachwissen können Angreifer UIA trotzdem für sich nutzen. Wir hoffen, dass dieser Blogbeitrag das Bewusstsein für diese Angriffstechnik schärft und Blue Teamers hilft, sich gegen diese Angriffsvektoren zu verteidigen.
