Pérégrination d'un wanabee-hacker

INT 0x2E a la trick

2009-10-22T17:01:00.033+02:00

Je m'excuse de la présentation hasardeuse de ce post (notamment la page vide), blogger c'est de la bouse.

Afin de prouver au monde entier que je ne suis pas complètement mort, je me permet de mettre ici une petite analyse d'un trick anti-unpacker qui n'a pas reçu l'attention qu'il mérite à mon humble avis. Il n'est pas compliqué et pas très méchant mais il peut casser los boulos quand on le découvre.

En effet, il n'est pas présent dans la Holy Bible de l'unpacking de notre ami Peter et à ma connaissance la seule référence dans la littérature se trouve dans les slides d'une présentation faite récemment lors de la dernière conférence VB par Kurt Baumgartner. Mais cette analyse, qui décrit le trick comme "Int 0x2e 0xc0000005 location generation trick" est un peu trop rapide, donc j'en profite pour réveiller mon blog.

Comme tu l'a déjà deviné cher lecteur, ce trick utilise l'interruption 0x2E qui permettait de lancer dans « l’ancien temps » les appels systèmes Windows : on plaçait le numéro de l’appel dans le registre EAX, ses arguments dans EDX et hop ! Depuis, l’instruction SYSENTER à remplacé ce bouzin, car plus rapide. Mais bien sur INT 0x2E traine toujours sa ganache dans le coin pour des questions de compatibilité. Finalement, l'instruction n'est pas documentée par Microsoft, ce qui impose une approche "black box" si, comme moi, on est faignant et peu porté dans l'architecture Windows.

I- Utilisation "basique"

Le trick utilisé de la façon la plus simple possible donne :

B8 FFFFFFFF____MOV EAX,-1
CD 2E__________INT 2E
66:817A FE CD2_CMP WORD PTR DS:[EDX-2],2ECD

On appelle donc l’interruption avec comme numéro de syscall "-1" (ce qui est invalide).

Le comportement « normal » dans ce cas là est de faire échouer le syscall en plaçant un code d’erreur dans EAX (0xC000001C) et en faisant pointer EDX vers l’instruction suivant l'interruption. Donc dans notre exemple, EDX-2 pointe sur le début de l'instruction INT 2E dont les opcodes sont bien 2ECD en little-endian.

Par contre sous contrôle d’OllyDbg (v1 ou v2), le registre EDX va être mis à 0xFFFFFFFF si on passe l’interruption en « single-step ». Dans ce cas là un accès mémoire invalide sera réalisé lors de la comparaison, ce qui fera planter le programme.

Remarquons que ce trick devient aussi « anti-VM » dans le cas de VirtualBox de Sun (EDIT: Voir commentaires), puisque même sans être sous le contrôle du débuggeur le registre EDX est mis à 0xFFFFFFFF à tous les coups, sûrement une mauvaise implémentation des interruptions... Une raison de plus (avec la non-implémentation des hardwares breakpoints lorsqu’on n’utilise pas les techniques de virtualization matérielle) pour rester sur VMWare pour l’analyse de malwares.

Finalement, il est utile contre tout émulateur qui n'implémentent pas les interruption de façon rigoureuse.

II- Utilisation "avancée"

Ce qui n'est pas dit dans la littérature et qui est déjà connu des méchants (par exemple ceux qui font le packer de Waledac), c'est que :

d'une part, en plaçant autre chose dans EAX que "-1" la valeur de retour va varier et donner divers code d'erreur, tout ceci de façon "stable" (on nike pas tout dude). Pour vérifier cela on se fait un petit programme qui appelle l'interruption sur divers paramètres, voici les premières valeurs qu'on obtient :

INT 2E return values
Parameter	Return value
0xFFFFFFFF	0xC000001C
0x0-0x1	0xC0000005
0x2	0xC000005C
0x3	0xC0000005
0x4-0x8	0xC000000D
0x9	0xC0000002
0xA-0xC	0xC0000005
0xD	0xC0000008
0xE-0x10	0xC0000005
0x11	0xC00000F1
0x12	0xC0000141
...	...

Il y a donc certaines valeurs particulières, ce qui fait un levier de plus pour détecter un émulateur|débuggeur|VM-pourrie-de-chez-Sun.

d'autre part, ECX doit normalement toujours être positionné sur ESP après la levée de l'interruption.

Tout ca peut donner lieu à des utilisations plus rigolote du trick, comme celle-ci vu récemment dans mon malware préféré :

Le code démarre sur ça :

68 CD2EEB08___PUSH 8EB2ECD________________; INT 2E camouflé
58____________POP EAX
2D C42EEB08___SUB EAX,8EB2EC4_____________; EAX = 9
EB F4_________JMP SHORT Waledac_.00401153 ; JMP sur le INT 2E

Donc on saute sur le INT 2E camouflé au milieu du premier PUSH, ce qui donne à ce moment là le code suivant (les commentaires donnent les valeurs "attendues") :

CD 2E_______INT 2E
EB 08_______JMP SHORT Waledac_.0040115F
58__________POP EAX
2D C42EEB08_SUB EAX,8EB2EC4
EB F4_______JMP SHORT Waledac_.00401153
52__________PUSH EDX____________________; adresse qui suit INT2E (0x401155)
91__________XCHG EAX,ECX________________; EAX=ESP, ECX=0xC0000002
0FC9________BSWAP ECX___________________; ECX=0x020000C0
C1E1 04_____SHL ECX,4___________________; ECX=0x20000C00
8B00________MOV EAX,DWORD PTR DS:[EAX]__; adresse de retour initiale
2B4424 04___SUB EAX,DWORD PTR SS:[ESP+4]; EAX = 0
03C8________ADD ECX,EAX_________________; ECX=0x20000C00
81E9 FAE5FF_SUB ECX,1FFFE5FA____________; ECX=0x00002606
03CA________ADD ECX,EDX_________________; ECX = 0x401155 + 0x00002606 = 0x40375B
870C24______XCHG DWORD PTR SS:[ESP],ECX
FF1424______CALL DWORD PTR SS:[ESP]_____; CALL 0x40375B -> HERE WE GO 3v1L!

On voit dans ce petit exemple comment sont utilisés les trois leviers possibles de ce trick :

la valeur de retour qui doit être le code d'erreur associé à l'appel système (comme on passe pas d'arguments dans EDX, y a peu de risque que l'appel système fonctionne).
l'adresse mise dans EDX qui doit normalement être celle de l'instruction qui suit la levée de l'interruption.
ECX doit être égal à ESP après la levée de l'interruption.

En jouant avec les valeurs de retours on peut faire beaucoup de tricks différents pour tester l'implémentation de cette interruption, that's not so bad.

Bon allez je retourne dans ma grotte!

Oupsx...

2009-02-16T23:30:00.004+01:00

Cette semaine j'ai mis le nez dans le code de UPX 3.03, un packer connu pour être très facile à unpacker (ce qui se comprend puisque ce n'est pas pour ça qu'il a été conçu). Mais comme pour FSG, mon but n'était pas de faire de l'unpacking mais plutôt de comprendre comment le loader (le "stub" dans la terminologie UPX) fonctionne et réalise son unpacking. Ces stubs sont programmés en ASM et les commentaires sont plutôt laconiques, donc ça vaut le coup de sortir son débuggeur préféré pour comprendre à la main :-)

Ca ma permit de découvrir une "feature" assez marrante @Microsoft : quand on compile avec Visual Studio C++ un programme qui fait des opérations flottantes, le programme va vérifier dans le header PE que les sections de la mémoire qui ne doivent pas être "écrivables" (typiquement .text et .rdata) le sont bien. Sinon il déclenche un joli message "R6002: floating point not loaded error" et votre programme plante lamentablement. Le "side-effect" c'est que quand un packer lambda (comme FSG) décompresse son exécutable dans une zone mémoire (donc avec les droits d'écritures) il laisse les droits et donc le programme plante.
UPX résoud le problème en changeant les droits juste avant de jumper sur l'OEP mais ça implique un appel à VirtualProtect() pour pouvoir modifier le PE header (+ 1 pour remettre les anciens droits) et d'écrire dans la mémoire, donc une perte de temps.
Voir le post de kpnc sur le sujet.

Ayant une expérience très restreinte je ne sais pas comment les autres packers s'en sortent. Do you have any idea ?

Sur ce, voici le bouzin.

De retour...

2009-02-09T03:50:00.004+01:00

Pour te jouer un mauvais tour

Je suis toujours vivant, et j'espère avoir de nouveau le temps d'alimenter ce blog :-)

Ces temps-ci je travaille sur les packers et j'essaye de décortiquer leur fonctionnement avec plus ou moins de succès... J'ai commencé petit, donc par les packers les plus simples qui ne font que de la compression. Tout ça pour dire que j'écris des petites keynotes me permettant de me rapeller facilement ce que j'ai compris, il ne s'agit pas du tout d'un travail pédagogique (en gros c'est incompréhensible) mais sait-on jamais, ça peut peut-être dépanner quelqu'un :-)

La première est sur FSG 2.0, un packer très simple dont j'ai étudié le loader sans m'occuper de l'aspect compression qui a déjà été très bien expliqué par Beatrix.

Tu la trouvera ici.

J'ai aussi rajouté mon mail dans la colonne de droite, histoire que si tu est timide et que tu as vu des bourdes dans mon bouzin tu puisses m'insulter.

Holidays, sometimes holidays...

2008-08-13T10:59:00.002+02:00

Genre tu laches ton PaiCai ?!

Bon en fait pas vraiment, mais (pour une fois) je vais raconter ma vie : je pars au Canada dans 7 jours pour une année : ca va être hallluucccccinant ! Mais le temps que je m'installe, que je règle tous les problèmes qui vont très certainement arriver... Bref, avant que je puisse rebosser tranquillement sur mes petits projets, un bon mois va se passer. Donc l'activité de ce bl0g sera réduite.

Pour pas te laisser sur ta faim cher lecteur, je te livre quand même un petit source, il s'agit d'un dumper d'IAT, tu lui donnes le PID de ton process cible et il va t'afficher l'Import Address Table du module exécutable du process. Rien de c00l, mais ça peut facilement se modifier pour faire du hook d'IAT. Sinon, je commence à me lancer sur des outils un peu plus complexes, et j'essaye de me diversifier en étudiant quelques applis par ci par là, so see you soon ;)

Cachez ce module que je ne saurai voir...

2008-08-06T15:00:00.000+02:00

Putin qu'est ce qu'il fait chaud...

L'affichage des modules chargés par un processus ( les DLLs kwa !) de façon fiable est un problème qui se pose rapidement quand on commence à foutre le dawa dans la mémoire.

Il y a deux méthodes fort connues basées sur des fonctions documentées par Microsoft...

1- Cheese !

La première façon c'est d'utiliser CreateToolhelp32Snapshot() avec TH32CS_SNAPMODULE en premier argument, ça nous retourne un HANDLE sur un snapshot ( une "image" à un instant t de la mémoire, dans notre cas des modules ) et il suffit de se promener à partir de ce HANDLE avec la fonction Module32Next() pour récupérer une structure MODULEENTRY32 qui donne le nom de chaque module, son adresse de base, son chemin...

