First real exploitation on Windows

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