[WiShMaster - partie 3] Principe de shellcodisation avec WiShMaster (2)

Par Benjamin Caillat, Mastère Spécialisé Sécurité ESIEA
Le 16/09/2006

---

Résumé : La fonction BuildReferences. L’adresse de la structure globale. Les pointeurs vers des fonctions internes et des fonctions importées. Personnalisation des shellcodes. WiShMaster en quelques screenshots. A qui s’adresse cet outil ? Conclusion intermédiaire du dossier. - Lire l'article



La fonction BuildReferences

La fonction BuildReferences a la responsabilité d’accomplir toutes les taches d’initialisation. Elle se base sur des techniques couramment utilisées dans les shellcodes.


L’adresse de la structure globale

La première étape est de récupérer l’adresse de la structure globale. Il ne faut pas oublier que notre shellcode a été injecté à une adresse totalement inconnue. Pour cela, BuildReferences utilise les quelques instructions d’assembleurs inlinées suivantes :


ULONG ulLoadAddress;

// Récupère l'adresse courante
__asm
{
call GetLoadAddress
GetLoadAddress:
pop eax
mov ulLoadAddress, eax
}


Le call a pour effet d’empiler l’adresse de retour sur la pile, qui est ensuite dépilée dans eax. Après ces quelques instructions, ulLoadAddress contiendra donc l’adresse de l’instruction « pop eax ». En lui ajoutant le nombre d’octets entre cette instruction et la structure globale dans le shellcode, nous obtenons un pointeur sur cette structure.


Les pointeurs vers les fonctions internes

Les pointeurs vers les fonctions internes sont construits de proche en proche en partant de BuildReferences et ajoutant successivement la taille de chaque fonction.


Les pointeurs vers les fonctions importées

L’initialisation des pointeurs vers les fonctions importées est beaucoup plus délicate. Pour chaque fonction, BuildReferences doit éventuellement charger la librairie partagée, puis obtenir l’adresse de la fonction.

L’utilisation de la fonction de Windows « GetProcAddress » se heurte à deux problèmes.

Tout d’abord cette fonction prend en paramètre le nom de la fonction à charger. Notre shellcode devra par conséquent contenir le nom de toutes les fonctions importées, ce qui peut représenter une perte substantielle de place surtout lorsque l’on considère que l’API Win32 regorge de noms à rallonge (WriteProcessMemory, GetExitCodeProcess, SHGetSpecialFolderPath, …).

Ensuite, comment retrouver l’adresse de la fonction GetProcAddress elle-même ?

BuildReferences utilise plutôt une succession de techniques relativement classiques : dans un premier temps, elle récupère l’adresse de chargement de la librairie kernel32.dll via le PEB (Process Environnement Block), une structure user-land de Windows utilisée pour la gestion du processus, dont l’adresse est stockée en fs :[30h].

Elle utilise alors une fonction interne « GetProcAddressCkSum » pour retrouver l’adresse de LoadLibraryA et de GetProcAddress dans kernel32.dll. « GetProcAddressCkSum » prend en paramètre l’adresse de chargement d’une librairie et une checksum sur 32 bits, calculée en appliquant un algorithme de hash sur le nom de la fonction à trouver.

Elle parcourt ensuite l’export directory de la librairie en appliquant ce même algorithme sur tous les noms de fonctions exportés et en comparant le résultat à la checksum fournie.

Enfin, pour chaque fonction importée, BuildReferences va appeler LoadLibraryA pour charger la librairie adéquate. Au lieu d’utiliser GetProcAddress en lui passant le nom de la fonction, elle va alors de nouveau utiliser « GetProcAddressCkSum » en lui fournissant la checksum calculée à partir du nom.

Ainsi le shellcode ne devra contenir qu’un DWORD par fonction importée au lieu d’une longue chaîne de caractères.

Il faut cependant noter que certaines fonctions dans les dlls sont des « forwarders », c'est-à-dire que la référence dans l’export directory ne pointe pas vers la fonction, mais vers une chaîne du type [DLL].[FUNC]. La fonction réelle doit alors être cherchée dans la librairie « DLL » sous le nom « FUNC ».