Le code source du bouzin est ici, j'ai aussi utilisé cette API pour lister les threads d'un process ( même méthode sauf qu'on parcourt des THREADENTRY32 ce coup ci).

2- EnumProcessModules()

La deuxième f0cking way de lister les modules c'est d'utiliser une fonction qui porte bien son nom : EnumProcessModules()... Ca nous remplit un tableau avec des HANDLEs sur tous les modules chargés en mémoire pour un processus donné, ensuite on récupère les infos intéressantes avec les fonctions GetModuleBaseName(), GetModuleFileNameEx() et GetModuleInformation().

Le code source du bouzin est là, rien de bien particulier à dire.

3- Euh oué... et alors ?

Là cher lecteur t'a envie de me dire "Chapi chapo jojo, t'a réussi à utiliser des fonctions documentés pour faire exactement la même chose de deux manières différentes, putin tu roxsamere". Oui mais c'est là que ça devient intéressant...

Si on s'interesse à la structure du Process Executiv Block (celle qui "décrit" un processus en user-land), son troisième champ est :

PEB_LDR_DATA * LdrData;

Et la structure PEB_LDR_DATA contient (entre autre) :

...
LIST_ENTRY InLoadOrderModuleList;
LIST_ENTRY InMemoryOrderModuleList;
LIST_ENTRY InInitializationOrderModuleList;
...

C'est à dire le point de départ vers trois listes doublement chainées ( la structure LIST_ENTRY n'est constituée que deux pointeurs, l'un vers "l'avant", l'autre vers "l'arrière" ) qui vont liées entre elles des structures LDR_DATA_ENTRY décrivant les modules chargées en mémoire dans trois ordres différents...

Cette structure contient la suite du chainage dans ses trois premiers champs :

LIST_ENTRY InLoadOrderModuleList;
LIST_ENTRY InMemoryOrderModuleList;
LIST_ENTRY InInitializationOrderModuleList;

Tout ceci est décrit très brièvement, car même si ce n'est pas documenté officiellement tu trouvera facilement toutes les infos sur ces structures dans l'internet multimédia ( par exemple dans le post de lilxam sur nibbles ).

Ce qui est intéressant c'est que tout ça c'est dans l'user-land, alors bien sûr la première idée qui up dans ton mind c'est de modifier ces listes chainées, pour "cacher" ton module favoris dans un processus cible.

Et tu as raison, car c'est facile à faire :

On trouve l'adresse du PEB du processus cible en créant un thread distant sur la routine RtlGetCurrentPeb() et on récupère sa valeur de retour (l'adresse du PEB) avec un GetExitCodeThread().

On trouve ensuite l'adresse du premier module dans le champ LdrData, puis on démarre un parcours sur les LDR_DATA_ENTRY, quand on trouve le module qui nous intéresse, on l'enlève du chainage. Pour cela, c'est simplement de l'unlinkage dans une liste doublement chainée : on fait pointer le "pointeur avant" (Flink) du module précédent vers le module suivant, et le "pointeur arrière" (Blink) du module suivant vers le module précédent ( tu me suis ?). Par exemple, pour la InLoadOrderModuleList, ça donne :

/* Modifie Flink du module précédent (=Blink du module courant) pour le faire pointer sur le module suivant (=Flink du module courant) */
WriteProcessMemory(targetProcess,
module.InLoadOrderModuleList.Blink,
&module.InLoadOrderModuleList.Flink,
4,
NULL);

/* Modifie Blink du module suivant (=Flink du module courant + 4) pour le faire pointer sur le module précédent (=Blink du module courant) */
WriteProcessMemory(targetProcess,
module.InLoadOrderModuleList.Flink+4,
&module.InLoadOrderModuleList.Blink,
4,
NULL);

Faut pas oublier qu'on est dans un process distant, donc un autre espace mémoire, d'où le WriteProcesMemory(). Et là où ca pwne, c'est que si après cet unlinkage je lance mon premier programme de listings ( celui avec CreateToolhelp32Snapshot()), mon module n'apparait plus !!

Par contre, le EnumProcessModules() fonctionne toujours.. si on était un peu naïf on pourrait se dire que cette API utilise une façon "sûre" de lister les modules avec des techniques de jedi inside the kernel, et là on commence à s'exciter sur une way de la bypasser...

...Et puis on se rapelle qu'il y a deux autres listes doublement chainées sur les modules : InMemoryOrderModuleList et InInitializationOrderModuleList. Alors on fait le même unlinkage et on s'aperçoit que EnumProcessModules() utilise la InMemoryOrderModuleList, et qu'il est donc aussi facilement pwnable...

Ca nous donne un "cacheur" de modules que vous trouverez ici, vous lui filez un PID et un nom de module ( du type ntdll.dll kwa ) et il n'apparaitra plus lorsqu'on utilise les APIs sus-nommées.

C'est bien sûr pas la technique du siècle, il suffit de checker le dump mémoire pour voir les modules mais ce qui est rigolo c'est que par exemple ProcessExplorer utilise ces APIs pour lister les modules d'un process et donc on le pwn sans aucun souci, ça invite à être prudent sur les infos fournies par ce genre d'outils :-)

Je sais que tu m'observes.

2008-08-04T14:00:00.005+02:00

Et kéketufais toi ?

Toujours dans mes histoires de debuggeur, j'ai tenté d'améliorer la "non-intrusivité" du code que j'avais présenté dans ce post. Je me suis donc intéressé aux diverses techniques qui permettent à un processus de détecter qu'il est sous la surveillance d'un débuggeur, c'est classique mais ça mange pas de pain au nutella de le faire.

Pour cela, j'ai fait un développement en parallèle : à ma gauche... venu tout droit de sa contrée lointaine de l'user-land... le programme dontTryToDebugMe qui va faire appel à différentes techniques ninja pour checker la présence d'un débuggeur, et à ma droite... le JoE d3bugg3ur qui va tenter l'entourloupe de débugger son adversaire sans se faire repérer. La tension est à son comble, la foule est en délire... Avant de débuter ce qui sera sûrement un très grand match, rappelons que la principale contrainte est que je reste en user-land et que j'implémente les checks de la présence d'un débuggeur comme de simples appels de fonctions, c'est pas forcément très réaliste (pour certains d'entre eux) mais ça permet de se faire une bonne idée de leur fonctionnement.

1-PEB!IsDebugged et kernel32!IsDebuggerPresent

La première vérification de la présence d'un débuggeur peut se faire dans la structure Process Executive Block ( accessible en user-land et décrivant le process ). Si on la dump on trouve au troisième octet un champ nommé "IsDebugged" et qui (sans surprise) sera mis à 1 par le système si le process est débuggé ( y compris quand c'est par DebugActiveProcess() ). De plus, la fonction IsDebuggerPresent() va lire directement ce champ. Donc notre programme dontTryToDebugMe va faire un appel à la fonction sus-nommée et aussi checker directement la valeur de ce champ en récupérant l'adresse du PEB avec l'API RtlGetCurrentPeb() (histoire d'éviter les hooks sur IsDebuggerPresent()).
Ce double-check on the byte ne pose aucune problème a être éviter, il suffit bien entendu d'aller modifier en dur le champ avant que la cible n'ait pu le checker ( ce qui se fait sans souci, j'y reviens de suite ).

2- PEB!NtGlobalFlags and Heap Flags

La deuxième protection se trouve également en partie dans le Process Executiv Block. Elle se site au niveau du champ NtGlobalFlags qui va contenir des valeurs indiquant au programme comment gérer son tas ( cette gestion étant différente suivant que le process est débuggé ou non ). Après quelques tests, on se convainc assez facilement que ce champ prend la valeur 0x70 si le process est sous le contrôle d'un débuggeur. Il suffit alors de checker la valeur de ce champ, mais encore une fois le débuggeur n'a qu'a modifier la valeur pour y mettre 0x0 ( valeur de base ) avant que sa cible n'ait pu vérifier le champ.

Mais modifier en dur le PEB ne suffit pas en ce qui concerne le tas qui possède un comportement vraiment différent suivant que le process a été créé en mode debug ou non ( flags dans la structure de management du tas qui permettent aussi de checker le débuggage, taille des chunks différente..). Bref comme dirait l'ami zantrop "c'est le bowdel", et y a une solution qui permet de tout résoudre d'un coup : ne pas créer le process en mode debug et utiliser le mode non intrusif ( la boucle infinie à la place de l'EP et tout le bouzin, je te renvoie à ce post ), ce qui nous permet de bypasser tous les checks sur le tas !

Ca a aussi comme avantage qu'on maitrise le moment où notre cible commence à exécuter son code ( puisqu'on on le fait boucler sur son EP ) et donc on peut tranquillement modifier les champs du PEB avant de le laisser le process cible continuer et faire ses vérifications.

3- ntdll!NtQueryInformationProcess et kernel32!CheckRemoteDebuggerPresent

Plus profondément cachée, la fonction NtQueryInformationProcess() permet de récupérer tout un tas d'infos sur un processus. C'est un simple wrapper vers ZwQueryInformationProcess() qui débouche sur un appel système. Son prototype est :

NTSTATUS WINAPI NtQueryInformationProcess(
__in       HANDLE ProcessHandle,
__in       PROCESSINFOCLASS ProcessInformationClass,
__out      PVOID ProcessInformation,
__in       ULONG ProcessInformationLength,
__out_opt  PULONG ReturnLength
);

En fixant la valeur de l'argument ProcessInformationClass, on indique quels types d'info on veut regarder. Ces informations "résultantes" seront placés dans le buffer pointé par ProcessInformation (3eme argument). Ce qui nous intéresse c'est que en mettant 7 en ProcessInformationClass, la fonction nous retourne "a DWORD_PTR value that is the port number of the debugger for the process. A nonzero value indicates that the process is being run under the control of a ring 3 debugger." C'est easy donc, il suffit pour dontTryToDebugMe d'appeler cette fonction et de checker la nullité de ProcessInformation :-D
Pour l'appel, la doc nous indique comment faire : "This function has no associated import library. You must use the LoadLibrary and GetProcAddress functions to dynamically link to Ntdll.dll."

Maintenant pour notre debuggeur user-land il faut réagir, la fonction étant appelé directement par son addresse, je ne vois qu'une seule manière de ne pas se faire repérer : il faut la hooker "in-line", c'est à dire modifier directement son code.

Notre objectif est simple : dans le cas où cette fonction est appelé avec 7 en ProcessInformationClass, on doit mettre 0 dans le ProcessInformation pour ne pas être repéré. De plus, comme la fonction NtQueryInformationProcess() est souvent appelée pour tout un tas de trucs (c'est précis comme description, hein ?), on doit modifier son résultat seulement dans le cas qui nous intéresse et la laisser s'exécuter normalement dans les autres, sinon on va foutre un bon gros bordel.

Donc pour le hook, je vais mettre en place à l'adresse de NtQueryInformationProcess() un jump vers un shellcode que j'aurai placé en mémoire qui me permettra de gérer tranquillement la fonction. Pour celà je regarde d'abord la geule du code au début de cette fameuse fonction (en fait ZwQueryInformationProcess(), mais on va les confondre :-) :

MOV EAX,9A
MOV EDX,7FFE0300
CALL DWORD PTR DS:[EDX]
RETN 14

Il s'agit d'un classique appel système, donc c'est là que je dois intervenir et mettre mon JMP vers un shellcode qui va tout pwned. Mon loader que je vais mettre à cet endroit aura la tête suivante :

MOV EAX,0xFAFAFEFE
JMP EAX

Où 0xFAFAFEFE est l'adresse où se trouve le shellcode et qui sera patché au moment de l'exécution.
Ce loader va ainsi écraser les deux premières instructions de NtQueryInformationProcess() en laissant trois opcodes inutilisés (rappelle toi en pour la suite cher lecteur), il me faudra donc les rétablir dans les cas où je veux laisser la fonction s'exécuter normalement.

Maintenant intéressons nous au shellcode, gardons à l'esprit que viennent d'être mis en place dans la pile les arguments de NtQueryInformationProcess():

//Est ce que ProcessInformationClass == 7 ?
CMP DWORD PTR SS:[ESP+8],7

// Si c'est pas le cas, on ne dois pas intervenir
JNZ SHORT Normal

// Time to hook !
MOV EAX,0 // on met en place la valeur de retour
MOV EDX,DWORD PTR SS:[ESP+C]
MOV DWORD PTR SS:[EDX],0 // on met 0 dans la valeur résultat => check pwned !
CMP DWORD PTR DS:[ESP+14],0 // on teste si ReturnLength est NULL
JE SHORT FinDuHook // si c'est le cas, on n'a pas à la modifier
MOV EDX,DWORD PTR SS:[ESP+14]
MOV DWORD PTR SS:[EDX],4 // on met 4 dans ReturnLength

FinDuHook:
RETN 14

Normal: // ici on doit rediriger vers le flux normal d'exécution
MOV EAX,9A // rétablissement des deux premières instructions que le
MOV EDX,7FFE0300 // loader a écrasé
PUSH EBX // sauvegarde de EBX qui sera utilisé pour le JMP suivant
MOV EBX,NTDLL.7C91D7E9
JMP EBX // reprendre le cours normal de la fonction ( appel système )

Quelques remarques :

1- D'après la doc "The function returns an NTSTATUS success or error code." et on se convainc assez facilement que 0 est le code de succès, donc à mettre dans EAX :-)

2- Dans le cas du hook, il ne faut pas oublier de positionner ReturnLength (5ème argument c'est à dire ESP+14) à 4 car d'après la doc, c'est "A pointer to a variable in which the function returns the size of the requested information." et donc, même si il est optionnel, on pourrait imaginer que dontTryToDebugMe l'utilise et teste la valeur retournée pour voir qu'elle n'est pas nulle (dans le cas d'un test de debug on retourne un DWORD_PTR donc c'est 4 bytes ). D'ailleurs c'est ce qu'il fait le petit salopio.

3- Dans le cas où on ne veut rediriger vers le flux normal d'exécution, y a pas de mystères, on exécute les deux instructions que le loader a écrasé et on saute sur l'adresse hardcodé qui était l'instruction suivante ( que j'apellerai instruction Y pour la suite de ce merdier ). En fait, comme pour ce JMP j'utilise EBX, je vais d'abord le sauvegarder sur la pile et je vais mettre juste avant l'instruction Y un POP EBX pour rétablir la valeur de ce registre et m'éviter de faire foirer le programme qui s'attend à trouver une "certaine" valeur dedans :-) Et tout ça tombe très bien puisque j'avais de la place à la fin de mon loader ( 3 opcodes précisément, rapelle toi ! ). Bon bien sûr c'est pas beau caca d'avoir hardcodé cette adresse, on pourrait tout à fait la patcher à l'éxecution puisqu'elle est située à distance fixe du début de NtQueryInformationProcess(). Mais j'avais la flemme, donc c'est l'adresse "kivabien" pour XP SP3.

Là où c'est tout bon c'est que en hookant cette fonction, on pwne aussi CheckRemoteDebuggerPresent() qui l'utilise :-)

4- La MSDN c'est plus fort que toi...

Si on s'intéresse un peu à la doc sur les exceptions dans la MSDN, on trouve la fonction suivante :

BOOL CheckForDebugger()
{
__try
{
DebugBreak();
}
__except(GetExceptionCode() == EXCEPTION_BREAKPOINT ?
     EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH)
{
// No debugger is attached, so return FALSE
// and continue.
return FALSE;
}
return TRUE;
}

Rien de bien folichon, on déclenche une breakpoint exception dans le process appelant ( donc dontTryToDebugMe dans notre cas ), et on regarde si effectivement cette exception s'est produite ( par l'appel à GetExceptionCode() ), si ce n'est pas le cas ça veut dire qu'elle a été "catché" par un débuggeur. Pour bypasser ça, il suffit de faire en sorte que le débuggeur ne gère pas la breakpoint exception et la laisse arriver jusqu'au process debuggé, cela se règle dans la fonction ContinueDebugEvent() en mettant le troisième argument à DBG_EXCEPTION_NOT_HANDLED, ce qui laisse le programme responsable de l'exception la traiter ( et la détecter :-).
En pratique ça veut dire que toutes les breakpoints exceptions doivent pouvoir être gérés par le programme cible, ce qui posera sans doute des problèmes quand il s'agit d'exceptions "non-naturelles" (mises en place par le débuggeur), mais dans mon cas, mon but étant plutôt de tracer le comportement du programme de façon furtive ça n'a pas de conséquences.

5- debug me !

Pour l'instant le JoE d3bugg3r s'en sort bien, tous les checks d'avant sont assez facilement bypassables... C'est maintenant que les choses se compliquent :-)

