peafl64

Instrumentation d'un binaire en mode utilisateur avec des NOPs

Instrumentation d'un binaire en mode noyau avec filtrage par ID de processus

Instrumentation d'un binaire en mode noyau avec filtrage par ID de thread et sortie détaillée

Comment remplacer les pilotes Windows

D'abord, vous devez vérifier si votre machine démarre avec BIOS ou UEFI.
Pour les machines Hyper-V : les machines de génération 1 utilisent le BIOS, et les machines de génération 2 utilisent l'UEFI.
Si votre machine utilise le BIOS, vous devez patcher winload.exe :

• Récupérez une copie de winload.exe depuis votre VM et trouvez-y la fonction ImgpValidateImageHash
• Patchez la valeur de retour pour qu'elle retourne toujours 0 dans rax. Par exemple, remplacez mov eax, edi par xor eax, eax dans le dernier bloc de code de la fonction
• Copiez le winload patché dans le dossier system32 et exécutez bcdedit /set path \Windows\system32\winload2.exe

Si votre machine démarre avec UEFI, utilisez l'utilitaire EfiGuard pour patcher winload.efi.
Aide-mémoire des commandes si vous utilisez le Gestionnaire Hyper-V :

1. Créez un nouveau disque dur pour la machine virtuelle
2. Utilisez le FAT.vhdx fourni dans le dossier Tools (ou créez-en un vous-même) contenant le module UefiShell+EfiGuard avec le nouveau disque dur
3. Modifiez l'ordre de démarrage de la machine pour que le nouveau disque dur soit en premier
4. Après le démarrage, dans UefiShell, exécutez les commandes suivantes :

Instrumentez ensuite le pilote de votre choix. Pour charger un pilote instrumenté sur une machine Windows, il doit être signé, et un certificat auto-signé suffit pour satisfaire aux exigences de l'OS :

