Benutzerkontensteuerung (UAC) durch Umgehen vertrauenswürdiger Verzeichnisse

Ursprünglicher Autor: David Wells
  • Übersetzung

Der Informationssicherheitsexperte David Wells hat eine Möglichkeit zur Umgehung der UAC-Kontensteuerung in Windows 10 veröffentlicht

Hallo an alle!

Bei der Erforschung einiger der neuen UAC-Umgehungstechniken (UAC) entdeckte ich zum Zeitpunkt dieses Artikels eine völlig neue UAC-Umgehungsmethode. Es ist erwähnenswert, dass Microsoft die Benutzerkontensteuerung nicht als Sicherheitsgrenze betrachtet. Wir berichten jedoch weiterhin über verschiedene Fehler bei Microsoft, und ich möchte die Details der Schwachstelle mitteilen, die ich hier gefunden habe. Diese Methode wurde erfolgreich unter Windows 10 Build 17134 getestet. Bevor ich mich eingehender mit den Details meiner Suche befasse, werde ich Ihnen zunächst eine kleine Erläuterung dazu geben, wie der UAC-Dienst funktioniert.

Uac-Grundierung

Wenn ein Benutzer der Gruppe Administratoren eine Anwendung starten möchte, für die erhöhte Berechtigungen erforderlich sind, zeigt die Benutzerkontensteuerung die entsprechende Anforderung an, und der Benutzer, der Mitglied der Gruppe Administratoren ist, muss die Aktion bestätigen. Diese UAC-Anforderung tritt jedoch nicht für ALLE administrativ ausführbaren Dateien in Windows auf . Es gibt einige Ausnahmen, mit denen die Privilegien einer ausführbaren Datei "automatisch" erhöht werden, ohne eine UAC-Anforderung zu verursachen. Dabei wird die UAC umgangen (sehr zur Überraschung!). Diese bestimmte Gruppe ausgewählter vertrauenswürdiger ausführbarer Dateien führt zusätzliche Systemsicherheitsprüfungen durch, um sicherzustellen, dass diese Dateien tatsächlich zuverlässig sind. Daher missbrauchen Informationsangreifer diese Funktion normalerweise nicht. Dieser Ansatz wurde bereits in früheren UAC-Workarounds verwendet und wird die Grundlage für meinen neuen Workaround bilden. Es gibt jedoch einige Schlupflöcher, die wir verwenden müssen, damit unser Angriff erfolgreich sein kann. Schauen wir uns die Anforderungen an, die erfüllt sein müssen, wenn unsere ausführbare Datei "automatisch in Berechtigungen angehoben werden soll". Dazu zeige ich einige Bilder der disassemblierten Bibliothek "appinfo.dll" (AIS, das Anfragen zur Privilegieneskalation verarbeitet, ist eine der Hauptkomponenten von UAC).

Anforderung 1: Die Datei ist so konfiguriert, dass Berechtigungen automatisch erhöht werden

Wenn eine Anforderung zur Erhöhung der Berechtigungen für ein Programm auftritt, wird im AIS-Dienst (appinfo.dll) ein RPC-Aufruf mit dem Zielpfad als Argument übergeben. Dieser Dienst stimmt dann mit dem Ziel der ausführbaren Datei der Datei zum Lesen überein. Im Manifest der ausführbaren Datei wird versucht, den Wert zu lesen, um den Schlüssel "autoElevate" (sofern vorhanden) zu erhalten.

Abbildung 1 - Lesen des Manifests der ausführbaren Datei, um den Wert des Schlüssels "autoElevate" zu erhalten.



Wenn der Wert empfangen wird und der Wert „True“ ist, wird die Datei von einer ausführbaren Datei, die mit erhöhten Berechtigungen ausgeführt wird, als „automatische“ erhöhte Berechtigungen behandelt und das Dialogfeld des UAC-Dienstes nicht aufgerufen (vorausgesetzt, dass die folgenden Anforderungen erfüllt wurden).

Abbildung 2 - Rufen Sie "bsearch" auf, um den Namen der ausführbaren Datei in der Liste der ausführbaren Dateien zu überprüfen. "Automatisch anheben".



Einige dieser hart programmierten Dateien im Whitelist-System sind:
'cttunesvr.exe', 'inetmgr.exe', 'migsetup.exe', 'mmc.exe', 'oobe.exe', 'pkgmgr.exe', 'provisionhare.exe', 'provisionstorage.exe', 'spinstall.exe', 'winsat.exe'

Voraussetzung 2: Richtig signiert

Es wird davon ausgegangen, dass die zweite Bedingung für eine "automatische" Privilegieneskalation nach dem Senden einer Anforderung an die Benutzerkontensteuerung die Signaturprüfung mit "wintrust!" WTGetSignatureInfo.

Dies bedeutet, dass der Angreifer nicht einfach eine eigene Manifest- oder ausführbare Datei erstellen kann, die für die automatische Erhöhung und den Erfolg von Privilegien erforderlich ist, da die Binärdatei des Angreifers wahrscheinlich falsch signiert ist und die letzte Anforderung ist aus einem vertrauenswürdigen Verzeichnis \ Verzeichnis.

Voraussetzung 3: Ausführung aus einem vertrauenswürdigen Verzeichnis \