Un autre trick consiste à se débugger soit même : on créé un nouveau processus et on lui fait appeler DebugActiveProcess() sur son processus parent, dans le cas où il on a déjà un débuggeur sur le dos, l'appel de cette fonction va échouer et hop, débuggeur spooted !

En pratique j'ai implémenté ça dans dontTryToDebugMe par une création d'un process "classique" ( = notepad.exe, pour être le plus "portable" possible ) dans lequel je vais créer un thread distant. Mais on ne peut pas juste lui faire exécuter DebugActiveProcess() car on va prendre dans la geule le comportement par défaut de cette fonction qui est "Exiting the debugger also exits the process unless you use the DebugSetProcessKillOnExit() function." c'est à dire que lorsque notre thread distant va terminer, il va tuer dontTryToDebugMe...
Donc il faut travailler un peu plus et se faire un petit shellcode qui va nous faire l'appel à DebugSetProcessKillOnExit() pour changer le comportement par défaut lors de la fin du thread distant.
En pratique, ca ressemble à ça :

push 0xFAFAFEFE // the PID of the process to debug
mov edx,kernel32.DebugActiveProcess
call edx
test eax,eax
jz fin // if it works we dont jump
mov edx,kernel32.DebugSetProcessKillOnEx
push 0
call edx

fin:
retn

0xFAFAFEFE est le PID de dontTryToDebugMe que je patche à l'exécution avant de copier le shellcode dans le process distant ( pas oublier de le faire en little-endian :). Il faut aussi éviter de faire l'appel à DebugSetProcessKillOnEx() dans le cas où DebugActiveProcess() à échoué car la valeur de retour de notre shellcode ( celle qui nous permet de dire si ça a marché ou pas ) sera celle du dernier appel, donc de DebugSetProcessKillOnEx() et cette fonction semble "marcher" même si DebugActiveProcess() a échoué.

Une fois le shellcode patché, on l'écrit dans notre process notepad.exe, on le fait s'exécuter en créant un thread à son adresse avec CreateRemoteThread() et on récupère la valeur de retour avec GetExitCodeThread()... Si c'est 0 ça veut dire que ça a échoué donc qu'un débuggeur est là :-)

Pour bypasser ça, c'est la galère... le débuggeur ne controlant pas la création du processus "fils" notepad.exe, il ne peut pas venir hooker à temps DebugActiveProcess() dans celui-ci. Et même si on y arrivait (= l'appel à DebugActiveProcess() "marcherait" tout le temps) dontTryToDebugMe pourrait venir vérifier qu'on reçoit effectivement les exceptions ( par exemple celle de création du process qui est toujours reçue en premier ).

6- Tic tac, tic tac...

Une technique bien connue consiste à utiliser les différents compteurs que le système maintient à jour : l'idée consiste simplement à remarquer que certaines opérations prennent beaucoup plus de temps selon qu'un débuggeur est présent ou non. Quel genre d'opérations ? Sur le net on trouve pas mal d'exemples avec de simples boucles sur des printf(). Perso j'ai aucune différences, les printfs prennent autant de temps que le débuggeur soit là ou pas (ce qui semble assez logique, l'affichage d'une chaine par le biais d'un printf() n'est pas un évènement de débug, non?)... Il faut donc mieux utiliser une opération véritablement couteuse dans le cas d'un débuggage, par exemple OutputDebugString() :-)

Le code qu'on met dans dontTryToDebugMe est donc du genre :

firstTick=GetTickCount();

for(loop=0;loop<10000;loop++)
{
OutputDebugString("MDR");
}

secondTick=GetTickCount();

if(secondTick-firstTick > NORMAL_TIME_COUNT)
{
// too long, debugger spooted xD
}
else
{
// no debugger
}

NORMAL_TIME_COUNT est une constante définie à partir de mesures des exécutions sans débuggeur ! Dans mon cas j'ai utilisé GetTickCount() mais on peut aussi faire avec QueryPerformanceCounter()...

Là encore pour le bypasser, c'est pas du gateau mon salop : on pourrait hooker GetTickCount() et lui faire retourner une valeur constante ( dans ce cas là le test secondTick-firstTick>NORMAL_TIME_COUNT serait toujours faux..) mais il suffit de modifier le test de notre précédent code et de mettre : if((secondTick-firstTick>NORMAL_TIME_COUNT)
||(secondTick==firstTick))

et on détecte le hook :)

7- C'est cadeau !

Pour terminer ce tour non-exhaustif, une technique un peu plus aggressive...

A force de m'attacher à des process pour essayer de leur démonter la tête, j'ai finis par m'apercevoir ( bien ouerj oeil de lynx ) que tous les débuggeurs ring3 ( que ça soit OllyDbg ou le JoE d3bugg3r ) créent un nouveau thread dès qu'ils s'attachent et que ce nouveau thread démarre toujours sur la fonction DbgUiRemoteBreakIn() dont le code est de la forme suivante :

VOID
NTAPI
DbgUiRemoteBreakin(VOID)
{
/* Make sure a debugger is enabled; if so, breakpoint */
if (NtCurrentPeb()->BeingDebugged) DbgBreakPoint();
/* Exit the thread */
RtlExitUserThread(STATUS_SUCCESS);
}

Mais le code n'est pas le plus important, ce qui rox, c'est que cette fonction soit toujours appelée au moment de l'attachement, pour empêcher un débuggeur de s'attacher, il nous suffit de remplacer le code de cette API par un code qui va l'emmerder ! Pour faire simple, dontTryToDebugMe va écrire un appel à TerminateProcess() à l'emplacement de cette fonction, et ainsi quand le débuggeur s'attache au process, BAM il se termine.

La parade est simple, il suffit au débuggeur de repatcher à chaud le code de cette API avant de s'y attacher. Bon, a noter que dans notre cas j'ai même pas eu besoin de le faire puisque le JoE d3bugg3r s'attache au moment où la cible est à son EP, donc elle n'a pas pu encore patché son DbgUiRemoteBreakin(). Disons que cette protection est utile pour empêcher l'attachement à un process en cours, ou alors il faudrait utiliser un version modifiée de la DLL qui contient cette fonction (ntdll) mais là j'imagine qu'on touche du doigt des domaines un peu plus compliqué ( packers ? ) et j'en suis pas encore là :-)

A noter un effet de bord intéressant : ce fameux DbgUiRemoteBreakin() explique l'exception qui est toujours levé lorsqu'on commence de débugger un process en mode non intrusif ( il y en a aussi une en mode intrusif mais cela ne nous regarde pas ;). J'avais pris en compte ce fait en laissant toujours de côté la première exception dans le code de mon débuggeur, mais là on s'aperçoit que si on modifie le byte IsDebugged du PEB, l'exception ne sera plus levée, donc la première exception qu'on cathera sera une "vraie", à prendre en compte donc :)

