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.
Das Verpacken dieses Codes als Bibliothek würde das sorgfältige Entfernen aller interaktiven Befehlszeilenanalysen und Standardausgaben erfordern. Dann, ohne größere Umschreibungen, würde das 'Kit':
Angreifer, die an dieser speziellen Vorgehensweise interessiert sind – im Gegensatz zu sehr vielen anderen, besser kreuzkompatiblen, keine SYSTEM-Rechte erfordernden Techniken – haben ihren eigenen Code wahrscheinlich bereits basierend auf dem Proof-of-Concept vom April 2015 angepasst – vor mehr als 3 Jahren.
Aufgrund der Verwendung der Windows-Symbol-Engine müssen Sie entweder das Windows Software Development Kit (SDK) oder das Windows Driver Kit (WDK) mit installierten Debugging-Tools für Windows haben. Das Tool sucht automatisch nach Ihrem Installationspfad und nutzt die in diesem Verzeichnis vorhandenen DbgHelp.dll und SymSrv.dll. Da diese Dateien nicht weiterverteilt werden dürfen, können sie nicht mit der Freigabe des Tools enthalten sein.
Alternativ, wenn Sie diese Bibliotheken selbst beschaffen, können Sie den Quellcode ändern, um sie zu verwenden.
Die Verwendung von Symbolen erfordert eine Internetverbindung, sofern Sie sie nicht lokal zwischengespeichert haben. Zusätzlich sollten Sie die Variable _NT_SYMBOL_PATH einrichten, die auf einen geeigneten Symbolserver und einen zwischengespeicherten Ort verweist.
Es wird davon ausgegangen, dass ein IT-Experte oder anderer Troubleshooter, der offensichtlich Kernel-Speicher lesen/schreiben/ausführen muss (und Kenntnisse über die entsprechenden Kernel-Variablen hat, auf die zugegriffen werden soll), bereits mehr als vertraut mit den oben genannten Einrichtungsanforderungen ist. Bitte erstellen Sie keine Issues, die fragen, was das SDK ist oder wie man eine Umgebungsvariable setzt.
Ein Treiber hat Kernel-Pool verloren? Warum nicht ntoskrnl.exe!ExFreePool aufrufen und die leckende Kernel-Adresse übergeben? Was ist mit einer Objektreferenz? Rufen Sie ntoskrnl.exe!ObfDereferenceObject auf und lassen Sie sie bereinigen.
Möchten Sie das Kernel-DbgPrint-Protokoll ausgeben? Warum nicht den internen Ringpuffer bei ntoskrnl.exe!KdPrintCircularBuffer ausgeben?
Sie fragen sich, wie groß die Kernel-Stacks auf Ihrem Rechner sind? Versuchen Sie, auf ntoskrnl.exe!KeKernelStackSize zu schauen.
Möchten Sie die Systemaufruftabelle auf Hooks überprüfen? Geben Sie ntoskrnl.exe!KiServiceTable aus.
Dies sind nur einige Beispiele – alle Ring-0-Adressen werden akzeptiert, entweder durch modul!symbol-Syntax oder durch direktes Übergeben des Kernel-Zeigers, falls bekannt. Die Windows-Symbol-Engine wird verwendet, um diese nachzuschlagen.
Das Tool erfordert bestimmte Kernel-Variablen und -Funktionen, die nur in modernen Versionen von Windows 10 bekannt sind und nur für 64-Bit-Systeme vorgesehen sind. Diese Einschränkungen sind darauf zurückzuführen, dass auf älteren Systemen (oder x86-Systemen) diese strengeren Sicherheitsanforderungen nicht existieren und daher eher traditionelle Ansätze verwendet werden können. Dies ist ein persönliches Werkzeug, das ich zur Verfügung stelle, und ich hatte keinen Bedarf für diese älteren Systeme, auf denen ich stattdessen einen einfachen Treiber verwenden könnte. Das Repository akzeptiert jedoch Pull-Requests, falls jemand Interesse an einer Portierung hat.
Zweitens gelten aufgrund der Anwendungsfälle und meiner eigenen Bedürfnisse die folgenden Einschränkungen:
Offensichtlich könnten diese Einschränkungen behoben werden, indem programmatisch ein anderer Ansatz gewählt wird, aber sie passen zu den Bedürfnissen eines Befehlszeilentools und meinen Anwendungsfällen. Auch hier sind Pull-Requests willkommen, falls andere eigene Ergänzungen beisteuern möchten.
Beachten Sie, dass die gesamte Ausführung (einschließlich der Ausführung der Befehle --read und --write) im Kontext eines System-Worker-Threads auf PASSIVE_LEVEL erfolgt. Daher sollten keine Benutzermodus-Adressen als Parameter/Argumente übergeben werden.
Pull-Requests sind willkommen. Für größere Änderungen öffnen Sie bitte zunächst ein Issue, um zu besprechen, was Sie ändern möchten.
Copyright 2018 Alex Ionescu. Alle Rechte vorbehalten.
Die Weiterverwendung und Vervielfältigung in Quell- und Binärform, mit oder ohne Änderungen, ist unter
den folgenden Bedingungen gestattet:
1. Weiterverbreitungen des Quellcodes müssen den obigen Urheberrechtshinweis, diese Liste der Bedingungen und
den folgenden Haftungsausschluss enthalten.
2. Weiterverbreitungen in binärer Form müssen den obigen Urheberrechtshinweis, diese Liste der Bedingungen
und den folgenden Haftungsausschluss in der Dokumentation und/oder anderen mit der Verbreitung bereitgestellten
Materialien enthalten.
DIESE SOFTWARE WIRD VON ALEX IONESCU "WIE BESEHEN" ZUR VERFÜGUNG GESTELLT, UND JEGLICHE AUSDRÜCKLICHE ODER
STILLSCHWEIGENDE GEWÄHRLEISTUNGEN, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF DIE STILLSCHWEIGENDEN GEWÄHRLEISTUNGEN
DER MARKTGÄNGIGKEIT UND DER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK, WERDEN AUSDRÜCKLICH ABGELEHNT. IN KEINEM FALL
HAFTET ALEX IONESCU ODER BEITRAGENDE FÜR DIREKTE, INDIREKTE, ZUFÄLLIGE, BESONDERE, EXEMPLARISCHE ODER
FOLGESCHÄDEN (EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF DIE BESCHAFFUNG VON ERSATZGÜTERN ODER
DIENSTLEISTUNGEN, NUTZUNGSAUSFALL, DATENVERLUST ODER GESCHÄFTSUNTERBRECHUNG), WIE AUCH IMMER VERURSACHT
UND AUF JEDER HAFTUNGSTHEORIE, OB AUS VERTRAG, STRIKTER HAFTUNG ODER UNERLAUBTER HANDLUNG
(EINSCHLIESSLICH FAHRLÄSSIGKEIT ODER ANDERWEITIG), DIE AUS DER NUTZUNG DIESER SOFTWARE ENTSTEHEN,
SELBST WENN AUF DIE MÖGLICHKEIT SOLCHER SCHÄDEN HINGEWIESEN WURDE.
Die in der Software und Dokumentation enthaltenen Ansichten und Schlussfolgerungen sind die der Autoren und
sollten nicht als offizielle Richtlinien interpretiert werden, weder ausdrücklich noch stillschweigend, von Alex Ionescu.