J'ai toujours aimé faire de la recherche de vulnérabilités dans le noyau, en particulier le noyau Windows. Le processus implique toujours un mélange d'analyse statique et dynamique. Faire de l'analyse dynamique peut rapidement devenir fastidieux. Le cycle debug / crash / reboot / reset de tous les points d'arrêt est lent et pénible. Quand vous voulez faire du fuzzing, cela nécessite souvent de configurer une ou plusieurs machines virtuelles plus un débogueur noyau et d'écrire des scripts bricolés pour gérer la détection de crash...

Faire des snapshots avec des machines virtuelles aide, mais c'est lent.

En 2018, Microsoft a introduit un nouvel ensemble d'API nommé Windows Hypervisor Platform (WHVP). Ces API permettent de configurer une partition (VM dans le langage hyper-V) avec des processeurs virtuels et d'avoir un contrôle sur les VM exits qui se produisent dans la machine virtuelle. C'est presque comme avoir votre propre gestionnaire de VM-exit en espace utilisateur. Très pratique pour faire des choses utiles, par exemple Simpleator ou applepie.

J'ai donc commencé à jouer avec WHVP et j'ai fait un premier PoC me permettant d'exécuter du shellcode dans une partition Hyper-V. Il était écrit en Python et assez lent. Ce premier PoC a assez rapidement évolué vers une sorte de traceur basé sur des snapshots. Je voulais avoir quelque chose pour amorcer le CPU virtuel et assez facile à configurer. Comme j'utilisais déjà un débogueur noyau pour jouer avec ma cible, j'ai décidé d'utiliser des kernel dumps réalisés avec WinDbg comme snapshot. Avec cela, j'avais juste besoin de configurer une partition avec un cpu virtuel. Le contexte du cpu virtuel est défini avec le contexte extrait du dump. Chaque fois que le cpu virtuel a besoin d'une page physique, j'utilise celles du dump.

Avec cela, j'ai pu forker l'état du dump dans une partition puis reprendre l'exécution. Cela m'a permis de tracer facilement l'exécution de ma fonction cible. En modifiant les arguments et en restaurant l'état mémoire de la partition, il était aussi très facile de fuzzer la cible.

Ce travail a été présenté à la conférence SSTIC en 2020 et publié sur github.

L'outil implémente 2 possibilités pour obtenir la couverture. La première exploite le TF (Trap Flag) classique pour avoir des interruptions INT1 sur chaque instruction. Cela nécessite de modifier la cible et c'est lent. J'aurais préféré utiliser le trap flag MONITOR. Mais WHVP n'offre pas cette possibilité.

Afin d'avoir des performances correctes (requises pour le fuzzing), j'ai décidé de réduire la précision de la couverture et d'ajouter un mode où l'on sait uniquement quand une instruction est exécutée pour la première fois.

Pour cela, je patche les pages extraites du snapshot avec des octets 0xcc (uniquement pour les pages exécutables). Quand le cpu exécutera ces instructions patchées, l'hyperviseur interceptera l'exception et réécrira les instructions avec le code original.

C'est comme avoir un point d'arrêt logiciel unique posé sur chaque instruction. Cela fonctionne 95% du temps, mais dans certains morceaux de code particuliers (ceux avec des jump tables par exemple), cela échouera car des données seront remplacées.

Pour contourner cela, une option serait de désassembler le code avant de le mapper et de ne patcher que ce qui est nécessaire (peut-être la prochaine fois).

Au cours de mon expérience, j'ai rencontré plusieurs limitations lors de l'utilisation de WHVP. C'est lent, vraiment lent. Le code source de VirtualBox contient des commentaires intéressants :)

Donc pour avoir des performances correctes, il faut vraiment limiter les VM exits et c'est incompatible si vous voulez utiliser Hyper-V comme hyperviseur de traçage (car cela nécessite beaucoup de VM exits).

Au même moment, j'ai commencé à utiliser bochs (en particulier la partie instrumentation) pour vérifier si les traces obtenues par l'outil étaient correctes. Bochs était une sorte d'oracle pour voir si j'avais des traces divergentes.

Bochs est plus rapide que WHVP lors d'un traçage complet et vous avez aussi l'avantage d'avoir les accès mémoire plus d'autres bonnes choses utiles.

J'ai décidé d'ajouter bochs comme autre backend. whvp n'était plus un nom approprié et j'ai opté pour rewind.

Utilisation typique

rewind a été conçu autour de mon propre flux de travail lorsque je mène des évaluations de sécurité pour des pilotes noyau sur la plateforme Windows.