Pour conclure, on peut remarquer que dans les conditions dans lesquelles je me suis plaçé ( c'est à dire en avantageant le débuggeur en lui laissant la main en premier ), il est facile de bypasser les APIs fournie par Microsoft ( IsDebuggerPresent(), CheckRemoteDebugger() ), mais d'un autre côté il y a d'autres checks très faciles à mettre en place ( le self-debug ou les timers ) qui semblent difficiles (impossibles?) à pwned... Donc le JoE d3bugg3r a perdu, mais il reviendra, plus fort, plus beau :D

Je suis bien sûr loin d'avoir étudier tous les anti-debug ( j'en ai même laisser certains importants de côté ), je me suis cantonné à des techniques "non-agressive" (ormis la dernière, mais c'est du caca celle là), je continuerai ce travail d'ici peu de temps pour voir où ça mène ;-)

Le code du debuggeur se trouve ici, le mode non-intrusif implémente tous les anti-anti-debug que j'ai décrit au dessus. Le code source de dontTryToDebugMe est là ainsi que le binaire compilé sous XP SP3 ici ( vous pouvez checker votre débuggeur maison, voir si il fait mieux que moi :p ).

Coté bibliographie je me suis en grande partie basé sur l'article référence de N. Fallière que vous pouvez trouver ici.

Inject your DLL

2008-07-22T17:21:00.001+02:00

Pour continuer mon apprentissage du fabuleux (aheum) monde de Windows, je me suis lancé dans l'implémentation d'un grand classique : l'injection de DLL.

