[WiShMaster - partie 5] Principe et Fonctionnement - RConnect/WiShMaster Vs firewalls personnels (2)

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

---

Résumé : Evaluation de la détection de RConnect shellcodisé. Le concept des firewalls personnels : XP SP2, basiques & avancés. Rappels sur le passage en mode noyau sous Windows. Les hooking user-land par patch du header et kernel-land par patch de la SSDT. L’installation des fonctions callback. - Lire l'article



Evaluation de la détection de RConnect shellcodisé

L’objectif de cette partie est de présenter les résultats d’une évaluation de la détection de RConnect shellcodisée par différents firewalls personnels couramment utilisés. Commençons par détailler un peu le fonctionnement des firewalls personnels.


Le concept des firewalls personnels

Un firewall personnel est un programme de protection qui contrôle les accès au réseau effectués par les différents éléments du système. Mis à part quelques composants du système, la notion d’élément correspond à un exécutable du système de fichiers.

Deux modes d’accès sont généralement différentiés : le mode client où l’élément essaye de se connecter sur un serveur et le mode serveur où il se place en attente de connexion. Pour chaque mode, l’accès de l’élément pourra être autorisé, interdit ou inconnu.

Le firewall dispose d’une base locale conservant les autorisations pour les différents éléments. Lorsqu’un accès a lieu, il consulte cette base et réagit en conséquence. Si l’élément effectue ce type d’accès pour la première fois (accès inconnu), le firewall personnel affiche une popup pour demander à l’utilisateur la conduite à tenir et intègre éventuellement cette réponse à la base.

De manière très schématique, il existe trois catégories de firewalls personnels :

- le FW personnel de XP SP2,
- les FW personnels basiques,
- les FW personnels avancés,


Le FW personnel de XP SP2

Le service pack 2 de Windows XP intègre un « pseudo » firewall personnel. « Pseudo » car il n’effectue aucun filtrage des flux sortants (accès en mode client) ! Il n’apporte en conséquent aucune sécurité face à des backdoors comme RConnect (même dans sa forme originelle).


Les FW personnels basiques

Les firewalls personnels « basiques » effectuent un filtrage des flux entrant et sortant.
La connexion de RConnect dans sa forme originelle déclenchera l’affichage d’une popup car l’exécutable est inconnu de la base de données du firewall.

En revanche, lors de son exécution sous forme de thread injecté dans un processus navigateur, le firewall verra un accès client du navigateur et l’autorisera. Ce type de firewall personnel peut donc être contourné en combinant la shellcodisation et l’injection de RConnect.


Les FW personnels avancés

Les firewalls personnels « avancés » effectuent également un filtrage des flux entrant et sortant, mais analysent en plus les opérations effectuées par les applications afin de détecter des comportements suspects et par exemple de bloquer les tentatives d’injection de thread.

Cette surveillance peut être mise en place via différentes techniques. Sans chercher à en dresser une liste exhaustive, cette partie expose trois techniques couramment utilisées : le hooking user-land par patch du header, le hooking kernel-land par patch de la SSDT et l’installation de fonctions callback.

Elle présentera ensuite rapidement quelques cas concrets d’implémentation dans des firewalls personnels existants pour évaluer leurs limites. Le choix de firewalls personnels présentés dans cette étude est purement illustratif. Ce document n’a pas pour objectif de procéder à une évaluation du meilleur firewall personnel.


Rappels sur le passage en mode noyau sous Windows

Pour comprendre ces techniques, revenons rapidement sur le passage en mode noyau sous Windows. Le système Windows expose un ensemble de fonctions systèmes qui sont accessibles via le vecteur d’interruption 2Eh. A partir de Windows XP, si le processeur supporte les « Fast System Call », le passage en mode noyau de fait plutôt via l’instruction « sysenter ».

La librairie « ntdll.dll » expose un jeu de fonctions équivalent, qui consistent pour la plupart en un simple wrapper effectuant les instructions nécessaires au passage en mode noyau. Par exemple, voici le désassemblage de la fonction ZwCreateProcess dans ntdll.dll sur un Windows XP professionnel :


7C91D7D2 B8 35000000 MOV EAX,35
7C91D7D7 BA 0003FE7F MOV EDX,7FFE0300
7C91D7DC FF12 CALL DWORD PTR DS:[EDX]
7C91D7DE C2 2000 RETN 20


Avec :


7FFE0300 8B EB 91 7C 94 EB 91 7C 00 00 00 00 00 00 00 00 ‹ë‘|”ë‘|........
Et :
7C91EB8B 8BD4 MOV EDX,ESP
7C91EB8D 0F34 SYSENTER


L’API native n’est cependant pas officiellement documentée et les applications ne doivent pas l’utiliser directement afin de garantir une portabilité maximale sur les différentes versions de Windows.

Par exemple, les programmes s’exécutant dans le sous-système Win32 doivent s’appuyer sur l’API Win32, exposée notamment dans les célèbres dll kernel32.dll, user32.dll et gdi32.dll. L’API Win32 repose bien sûr en interne sur l’API native.

Par exemple la fonction CreateRemoteThread exposée par kernel32.dll appelle NtCreateThread en interne :