La première étape consiste à installer le logiciel cible dans une machine virtuelle. Comme j'utilise un mélange d'analyse statique et dynamique, je configure aussi un débogueur noyau.

Après avoir ouvert quelques pilotes au hasard dans IDA, je commence rapidement à cibler certaines fonctions. Pour cela, je place habituellement des points d'arrêt avec windbg et combiné avec ret-sync, je peux commencer à jouer.

C'est là que rewind entre en jeu. Au lieu de modifier des buffers au hasard en mémoire, de faire du pas à pas et d'annoter l'IDB pour avoir une idée approximative de ce qui se passe, je prends un snapshot avec windbg et j'utilise rewind à la place.

Cela facilitera grandement le processus. Avoir un snapshot offre beaucoup d'avantages. Tout est déterministe. Vous pouvez rejouer ad nauseum un appel de fonction. Vous pouvez lancer un fuzzer si la fonction cible semble intéressante. Vous pouvez même fermer la VM car elle n'est plus nécessaire.

Prérequis

Évidemment, vous avez besoin de Rust (installation testée sur Windows et Linux avec Rust 1.50). CMake est également nécessaire pour certaines dépendances.

Git

Commencez par cloner le dépôt :

Continuez avec l'installation du backend bochs

Bochs

Clonez le dépôt bochscpu (https://github.com/yrp604/bochscpu) dans le répertoire vendor :

Téléchargez les artefacts bochs précompilés depuis bochscpu-build (https://github.com/yrp604/bochscpu-build)

Extrayez les dossiers lib et bochs dans le checkout bochscpu.

WHVP

Sous Windows, WHVP sera également compilé comme backend.

Dans une session PowerShell avec élévation de privilèges, utilisez la commande suivante pour vérifier si WHVP est activé :

S'il n'est pas activé, vous pouvez utiliser l'applet de commande Set-WindowsOptionalFeature pour l'activer. Vous devrez également activer Hyper-V.

Vous devez également avoir un Windows SDK (10.0.19041.0) installé. Vous pouvez le télécharger depuis https://developer.microsoft.com/fr-fr/windows/downloads/windows-10-sdk/.

Compilation à partir de la branche master

Vous devez installer LLVM et définir la variable d'environnement LIBCLANG_PATH (requise par bindgen). Voir https://rust-lang.github.io/rust-bindgen/requirements.html pour une explication détaillée.

À partir de là, vous devriez pouvoir compiler rewind (nightly requis à cause de unwind_attributes dans la crate bochscpu) :

Le binaire rewind sera disponible dans le répertoire target/release.

Vous pouvez également utiliser cargo pour installer localement :

Problèmes de compilation courants

• si cmake n'est pas dans le PATH, vous aurez une erreur lors de la compilation de zydis

• si le Windows SDK est différent de ceux pris en charge, whvp-sys échouera à la compilation

Exemples

Un tutoriel de base exploitant CVE-2020-17087 est fourni dans le répertoire examples

Feuille de route

Voir TODO.md

Bugs/Limitations connus

• Ce logiciel en est à un stade très précoce de développement et constitue une expérience en cours.
• Parfois, le traceur est incapable de tracer la fonction cible (le problème le plus courant est un état de cpu virtuel invalide).
• Lors de l'utilisation du mode de couverture hit, le traceur se comporte mal sur certaines fonctions (c'est le cas avec certaines switch tables). La raison est que chaque octet est remplacé par des points d'arrêt logiciels (y compris les données si elles sont présentes dans une page exécutable). Une meilleure façon de faire serait d'obtenir la liste de tous les blocs de base à partir d'un désassembleur par exemple.
• La fonction cible sera exécutée avec un processeur virtuel unique, vous n'avez pas de support matériel, donc il est probable que quelque chose cloche si vous tracez des fonctions liées au matériel.
• Cet outil est mieux utilisé pour cibler des fonctions spécifiques
• Pour avoir les meilleures performances, minimisez les VM exits et les pages modifiées car ils peuvent être très coûteux et augmenteront le temps nécessaire pour exécuter la fonction.
• N'utilisez pas hyper-V pour faire des snapshots. Les Windows Hyper-V sont "enlightened", ce qui signifie qu'ils utilisent la paravirtualisation, ce n'est actuellement pas géré
• Certains symboles ne sont pas résolus correctement

Licence

Cet outil est actuellement développé et sponsorisé par Quarkslab sous la licence Apache 2.0.

Salutations

Salutations à @yrp604, @0verclk0, Alexandre Gazet pour leur aide, leurs retours et leurs réflexions. Merci aussi à tous mes collègues chez Quarkslab !