Mon but est donc simple : injecter une bibliothèque dynamique dans un/des process distant(s) ( sans m'occuper de l'utilisation qu'on pourrait en faire ). Pour celà j'ai implémenté différentes techniques "de base" dans un petit tool. J'ai également tripé en essayant de rendre le truc le plus furtif possible, c'est à dire en libérant au maximum la mémoire allouée pour l'injection quand il y en a. Let's start :

1- "Classical method" :

Archi-connue, cette technique consiste à utiliser l'API CreateRemoteThread() qui créé donc un thread dans un process distant (jsuis totally bilingual et oué) en lui donnant l'adresse de LoadLibrary() à laquelle on fournit le nom de la DLL à injecter, qui aura été précédemment écris dans la mémoire du process cible ( VirtualAllocEx() + WriteProcessMemory() ).

La seule difficulté c'était de savoir quand je pouvais libérer cette mémoire allouée pour l'appel ( et gagner un petit peu de furtivité plutot que de laisser le nom de la DLL se balader dans la mémoire ) : il me fallait détecter que l'injection était terminée donc que LoadLibrary() à finie son boulot. Comme j'étais chaud bouillant j'ai commencé à dumper le EIP en boucle et à m'exciter sur les valeurs qu'il pouvait prendre une fois l'injection terminée... Puis j'ai découvert WaitForSingleObject(), qui dixit la doc "Waits until the specified object is in the signaled state or the time-out interval elapses." et pour un thread le "signaled state" c'est "when the thread terminates." c'est dans la poche :-)

A noter qu'il ne faut pas oublier de s'allouer les droits de debug pour pouvoir ouvrir un HANDLE sur n'importe quels process et pouvoir ainsi s'injecter dans tout ce qui bouge.
De plus, cette méthode ne fonctionne que sous Windows NT alors par acquis de conscience j'ai rajouté une fonction isWindowsNT() qui utilise l'API GetVersionEx() pour vérifier que la version de l'OS est ok...

2- "Cave code method"

La technique précédente c'est du tout bon, ca marche bien, mais ça fait appel à l'API surpuissante CreateRemoteThread() qui finalement sert "juste" à faire un appel à LoadLibrary(), et qui peut être facilement repéré par des outils anti-injection (enfin, j'imagine :p ).
Donc une autre idée est de se coder un loader en assembleur qui remplacerait l'appel à CreateRemoteThread(), ce qui nous permettrait de nous injecter en chargeant ce loader dans la mémoire du process distant puis en redirigeant le flux d'exécution dessus.

La principale difficulté en ce qui concerne le loader c'est qu'il contient plusieurs adresses qu'on ne connait pas au moment de la compilation : l'adresse de retour où on retournera après que notre loader ait été exécuté, l'adresse de l'argument de LoadLibrary() (= le nom de la dll qu'on veut mapper) et l'adresse de LoadLibrary() ( même si en pratique on a envie d'hardcodé celle là, il faut pas forget que même entre service pack 2 et 3 sous XP il y a des différences au niveau des adresses de mapping des DLLs, donc si on veut faire un truc un minimum portable c'est pas top).

Cela nous donne :

push 0xFAFAFEFE // return address

pushfd // save the eflags register
pushad // save the registers

push 0xFAFAFEFE // argument of LoadLibrary()
mov eax,0xFAFAFEFE // @ of LoadLibrary()
call eax

popad
popfd

ret

Je fous des 0xFAFAFEFE à la place des trucs que je vais devoir patché et j'oublie pas de sauvegarder les registres avant et de les rétablir après histoire de pas avoir de souci :-)

Le code du loader se trouve donc dans mon process "injecteur" et premier petit problème, comment localiser ce code pour pouvoir le patcher ? Sous GCC y a pas de souci, tu utilises la balise __asm__ et tu fous ton code ASM direct à l'intérieur d'une fonction, l'adresse de la fonction te donnera l'adresse de ton loader et en cadeau bonus, tu peux même déclarer une autre fonction "vide" derrière ce qui te permettra de connaitre la taille de ton loader avec la différence d'adresse. Sauf que voilà, dans le but de m'introduire plus profondément dans la communauté des t4pz je mange des chocapicz et je compile désormais avec VC++ 2008. Et sous ce magnifique compilateur que trouve t'on à l'adresse de la fonction dans laquelle on a mis le code ASM du loader ? Je te le donne en mille émile :

00401005 JMP main.00401060

Oui dude, un JMP vers le "vrai" code de la fonction, ce qui est emmerdant. Donc la seule solution c'est de transformer mon loader en opcodes et de mettre tout ça dans une variable globale qui me donnera l'adresse dont j'ai besoin.

Donc une fois que l'adresse du loader est connue, on commence par patcher l'adresse de l'argument de LoadLibrary() qu'on obtient en allouant de la mémoire dans le process cible avec VirtualAllocEx() puis celle de LoadLibrary() qu'on obtient avec GetProcAddress().

Reste à mettre l'adresse de retour, pour celà on va d'abord suspendre le main thread du process distant, à cet effet je me suis codé une fonction qui récupère le TID de ce thread à partir du PID du process distant, rien de bien compliqué : on fait un snapshot de tous les threads du système avec CreateToolhelp32Snapshot(), on récupère ceux dont le PID owner est le même que le PID de notre process cible. Une fois le TID du main thread récupéré, on créer un HANDLE dessus avec OpenThread() et on suspend le thread avec SuspendThread().

On récupère alors l'EIP avec GetThreadContext(), on l'écrit dans notre loader.. et hop ! notre loader est patché, il ne reste plus qu'à le copier dans la mémoire de notre cible. Une fois que c'est fait on modifie l'EIP pour qu'il pointe vers lui avec SetThreadContext(), on relance le thread et on attend ! Si tout va bien, le process cible va exécuter notre loader, charger la DLL puis revenir là où il était...

Oui mais voilà, on attend un peu trop longtemps... Tout est en place, l'EIP pointe bien sur notre loader mais pourtant le code ne s'exécute pas ou du moins pas tout de suite.. à moins que je "passe la souris dessus" ( pour un process graphique j'entend, pour un process console c'est une autre histoire ) . Ce qui n'est pas très pratique, je voudrai pouvoir être sûr que mon code va être exécuté directement une fois que j'ai relancé le thread sans devoir intervenir sur la cible et ainsi pouvoir libérer la mémoire occupé par le loader histoire d'être caché inside the bosquet.

Ma première idée c'était que le problème se situe au niveau de l'ordonnancement : le système ne donne pas de temps processeur à mon process cible tant qu'il n'y pas "quelque chose" qui lui laisse croire qu'il va se passer un truc important dans ce process ( d'où le coup de souris ) ou qu'il n'a rien de mieux à faire. Ce qui est confirmé par le fait que "de temps en temps" l'injection va avoir lieu au bout de 10s et dans d'autres cas, après une minute toujours rien...

Donc j'ai commencé à faire le fou avec les fonctions SetPriorityClass() et SetThreadPriority() histoire de "forcer" le processeur à exécuter mon process cible. Mais j'ai eu beau foutre la priorité max, j'ai vu aucune différence notable... Et j'ai donc abandonné l'idée en me disant que de toute façon l'ordonnanceur Windows doit être un beau bordel et que faudrait être maso ( ou plus fort que moi :p ) pour jouer avec. J'ai quand même retenu cette phrase de la doc qui m'a bien fait rire "Threads are scheduled in a round-robin fashion at each priority level". On y croit.

Finalement, ce que je veux c'est un moyen de simuler mon "coup de souris" sur la cible puisque apparament il n'y a que ça qui force le process à être exécuté ca$h par le processeur à coup sûr. "Me dis pas que dans ces API de malades que Windows possèdent en ce qui concerne les manipulations de processus en user-land, je trouverai pas mon bonheur." Et effectivement, je l'ai trouvé, il suffit d'envoyer un "message" au process qui, comme tout bon GUI process possède une "message queue" et va réagir au quart de tour pour traiter ce message. Pour cela j'utilise PostThreadMessage() qui, dixit la doc, "posts a message to the message queue of the specified thread" (sympa la doc non?). L'effet est immédiat : mon code est exécuté dans la seconde, et je peux enchainer en libérant la mémoire du loader, celle de l'argument de LoadLibrary() et ni vu ni connu jt'injecte :-)

Reste que pour un process console "basique" y a pas de message queue et que donc mon message va tomber dans le vide inter-sidéral et ça ne va rien accélèrer, donc pour ces process là ( que je détecte suivant le code de retour de PostThreadMessage() ) je libère pas la mémoire allouée dans la cible et j'attend sagement que l'injection se fasse. Si quelqu'un connait une fucking way de forcer un process console à être exécuté ca$h par le processeur je lui serai gré de m'en faire part.

3- "SetWindowsHookEx()" :

Là encore, une méthode très connue : tout se joue avec l'API SetWindowsHookEx() qui permet de poser un hook (en gros, une fonction) pour un certain type d'event : si cet event se produit, notre fonction sera appelée. Pour que la fonction soit appelée dans un process distant (= la cible de l'injection) elle dois être définie dans une DLL, lorsque l'event se produit, le process va vouloir exécuter la fonction définie comme étant le hook et pour cela il va charger la DLL qui la contient :-) De plus, on peut définir si on veut poser le hook pour un thread particulier ou pour tous les threads qui sont dans le "same desktop" donc ça nous donne une possibilité d'injection massive ! Intéressons nous d'abord à une attaque "ciblé".

La théorie ça rox, mais en bidouillant un peu on s'aperçoit que cette API est un peu plus fourbe que ça :

1- Première remarque : cette technique ne marche que sur des process "graphiques" et pas pour des process consoles ( décidément... ), en trifouillant sur le net on trouve une explication "Hooks don't work on console processes. The process wich runs consoles (csrss) is considered to be too important to the system so it is designed this way." Pour rendre les choses plus propres on a un moyen de distinguer les process consoles/GUI et éviter ainsi des appels inutiles :

if(WaitForInputIdle(targetHandle,0)==WAIT_FAILED)
{
// console process
}
else
{
// GUI process
}

2- Sur quel évènement poser ce hook ? Il nous en faut un qui nous garantisse une injection le plus rapidement possible une fois le hook mis en place. Je comprend pas vraiment pourquoi la majorité des exemples sur le net se borne à mettre WH_CBT en argument de SetWindowsHookEx() c'est à dire un évènement qui correspond à "activating, creating, destroying, minimizing, maximizing, moving, or sizing a window", en gros un truc qui nous pousse à devoir intervenir sur le process cible avec la souris. En mettant un WH_GETMESSAGE qui lui "Installs a hook procedure that monitors messages posted to a message queue. ", il suffit ensuite de poster un message avec PostThreadMessage() et on est sûr que le hook va avoir lieu...

3- Le hook n'existe que tant que le thread qui le pose est vivant, dès qu'il meurt non seulement le hook n'existe plus ( et donc l'injection ne peut plus avoir lieu ) mais de plus, il va y avoir un FreeLibrary() sur notre DLL dans le thread qui a utilisé ce hook. Là j'avoue ne pas vraiment comprendre pourquoi il y a cet appel, après une petite enquète il est déclenché par un GetMessageW(), j'aurai donc tendance à penser que c'est bien déclenché à distance mais il n'est pas à exclure que ça soit plutôt une erreur dans mon implémentation ;-)
Ca pose en tout cas un léger problème : une fois que le thread qui a posé le hook est mort, le FreeLibrary() qui va avoir lieu dans la cible va décrémenter le compteur de référence de la DLL qui va arriver à 0 (=plus personne n'a besoin de cette bibliothèque) et elle va donc être déchargé de la cible... Un peu emmerdant c'était justement le but de la manoeuvre de la charger :-D
Donc pour bypass ce ptit souci j'ai rajouté dans la fonction de hook dans la DLL un appel à LoadLibrary() sur elle-même, ce qui incrémente le compteur de référence et évite qu'elle soit déchargé lors de la mort du thread injecteur. "C'est moche mais ça marche !"
Vous trouverez le code de la DLL en question ici. Remarquez le très subtil chemin de la DLL rentrer en dur pour l'appel à LoadLibrary()...

4- "The IvanOv m4l4ri4"
Ainsi nommée d'après la personne bien intentionné qui m'en a donné l'idée.

Comme dis précédemment, SetWindowsHookEx() permet de poser un hook sur tous les threads du bureau, ce qui nous donne envie de s'en servir pour injecter tout le monde !
Déjà, dans l'idée de l"IvanOv m4l4ri4", l'évènement qui va déclencher le hook ne sera pas "controlé" par l'injecteur : on va laisser le WH_CBT et dès qu'un process "bougera" il sera infecté (c'est plus rigolol, non ?).

Rappelons nous que le hook n'existe que tant que le thread qui l'a posé est vivant. Or, on a pas envie de laisser tourner notre process injecteur en tache de fond le temps que tous les autres process soient infectés. Pour celà il serait plus judicieux de faire une première injection dans un process dont on est sûr qu'il sera "toujours là" et on laisse ce process poser le hook.

En fait tout va se jouer dans la DLL, on va l'injecter dans notre process qui va servir de pivot à l'infection, puis on va poser le hook sur tout le système dans le DllMain(). Une fois le hook posé, tous les process qui vont recevoir un event graphique vont charger la DLL. Ca nous amène au principal problème de cette technique : les hooks qui concerne tous les threads du bureau sont extrèmement couteux en performance, donc si à chaque chargement de la DLL, le hook est de nouveau posé ça va rapidement faire ramer la machine, pas très discret. Il nous faut donc un moyen de savoir si le hook est déjà poser quand on charge la DLL, histoire de savoir si c'est à nous de le faire ou pas. Ce qu'on veut c'est donc une sorte de "variable globale" au système qui serait en gros mise à 1 si le hook est déjà en place et nous permettrait ainsi une communication inter-processus. Et ça porte un nom : le mutex. Pour faire simple un mutex est lié à un thread qui le "possède", et n'importe quel thread du système peut essayer de prendre possession du mutex en appelant WaitForSingleObject(), il réussira si personne ne l'a pris avant lui (ou si il l'a libéré). Pour le reconnaitre le mutex sera dans notre cas "nommé" c'est à dire qu'on lui donne un nom particulier. Donc tout ce qu'il y a faire lors du chargement de la DLL c'est de faire appel à CreateMutex() avec le nom de notre mutex, si c'est le premier appel le mutex va être créé, puis le thread va faire un WaitForSingleObject() pour en prendre possession, et ainsi poser le hook. Le prochain thread qui "bouge" va utiliser le hook et charger la DLL, ce coup-ci l'appel à CreateMutex() lui retournera juste un HANDLE sur le mutex ( qui existe déjà ) et l'appel à WaitForSingleObject() lui signalera que le mutex est déjà pris par un autre thread, donc que ce n'est pas à lui de poser le hook.
Remarquons que pour faire la première injection, il ne faut pas utiliser la technique 1 qui consiste à créer un thread dans le process cible, car une fois que ce thread va se terminer, le hook va être enlevé et le mutex se retrouvera esseulé (= dans l'état WAIT_ABANDONED, qui est décrit à tord comme un "success state" dans la doc).. La "cave method" est bien plus adapté car elle utilise le main thread ( je savais bien que j'avais pas fait ça pour rien !).
Donc pour cette technique il suffit de lancer l'injection de la DLL dont le code source est ici en "cave method" puis de laisser faire la nature, le premier qui bouge, BAM dans sa geule.

Il faut quand même remarquer que j'ai un souci au niveau de la libération du mutex, qui doit se faire lorsque le process "pivot" de l'injection meurt, donc quand il décharge la DLL. J'ai pas réussi à faire marcher un ReleaseMutex() dans la clause DLL_PROCESS_DETACH de ma DLL. C'est pas vraiment grave dans le sens où ça empeche juste la technique de fonctionner une deuxième fois de suite avec un mutex de même nom ( le mutex est en WAIT_ABANDONED : le thread qui le possèdait est mort et ne l'a pas libéré ). Mais si votre infection a bien fonctionné, y a normalement pas besoin de la relancer :-)

Le code final est ici.

Debug me !

2008-07-14T17:00:00.001+02:00

Dans la série des useless tools...

Après l'avoir vu utilisé dans différents articles (notamment le très bon post de YoLeJedi sur nibbles ou encore par Ivan dans son implémentation de PaX) j'ai décidé de me coder un petit débuggeur tranquillou mon pépère.
Mon idée est classique : c'est de permettre deux modes : l'un intrusif et l'autre pas. Késako ?

I- Be bad

Le mode intrusif c'est du classique, on créé un processus en mode debug et on va donc recevoir tous les debugEvent qui vont se produire ( chargement des DLLs, exceptions...) ce qui peut être bien pratique pour fuzzer : on lance une application en boucle avec différentes entrées et on récupère les exceptions pour voir où ça merde. Côté réalisation y a rien de bien compliqué, surtout que la doc est assez explicite sur ce point: après la création du process ( avec l'argument DEBUG_PROCESS ) on rentre dans une debug loop qui va catcher tout les debugEvent et c'est du tout bon.

II- Be bad ok, but without pain please

Le mode non-intrusif est plus fallacieux. Déjà, quel est son intéret ? Il est simple : un process peut avoir des comportements différents suivant qu'il est sous le contrôle d'un débuggeur ou non. Sans rentrer dans des techniques anti-debugging complexes on peut citer deux exemples "naturels" : le gestionnaire d'exception final ( aka UnhandledExceptionFilter ) qu'on peut mettre en place dans un programme avec SetUnhandledExceptionFilter() n'est pas appelé en mode debug, ce qui n'est pas très pratique quand on veut tester une exploitation qui consiste justement à réécrire son adresse. On peut aussi parler des chunks dans le tas qui sont différents en mode débug (16 bytes de plus), ce qui facilite pas les choses lors du test d'un heap overflow ;-)

L'idée du mode non-intrusif consiste à s'attacher au process une fois qu'il est lancé avec l'API DebugActiveProcess(). J'ai alors crié "This is just so fuking easy !" : je créé mon process avec un CreateProcess() en mode normal, j'apelle cette API pour m'attacher puis je lance ma debug loop et hop.

Je me suis lancé, j'ai codé, j'ai compilé, j'ai executé et jme suis pris un comportement bien bizarre dans la gueule : pour la majorité des process auquels je m'attache ça plante complètement, pour d'autres ça marchent, mais pas à tous les coups et dans certains cas, chose bizarre, j'arrive à récupérer le nom des DLLs qui sont chargés (après l'avoir lancé une première fois) alors que ça ne devrait pas être le cas...

Après avoir consulté l'oracle (aka YoLeJedi :p), j'ai compris ce qui se passait. Pour celà, intéressons nous au processus de création d'un process sous Windows (par l'appel à CreateProcess()) : il se divise en 6 étapes (extrait de Windows Internals) :

Open the image file (.exe) to be executed inside the process.
Create the Windows executive process object.
Create the initial thread (stack, context, and Windows executive thread object).
Notify the Windows subsystem of the new process so that it can set up for the new process and thread.
Start execution of the initial thread (unless the CREATE_ SUSPENDED flag was specified).
In the context of the new process and thread, complete the initialization of the address space (such as load required DLLs) and begin execution of the program

Comme on peut le voir c'est assez complexe, et c'est là que se situe le problème, si juste après l'appel à CreateProcess() j'apelle DebugActiveProcess(), je risque de m'attacher avant que la fin de l'initialisation réalisé à l'étape 6 ne soit terminée. Or DebugActiveProcess() est une API qui est faite pour s'attacher à des process "en cours" donc complètement initialisé. Ca explique aussi pourquoi desfois je reçois les noms des DLLs : si je m'attache avant l'étape 6 alors je serai "notifié" du chargement des DLLs comme si le process avait été lancé en mode DEBUG ( m'enfin je m'avance peut être un peu là ).
Tout ce qu'il faut retenir c'est qu'il faut laisser le processus d'initialisation se terminer avant de s'attacher.

Une première idée pourrait être de caler un ptit Sleep(X) avant de faire appel à DebugActiveProcess() : ça fonctionne mais c'est moche : si la durée d'endormissement est trop longue le process qu'on débugge aura déjà attaquer d'exécuter son code et donc on risque de louper des debugEvents ( et c'est bien sûr pas portable du tout, si un process charge beaucoup de DLLs il mettra plus de temps à s'initialiser et hop il faudra changer la valeur ).

Il existe une meilleure façon de faire, in 6 steps :

1- On créé le process en mode SUSPENDED : il est suspendu (jure?)...
2- On modifie l'Entry Point (EP) du programme pour y mettre une boucle infinie
3- On relance le process et on attend que le main thread (créé à l'étape 5) du programme atteigne l'EP ( avant d'y arriver il réalise l'étape 6 de l'initialisation, c'est à dire le chargement des DLLs et tout le bordel) : le process est alors complétement initialisé et se met à boucler.
4- On s'attache au process avec DebugActiveProcess() .
5- On restaure l'EP initial, le main thread commence l'execution du code et on n'en perd pas une miette :-)

Décrivons plus en détail les étapes les plus compliquées (pas trop non plus :p) :

2- Il nous faut récupérer l'EP, pour celà jme fait un petit parcours du header PE. Les lecteurs assidus de ce blog (et ils sont nombreux, aheum), auront remarqué que mon premier useless tool était justement un PE reader, cool, je peux réutiliser mon code ?! En fait pas du tout, pour faire plaisir au ch3f je mappe le fichier en mémoire avec MapViewOfFile() et je le parcours directement en déréférençant des pointeurs.
2-1 Une fois l'adresse de l'EP récupérée, on utilise VirtualProtectEx() pour changer la protection de la mémoire où il se trouve et pour pouvoir y écrire.
2-2 On oublie pas de faire une sauvegarde des deux premiers octets se trouvant à l'EP
2-3 On écrit EB FE à la place de ces octets ce qui correspond aux opcodes d'un JMP à la même addresse, donc une boucle infinie :). On cale un ptit appel à FlushInstructionCache() derrière pour s'assure que nos modifs se propageront bien en mémoire centrale et ne resteront pas dans le cache du processeur.

3- On relance le processus avec ResumeThread(), et on attend qu'il atteigne l'EP en dumpant la valeur de l'EIP avec GetThreadContext().

4- Appel à DebugActiveProcess()..

5- On réécrit les anciens opcodes à la place de notre boucle infinie, on oublie pas de flusher et de restaurer les anciens droits de la mémoire.

Let's launch the debug loop, et c'est good :-)

III- Et comment tu t'apelles ?

Comme YoLeJedi l'explique dans son post, dans le monde non intrusif, on n'a pas accès aux noms des DLLs loadés en mémoire directement dans les structures de debug qu'on récupère. Pour trouver ces noms il faut se casser un peu le c..
YoLeJedi donne 3 techniques pour le faire, perso j'ai implémenté la première qui, dixit le maitre, est la plus rapide :-)
"Le principe consiste à mapper le premier octet du fichier en mémoire à partir de son Handle (CreateFileMapping + MapViewOfFile). Ceci crée indirectement un objet section qui contient le chemin du fichier. Celui-ci est alors récupéré avec l’API GetMappedFileName. La lettre du lecteur est retrouvée avec le couple GetLogicalDriveStrings + QueryDosDevice."
Et on trouve un code source qui nous fait tout ça ici.

Mais comme ce code est un peu trop propre et que le copier/coller favorise pas l'apprentissage, je me suis retapé un codage "maison" que vous trouverez dans la fonction getTheNameOfTheFile(), c'est pas vraiment joli (voire carrément dégeulasse) et sûrement pas assez commenté mais ca reste du parcours de string, donc pas très complexe à refaire :)

