harryanon/r0akUtilitaire en ligne de commande Windows pour lire, écrire et exécuter du code en mode noyau depuis un contexte Administrateur en utilisant une technique de redirection d'exécution par validation de police, permettant un débogage avancé du noyau et le dépannage système.
r0ak est un utilitaire en ligne de commande Windows qui vous permet de lire, écrire et exécuter facilement du code en mode noyau (avec certaines limitations) depuis l'invite de commandes, sans nécessiter autre chose que des privilèges Administrateur.
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
USAGE: r0ak.exe
[--execute <Address | module.ext!function> <Argument>]
[--write <Address | module.ext!function> <Value>]
[--read <Address | module.ext!function> <Size>]
Le noyau Windows est un environnement riche dans lequel des centaines de pilotes s'exécutent sur un système typique, et où des milliers de variables contenant l'état global sont présentes. Pour un dépannage avancé, les experts informatiques utilisent généralement des outils tels que le débogueur Windows (WinDbg), les outils SysInternals, ou écrivent les leurs. Malheureusement, l'utilisation de ces outils devient de plus en plus difficile, et ils sont eux-mêmes limités par leur propre accès aux API Windows et aux fonctionnalités exposées.
Certains des défis actuels incluent :
Dans un tel environnement, il était clair qu'un outil simple pouvant être utilisé comme un pansement/correctif d'urgence et pour dépanner rapidement les problèmes au niveau du noyau/système qui peuvent être apparents en analysant l'état du noyau pourrait être précieux pour la communauté.
r0ak fonctionne en redirigeant le flux d'exécution des vérifications de validation de police de confiance du gestionnaire de fenêtres lors de la tentative de chargement d'une nouvelle police, en remplaçant la routine de comparaison de la table des polices de confiance par une fonction alternative qui planifie un élément de travail exécutif (WORK_QUEUE_ITEM) stocké dans le nœud d'entrée. Ensuite, l'enfant droit de la table des polices de confiance (qui sert de nœud racine) est remplacé par un tampon d'écriture de pipe nommé (NP_DATA_ENTRY) dans lequel un élément de travail personnalisé est stocké. La fonction de travail sous-jacente de cet élément et son paramètre seront finalement exécutés par un ExpWorkerThread dédié à PASSIVE_LEVEL une fois qu'un chargement de police est tenté et que la routine de comparaison s'exécute, recevant le nœud parent basé sur un pipe nommé comme entrée. Un événement de trace Event Tracing for Windows (ETW) en temps réel est utilisé pour recevoir une notification asynchrone que l'élément de travail a terminé son exécution, ce qui permet de démanteler les structures, de libérer les tampons en mode noyau et de restaurer le fonctionnement normal en toute sécurité.
Lors de l'utilisation de l'option --execute, cette fonction et ce paramètre sont fournis par l'utilisateur.
Lors de l'utilisation de --write, un gadget personnalisé est utilisé pour modifier des valeurs 32 bits arbitraires n'importe où dans la mémoire du noyau.
Lors de l'utilisation de --read, le gadget d'écriture est utilisé pour modifier le pointeur et la taille du tampon HSTI du système (N.B. : Ce comportement est destructeur pour toute autre application qui demandera les données HSTI. Comme il s'agit d'un comportement facultatif de Windows et que cet outil est destiné au débogage/expérimentation d'urgence, cette perte de données a été considérée comme acceptable). Ensuite, l'API HSTI Query est utilisée pour copier les données dans l'espace d'adressage en mode utilisateur de l'outil, et un dump hexadécimal est affiché.
Étant donné que seules des fonctionnalités intégrées Windows, signées par Microsoft, sont utilisées, et que toutes les fonctions appelées font partie du bitmap KCFG, il n'y a aucune violation des contrôles de sécurité, et aucun indicateur de débogage n'est requis, ni l'utilisation de pilotes tiers mal écrits.
Non. Étant donné que cet outil — et la technique sous-jacente — nécessitent un jeton privilégié de niveau SYSTEM, qui ne peut être obtenu que par un utilisateur exécuté sous le compte Administrateur, aucune limite de sécurité n'est contournée pour obtenir l'effet. Le comportement et l'utilité de l'outil ne sont possibles que grâce au contexte de sécurité élevé/ privilégié du compte Administrateur sur Windows, et sont considérés comme un comportement de conception.
Bien sûr ! Il est important de toujours signaler les problèmes de sécurité à Microsoft, même si aucune violation des limites privilégiées ne semble s'être produite — leurs équipes de chercheurs et de développeurs pourraient trouver de nouveaux vecteurs et moyens d'atteindre certains chemins de code auxquels un chercheur externe n'aurait pas pensé.
Ainsi, en novembre 2014, un dossier de sécurité a été déposé auprès du Microsoft Security Research Centre (MSRC) qui a répondu : "[…] n'entre pas dans le cadre d'un problème de sécurité que nous traiterions via notre véhicule traditionnel de Bulletin de Sécurité. Il […] présuppose des privilèges administrateur — un endroit où, architecturalement, nous ne définissons actuellement pas de limite de sécurité défendable. Par conséquent, nous ne poursuivrons pas cette piste pour la corriger."
De plus, en avril 2015 lors de la conférence Infiltrate, une présentation intitulée Insection : AWEsomely Exploiting Shared Memory Objects a détaillé ce problème, y compris aux développeurs Microsoft présents, qui ont convenu que cela était actuellement hors du champ des limites de sécurité architecturales de Windows. En effet, il existe littéralement des dizaines — voire plus — d'autres moyens par lesquels un Administrateur peut lire/écrire/exécuter de la mémoire Ring 0. Cet outil permet simplement une commodification facile d'un de ces vecteurs, à des fins de débogage et de dépannage de problèmes système.