La fonction « GetProcAddressCkSum » de WiShMaster supporte ce type de structure : elle charge la nouvelle librairie et récupère l’adresse de la fonction désignée. A titre d’exemple, sous Windows XP, les fonctions HeapAlloc et HeapFree pointent respectivement vers NTDLL.RtlAllocateHeap et NTDLL.RtlFreeHeap.

A l’issue de la fonction BuildReferences, l’adresse de la structure globale a été récupérée et ses différents champs ont été initialisés. Nous disposons donc de toutes les données nécessaires pour exécuter le code réel.


L’étape « Generate »

L’étape « Generate » consiste à patcher certaines valeurs du shellcode afin de le personnaliser. Prenons par exemple le cas d’un shellcode effectuant un « reverse connect ». Celui-ci va typiquement contenir dans la structure GLOBAL_DATA l’adresse IP et le port du serveur sur lequel se connecter.

Le principe est d’initialiser ces champs dans les fichiers sources avec des valeurs canari (0xaabbccdd, …). A l’issue de l’étape « Extract », le shellcode contient donc ces valeurs spéciales. WiShMaster va ensuite les patcher par des valeurs réelles entrées par l’utilisateur lors de l’étape « Generate ».

Les données à patcher sont bien sûr très dépendantes de la structure du shellcode. L’opération « Generate » est donc accomplie dans une dll séparée qui peut être remplacée en fonction du shellcode.

Par exemple, imaginons qu’un premier développeur souhaite publier un shellcode. Il écrit le code source, génère le shellcode et créé la dll représentant l’étape « Generate » pour ce shellcode. Il met à disposition son shellcode compilé contenant les valeurs canari et la dll « Generate ».

Un second développeur peut alors remplacer la dll « Generate » de WiShMaster par celle fournie, ouvrir le shellcode dans WiShMaster et exécuter les étapes « Generate », « Xor » et « Integration ». Il peut ainsi utiliser le shellcode sans avoir accès au code source, qui reste la propriété du premier développeur.

Nous obtenons ainsi une véritable séparation entre la partie fonctionnelle (le shellcode) et l’enveloppe, le contexte d’utilisation.


A qui s’adresse cet outil ?

WiShMaster vise un public relativement large : les consultants en sécurité ayant besoin de shellcodes pour mener des tests d'intrusion, les responsables sécurité souhaitant sensibiliser les utilisateurs finaux avec des démonstrations, les chercheurs en sécurité voulant explorer des techniques comme l’injection de thread,…


WiShMaster en quelques screenshots.

WiShMaster est une application graphique développée en C#. Les différents fichiers de configuration sont générés en XML. La fenêtre principale est la suivante :






Elle est principalement constituée d’un tableau à sept lignes, chacune représentant l’une des étapes décrites précédemment. Il est également possible de visualiser les fonctions internes, importées et les chaînes de caractères détectées :






Un projet dispose d’un grand nombre d’options de configuration. Un wizard a donc été intégré, permettant de créer des squelettes de projets.


Conclusion intermédiaire

Une fois le code écrit en respectant les conventions d’écriture, la transformation en shellcode est une opération quasiment automatique et très rapide. WiShMaster est capable de shellcodiser des programmes d’une taille relativement importante.

A titre d’exemple, je l’utilise dans un de mes projets ( x90re’s backdoors ) pour shellcodiser des programmes de 20 000 lignes de code, générant des shellcodes de 40 ko. La suite du dossier sur WiShMaster illustrera ceci par un exemple concret : la shellcodisation d’une backdoor toute simple afin d’améliorer ses capacités. La shellcodisation permet d’obtenir un code manipulable et ouvre un panel très large de possibilités.

Autres ressources dans ce même dossier :

[WiShMaster - Partie 1] Introduction à l'ecriture de shellcodes en C - lien

[WiShMaster - Partie 2] Principe de shellcodisation avec WiShMaster (1) - lien

[WiShMaster - Partie 4] Principe et Fonctionnement - RConnect/WiShMaster Vs firewalls personnels (1) - lien

[WiShMaster - Partie 5] Principe et Fontionnement - RConnect/WiShMaster Vs firewalls personnels (2) - lien

[WiShMaster - Partie 6] Principe et Fonctionnement - RConnect/WiShMaster Vs firewalls personnels (3) - lien

[WiShMaster - Partie 7] Résultat de RConnect avec des firewalls personnels et conclusion - lien