Der Informationssicherheitsexperte David Wells hat eine Möglichkeit veröffentlicht, die UAC-Benutzerkontensteuerung in Windows 10 zu umgehen
Hallo allerseits!
Bei der Suche nach neuen Problemumgehungen für die Benutzerkontensteuerung (User Account Control, UAC) habe ich zum Zeitpunkt dieses Schreibens eine völlig neue Problemumgehung für die Benutzerkontensteuerung entdeckt. Es ist erwähnenswert, dass Microsoft die Benutzerkontensteuerung nicht als Sicherheitsgrenze betrachtet. Wir melden jedoch immer noch verschiedene Fehler bei Microsoft und ich möchte die Details der hier gefundenen Sicherheitsanfälligkeit mitteilen. Diese Methode wurde unter Windows 10 Build 17134 erfolgreich getestet. Bevor ich mich mit den Details meines Funds befasse, werde ich Ihnen zunächst eine kleine Erklärung zur Funktionsweise des UAC-Dienstes geben.
Uac-GrundierungWenn ein Benutzer, der Mitglied der Gruppe Administratoren ist, eine Anwendung ausführen möchte, für die erhöhte Berechtigungen erforderlich sind, zeigt die Benutzerkontensteuerung eine entsprechende Anforderung an, und ein Benutzer, der Mitglied der Gruppe Administratoren ist, muss die Aktion bestätigen. Diese Benutzerkontensteuerungsanforderung tritt jedoch nicht für ALLE administrativ ausführbaren Dateien unter Windows auf . Es gibt einige Ausnahmen, die die Berechtigungen einer ausführbaren Datei "automatisch" erhöhen, ohne eine UAC-Anforderung zu verursachen, wobei die UAC umgangen wird (sehr zu Ihrer Überraschung!). Diese bestimmte Gruppe ausgewählter vertrauenswürdiger ausführbarer Dateien wird vom System zusätzlichen Sicherheitsüberprüfungen unterzogen, um sicherzustellen, dass diese Dateien tatsächlich zuverlässig sind. Daher missbrauchen Informationsangreifer diese Funktion normalerweise nicht. Dieser Ansatz wurde in früheren UAC-Bypass-Methoden verwendet und wird die Grundlage meiner neuen Bypass-Methode sein. Es gibt jedoch einige Lücken, die wir schließen müssen, damit unser Angriff erfolgreich ist. Schauen wir uns die Anforderungen an, die erfüllt sein müssen, damit unsere ausführbare Datei automatisch zu Berechtigungen erhöht wird. Zu diesem Zweck zeige ich einige Bilder der disassemblierten Bibliothek appinfo.dll (der AIS-Dienst, der Eskalationsanforderungen für Berechtigungen verarbeitet, ist eine der Hauptkomponenten der Benutzerkontensteuerung).
Anforderung 1: Datei, die so konfiguriert ist, dass Berechtigungen automatisch erhöht werden
Wenn eine Anforderung zur Eskalation von Berechtigungen für ein Programm auftritt, führt der AIS-Dienst (appinfo.dll) einen RPC-Aufruf mit dem als Argument übergebenen ausführbaren Zielpfad durch. Dieser Dienst ordnet dann den ausführbaren Zielinhalt der zu lesenden Datei zu. Im Manifest der ausführbaren Datei wird versucht, den Wert zu lesen, um den Schlüssel "autoElevate" zu erhalten (falls vorhanden).
Abbildung 1 - Lesen des Manifests der ausführbaren Datei, um den Schlüsselwert "autoElevate" zu erhalten.
Wenn der Wert empfangen wird und True ist, wird die Datei als "automatische" ausführbare Datei mit erhöhten Berechtigungen betrachtet, die mit einer Eskalation der Berechtigungen ausgeführt wird und nicht das Dialogfeld "UAC-Dienst" aufruft (vorausgesetzt, sie hat die folgenden Anforderungen erfüllt).
Abbildung 2 - Aufruf von "bsearch", um den Namen der ausführbaren Datei in der Liste der ausführbaren Dateien zu überprüfen.
Einige dieser Dateien, die im System fest programmiert sind, werden in die Whitelist aufgenommen:
'cttunesvr.exe', 'inetmgr.exe', 'migsetup.exe', 'mmc.exe', 'oobe.exe', 'pkgmgr.exe', 'ordershare.exe', 'provisionstorage.exe', 'spinstall' .exe ',' winsat.exe '
Anforderung 2: Ordnungsgemäß unterschrieben
Es wird davon ausgegangen, dass die zweite Bedingung für die "automatische" Erhöhung der Berechtigung nach dem Senden einer Anforderung an die Benutzerkontensteuerung darin besteht, eine Signaturprüfung mit "wintrust! WTGetSignatureInfo ".
Dies bedeutet, dass der Angreifer nicht einfach sein eigenes Manifest oder eine ausführbare Datei erstellen kann, die für die „automatische“ Erhöhung von Berechtigungen erforderlich ist, und erfolgreich ist, da die Binärdatei des Angreifers höchstwahrscheinlich falsch signiert ist und die letzte Anforderung, die Ausführung, ebenfalls nicht erfüllt wird. aus einem vertrauenswürdigen Verzeichnis.
Anforderung 3: Ausführung aus einem vertrauenswürdigen Verzeichnis
Die letzte Voraussetzung für das Erhalten einer "automatischen" Erhöhung von Berechtigungen ist, dass sich die ausführbare Zieldatei in einem "vertrauenswürdigen Verzeichnis" befindet, z. B. "C: \ Windows \ System32". Abbildung 3 zeigt, dass AIS diese Überprüfung des Pfads mit der Upgrade-Anforderung durchführt. In diesem Fall ist einer der als "vertrauenswürdig" eingestuften Pfade "C: \ Windows \ System32".
Abbildung 3
Der Titel dieses Artikels lautet "UAC (Bypass User Account Control) durch Nachahmen vertrauenswürdiger Verzeichnisse", sodass Sie wahrscheinlich leicht erraten können, was als Nächstes passieren wird.
UAC-UmgehungWie bereits im Abschnitt "UAC Primer" erwähnt, werden automatische Berechtigungen (UAC Bypass) für ausführbare Dateien ausgeführt, die:
- Konfiguriert für die automatische Eskalation von Berechtigungen
- Richtig signiert
- Aus einem vertrauenswürdigen Verzeichnis ausführen ("C: \ Windows \ System32")
Appinfo.dll (AIS) verwendet die RtlPrefixUnicodeString-API, um zu überprüfen, ob der ausführbare Dateipfad mit "C: \ Windows \ System32 \" übereinstimmt, um eines der vertrauenswürdigen Verzeichnisse zu überprüfen. Dies ist ein ziemlich verstärkter Betontest, da er mit dem Speicherort der kanonischen Datei verglichen wird.
Um eine Umgehung dieser Prüfung zu organisieren, erstelle ich ein Verzeichnis mit dem Namen "C: \ Windows \" (beachten Sie das Leerzeichen nach "Windows"). Natürlich können Sie mit dieser Aktion die Prüfung RtlPrefixUnicodeString immer noch nicht bestehen, und ich werde auch erwähnen, dass dies ein etwas ungültiger (oder zumindest "unfreundlicher") Verzeichnisname ist, da Windows beim Erstellen des Verzeichnisses keine Leerzeichen am Ende des Namens zulässt (versuchen Sie es) )
Verwenden Sie jedoch die CreateDirectory-API und fügen Sie "\\? \ "Zu dem Verzeichnisnamen, den ich erstellen möchte, können wir einige dieser Namensfilterregeln umgehen und eine Anforderung zum Erstellen des Verzeichnisses direkt an das Dateisystem senden.
Dies führt zur Erstellung eines unbequemen Verzeichnisses, das zusammen mit dem echten "C: \ Windows \" problemlos im Dateisystem vorhanden ist (außer wenn Sie versuchen, im Windows Explorer etwas damit zu tun).
Nachdem wir das Verzeichnis "C: \ Windows \" haben, können wir das Verzeichnis "System32" darin erstellen und eine der signierten ausführbaren Dateien (die vom System "automatisch" zur Erhöhung von Berechtigungen zugelassen werden) aus dem realen Verzeichnis "C:" kopieren. \ Windows \ System32 ".
Zu diesem Zweck habe ich "winSAT.exe" kopiert (eine der Dateien in der weißen Liste der ausführbaren Windows-Dateien mit der vom System zugelassenen "automatischen" Erhöhung der Berechtigungen).
Wenn wir versuchen, diese Datei aus unserem neuen Verzeichnis "C: \ Windows \ System32 \ winSAT.exe" auszuführen, werden die folgenden APIs (siehe Abbildung 6) in appinfo.dll durchlaufen, bevor eine vertrauenswürdige Verzeichnisprüfung durchgeführt wird. Dies ist wichtig und die Grundlage dafür, warum diese Problemumgehung funktioniert.
Abbildung 6
Wenn dieser unbequeme Pfad mit einem Leerzeichen an AIS gesendet wird, um die Eskalation von Berechtigungen anzufordern, wird der Pfad an GetLongPathNameW übergeben, das ihn wieder in "C: \ Windows \ System32 \ winSAT.exe" konvertiert (Leerzeichen entfernt).
Großartig!
Dies ist die Zeile, in der die gültige Verzeichnisprüfung (mit RtlPrefixUnicodeString) für den Rest der Prüfung bestanden wurde.
Das Schöne an meiner Lösung ist, dass nach dem Überprüfen des vertrauenswürdigen Verzeichnisses dieser konvertierte Pfad ausgeführt wird, der dann freigegeben wird, und die restlichen Überprüfungen (und die endgültige Anforderung der Eskalation von Berechtigungen) mit dem ursprünglichen Namen des ausführbaren Verzeichnisses (mit einem zusätzlichen Leerzeichen) ausgeführt werden.
Auf diese Weise kann ich alle anderen Überprüfungen durchführen und appinfo.dll akzeptiert, dass meine Kopie von winSAT.exe eine "automatische" Erhöhung der Berechtigungen aufweist (da sie korrekt signiert und der weißen Liste für die "automatische" Erhöhung der Berechtigungen hinzugefügt wurde).
Um den Schadcode tatsächlich zu verwenden, habe ich einfach die gefälschte WINMM.dll (importierte winSAT.exe) in mein aktuelles Verzeichnis "C: \ Windows \ System32 \" kopiert, um die lokale DLL zu fälschen. Das vollständige Konzept ist in der folgenden Abbildung dargestellt.
Abbildung 7
→
Link zu Github