7C8104E1 56 PUSH ESI
7C8104E2 50 PUSH EAX
7C8104E3 68 FF031F00 PUSH 1F03FF
7C8104E8 8D85 50FCFFFF LEA EAX,DWORD PTR SS:[EBP-3B0]
7C8104EE 50 PUSH EAX
7C8104EF FF15 4414807C CALL DWORD PTR DS:[<&ntdll.NtCreateThread>]


Au niveau du noyau, l’exécution est systématiquement transférée à la fonction « KiSystemService » lors d’un passage en mode noyau par l’instruction « int 2eh » et à la fonction « KiFastCallEntry » lors de l’utilisation des « Fast System Call ».

Ces fonctions ont un code relativement proche ; elles utilisent la valeur stockée dans eax comme index dans une table appelée SSDT pour récupérer l’adresse de la fonction réelle.

Il faut noter que cette description est très épurée et que le mécanisme complet fait intervenir des structures beaucoup plus complexes. Analysons tout cela sur notre système. La table d’adresses SSDT est située en 0x804e26a8. Nous récupérons l’adresse contenue dans la 53ème case (53 == 35h).


kd> dd 804e26a8+35h*4
804e277c 8057b1c5 8059a849 805a4acf 8059ed5c
804e278c 80659019 80659173 8056559e 8058935c


Cette adresse correspond bien à la fonction NtCreateThread


kd> u 8057b1c5
nt!NtCreateThread:
8057b1c5 6a28 push 0x28
...


Le schéma suivant résume le flot d’exécution (simplifié) suivi lorsqu’une application Win32 appelle la fonction CreateThread de kernel32.dll.






Le hooking user-land par patch du header

Le hooking user-land par patch du header consiste à détourner le flot d’exécution au niveau de l’espace mémoire user-land, en patchant l’entête des fonctions à surveiller avec un saut vers le code d’analyse.

Prenons l’exemple du firewall personnel Kerio (de Sunbelt Software) qui implémente cette technique. La fonction CreateRemoteThread commence dans la libraire kernel32.dll par les instructions suivantes :


.text:7C81042C push 410h
.text:7C810431 push 7C810608
.text:7C810436 call 7C8024C6


Analysons maintenant le début de cette fonction dans l’espace mémoire d’un processus. Les extraits suivants ont été générés en analysant la mémoire d’une application personnelle développée pour l’occasion.


7C81042C > $-E9 BF009283 JMP 001304F0
7C810431 . 68 0806817C PUSH kernel32.7C810608
7C810436 . E8 8B20FFFF CALL kernel32.7C8024C6
7C81043B . A1 CC36887C MOV EAX,DWORD PTR DS:[7C8836CC]


La fonction commence par un jump à l’adresse 0x1304F0


001304F0 B8 61000000 MOV EAX,61
001304F5 68 09FFFFFF PUSH -0F7
001304FA 8D5424 00 LEA EDX,DWORD PTR SS:[ESP]
001304FE CD 2E INT 2E
00130500 83C4 04 ADD ESP,4
00130503 85C0 TEST EAX,EAX
00130505 74 06 JE SHORT 0013050D
00130507 C1E8 16 SHR EAX,16
0013050A C2 1C00 RETN 1C
0013050D 68 10040000 PUSH 410
00130512 -E9 1AFF6D7C JMP kernel32.7C810431


Kerio a donc patché « à la volée » l’entête de la fonction CreateRemoteThread avec un saut vers un code d’analyse, qui transfert l’exécution au service 0x61 du noyau. Le code retour est ensuite analysé.

S’il est égal à zéro, l’exécution saute en 0x13050D où nous retrouvons le « PUSH 410 » qui a été écrasé par le « jump », puis elle revient dans la fonction CreateRemoteThread, juste après le « jump ».

Sinon, nous retournons directement à l’appelant sans exécuter la fonction. En résumé, sans hooking, le flot d’exécution est le suivant :






Après le hooking, il devient :






La véritable vérification est effectuée dans le noyau. En analysant rapidement la mémoire du noyau, nous constatons que la protection consiste – entre autres – à vérifier que l’adresse de retour appartient bien à un module chargé (l’exécutable lui-même ou une dll).

En effet, lors d’une injection de thread, le code injecté réside dans un des tas du processus et non dans un espace correspondant à un module chargé. Cette protection permet donc typiquement d’empêcher l’appel de certaines fonctions critiques à partir d’un espace mémoire alloué manuellement.


Le hooking kernel-land par patch de la SSDT

Le hooking kernel-land par patch de la SSDT consiste à modifier certains pointeurs de la SSDT pour exécuter le code d’analyse lors de l’appel du service. Le schéma suivant résume le nouveau flot d’exécution après la modification de l’entrée 0x35 de la table.






L’installation de fonctions callback

Windows offre la possibilité d’installer des fonctions callback qui seront appelées lors de l’exécution de certains événements. A titre d’exemple, certains firewalls personnels utilisent le service PsSetLoadImageNotifyRoutine du noyau pour enregistrer une fonction callback qui sera appelée lors de la création d’un nouveau processus.

Cette fonction affiche alors (par l’intermédiaire d’un processus utilisateur) une fenêtre de confirmation à l’utilisateur.

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 3] Principe de shellcodisation avec WiShMaster (2) - lien

[WiShMaster - Partie 4] Principe et Fonctionnement - RConnect/WiShMaster Vs firewalls personnels (1) - 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