Die letzte Voraussetzung für das Erzielen einer "automatischen" Privilegiensteigerung ist, dass sich die ausführbare Zieldatei in einem "vertrauenswürdigen Verzeichnis" befindet, beispielsweise "C: \ Windows \ System32". Abbildung 3 zeigt, dass AIS diese Pfadprüfung mit einer Eingabeaufforderung durchführt. In diesem Fall wird als "vertrauenswürdig" der Pfad "C: \ Windows \ System32" bezeichnet.

Abbildung 3



Der Titel dieses Artikels lautet „User Account Control Bypass (UAC) durch Parodieren von vertrauenswürdigen Verzeichnissen“, sodass Sie wahrscheinlich leicht erraten können, was als Nächstes passieren wird.

UAC-Umgehung

Wie bereits erwähnt, wird die automatische Privilegierung (UAC-Umgehung) für ausführbare Dateien ausgeführt, die Folgendes ausführen:

  1. Konfiguriert, um eine "automatische" Privilegieneskalation zu erhalten
  2. Richtig unterschrieben
  3. Läuft von einem vertrauenswürdigen Verzeichnis ("C: \ Windows \ System32")

Appinfo.dll (AIS) verwendet die RtlPrefixUnicodeString-API, um zu überprüfen, ob der ausführbare Pfad der Datei mit "C: \ Windows \ System32 \" einem der vertrauenswürdigen Verzeichnisse entspricht. Dies ist eine ziemlich verstärkte Betonüberprüfung, wenn man den Vergleich mit dem kanonischen Speicherort der Datei berücksichtigt.

Um eine Durchforstung dieser Prüfung zu organisieren, erstelle ich ein Verzeichnis mit dem Namen "C: \ Windows \" (beachten Sie das Leerzeichen nach "Windows"). Natürlich kann die RtlPrefixUnicodeString-Prüfung mit dieser Aktion immer noch nicht bestanden werden, und ich erwähne auch, dass dies ein etwas ungültiger (oder zumindest "unfreundlicher") Verzeichnisname ist, da Windows beim Erstellen des Verzeichnisses keine Leerzeichen zulässt (versuchen Sie das ).

Verwenden Sie jedoch die CreateDirectory-API und fügen Sie „\\? \ ”Für den Namen des Verzeichnisses, das ich erstellen möchte, können wir einige dieser Namensfilterregeln umgehen und eine Anforderung senden, ein Verzeichnis direkt an das Dateisystem zu erstellen.



Dies führt zur Erstellung eines unbequemen Verzeichnisses, das zusammen mit dem eigentlichen "C: \ Windows \" glücklich im Dateisystem vorhanden ist (es sei denn, Sie versuchen etwas in Windows Explorer damit zu tun).



Jetzt, da wir das Verzeichnis "C: \ Windows \" haben, können wir das Verzeichnis "System32" erstellen und eine der signierten, ausführbaren Dateien (die vom System für die "automatische" Privilegierung der Rechte zugelassen sind) aus dem echten "C" kopieren: \ Windows \ System32 ".
Dazu habe ich „winSAT.exe“ (eine der Dateien in der Whitelist der ausführbaren Windows-Dateien mit dem System, das die automatische Erhöhung der Berechtigungen aktiviert hat) kopiert.
Wenn wir versuchen, diese Datei von unserem neuen Verzeichnis "C: \ Windows \ System32 \ winSAT.exe" aus zu starten, werden die folgenden APIs (siehe Abbildung 6) in appinfo.dll durchlaufen, bevor die Überprüfung des vertrauenswürdigen Verzeichnisses durchgeführt wird. Dies ist wichtig und die Grundlage, warum dieser Bypass funktioniert.

Abbildung 6



Wenn dieser unpraktische Pfad mit einem Leerzeichen an AIS gesendet wird, um eine Anforderung für die Privilegieneskalation zu erhalten, wird der Pfad an GetLongPathNameW übergeben, der ihn zurück in „C: \ Windows \ System32 \ winSAT.exe“ konvertiert (Leerzeichen wird entfernt).

Großartig!

Dies ist nun die Zeichenfolge, in der das gültige Verzeichnis (mit RtlPrefixUnicodeString) für den Rest der Validierung validiert wurde.

Das Schöne an meiner Lösung ist, dass nach der Überprüfung des vertrauenswürdigen Verzeichnisses dieser konvertierte Pfad ausgeführt wird, der dann freigegeben wird und die verbleibenden Überprüfungen (und die letzte Anforderung zur Privilegieneskalation) mit dem ursprünglichen Namen des ausführbaren Verzeichnisses (mit zusätzlichem Speicherplatz) ausgeführt werden.

Dadurch können alle anderen Prüfungen bestanden werden, und appinfo.dll akzeptiert meine Kopie von winSAT.exe wie bei einer "automatischen" Privilegieneskalation (da sie korrekt signiert ist und zur weißen Liste für die "automatische" Privilegieneskalation hinzugefügt wird).

Um den Schadcode tatsächlich zu verwenden, kopierte ich einfach die gefälschte WINMM.dll (importierte winSAT.exe) in mein aktuelles Verzeichnis „C: \ Windows \ System32 \“, um die lokale DLL zu ersetzen. Das Gesamtkonzept ist in der folgenden Abbildung dargestellt.

Abbildung 7.



Link zu Github

Jetzt auch beliebt: