Les shellcodes x86 sur Windows seven :

Un shellcode est un code arbitraire injecté dans la mémoire comme par exemple dans le cas d’un buffer overflow permettant de faire ce que l’on veut sur le pc de la victime, on les appelle shellcode car ce type de code est souvent utilisé pour obtenir un shell ou une invite de commande pour prendre le contrôle total du pc distant. Les shellcodes sont constitués d’une suite d’instructions assembleur et peuvent donc faire tout ce que l’on souhaite.

L’écriture de shellcodes Windows nécessite de connaître les API Windows, de savoir dans quelle dll une fonction que l’on souhaite utiliser se trouve, de charger cette dll puis d’appeler directement l’adresse de la fonction.

Il faut savoir qu’un shellcode ne doit pas contenir de null byte ou octet nul en français, c’est à dire le caractère de terminaison d’une string en C, car dans un exploit, le shellcode est placé dans un tableau de char afin d’être comme je le disais : injecté, donc si un null byte se trouve dans cette chaîne, votre shellcode ne sera pas entièrement copié dans le buffer et ne pourra donc fonctionner normalement.

Shellcode statique :

Dans un premier temps on va créer un shellcode statique c’est à dire qui ne fonctionnera plus lorsque vous aurez rebooté votre seven et ceci à cause de l’aslr (Address Space Layout Randomization) introduit sur les OS de microsoft depuis la sortie de vista. Notre shellcode sera tout simple, il affichera une MessageBox avec un titre et un message, puis quittera.

On a donc besoin de l’adresse effective de LoadLibraryA qui se trouve dans kernel32.dll pour charger user32.dll, de l’adresse effective de MessageBoxA contenue dans cette dernière et de ExitProcess qui se trouve également dans kernel32.dll, qui elle est toujours chargée.

Voici les prototypes de nos fonctions :

Pour trouver ces adresses je vais utiliser mon tool : ListExportedFunctions. Mais vous pouvez utiliser les /fonctions LoadLibrary() et GetProcAddress() pour les obtenir.

On obtient l’adresse 0x76F74BC6 pour LoadLibraryA, 0x7782FEAE pour MessageBoxA et 0x76F7734E pour ExitProcess.

En ce qui concerne les strings dont nous avons besoin pour nos fonctions, sachant que dans un shellcode on ne peut utiliser la section réservée aux données, celle nommée « .data », nous utiliserons une technique se servant des instructions jmp, call et pop, pour obtenir un pointeur vers chacune de nos strings.

Voici un exemple de cette technique :

Le registre ecx contient maintenant un pointeur vers notre string « hello world ». Mais il y a un problème : cette string crée un null byte et comme dit plus haut, un shellcode ne doit pas en contenir.
Pour y remédier, nous allons utiliser un autre registre, le mettre à 0 avec l’instruction xor, ajouter un caractère à la fin de notre string, puis écraser ce caractère par le byte de poids faible de ce dernier registre. Avec cette technique, notre string sera bien terminée par un zéro mais sans null byte.

Exemple :

Voici donc maintenant notre shellcode au complet :

Si vous essayez d’exécuter ce shellcode vous n’y arriverez pas, car il faut passer par un programme intermédiaire écrit en C que j’appellerai « shellcodetest.c », qui, chez moi est compilé avec gcc (mingw). Si vous souhaitez le compiler avec Visual Studio, il vous faudra utiliser la fonction VirtualProtect() sur la variable code.

Pour obtenir les bytes du shellcode à placer dans le buffer, vous pouvez utiliser l’outil GetShellcode. Après compilation et exécution de shellcodetest nous obtenons :

Seulement voilà, après un reboot, ce shellcode ne fonctionnera plus car l’adresse des fonctions écrites en dur ici auront changées, il nous faut donc une autre approche. Cette nouvelle approche est souvent appelée « shellcode générique » et c’est ce que nous allons voir maintenant.

Shellcode générique :

Au lieu d’utiliser un programme externe qui nous donne les adresses des fonctions que nous souhaitons utiliser, et de se contenter d’un copié/colleé de l’adresse dans le code assembleur, il nous faut les trouver directement dans le shellcode. Cette approche nécessite d’abord de connaître l’adresse de base de kernel32.dll.

Il existe plusieurs techniques pour trouver cette adresse dont une qui utilise la structure du PEB. On trouve le pointeur sur ce PEB à fs:[0x30].
Une fois dans cette structure à 0x0c, on tombe sur une autre structure nommée PEB_LDR_DATA. Dans cette dernière, à 0x1c, il y a une liste chaînée qui contient les modules chargés en mémoire.

Cette liste chaînée porte le nom de InitializationOrderModule. Sur windows XP & vista, kernel32.dll est toujours chargée en deuxième position, mais sur seven elle l’est en troisième. Une façon de rendre portable cette technique sur tous les OS de microsoft est de regarder à la fin de chaque nom de module que l’on parcourt (nom que l’on trouve à l’offset 0x20 sur chaque élément de InitializationOrderModule). Le nom de la dll/module doit faire 12 caractères (n’oublions pas que nous sommes en unicode).

Puis enfin à 0x08 sur chaque élément, on y trouve l’adresse de base du module.

Voici le code assembleur qui nous permet de trouver l’adresse de kernel32.dll :

Avec ce code, eax contient l’adresse de base de kernel32.dll. Il ne nous reste donc plus qu’à obtenir l’adresse de nos fonctions. On va refaire le même shellcode que dans l’exemple précédent, c’est à dire celui qui était statique.

On y va en deux fois :
– On trouve les adresses de LoadLibraryA et de ExitProcess qui se trouvent dans kernel32.dll
– On trouve l’adresse de MessageBoxA qui se trouve dans user32.dll.

Pour trouver l’adresse de nos fonctions, nous allons utiliser le PE format et parser les dll afin d’obtenir les adresses dans la table d’exportation. Pour en savoir plus sur le format PE, vous pouvez lire l’article Le format PE. Ce tutoriel ne suffit pas pour la suite car pour un shellcode on ne peut pas lire toutes les en-têtes, utiliser fread, fseek etc… Il nous faut donc connaître à l’avance les offsets de tout ce que l’on a besoin :

Plutôt que de comparer dans le shellcode chaque nom de fonctions listé depuis la table d’exportation d’une dll avec un nom que l’on recherche, nous allons utiliser un système de hash.

C’est à dire, au départ créer un hash pour chaque nom de fonction que l’on souhaite utiliser, puis dans le shellcode à chaque nom de fonction parcouru on générera ce hash pour le comparer avec celui que l’on recherche. Cette technique permet de diminuer la taille de notre shellcode.

Ici le code qui permet de générer le hash d’une fonction: GenerateHash.

Pour ce qui va suivre, il faut faudra un minimum de connaissances en assembleur. Nous savons donc comment trouver l’adresse de kernel32.dll, qu’il faut parcourir la table d’exportation et comment la parcourir pour trouver les adresses de nos fonctions. Quant au nom de fonction, nous savons qu’il faut utiliser un hash pour la comparaison. On a donc tout ce qu’il nous faut pour rendre notre shellcode générique.

Voici notre shellcode qui affiche la MessageBox mais de façon générique :

N’oubliez pas que pour l’essayer, il faut obtenir les bytes avec par exemple GetShellcode et utiliser shellcodetest.c

On obtient exactement pareil :

On a donc d’abord créé un shellcode qui fonctionnera uniquement sur notre pc et sans reboot, pour finir par un qui fonctionnera (normalement) en tout temps et sur n’importe quel windows.