Vous trouverez donc la source du bouzin ici ( pas oublié de linker avec Psapi.lib lors du build de l'executable pour GetMappedFileName() ) et le binaire compilé sous XP SP2 là.

Une prochaine amélioration pourrait être un mode interactif pour pouvoir afficher la mémoire du process avec des commandes à la gdb...

Thanks to YoLeJedi pour son aide et ses commentaires utiles ;-)

Useless tool...

2008-07-07T18:04:00.003+02:00

Inauguration d'une nouvelle section de ouf qui regroupera les tools inutiles que je code...

First entry : un PE reader qui a rien de bien original si ce n'est que j'essaye de restreindre l'affichage aux champs intéressants. Il peut être facilement customizé pour n'afficher que le header qui vous intéresse.
J'ai aussi rajouter ma section cop4ain, donc si t'es mon copin et que je t'ai oublié, query me on irc ;-)

First real exploitation on Windows

2008-06-22T21:49:00.036+02:00

Le titre en anglais ça pête...

Les stacks overflows de base sous Windows sont, comme sous Linux, bien documentés, mais les cas pratiques sont pas forcément toujours très réalistes. L'idée est donc ici de se frotter à un ptit tool conseillé par mon maitre jedi Heurs : IntelliTamper 2.07.

Ce qui suit a été réalisé sous Windows XP SP2 FR.

I- Première approche de la cible

IntelliTamper est un "aspirateur web" : vous lui donnez un site, il vous en recrache l'arborescence. On a aussi la possibilité de sauvegarder l'architecture d'un site dans un fichier .map et bien sûr de charger un .map précédemment sauvé :-)

On dl le bouzin, on le lance et on observe...

Nous sommes à la recherche d'un overflow, donc on regarde les différents moyens que l'utilisateur a à sa disposition pour passer des données au programme. A première vue, il y en a deux : l'url que le logiciel doit scanner (qui se rentre dans la barre du haut) et les fichiers .map qu'il peut charger (accessible par un classique "File/Load").

It's time to fuzzzzzzz this bullshit

L'idée est donc ici de balancer des masses de données dans les différentes entrées possibles et de croiser les doigts pour que ça plante, ce qui indiquerait un overflow que nous pourrions peut être exploiter :-) Pour cela j'utilise un tool fournit avec le framework Metasploit : je lui donne la longueur de chaine que je veux et il me la génère en faisant en sorte que je n'ai jamais les 4 mêmes caractères côte à côte, ça permet de voir ( d'après le rapport d'erreur microsoft ) qu'elle est la longueur de données qu'il faut pour faire merder le bouzin.

First test, on balance une grosse chaine de caractères (500) dans la barre URL et il se passe... rien du tout ! On se décourage pas, on rajoute une url correcte devant notre chaine et on re-teste et ...

Yeah, un premier overflow spooted !

Deuxième test : on se fabrique un petit fichier .map en y mettant là encore une chaine très longue.
Et... bingo ! Après avoir balancer des données de longueur diverse ( et avoir rajouter un saut de ligne derrière ), un autre message d'erreur qui va bien apparaît aux alentours des 7500 caractères.
Nous avons donc deux overflows ( à première vue ) dans ce programme, et comme dans la vie il faut faire des choix, nous allons nous intéresser ici à celui qui est provoqué par le chargement de fichiers .map foireux.

II- This is not so easy

Regardons le rapport d'erreur issue de notre BOF :

Notre offset ne correspond à rien dans la chaine de caractère que nous avons mis dans notre fichier .map de la mort. Ce n'est donc pas directement un écrasement d'adresse de retour qui provoque l'overflow.
Pour vérifier ça on lance OllyDbg sur notre tool et on charge notre fichier crafté pour voir qu'est ce qui provoque le plantage :

La valeur chargée dans EBX est issue de la stack, où a surement été copié le contenu de notre fichier crafté, elle doit donc être foireuse et au moment d'accéder à EBX+73B0 on tombe sur une zone mémoire non allouée et ça déclenche un "Access violation". Simple, non ? Regardons exactement la gueule de la stack au moment du plantage pour s'en convaincre : la copie de notre fichier commence en 00123A64, et EBX a effectivement été réécris puisqu'il contient 6964652D qui est bien contenu dans notre .map. Voyons si nous ne pouvons pas nous servir de ce déclenchement d'erreur pour rediriger le flux d'exécution... :-)

Un autre "détail" intéressant est le fait que, à partir d'un certains nombres de caractères, notre programme est "killé" et sans aucun message d'erreur, essayons d'identifier la source de ce comportement étrange ( jsuis trop en forme là ) :

Je bourrine un bon gros fichier .map fabriqué avec amour ( plus de 12000 caractères ) et on observe avec Olly... Notre "Access violation" a bien lieu à la même ligne à cause de la valeur contenue dans EBX, le programme va alors chercher un gestionnaire d'exception pour traiter ce cas d'erreur...

Interlude - Gestion d'exception sous Windows

Pour bien comprendre ce qui suit, il est bon d'avoir quelques notions de la gestion d'exception sous windows : ce qui suit est lâchement pompé du très bon article de Carib publié dans theHackademyManuel #12

Lorsqu'un évènement imprévu survient et qu'une exception est déclenchée le contrôle est passé à la procédure KiUserExceptionDispatcher() qui va dérouler un algorithme pour décider où doit se poursuivre l'exécution du programme. Il existe différents types de gestionnaire, regroupés sous l'acronyme SEH (Structured Exception Handling), mais dans notre cas il est bon de retenir que ceux qui nous intéressent (car mis dans la pile :)) sont les gestionnaires de threads qui sont mis en place à l'aide d'une structure SEH simple :

DWORD Next SEH
DWORD SEH Handler

Le premier champ pointe sur la structure SEH suivante ( ou -1 si il y en a pas ) et le second désigne la procédure qui traitera l'exception.
Les gestionnaires d'un thread sont donc chainés les uns aux autres : si un handler n'est pas capable de gérer une exception, il a la possibilité de renvoyer une valeur signifiant à KiUserExceptionDispatcher() de passer le contrôle au gestionnaire suivant, qui pourra éventuellement la traiter. Rajoutons à cela le fait que ces structures SEH sont placés dans la pile et que le dernier gestionnaire installé ( donc celui qui sera appelé en premier ) est pointé par fs:[0].
Ce qu'il faut retenir, c'est que lorsqu'une exception se déclenche le dernier gestionnaire d'exception installé est appelé et qu'il y a donc redirection du flux d'exécution sur le SEH Handler qu'il contient.

Un dernier détail, qui n'en est pas un, c'est que au moment du lancement du SEH Handler, le système lui passe 3 arguments dont le premier est un pointeur vers un code d'erreur associé à l'exception ( et qui se trouve placé dans la pile ) et le deuxième est un pointeur vers la structure SEH dont on lance justement le SEH Handler ! ( donc ce deuxième argument contient exactement l'adresse du champ Next SEH ).

Fin de l'interlude

Donc on revient à notre programme qui cherche un gestionnaire d'exception après avoir eu un accès mémoire invalide : il regarde donc dans fs:[0] pour trouver le plus récemment enregistré et il y lit... 001265F4 qui est bien une adresse dans la pile et qui a été écrasé lors de la copie de notre .map fr0m the h3ll. Alors le programme JUMPe sur l'adresse du SEH Handler, qui est invalide car j'ai mis de la merde dans mon fichier, et donc ça redéclenche une exception qui ne peut être traitée car il n'y a plus de gestionnaires SEH et donc finalement le programme se kill ( c'est très schématique, toute information complémentaire est encouragée dans les commentaires ;))

Donc l'idée est assez simple : on va réécrire le champ SEH Handler avec une valeur "qui va bien" pour rediriger le flux d'exécution à partir du déclenchement d'une exception.
Le problème c'est que n'est plus aussi simple depuis l'introduction du flag de compilation /SafeSEH avec Visual Studio 2003 qui fait en sorte qu'on ne puisse donner comme adresse de SEH Handler que des valeurs qui ont été précédemment enregistrées, et donc on est un ptit peu niked. Vérifions donc si ce tag est présent ici, pour cela j'utilise le plugin pour Olly SafeSEH disponible ici.
Il va nous indiquer ce qui a été compilé avec le flag :

Alleluia ! L'exécutable n'a pas été compilé avec /SafeSEH, ce qui veut dire qu'on peut JUMPer où l'on veut dans son code... Le but étant de revenir dans la stack où l'on a copié notre .map ( et qui pourrait contenir un shellcode :)), c'est là qu'on se rapelle du fait que le gestionnaire d'exception prend en deuxième argument l'adresse de la structure SEH, qui se trouve donc être dans la stack à un endroit qu'on peut tout à fait écraser...

Une technique classique lors de ce genre d'exploitation consiste à mettre l'adresse d'une suite d'instructions : POP | POP | RET comme SEH Handler, on va donc ainsi dépiler l'adresse de retour, puis le premier argument et retourner sur le deuxième argument du handler ( le pointeur vers notre structure SEH dans la pile, c'est à dire le champ Next SEH ).
Une fois qu'on est revenu sur le Next SEH, on a à notre disposition les 4 octects de ce champ pour JUMPer sur un shellcode qu'on aura placé dans la pile...

III- Now it's time to do the payload

Essayons de tout mettre en place pour n'avoir plus que le shellcode à insérer dans notre fichier .map. Si on récapitule par un petit schéma de notre pile montrant les différentes étapes :

On met tout ça en place dans un fichier .map qui va bien en prenant comme adresse du POPPOPRET 00416CEB où l'on trouve :

00416CEB |. 59 POP ECX
00416CEC |. 59 POP ECX
00416CED \. C3 RETN

Le fait que ça soit POPer dans ECX a son importance comme nous le verrons tout à l'heure.

On lance le programme, l'exception se déroule et on regarde la tête de notre stack avant l'appel au gestionnaire d'exception (j'ai rempli tous les caractères inutiles par des 0x90 et mis des 0xCC dans le Next SEH) :

