harryanon/r0akWindows-Befehlszeilen-Dienstprogramm zum Lesen, Schreiben und Ausführen von Kernel-Mode-Code aus dem Administrator-Kontext mithilfe einer Font-Validierungs-Execution-Redirection-Technik, die erweitertes Kernel-Debugging und System-Fehlerbehebung ermöglicht.
r0ak ist ein Windows-Befehlszeilenprogramm, mit dem Sie bequem über die Eingabeaufforderung Kernel-Mode-Code lesen, schreiben und ausführen können (mit einigen Einschränkungen) – ohne dass etwas anderes als Administratorrechte erforderlich ist.
r0ak v1.0.0 -- Ring 0 Army Knife
http://www.github.com/ionescu007/r0ak
Copyright (c) 2018 Alex Ionescu [@aionescu]
http://www.windows-internals.com
VERWENDUNG: r0ak.exe
[--execute <Adresse | module.ext!funktion> <Argument>]
[--write <Adresse | module.ext!funktion> <Wert>]
[--read <Adresse | module.ext!funktion> <Größe>]
Der Windows-Kernel ist eine reichhaltige Umgebung, in der auf einem typischen System hunderte Treiber ausgeführt werden und in der tausende Variablen mit globalem Zustand vorhanden sind. Für fortgeschrittene Fehlerbehebung nutzen IT-Experten typischerweise Werkzeuge wie den Windows-Debugger (WinDbg), SysInternals-Tools oder schreiben eigene. Leider wird die Nutzung dieser Tools zunehmend schwieriger, und sie sind selbst durch ihren eigenen Zugriff auf Windows-APIs und bereitgestellte Funktionen eingeschränkt.
Zu den heutigen Herausforderungen gehören:
In einer solchen Umgebung war klar, dass ein einfaches Werkzeug, das als Notfall-Pflaster/Hotfix verwendet werden kann und zur schnellen Fehlerbehebung von Kernel-/Systemebenenproblemen dient, die durch die Analyse des Kernel-Zustands offensichtlich werden, für die Community wertvoll sein könnte.
r0ak funktioniert, indem es den Ausführungsfluss der vertrauenswürdigen Schriftart-Validierungsprüfungen des Fenstermanagers umleitet, wenn versucht wird, eine neue Schriftart zu laden. Dazu wird die Comparator-Routine der vertrauenswürdigen Schriftarttabelle durch eine alternative Funktion ersetzt, die ein im Eingabeknoten gespeichertes Executive Work Item (WORK_QUEUE_ITEM) plant. Anschließend wird der rechte Kindknoten der vertrauenswürdigen Schriftarttabelle (der als Wurzelknoten dient) mit dem Schreibpuffer eines Named Pipes (NP_DATA_ENTRY) überschrieben, in dem ein benutzerdefiniertes Work Item gespeichert ist. Die zugrundeliegende Worker-Funktion dieses Items und ihr Parameter werden schließlich von einem dedizierten ExpWorkerThread auf PASSIVE_LEVEL ausgeführt, sobald ein Schriftartladevorgang versucht wird und die Comparator-Routine ausgeführt wird, die den Named-Pipe-gestützten Elternknoten als Eingabe erhält. Ein Echtzeit-Event Tracing for Windows (ETW)-Ablaufverfolgungsereignis wird verwendet, um eine asynchrone Benachrichtigung zu erhalten, dass das Work Item die Ausführung abgeschlossen hat, was es sicher macht, die Strukturen abzubauen, die Kernel-Mode-Puffer freizugeben und den normalen Betrieb wiederherzustellen.
Bei Verwendung der Option --execute werden diese Funktion und dieser Parameter vom Benutzer bereitgestellt.
Bei Verwendung von --write wird ein benutzerdefinierter Gadget verwendet, um beliebige 32-Bit-Werte an beliebigen Stellen im Kernel-Speicher zu ändern.
Bei Verwendung von --read wird der Schreib-Gadget verwendet, um den HSTI-Pufferzeiger und die -Größe des Systems zu ändern (Achtung: Dies ist destruktiv im Hinblick auf andere Anwendungen, die die HSTI-Daten anfordern. Da es sich um optionales Windows-Verhalten handelt und dieses Werkzeug für die Notfall-Fehlerbehebung/Experimente gedacht ist, wurde dieser Datenverlust als akzeptabel angesehen). Anschließend wird die HSTI-Abfrage-API verwendet, um die Daten zurück in den Benutzermodus-Adressraum des Tools zu kopieren, und es wird eine Hex-Dump angezeigt.
Da ausschließlich integrierte, von Microsoft signierte Windows-Funktionalität verwendet wird und alle aufgerufenen Funktionen Teil der KCFG-Bitmap sind, gibt es keine Verletzung von Sicherheitsprüfungen, und es sind keine Debugging-Flags oder die Verwendung schlecht geschriebener Drittanbieter-Treiber erforderlich.
Nein. Da dieses Tool – und die zugrundeliegende Technik – ein SYSTEM-privilegiertes Token erfordern, das nur von einem Benutzer erlangt werden kann, der unter dem Administratorkonto arbeitet, werden keine Sicherheitsgrenzen umgangen, um den Effekt zu erzielen. Das Verhalten und die Nützlichkeit des Tools sind nur aufgrund des erhöhten/privilegierten Sicherheitskontexts des Administratorkontos unter Windows möglich und werden als verhaltensbedingtes Design angesehen.
Natürlich! Es ist wichtig, Sicherheitsprobleme immer bei Microsoft zu melden, auch wenn keine Verletzung privilegierter Grenzen aufgetreten zu sein scheint – ihre Teams von Forschern und Entwicklern könnten neuartige Vektoren und Wege finden, um bestimmte Codepfade zu erreichen, an die ein externer Forscher möglicherweise nicht gedacht hat.
Daher wurde im November 2014 ein Sicherheitsfall beim Microsoft Security Research Centre (MSRC) eingereicht, der wie folgt antwortete: "[…] fällt nicht in den Bereich eines Sicherheitsproblems, das wir über unser traditionelles Security Bulletin-Fahrzeug behandeln würden. Es […] setzt Administratorrechte voraus – einen Ort, an dem wir architektonisch derzeit keine verteidigbare Sicherheitsgrenze definieren. Daher werden wir dies nicht zur Behebung verfolgen."
Darüber hinaus wurde im April 2015 auf der Infiltrate-Konferenz ein Vortrag mit dem Titel Insection : AWEsomely Exploiting Shared Memory Objects gehalten, der dieses Problem detailliert darlegte, auch gegenüber anwesenden Microsoft-Entwicklern, die zustimmten, dass dies derzeit außerhalb des Rahmens der architektonischen Sicherheitsgrenzen von Windows liege. Dies liegt daran, dass es buchstäblich Dutzende – wenn nicht mehr – anderer Möglichkeiten gibt, mit denen ein Administrator Ring-0-Speicher lesen/schreiben/ausführen kann. Dieses Tool ermöglicht lediglich eine einfache Kommerzialisierung eines solchen Vektors zum Zwecke der Fehlerbehebung und Problemdiagnose von Systemproblemen.