Si le pilote que vous avez instrumenté est déjà utilisé par le système, utilisez ces commandes (en tant qu'administrateur) pour remplacer le fichier du pilote :

Puis exécutez :

Fuzzing avec WinAFL

L'intégration avec WinAFL se fait en compilant un harnais à l'aide des en-têtes fournis.
En plus des en-têtes, il y a example.c, un programme d'exemple qui montre comment les utiliser.
Les en-têtes fournis sont une légère modification des en-têtes déjà fournis par WinAFL pour intégrer un autre outil d'instrumentation statique de binaires appelé Syzygy.

Fuzzing avec kAFL

La manière dont nous nous intégrons avec kAFL est assez simple.
Normalement, un harnais kAFL s'exécute sur une machine virtuelle et communique avec le frontend du fuzzer via des « hypercalls » spéciaux.
Ces hypercalls indiquent au fuzzer de faire de nombreuses choses, parmi lesquelles charger les données de couverture d'IntelPT et les analyser sous forme de bitmap AFL.
Parce que peafl64 rend le traçage IntelPT obsolète, nous devons préparer une méthode pour transmettre les données de couverture au fuzzer.
Par conséquent, nous avons étendu qemu et kvm avec des « hypercalls » qui permettent au harnais (en mode utilisateur) exécuté dans une VM d'envoyer les données de couverture qu'il a collectées via le pilote auxiliaire.

Configuration ESXi

Ceci concerne spécifiquement la configuration sur ESXi, mais devrait être pertinent pour d'autres plateformes de virtualisation comme AWS.
La configuration est assez simple :

• Créez une machine Ubuntu
• Assurez-vous que « Expose hardware assisted virtualization to the guest OS » est activé dans la configuration CPU de la machine
• Clonez le dépôt sbi_kAFL
• Installez kAFL normalement comme indiqué dans le dépôt kAFL, mais au lieu de l'étape install.sh qemu, exécutez install.sh qemu_sbi

Pour fuzzer avec kAFL et peafl64, nous devons configurer une machine de fuzzing :

• Compilez le pilote auxiliaire et signez-le
• Compilez un harnais en utilisant les en-têtes fournis avec notre fork de kAFL
• Sur la VM, chargez le pilote auxiliaire
• Exécutez le loader de kAFL

À part cela, le fuzzing avec notre fork de kAFL est identique au fuzzing normal avec kAFL.

Flux d'exécution

Aperçu des étapes :

1. Déterminer les points d'insertion pour le code d'instrumentation
2. Localiser les instructions et structures qui nécessiteront des ajustements
3. Insérer le code d'instrumentation dans les fonctions demandées
4. Ajuster :
   • Les instructions relatives
   • Les tables de sauts
   • Les gestionnaires d'exceptions
   • Les en-têtes PE
   • Diverses configurations PE (load config)
5. Reconstruire le PE avec les sections instrumentées

D'abord, nous utilisons IDA pour trouver et analyser les instructions et les emplacements d'intérêt.
L'analyse crée un fichier dump.json qui contient toutes ces informations au format json.
instrument.py contient la logique d'instrumentation, et le flux lui-même est décrit dans la fonction process_pe.
Pour instrumenter le binaire, nous dupliquons ses sections exécutables, où tout le code instrumenté se trouvera.
Ensuite, nous traitons toutes les instructions relatives et déterminons comment, et si, il faut les gérer. Supposons un saut court de l'adresse X vers l'adresse Y. Nous insérons du code d'instrumentation entre X et Y, et la cible se trouve maintenant à l'adresse Z (Z = Y + len(instrumentation)).
Cela signifie que nous devons modifier le saut. Si l'adresse Z est maintenant hors de la portée des sauts courts, nous devons transformer le saut de short en far. (instrument.py:expand_relative_instructions)
Par exemple :

• short jmp 0x57 (eb 55) -> near jmp 0x604 (e9 ff 05 00 00)

C'est également le cas pour les instructions comme call, loop et les sauts conditionnels.
Un autre cas courant à gérer est celui des instructions relatives à RIP introduites en assembleur x64 :

• call [rip+0x1000]

Nous mettons à jour les éléments suivants pour pointer vers le code instrumenté : table de relocalisation, table d'exportation, configuration de chargement, répertoire TLS et enregistrements d'exceptions.
Les mises à jour sont effectuées en remplaçant toutes les adresses des sections d'origine par leurs homologues instrumentés. (instrument.py:update_addr)
Les en-têtes sont mis à jour pour refléter les modifications de la structure PE : sections ajoutées, point d'entrée modifié et taille PE. (instrument.py:update_pe_headers)

De plus, peafl64 est capable d'instrumenter le noyau Windows. Pour y parvenir, il analyse et met à jour la Dynamic Value Relocation Table (DVRT) et la SSDT, et gère les spécificités de PatchGuard.

La DVRT est une table générée par le compilateur qui décrit les emplacements des adresses qui doivent être modifiées lors du chargement du PE.
Elle est utilisée pour améliorer KASLR et aide à atténuer la vulnérabilité Spectre (1, 2, 3).
La DVRT est analysée à l'aide d'un ensemble de classes qui imitent la structure de la table (drt.py; instrument.py:get_updated_dynamic_relocs)

La gestion et la mise à jour de la SSDT n'étaient pas aussi simples.
Son adresse n'est pas exportée, nous avons donc dû nous appuyer soit sur les symboles, soit sur des heuristiques pour la localiser.
Notre solution utilise une approche heuristique, en utilisant NtWaitForSingleObject comme marqueur constant pour toutes les versions de Windows 10 et en trouvant l'adresse de la SSDT relativement à celui-ci. (instrument.py:ntoskrnl_update_KiServiceTable)
Cette approche fonctionne pour tous les noyaux Windows 10, mais devra être ajustée pour les autres versions de noyau.

TODO

• prise en charge x64
• Nouveaux gestionnaires d'exceptions (cxx4)
• Améliorer les performances du dumper IDA
• Analyser entièrement la structure LOAD_CONFIG
• Ajouter des tests
• Prendre en charge davantage de versions du noyau Windows dès le départ
• Intégrer avec Nyx (le nouveau kAFL)