001265E4 90909090
001265E8 90909090
001265EC 90909090
001265F0 90909090
001265F4 CCCCCCCC Pointer to next SEH record
001265F8 00416CEB SE handler
001265FC 00000000
00126600 00000000
00126604 00000000

On laisse l'exception continuer... La main est donné au "gestionnaire" placé en 00416CEB qui double-POP et retourne à l'adresse 001265F4 pour s'interrompre ( instruction 0xCC). It's fun !

Mais on remarque quelque chose : après avoir copié mon adresse 00416CEB dans la pile (donc en partant du 0xEB pour finir par copier le 0x00), toute la suite a été mis à 0x00... Donc dès qu'on 0x00 est copié, tout ce qui suit est aussi mis à zéro !

Ca nous pose un problème : on ne peut pas utiliser l'espace mémoire situé après l'adresse du SE Handler pour mettre un shellcode ( on aurait pu atteindre ce shellcode en mettant un JMP 4 à la place du champ Next SEH et ainsi retomber après le champ SEH Handler ).
Donc on doit obligatoirement placer le shellcode avant la structure SEH et trouver un moyen, avec les 4 octets du champ Next SEH de "remonter" dans la pile.

Placer le shellcode plus haut ne pose aucun problème si ce n'est qu'il ne faut pas qu'il y ait de 0x00 dedans. Il faut maintenant JUMPer pour "remonter" au dessus. Pour celà, nous avons donc 4 octets à notre disposition. Ma première idée était de faire un JMP SHORT en négatif : on utilise des entiers signés donc un JMP 0xYY avec le premier bit de YY à 1 remontera dans la pile ( en fait descendra puisqu'elle croit vers les adresses décroissantes, mais bref vous avez compris l'idée ). Le problème est bien sûr évident : on ne peut "remonter" que à 127 octets à partir du JMP, donc ça limite grandement la taille de notre shellcode. Je n'y connais pas grand chose dans ce domaine mais en voyant la geule des générateurs automatiques, les shellcodes Windows semblent dépasser alègrement les 160 octets.
Donc il nous faut trouver un autre moyen pour remonter toujours plus haut (alllllerrrr plus hauuuut) in th3 st4ck.
C'est là qu'on se souvient du premier argument du SEH Handler qui est une adresse d'un code d'erreur mis dans la stack que l'on POP dans ECX au moment de notre POP|POP|RET. Essayons de manipuler cette adresse pour qu'elle tombe dans notre buff3r de la mort.
Pour cela, un petit rappel sur les registres :
si ECX=00123456
alors CX = 3456
CH = 34
CL = 56

