3psilon website

Sommaire

 - Le format PE
 - La table d’importation
 - La table d’exportation
 - Chk
 - Vérification des hooks IAT
 - Vérification des patchs IAT
 - Chk Source
 - Références

---

Nous avons de nombreuses fois évoqué les rootkits kernels, évoqués RkU et ses détections, présenté la SSDT. Je vous propose de simplifier la compléxité, et de nous intéresser à la détection des corruptions des exécutables.

Cette fois-ci, pas de driver, pas de risque de BSOD, tout se réalise en userland. ( rassurant pour les tests non ? :)

La corruption des exécutables. kesako ? Simple : modifier le processus en mémoire afin de corrompre des informations. Et plus précisement modifier le format PE pour détourner des fonctions.

Nous revenons toujours à la même logique. Windows (et les autres environnements) fonctionne avec des appels système (SYSCALL), avec des librairies système qui offrent un ensemble de service aux exécutables. Ainsi, l’objectif pour un malware sera d’intercepter/modifier certaines informations.

Le format PE

(Portable Executable File Format) Ce format est un standard développé par Microsoft pour les fichiers exécutables (exe, ocx, dll, cpl). Ce format permet au système d’exploitation de pouvoir charger correctement les fichiers en mémoire avec différentes informations (fonctions utilisées et exportées, ressources, taille). Ce format est inscrit dans l’entête de ces fichiers et doit être strictement respecté. Un nombre important de documentation existe, de nos jours ce format n’est plus un mystère.

Nous pouvons trouver beaucoup d’exemple sur Internet pour corrompre ce format, mais peu d’exemple montrant les techniques de détection. Je me lance donc dans cet exercice.

Revenons un bref instant à ce format PE, deux sections vont particuliérement nous intéresser :

La table d’importation

Cette table contient les librairies et les fonctions utilisées par le fichier binaire. Elle a été construite lors de la compilation/création du programme. Cette dernière phrase est importante, car cela indique que toutes librairies et fonctions chargées dynaniquement ne seront pas incluses dans cette table. Nous appellons çca, les librairies statiques.

La table d’exportation

Cette table est généralement liée aux librairies. En effet, elle contient toutes les fonctions exportées. Ce sont des fonctions qui peuvent être appellées et utilisées par un programme tiers.

Ces tables contiennent (en autre) les adresses mémoires des fonctions. Ces adresses sont valables uniquement dans l’espace mémoire du programme, ce qui implique que tout programme aura une copie mémoire de la fonction, et plus généralement de la librairie entière.

Vous l’aurez deviné, tout ceci se déroule en mode utilisateur, aucune intervention de driver. L’unique nécessité est de posséder les droits administrateurs afin de ’se balader’ dans la mémoire des processus.

Chk

Le programme que je propose est une ébauche, néanmois il peut être amélioré. Ces techniques de détection sont également incluses dans Seem 4.50.

Chk est un programme en mode console qui permet de lancer deux types de vérification du format PE sur l’ensemble des processus actifs.

Vérification des hooks IAT

Le programme vérifie les adresses contenues dans l’IAT de chaque processus. Cela consiste à récupérer les adresses des fonctions utilisées par les processus en parcourant leur format PE, puis à charger les fonctions manuellement pour les comparer. Si une différence entre les adresses est constatée, cela peut-être considéré comme un hook.

L’interprétation des résultats est relativement simple. Winamp a chargé la librairie ’user32.dll’. L’adresse de la fonction ’DrawTextA’ contenu dans sa table d’importation n’est pas 0x77D65D61 mais 0x01A72238. Or cette dernière adresse correspond à la librairie ’gen_jumpex.dll’ et non à ’user32.dll’. Cela indique un détournement.

Concernant, ’calc.exe’, ici nous ne pouvons avoir le responsable du hook. En revanche, on constate la variante des adresses. Ici, nous avons utilisé ’ZImport’ qui est un programme externe de test réalisant ce type de hook.

Vérification des patchs IAT

Le programme vérifie les librairies chargées par les processus. Il charge manuellement ces librairies pour trouver les adresses des fonctions exportées. Ces adresses mémoires sont ensuite utilisées pour réaliser une lecture dans la mémoire des processus à partir de ces adresses précisément. Une fois cette lecture réalisée, il reste à vérifier les premiers bytes pour détecter d’éventuel détournement (JUMP, PUSH, CALL) Exemple :

Dans cet exemple, on constate que Firefox et Winamp sont corrompus.

L’interprétation utilise le même principe de raisonnement que pour les hooks de l’IAT. Néanmoins, ici les adresses dans la table d’importation sont correctes, néanmoins on constate un détournement dans les premiers bytes de la fonction. Si ce détournement pointe sur une autre librairie on peut en conclure un patch de l’IAT.

Maintenant, reste à savoir si ce détournement est malsain, car ces techniques peuvent être utilisée à juste titre. Ici ’gen_jumpex.dll’ est simplement une librairie de Winamp et ’seem.dll’ une librairie de Seem.

Chk Source

Le projet est réalisé avec Code ::Blocks et le compilateur est GCC. Les sources ne sont plus disponibles pour conserver l’intégrité de Seem sachant que c’est le démarrage d’une nouvelle section. Si les demandes en sont faites, je mettrais tout de même les sources de la détection des simples patchs.

Bonne utilisation et bonne lecture !!

Références

securiteam.com

microsoft.com

codeguru.com

smidgeonsoft.com

LordPE.com

2bytejumps.com