gamozolabs/applepieUn hyperviseur pour le fuzzing construit avec WHVP et Bochs
Bonjour ! Bienvenue sur applepie ! C'est un outil conçu pour le fuzzing, l'introspection et la recherche de bugs ! C'est un hyperviseur utilisant l'API Windows Hypervisor Platform présente dans les versions récentes de Windows (plus précisément, cela a été développé et testé sur Windows 10 17763). Bochs est utilisé pour fournir une introspection approfondie et l'émulation de périphériques.
L'API Windows Hypervisor Platform (WHVP) est un ensemble d'API pour accéder aux capacités d'hyperviseur de Hyper-V. Cette API nous permet d'implémenter facilement une machine virtuelle entièrement en espace utilisateur sans avoir besoin de pilotes spéciaux ou d'autorisations particulières.
Ce projet se développe rapidement. Je tweeterai probablement lorsque de nouvelles fonctionnalités sortiront avant qu'elles ne soient documentées.
J'aime avoir des objets physiques pour mes projets :
C'est un outil conçu pour le fuzzing et l'introspection lors de recherches en sécurité. En utilisant un hyperviseur, les techniques courantes de fuzzing peuvent être appliquées à n'importe quelle cible, qu'elle soit noyau ou espace utilisateur. Cet environnement permet le fuzzing de systèmes entiers sans nécessiter l'accès au code source de la cible. Au niveau de l'hyperviseur, on peut collecter la couverture de code, et si nécessaire, l'émulation Bochs peut être utilisée pour fournir une introspection arbitraire dans un environnement d'émulation. Ces informations de couverture peuvent être utilisées pour déterminer l'efficacité des cas de fuzzing. Un cas de fuzzing qui provoque une augmentation de la couverture peut être sauvegardé car il s'agit d'un cas intéressant. Cette entrée peut être réutilisée ultérieurement, enrichie par de nouvelles corruptions.
Le fuzzing par snapshot est l'utilisation principale de cet outil. On prend un snapshot d'un système dans un certain état et on le sauvegarde. Ce snapshot peut ensuite être chargé pour le fuzzing, où un cas de fuzzing est injecté, puis on le reprend. Comme la machine virtuelle peut être réinitialisée très facilement, on peut la réinitialiser souvent. Si Word met 5 secondes à démarrer, mais que vous pouvez le capturer juste au moment où il lit votre fichier, vous pouvez réduire le cas de fuzzing à ce qui est pertinent pour une entrée. Cela permet une boucle de fuzzing très serrée sans avoir besoin d'accéder au code source. Comme les machines virtuelles sont totalement séparées, plusieurs peuvent être exécutées en parallèle pour passer à l'échelle sur tous les cœurs.
Actuellement, cet outil prend uniquement en charge la collecte de couverture de code, le téléchargement dynamique de symboles pour Windows et l'analyse des symboles/modules pour les cibles Windows également. Le support du fuzzing arrivera très bientôt.
Étant donné que j'ai déjà écrit presque toutes ces fonctionnalités auparavant (couverture, fuzzing, réinitialisations rapides, etc.), je m'attends à ce que ce projet devienne assez rapidement prêt pour le fuzzing, sauf si je suis distrait :D
Je vise la fin janvier pour la couverture (fait !), les retours, la liste des modules (fait !), les listes de processus, les réinitialisations rapides et le support des symboles (fait !). Cela en ferait un fuzzer très performant.
La cible principale supportée est Windows 10 moderne. Les cibles Windows permettent de télécharger des symboles depuis le store de symboles. Cela permet une couverture symbolique pour les cibles Windows dès le départ. Cependant, le code est écrit de manière à ce qu'un « enlightenment » Linux puisse être facilement ajouté.
Sans aucun « enlightenment », tout système d'exploitation qui démarre peut toujours être fuzzé et une couverture de base peut être collectée.
Avant de signaler des problèmes de support d'OS, veuillez vérifier que le problème vient de l'hyperviseur / des modifications apportées à Bochs en essayant de démarrer votre cible avec un Bochs pré-construit standard sans hyperviseur. Bochs n'est pas couramment utilisé et peut fréquemment avoir des bugs bloquants même pour des choses courantes comme le démarrage de Linux. Surtout avec les changements internes rapides concernant l'utilisation de CPUID/MSR suite aux atténuations Spectre/Meltdown intégrées dans les OS.
Consultez la page des problèmes sur Github pour une liste des problèmes. J'en ai déjà ajouté quelques-uns. Certains doivent être résolus rapidement avant de commencer le développement du fuzzing.
Pour construire ce projet, vous avez besoin de quelques éléments :
Installez Visual Studio 2017 et assurez-vous qu'il est à jour. Nous utilisons des API, en-têtes et bibliothèques de pointe.
J'utilisais la version de cl.exe : Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27025.1 for x64
Et la version du SDK 10.0.17763.0
Installez Rust via https://rustup.rs/. J'utilisais rustc 1.32.0-nightly (b3af09205 2018-12-04)
Assurez-vous d'installer la chaîne d'outils x86_64-pc-windows-msvc car seul le 64 bits est supporté pour ce projet.
Assurez-vous que cargo est dans votre PATH. Cela devrait être le cas par défaut.
Allez chercher Python https://www.python.org/ et assurez-vous qu'il est dans votre PATH afin que python puisse être invoqué.
Installez Cygwin 64 bits (https://www.cygwin.com/setup-x86_64.exe) spécifiquement dans C:\cygwin64. Lors de l'installation de Cygwin, assurez-vous d'installer les paquets autoconf et make.
Allez dans « Activer ou désactiver des fonctionnalités Windows » et cochez la case à côté de « Hyper-V » et « Windows Hypervisor Platform ». Cela nécessite bien sûr que votre ordinateur supporte Hyper-V.
Ce guide d'installation a été vérifié sur la configuration suivante :
Clean install of Windows 10, Build 17763
rustc 1.33.0-nightly (8e2063d02 2019-01-07)
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27025.1 for x64
Visual Studio Community 2017 version 15.9.4
applepie commit `f84c084feb487e2e7f31f9052a4ab0addd2c4cf9`
Python 3.7.2 x64
git version 2.20.1.windows.1