La valeur qu'on a mis dans ECX ( une adresse sur la stack ) est de la forme 0012XXYY et rappelons nous que le fichier copié dans la stack est décris par une plage d'adresse de la forme 0012ZZYY et est d'une très grosse taille ( plus de 11k octets ). Donc il serait intéressant de manipuler CH pour transformer XX en ZZ et caler un JMP ECX derrière qui nous amènerait en plein milieu de notre buffer. Ceci est tout à fait faisable sur 4 octets puisque MOV CH,ZZ est sur 2 octets et JMP ECX de même.
Dans mon cas, le paramètre POPer dans ECX est 00123314 ( l'adresse où se trouve le code d'erreur de l'exception ) et mon fichier copié dans la stack commence à l'adresse 00123A64, il me suffit par exemple de faire un MOV CH,3B ( B5 3B en ASM x86 ) et je me retrouve avec ECX qui contient l'adresse 00123B14 qui pointe inside my buff3r. Je rajoute derrière un JMP ECX ( FF E1 ) et en 4 octets me voilà en position de force pour exécuter un shellcode :-)
Pour récapituler, ma stack ressemble finalement à :

00123A64 90909090 <- Début de la copie de mon file
00123A68 90909090
. . .
00123B14 90909090 <- Pointé par ECX après MOV CH,3B
. . .
001265E8 shellcode
001265EC from
001265F0 the h3ll
001265F4 E1FF3BB5 Pointer to next SEH record
001265F8 00416CEB SE handler
001265FC 00000000
00126600 00000000

J'ai transformé tous mes caractères caca par des NOPs (0x90) histoire de pas me prendre la tête avec les adresses, là je peux remonter très haut à partir de ECX et caler un shellcode de plus de 10k octets sans problème.

Pour conclure, on voit que les SEH c'est de la boulette pour se faire un BOF qui pwne, mais il faut bien avoué que si le tag /SafeSEH avait été mis à la compilation du tool, cette technique ne marcherait pas ( impossible de mettre l'adresse d'un POP|POP|RET en SEH Handler ).
Il doit aussi sûrement exister d'autres manières que le MOV CH,XX JMP ECX pour 'remonter' dans notre buffer.

Et pour pas vous vendre du vent, voici un fichier crafté avec un shellcode bien foireux made in Metasploit : il vous lance un processus cmd.exe mais vous ne le verrez pas puisqu'il appelle WinExec avec un paramètre mis à 0 au lieu de 1, et comme le shellcode est polymorphique et que j'y connais (pour le moment ! :=D) pas grand chose dans ce domaine, je vois pas bien ce qu'il faut modifier. Donc vous pouvez checker que ça marche dans le sens où le processus est bien créé :-) ( ou remplacer le shellcode par un qui marche mieux ...)

Je peux pas vous mettre directement le fichier .map ( la copie du 0x00 ne passe pas ;-X) mais je vous donne le dump hexadécimal du file, vous permettant de le générer vous même avec les outils qui vont bien pour ça ( python? :p ) :

map.txt

Special thanks to 0vercl0k and Ivan x-D

Double-free attack V2.0

2008-06-16T18:34:00.013+02:00

Suite aux nombreux messages d'encouragement qui ont suivis la première version de ce post (traduction : après deux remarques du genre "Putin mais ton dernier post c'est de la merde t'as rien décris du tout") j'ai décidé de reprendre à zéro l'analyse du double-free() et de pousser un peu plus loin. Et j'ai bien fait... puisqu'il y avait plus de choses à dire que ce que je pensais :-)

I- Il y a fort longtemps...

Donc on reprend l'histoire depuis le début : toute personne ayant déjà suivie un cours de programmation en C s'est entendu dire "il ne faut pas oublier de free() tout pointeur alloué avec malloc(), et ne pas re-free() une zone déjà libéré". En effet, si on en croit la page de manuel qui va bien : "if the space [qu'on essaye de free()] has been deallocated by a call to free() [...] the behavior is undefined." Donc si on "double-free()" un pointeur, le comportement serait aléatoire ?

Nous allons donc voir, à travers plusieurs versions de la libc ( puisque ce qui nous intéresse ici c'est les fonctions malloc() et free() ) quel est ce fameux comportement.

Testons ça dans un premier temps sur une version Windows XP SP2 ...

int main()
{
void * first=malloc(20);
void * second;
void * third;

free(first);
free(first); // Oh My God, un double-free !

second=malloc(20);
*((int *)second)=2;
third=malloc(20);
*((int *)third)=3;

printf("second : %d, third : %d\n",*((int*)second),*((int*)third));

return 0;
}

Et là que se passe t'il dude ?

> second : 3, third : 3

Là tu n'en crois pas tes yeux cher lecteur, mais pour finir de te convaincre de ce comportement intéressant, je rajoute un petit :

...
if(third==second)
printf("third = second !!!\n");
...

Et ça donne :

> second : 3, third : 3
third = second !!!

WTF ? Et bien oui les deux pointeurs désignent la même zone mémoire ! Donc quand on fait un double-free() avec cette version de la libc, les deux malloc() qui suivent vont désigner le même endroit, on comprend aisément que si dans un programme ce genre d'erreur se produit, ou du moins qu'on arrive à faire en sorte que ça soit le cas ( genre un cas à la con que le programmeur a pas prévu qui va "double-free()" une variable globale) et que l'utilisateur à la main sur les données rentrées à partir du deuxième malloc(), il va écraser celles du premier et c'est le 0v3RFl0W dude !

II- And now, what's up ?

Il est temps de tester le double-free() avec la dernière version de la libc (2.7), je reprend donc mon superbe code, je lance l'exécution et là :

*** glibc detected *** ./test: double free or corruption (fasttop): 0x0804a008 ***

Pinaiz, ils ont implémenté une protection anti-"double free()". Shame on me, mon overflow de la mort ne fonctionne plus ?

Intéressons nous donc réellement au fonctionnement de free()|malloc(), pour voir quelle est cette nouvelle protection qui ma pwned.
Donc, direction la libc et plus particulièrement malloc.c qui contient le code des deux fonctions sus-nommées ( et oué ).

Première étape, se renseigner sur la gestion des blocs (chunks) libres, puisque c'est celà qui nous intéresse ici.
On trouve un passage intéressant dans les commentaires ligne 2049 :
"Chunks of the same size are linked with the most recently freed at the front, and allocations are taken from the back."
Donc les blocs libres sont mis dans des "free-list" qui contiennent des blocs de même taille et l'allocation fonctionne sur un modèle FIFO : quand on libère un bloc il est ajouté en tête de la liste qui le concerne et quand on a besoin d'un bloc on prend le plus "vieux" ( donc celui qui se trouve à la fin ).

Regardons donc maintenant la protection "anti-double free()" : on cherche le code de free() et on voit à la ligne 4594 :

if (__builtin_expect (*fb == p, 0))
{
errstr = "double free or corruption (fasttop)";
goto errout;
}

où p est l'adresse du bloc qu'on veut libérer et fb un pointeur vers la free-list qui lui est associé (celle qui contient les blocs libres de même taille que lui).
Tiens donc ? Ce test vérifie donc que le bloc qu'on veut libérer n'est pas celui qui se trouve en tête de la free-list associée, donc si il n'est pas le dernier qui a été free().
Vérifions ce comportement :

int main()
{

void * first=malloc(12);
void * second=malloc(12); // Ces deux pointeurs seront stockés dans la même free-list lors de leurs libération

free(first);
free(second);
free(first); // Oh my God, double-free() on first !

return 0;
}

On lance le bouzin et... aucun message d'erreur ! On a pu double-free() notre pointeur sans aucun souci. Le check qui est effectué par la libc est donc facilement bypassable... Mais en même temps on "comprend" qu'un check complet de la free-list ( donc un parcours linéaire ) serait très couteux en temps.

Maintenant qu'on voit comment on peut pwned la protection, voyons si on pourrait exploiter celà pour faire un overflow. Réprésentons l'évolution de la free-list associée à mes deux pointeurs first et second :

C'est là que dans ton cerveau malade la possibilité de l'overflow apparait (rappelons que lors de l'appel à malloc(), le bloc choisi est celui qui se trouve "en bas" de la free-list), si je rajoute dans mon code :

...

void * third=malloc(12); // va prendre le premier bloc du bas (=first)
void * fourth=malloc(12); // va prendre le deuxième bloc en partant du bas (=second)
void * cinqth=malloc(12); // va prendre le troisième bloc en partant du bas (=first !)

if(third==cinqth)
printf("Double free inside the heap !\n");

}

Et l'exécution donne :
$ Double free inside the heap !

Cinqth (et oué) et third pointe sur le même bloc ! Donc on en reviens au principe originel : ce qui sera écris à partir de cinqth écrasera ce qui a été écris à partir de third -> game over.

On peut donc voir que les double-free() sont encore possibles, il faut néanmoins, pour qu'ils soient exploitables, qu'il y ait eu au moins un autre free() d'un bloc de même taille entre temps.

III- The ultimate protection...

La solution pour éviter de devoir checker dans des codes assez lourd à chaque free(ptr) ce qu'on a fait avant avec le pointeur, c'est de faire :

free(ptr); ptr=NULL;

puisque d'après le manuel "If ptr is NULL, no operation is performed.", donc un deuxième free() ne foutra pas la zone. Easy, no ? A noter que ce genre de "bug" est déjà arrivé sur des projets assez costaud (voir ici).

GCC is protecting you...

2008-06-12T21:30:00.000+02:00

Pour un newbie qui veut devenir une pop-star du hack, les "buffers overflows" (BOF), techniques ancestrales, constituent une cible de choix car très documenté et assez facile à réaliser. Malheureusement pour lui, le jeune wanabee va très vite s'apercevoir que les buffers overflows ça marche plus comme dans les tutoriaux de grand-papa.

Dans ce post je vais m'efforcer de décrire les protections de GCC 4 ( donc la version actuelle ) concernant les "stack-overflows", la variante la plus abordable des BOFs, histoire de mieux comprendre was passiert.

Il est supposé que celui qui lit ça connait le principe d'un stack overflow, si ce n'est pas le cas, il peut se mettre un doigt dans le cul car je ne vais pas expliquer quelque chose que d'autres ont déjà décrit bien mieux que moi.

I- GCC has a protector...

Et son nom est le Stack Smashing Protector (SSP) dont le but est simple : tout d'abord protèger la cible principale d'un stack overflow c'est à dire l'adresse de retour empilé au moment d'un appel de fonction. Mais aussi une deuxième cible potentielle : la sauvegarde du Base Pointer qui est effectué par le prologue de la fonction ( pour éviter les attaques du type "Off by one"), et la troisième cible possible : les variables locales de la fonction qui pourraient également être écrasées par un buffer. Finalement, il existe une quatrième et dernière cible : les arguments de la fonction ( qui pourrait être écrasés pour faire de multiple "Ret-onto-ret" par exemple ).

Pour réaliser ces 4 objectifs, le SSP va réaliser trois actions particulières en intervenant directement au niveau du code assembleur produit par GCC : l'ajout de canary, la réorganisation des variables locales et la sauvegarde des arguments des fonctions.

Avant d'entrer plus dans les détails, remarquons que le SSP est activé par défaut dans GCC 4 et que vous pouvez le désactiver en compilant votre programme avec l'option -fno-stack-protector, ce qui permet de très vite comprendre les différences.

II- Cui-cui

SSP, notre Superman, va, pour protéger le Saved EBP et le Saved EIP, rajouter un "canary". Le principe est simple : pour éviter que l'on puisse venir à partir d'un buffer ( situé plus bas dans la pile ) écraser ses deux sauvegardes, on va placer une constante aléatoire avant de placer les variables locales à la fonction :

Le principe théorique du canary est alors facile à comprendre : on suppose que le programme a la possibilité de connaitre de façon certaine la valeur du canary (en en plaçant une copie dans un endroit inaccessible en écriture) et que l'utilisateur lui ne peut pas la deviner (car elle est aléatoire). Il suffit alors au programme de vérifier à la fin de la fonction que c'est bien la même valeur.

En pratique, le fonctionnement des canary est différent avec SSP, puisque d'après la documentation, il y a des cas où le programme n'est pas capable de générer une valeur aléatoire pour mettre dans son canary. Dans ce cas-là il se rabat sur une valeur fixe : 0xff0a0000 ( en big-endian). Et c'est là que tout un tas de questions up dans ton mind !

Pourquoi le programme ne pourrait pas générer une valeur aléatoire ? Alors là c'est mystère et boule de gommes, cette valeur est normalement générer avec /dev/urandom et je vois pas bien pourquoi il y aurait un problème d'accès. En tout cas ce qui est sûr c'est qu'après pas mal de test, cette valeur n'est jamais aléatoire chez moi, et avec le manque de clarté des diverses docs là dessus je suis toujours à la recherche de la réponse. Donc notre canary contient toujours la valeur 0xff0a0000.

Mais si le canary à toujours la même valeur, pourquoi qu'on le remplace pas par cette valeur au moment de l'overflow et ni vu ni connu jt'embrouille ?!
Tu aura remarqué que la valeur du canary parait avoir été choisie : elle contient les caractères 0x00 ( terminaison d'une string ) et 0x0a c'est à dire "\n" en ASCII (terminaison pour la fonction gets() ) qui vont donc rendre impossible tout buffer overflow par les fonctions de manipulation de string : quand tu va vouloir copier ta chaine de caractère pour tout écraser tu ne pourra pas remplacer le canary par sa valeur car ces caractères particuliers constituent des fins de string et tu n'ira donc pas plus loin.
Mais là, une boulette apparait : si le buffer overflow n'est pas déclenché par une fonction de manipulation de string "classique" mais par une fonction encore plus foireuse "faite maison" ou directement en manipulant la mémoire avec memcpy() ? Ben là tu pourra tout à fait réécrire le canary...

Et les performances dans tout ça ?
Les canary ne sont rajoutés que dans les fonctions "où ça en vaut la peine", c'est à dire dès qu'un tableau de char de taille au moins égale à 8 est déclaré dans une fonction, ce qui limite l'atteinte aux performances.

En pratique ça ressemble à quoi ?
Pour celà, codons nous un exemple bateau de fonction "vulnérable" à un stack overflow :

void function(char * src)
{
char buffer[10];
strcpy(buff,src);
}

int main(int argc, char * argv[])
{
function(argv[1]);
return 0;
}

Il est important de remarquer que nous ne occupons pas du cas où la faille apparait directement dans le main() car dans GCC 4 le prologue de cette fonction est différent de celui des autres ( j'y reviendrai dans un autre post, mais pour le moment j'ai pas tout compris ) et ça ne fait que compliquer les choses et ça n'a aucun intéret pour comprendre le fonctionnement des canarys.

Donc on prend notre courage à deux mains, on lance gdb sur le programme et on désassemble notre function() pour voir si on voit quelque chose qui concerne ces fameux oiseaux. Je vous présente ces lignes de codes ASM suivies de commentaires quand il y a besoin :

function+0 : push %ebp
function+1 : mov %esp,%ebp
function+3 : sub $0x18,%esp
Ceci est le prologue classique d'une fonction avec réservation de la place nécessaire aux variables locales...

function+6 : mov 0x8(%ebp),%eax
function+9 : mov %eax,-0x14(%ebp)
Ces deux lignes seront expliqués plus bas, elles ne concernent pas les canarys

function+12 : mov %gs:0x14,%eax
function+18 : mov %eax,-0x4(%ebp)
Tiens donc, sauvegarde d'une "valeur" contenue dans le registre GS juste après EBP xD

... <- Ici du code sans importance : appel a strpcy()

function+23 : mov -0x4(%ebp),%eax
function+26 : xor %gs:0x14,%eax
function+33 : je 0x80483bc
function+35 : call 0x80482fc <__stack_chk_fail@plt>
On récupère la valeur sauvegardée précédemment et on la compare à la valeur initiale contenue dans le registre GS. Si elle est égale, on se dirige vers l'épilogue de la fonction sinon on saute sur la routine __stack_chk_fail dont le nom est assez explicite :P

function+40 : leave
function+41 : ret
Epilogue classique d'une fonction.

Le fonctionnement parait assez clair : la valeur du canary est stocké dans le registre GS et on le met comme prévue juste après le Saved EBP ( pointé par EBP ). Dans le cas où il est écrasé on saute sur une routine qui doit sûrement déclencher un message d'erreur pas piqué des ours ( oué ça se dit ).

Confirmons ce fonctionnement en sautant à pied joint dans la mémoire lorsqu'on est dans function() :

(gdb) break function
(gdb) run aaaaaaaa

Et là, que vois t'on dans la pile ?
...
0xbffdff90: 0x61616161 0xff0a0000 0xbffdffb8 0x0804842f
...
Notre buffer a donc été rempli par les 'a' (0x61) que nous avons donné en argument et tout de suite après vient... notre canary ! Tout de suite suivie par le Saved EBP et le Saved EIP.
Tout semble au mieux dans le meilleur des mondes, notre canary est bien en place et va donc empêcher les écrasement classiques par des fonctions type strcpy(). Ce qu'on voit par un test :

$ ./prog aaaaaaaaaaaaaaaaaaaaa
*** stack smashing detected ***: ./prog terminated

Donc, nos deux premiers objectifs sont atteints !

III- Réorganisation des variables locales d'une fonction

Cette réorganisation pars d'un principe simple : un buffer ne peut écraser que les valeurs qui ont été empilées avant lui, SSP se charge donc de mettre les buffers le plus près possible de EBP ( c'est à dire en haut de la pile ) et de placer les autres variables locales en dessous. Si le buffer déborde ça sera vers le haut et il ne pourra donc pas les écraser.
Pour s'en convaincre compilons le petit code ci-dessous :

void function()
{
int c=3;
int d=4;
char buff[8];
}

int main(int argc, char * argv[])
{
function();
return 0;
}

On regarde la tête de la stack dans function() :

(gdb)x/16x $esp
...
0xbfaf4010: 0xb7ef4b19 0x00000004 0x00000003 0x080482c8
...
(gdb) x/x buff
0xbfaf401c: 0x080482c8

Notre buffer se trouve bien plus haut dans la pile que nos deux variables locales, malgré le fait qu'il soit déclaré avant les deux constantes, il a été empilé en premier.

IV- Recopie des arguments d'une fonction

Dernière protection apportée par SSP : la recopie de certains arguments des fonctions, en fait tous les pointeurs passés en argument sont recopiés dans le contexte de la fonction pour éviter de faire référence aux arguments. Let's test :

void function(char * src, char * src2, int * c)
{
char buff[8];
strcpy(buff,src);
}

int main(int argc, char * argv[])
{
int * d;
function(argv[1],"bbbbb",d);
return 0;
}

On saute avec gdb dans la stack de function() pour voir ce qui se passe :

(gdb) b function
(gdb) run aaaaaaaa
function (src=0xbfcbd750 "aaaaaaaa", src2=0x8048510 "bbbbb", c=0xb7fe6dc0)
...

(gdb) x/16x $esp
0xbfcbb9a0: 0xbfcbb9bc 0xbfcbd750 0x00000000 0xb7fe6dc0
0xbfcbb9b0: 0x08048510 0xbfcbd750 0x00000000 0x61616161
0xbfcbb9c0: 0x61616161 0xff0a0000 0xbfcbb9f8 0x0804843c
0xbfcbb9d0: 0xbfcbd750 0x08048510 0xb7fe6dc0 0x080482ec

Voici donc que nos 3 adresses passées en arguments ont été recopiés dans le contexte de la fonction, avec bien sûr la réorganisation des variables locales elles se retrouvent plus haut que le buffer.
Pour finir de s'en convaincre, on regarde le code :

(gdb) disassemble function
...
prologue classique
...
function+6 : mov 0x8(%ebp),%eax
function+9 : mov %eax,-0x14(%ebp)
function+12: mov 0xc(%ebp),%eax
function+15: mov %eax,-0x18(%ebp)
function+18: mov 0x10(%ebp),%eax
function+21: mov %eax,-0x1c(%ebp)
...
mise en place du canary et suite de la fonction
...

Bref, rien de bien compliqué de ce côté là.

Pour conclure, j'espère que ce post t'aura permis de comprendre le fonctionnement de SSP. Maintenant on peut réfléchir à des attaques possibles contre les diverses protections misent en place :-)