Auteur LARDOUX Guillaume Contact guillaume guillaume.lardoux@epitech.eu Année Original 2009 Année de Refonte 2014 REVERSE ENGINEERING SOUS LINUX x86
Sommaire 1. Introduction 2. Format ELF & PE 3. Les outils Linux 4. Patcher un Binaire 5. Contourner une Structure Conditionnelle 6. Contourner ptrace() 7. Exploiter un Stack Overflow 8. Hooking avec LD_PRELOAD 9. Contourner le Stripping 10. Obfuscation de Code en C 2
1. Introduction Depuis que les ordinateurs existent, il y a toujours eu des bugs dans les machines, des erreurs de programmation ou des défauts dans la conception, conduisant un programme à un endroit d un système qu'il n'était pas censé visiter. Mais dès lors, plusieurs techniques on vu le jour afin d'analyser ces défauts de fonctionnement, dans le but de les corriger ou de les exploiter. Ces techniques reposent en réalité sur un seul grand principe d'analyse de binaire : le «Reverse Engineering». Dans ce document, je vais me consacrer à l'analyse de programme sous Linux 32bits, et non sous Windows, bien plus connu et documenté. L'unique raison à cela est que le système et la structure des fichiers exécutable sous Linux est grandement différente et beaucoup plus attrayante. Sous Windows il porte le nom de PE Portable Executable, tandis que sous Linux il est nommé ELF Extended & Linking Format ; ce dernier sera introduit au prochain chapitre. Il est bon de savoir que la majorité des techniques de Hacking moderne sont basées sur le Reverse Engineering, car cette méthode d'analyse permet de comprendre le fonctionnement sous-jacent et parfois «mystique» d'un programme, et par conséquent de découvrir des failles qu'il aurait été impossible de découvrir autrement, si ce n est par hasard. C'est donc un atout du point de vue de la «sécurité», comme du point de vue du développement, car il est souvent nécessaire de comprendre le cœur du flux d exécution d'un programme qui ne fonctionne pas comme on le souhaiterait pour pouvoir le corriger, ou même l optimiser en fonction de ses besoins! 3
2. Format ELF & PE Chaque fichier exécutable sous Linux repose sur une structure nommée ELF. Cette structure, détaillée dans /usr/include/elf.h, permet au système d'exécuter un programme en chargeant ses informations en mémoire de manière structurée. Un programme est découpé en section, et chaque section possède un nom et une fonction propre. De fait.text contient le code exécutable à proprement parler,.rodata contient les SDR String Data Reference etc. Ainsi, lorsqu'on exécute un programme sous Linux, le «loader» va commencer par lire l'ensemble du fichier suivant la structure ELF afin de charger en mémoire chaque information à la bonne place chaînes de caractères, appels système, environnement, etc. pour que ce programme puisse interagir correctement avec le système. 4
3. Les outils Linux Afin d'avoir la possibilité d'analyser un programme sous une forme humainement compréhensible, il est nécessaire de posséder quelques outils. Sous Windows ils sont très connu Ollydbg, PEiD, IDA, Win32Dasm etc., mais peut-être peu moins sous Linux. Voici une liste détaillant quelques outils utiles au Reverse Engineering sous Linux. - gcc GNU C Compiler - gdb GNU Debugger - objdump Désassembleur de fichier ELF - strace Trace les appels système d un programme - ltrace Trace les appels aux fonctions des librairies d un programme - string Affiche les SDR d un programme - hexedit Editeur Hexadécimal en mode «Console» Ce sont là des outils de bases indispensables, mais d'autres outils comme «elfsh» ou «DDD» peuvent s'avérer tout aussi intéressant. Pour ce tutoriel, cela sera suffisant. 5
4. Patcher un Binaire Pour cette première mise en pratique, je vais m'attarder sur la modification manuelle d'un programme. Pour cela, il va nous falloir analyser l'exécution du programme pour comprendre son fonctionnement et éditer son code machine directement avec «hexedit». Code Source C #include <stdio.h> int main() { int i = 0; } if (i > 15) printf("\n\naccess GRANTED!!\n\n"); else printf("\n\naccess DENIED!!\n\n"); return (0); Comme on peut le constater, obtenir un «accès» sur ce type de programme est un jeu d'enfant, il nous suffit simplement de modifier la valeur de «i» ou encore la condition «if else». Commençons par exécuter le programme et observons sa réaction. root~#./a.out ACCESS DENIED!! root~# Intéressant, nous avons eu un «ACCESS DENIED!!» parce que la valeur de «i» est inférieure à 15. Modifions donc la comparaison et essayons d obtenir un accès. On va commencer de manière simple en désassemblant le code machine du programme avec l utilitaire «objdump». 6
root~# objdump -d./a.out a.out: file format elf32-i386 Disassembly of section.init: 08048254 <_init>: 8048254: 55 [...] 08048354 <main>: 8048354: 8048358: 8d 4c 24 04 83 e4 f0 lea and 0x4(%esp),%ecx $0xfffffff0,%esp 804835b: ff 71 fc pushl -0x4(%ecx) 804835e: 55 push %ebp 804835f: 8048361: 89 e5 51 mov push %esp,%ebp %ecx 8048362: 83 ec 14 sub $0x14,%esp 8048365: c7 45 f8 00 00 00 00 movl $0x0,-0x8(%ebp) 804836c: 8048370: 83 7d f8 0f 7e 12 cmpl jle $0xf,-0x8(%ebp) 8048384 <main+0x30> 8048372: 83 ec 0c sub $0xc,%esp 8048375: 68 88 84 04 08 push $0x8048488 804837a: e8 1d ff ff ff call 804829c <puts@plt> 804837f: 83 c4 10 add $0x10,%esp 8048382: eb 10 jmp 8048394 <main+0x40> 8048384: 83 ec 0c sub $0xc,%esp 8048387: 68 9d 84 04 08 push $0x804849d 804838c: e8 0b ff ff ff call 804829c <puts@plt> 8048391: 83 c4 10 add $0x10,%esp 8048394: b8 00 00 00 00 mov $0x0,%eax 8048399: 8b 4d fc mov -0x4(%ebp),%ecx 804839c: c9 leave 804839d: 8d 61 fc lea -0x4(%ecx),%esp 80483a0: c3 ret 80483a1: 90 nop 80483a2: 90 nop 80483a3: 90 nop [...] J'ai volontairement supprimé une partie du code ASM afin de gagner de la place, mais cela n'empêche pas de comprendre simplement en lisant ce tutoriel étant donné que le code de la fonction «main» est présent. On observe un JLE Saut Conditionnel en 0x08048370 et juste au dessus un CMPL qui compare «i» avec 15. Logiquement, si on modifie la valeur 0xF 15 en décimal du CMPL ou si on supprime le saut conditionnel, on devrait obtenir un accès. On ouvre donc le programme avec «hexedit» et on recherche la chaine hexadécimale «837DF80F», qui correspond au code machine «if (i > 15)» en langage C. 7
Une fois trouvé, on vérifie si «7E12» JLE suit ce bout de code pour être sûr d écrire au bon endroit, et on change ce code «7E12» par des «NOP» No Operation, soit «9090» en hexadécimal, on sauvegarde avec le raccourci [CTRL + X] et on relance le programme. root~#./a.out ACCESS GRANTED!! root~# Et voila comment il est possible de modifier un programme sans posséder aucun code source. C est exactement le principe des «cracks» sous Windows, ou encore de certains patchs de sécurité. 8
5. Contourner une Structure Conditionnelle A présent que nous savons comment fonctionne un désassembleur et un éditeur hexadécimal, et la façon de modifier un binaire, il va nous falloir apprendre à contourner une structure conditionnelle un peu plus complexe, et cette fois sans toucher au code machine du programme! Code Source C #include <stdio.h> #include <string.h> int main() { char password[] = "Root"; char buffer[500+1]; } printf("password : "); fgets(buffer, sizeof(buffer), stdin); if (strncmp(buffer, password, strlen(password)) == 0) printf("\naccess GRANTED!!\n"); else printf("\naccess DENIED!!\n"); return (0); Comme vous pouvez le constater, j'ai implémenté un système d'authentification très simple, et le but du jeu étant d'obtenir un accès valide. Exécutons le programme afin d'observer son fonctionnement. root~#./a.out Password : root ACCESS DENIED!! root~# Nous allons à présent utiliser «gdb» pour tenter de contourner cette authentification. On charge le programme dans le debugger et on désassemble la fonction «main» afin d'analyser son comportement. 9
root~# gdb (gdb) file a.out Reading symbols from /root/a.out...done. Using host libthread_db library "/lib/libthread_db.so.1". (gdb) disass main Dump of assembler code for function main: 0x08048414 <main+0>: 0x08048418 <main+4>: lea and 0x4(%esp),%ecx $0xfffffff0,%esp 0x0804841b <main+7>: pushl 0xfffffffc(%ecx) 0x0804841e <main+10>: push %ebp 0x0804841f <main+11>: 0x08048421 <main+13>: mov push %esp,%ebp %edi 0x08048422 <main+14>: push %esi 0x08048423 <main+15>: push %ecx 0x08048424 <main+16>: 0x0804842a <main+22>: sub lea $0x20c,%esp 0xffffffeb(%ebp),%edi 0x0804842d <main+25>: mov $0x80485e9,%esi 0x08048432 <main+30>: cld 0x08048433 <main+31>: 0x08048438 <main+36>: mov $0x9,%ecx rep movsb %ds:(%esi),%es:(%edi) 0x0804843a <main+38>: sub $0xc,%esp 0x0804843d <main+41>: push $0x80485b8 0x08048442 <main+46>: call 0x8048340 <printf@plt> 0x08048447 <main+51>: add $0x10,%esp 0x0804844a <main+54>: mov 0x8049708,%eax 0x0804844f <main+59>: sub $0x4,%esp 0x08048452 <main+62>: push %eax 0x08048453 <main+63>: push $0x1f5 0x08048458 <main+68>: lea 0xfffffdf6(%ebp),%eax 0x0804845e <main+74>: push %eax 0x0804845f <main+75>: call 0x8048320 <fgets@plt> 0x08048464 <main+80>: add $0x10,%esp 0x08048467 <main+83>: lea 0xffffffeb(%ebp),%eax 0x0804846a <main+86>: mov $0xffffffff,%ecx 0x0804846f <main+91>: mov %eax,0xfffffdf0(%ebp) 0x08048475 <main+97>: mov $0x0,%al 0x08048477 <main+99>: cld 0x08048478 <main+100>: mov 0xfffffdf0(%ebp),%edi 0x0804847e <main+106>: repnz scas %es:(%edi),%al 0x08048480 <main+108>: mov %ecx,%eax 0x08048482 <main+110>: not %eax 0x08048484 <main+112>: dec %eax 0x08048485 <main+113>: sub $0x4,%esp 0x08048488 <main+116>: push %eax 0x08048489 <main+117>: lea 0xffffffeb(%ebp),%eax 0x0804848c <main+120>: push %eax 0x0804848d <main+121>: lea 0xfffffdf6(%ebp),%eax 0x08048493 <main+127>: push %eax 0x08048494 <main+128>: call 0x8048360 <strncmp@plt> 0x08048499 <main+133>: add $0x10,%esp 0x0804849c <main+136>: test %eax,%eax 0x0804849e <main+138>: jne 0x80484b2 <main+158> 0x080484a0 <main+140>: sub $0xc,%esp 10
0x080484a3 <main+143>: push 0x080484a8 <main+148>: call 0x080484ad <main+153>: add 0x080484b0 <main+156>: jmp 0x080484b2 <main+158>: sub 0x080484b5 <main+161>: push 0x080484ba <main+166>: call 0x080484bf <main+171>: add 0x080484c2 <main+174>: mov 0x080484c7 <main+179>: lea 0x080484ca <main+182>: pop 0x080484cb <main+183>: pop 0x080484cc <main+184>: pop 0x080484cd <main+185>: pop 0x080484ce <main+186>: lea 0x080484d1 <main+189>: ret End of assembler dump. (gdb) $0x80485c4 0x8048350 <puts@plt> $0x10,%esp 0x80484c2 <main+174> $0xc,%esp $0x80485d7 0x8048350 <puts@plt> $0x10,%esp $0x0,%eax 0xfffffff4(%ebp),%esp %ecx %esi %edi %ebp 0xfffffffc(%ecx),%esp Au vu de l exécution du programme, on peut déduire qu'il effectue une vérification du mot de passe saisi pour attribuer un accès ou non. On observe la fonction «strncmp» à l'adresse 0x08048494 suivie un peu plus loin d'une comparaison JNE en 0x0x804849e. On va commencer par poser un «breakpoint» juste au dessus de ce JNE, juste après la comparaison du mot de passe saisi, et on relance le programme. (gdb) break *0x0804849c Breakpoint 1 at 0x804849c (gdb) run Starting program: /root/a.out Password : Magicien Breakpoint 1, 0x0804849c in main () (gdb) 11
Ayant saisi «Magicien» comme mot de passe, le programme devra normalement nous afficher «ACCESS DENIED!!» si on continue son exécution. Il va donc falloir modifier le déroulement du programme afin de le faire passer sur le bout de code qui nous intéresse, c est-à-dire celui qui affiche «ACCES GRANTED!!». On va donc pointer sur la ligne juste après JNE Jump if Not Equal et on observe. (gdb) jump *main+140 Continuing at 0x80484a0. ACCESS GRANTED!! Program exited normally. (gdb) 12
6. Contourner ptrace() Avant de commencer : Qu'est-ce que «ptrace()»? ptrace(), diminutif de «Process Trace», est un appel système sous Linux qui permet de débugger un processus modification de sa mémoire, modification de ses registres etc. Vous pourrez obtenir d avantages d informations avec un simple «man ptrace» ou en lisant le manuel sur http://manpagesfr.free.fr/man/man2/ptrace.2.html Cet appel système peu aussi agir en tant que système de détection d'analyse, et peut donc permettre à des programmes de se protéger contre toute attaque ou analyse dynamique. Code Source C #include <stdio.h> #include <sys/ptrace.h> int main() { if (ptrace(ptrace_traceme, 0, 1, 0) < 0) printf("\ndebuging Detected...\n"); else printf("\naccess GRANTED!!\n"); return (0); } Comme on peut le voir, le programme quittera sans aucune explication seulement si on tente de le débugger, mais s exécutera normalement sinon. root~#./a.out ACCESS GRANTED!! root~# gdb./a.out (gdb) run Starting program: /root/a.out Debuging Detected... Program exited normally. (gdb) 13
Aucune surprise jusqu ici. Il va donc falloir trouver un moyen de contourner cette restriction en lançant une analyse. root~# objdump -d./a.out a.out: file format elf32-i386 Disassembly of section.init: 0804827c <_init>: 804827c: 55 push %ebp 804827d: 804827f: 89 e5 83 ec 08 mov sub %esp,%ebp $0x8,%esp 8048282: e8 8d 00 00 00 call 8048314 <call_gmon_start> [...] 08048394 <main>: 8048394: 8d 4c 24 04 lea 0x4(%esp),%ecx 8048398: 83 e4 f0 and $0xfffffff0,%esp 804839b: ff 71 fc pushl -0x4(%ecx) 804839e: 55 push %ebp 804839f: 89 e5 mov %esp,%ebp 80483a1: 51 push %ecx 80483a2: 83 ec 04 sub $0x4,%esp 80483a5: 6a 00 push $0x0 80483a7: 6a 01 push $0x1 80483a9: 6a 00 push $0x0 80483ab: 6a 00 push $0x0 80483ad: e8 02 ff ff ff call 80482b4 <ptrace@plt> 80483b2: 83 c4 10 add $0x10,%esp 80483b5: 85 c0 test %eax,%eax 80483b7: 79 12 jns 80483cb <main+0x37> 80483b9: 83 ec 0c sub $0xc,%esp 80483bc: 68 c8 84 04 08 push $0x80484c8 80483c1: e8 0e ff ff ff call 80482d4 <puts@plt> 80483c6: 83 c4 10 add $0x10,%esp 80483c9: eb 10 jmp 80483db <main+0x47> 80483cb: 83 ec 0c sub $0xc,%esp 80483ce: 68 de 84 04 08 push $0x80484de 80483d3: e8 fc fe ff ff call 80482d4 <puts@plt> 80483d8: 83 c4 10 add $0x10,%esp 80483db: b8 00 00 00 00 mov $0x0,%eax 80483e0: 8b 4d fc mov -0x4(%ebp),%ecx 80483e3: c9 leave 80483e4: 8d 61 fc lea -0x4(%ecx),%esp 80483e7: c3 ret 80483e8: 90 nop [...] 14
Comme on peut le remarquer à l'adresse 0x080483ad, il y a un appel à la fonction «ptrace», il va donc nous falloir supprimer ou contourner cet appel système afin de pouvoir lancer le programme normalement dans un debugger. Ouvrons-le avec «hexedit» et modifions le JNS en JMP pour le forcer à sauter. Pour ce faire, il suffit de modifier la valeur «7912» de ce JNS, en «EB12». On referme, et on exécute avec GDB pour vérifier. root~# hexedit./a.out root~#./a.out ACCESS GRANTED!! root~# gdb./a.out Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /root/a.out ACCESS GRANTED!! Program exited normally. (gdb)quit Tout fonctionne à merveille, le programme s'exécute normalement même lorsque nous le lançons avec un debugger, on peut donc considérer «ptrace» comme ayant été contourné. 15
7. Exploiter un Stack Overflow À présent, nous allons utiliser nos compétences afin de trouver et exploiter une faille de type «Stack Overflow». Il s'agit d'un débordement de mémoire se produisant dans la pile du programme cible. Voici un code vulnérable pour notre étude. Code Source C #include <stdio.h> #include <string.h> void Fonction() { printf("\nstack Overflow exploited!!\n"); } void Auth(char *argv) { char buffer[10]; strcpy(buffer, argv); } int main(int argc, char **argv) { if (argc > 1) { printf("cherche la Faille!!\n"); Auth(argv[1]); } else printf("usage : auth <password>\n"); return (0); } Dans ce programme très simple, un mot de passe saisi est placé dans un tampon de 10 octets (un caractère = 1 octet sur x86). Le problème ici est simple : que se passera t-il si je saisi un mot de passe de plus de 10 caractères? root~#./a.out Usage : auth <password> root~#./a.out Root Cherche la Faille!! root~#./a.out 1234567890 Cherche la Faille!! Segmentation fault 16
Comme nous pouvons le constater, il s est produit un dépassement de mémoire au bout de 10 caractères saisi. En langage C, le caractère de fin de chaine est toujours «\0», c'est pour cette raison que dans cet exemple la longueur maximum accordée à l'utilisateur est de 9 et non de 10! Cherchons maintenant un moyen d'exploiter ce problème. On va ouvrir «gdb» et lancer une analyse. On va saisir un mot de passe de 25 caractères et observer sa réaction. root~# gdb./a.out Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run aaaaaaaaaaaaaaaaaaaaaaaaa Starting program: /root/a.out aaaaaaaaaaaaaaaaaaaaaaaaa Cherche la Faille!! Program received signal SIGSEGV, Segmentation fault. 0x61616161 in?? () Très intéressant, nous avons complètement réécrit EIP Extended Instruction Pointer! EIP est un registre des processeurs INTEL x86 qui permet d'enregistrer l'adresse de la prochaine instruction à exécuter, on a ici complètement écraser cette adresse avec des «0x61» ; sachant que «0x61» est la valeur hexadécimale du caractère «a» dans la table ASCII, on peut en déduire qu'il est possible d'exploiter cette vulnérabilité pour rediriger totalement le flux d exécution du programme. Pour cette expérience, nous allons tenter d'exécuter la fonction «Fonction()». Mais nous avons un problème : Combien de caractères faut-il pour écraser complètement EIP? Il va falloir faire des essais successifs. (gdb) run aaaaaaaaaaaaaaa The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /root/a.out aaaaaaaaaaaaaaa Cherche la Faille!! Program received signal SIGSEGV, Segmentation fault. 0x08040061 in?? () (gdb) 17
Après quelques recherches, on comprend que 15 caractères permettent d'écrire sur le dernier octet du registre EIP, donc 18 caractères permettront de l écraser complètement, étant donné qu un registre de processeur x86 est codé sur 4 octet. Maintenant on recherche l'adresse de la fonction «Fonction()» avec gdb. (gdb) disass Fonction Dump of assembler code for function Fonction: 0x08048394 <Fonction+0>: push %ebp 0x08048395 <Fonction+1>: mov %esp,%ebp 0x08048397 <Fonction+3>: 0x0804839a <Fonction+6>: sub sub $0x8,%esp $0xc,%esp 0x0804839d <Fonction+9>: push $0x8048508 0x080483a2 <Fonction+14>: call 0x80482d4 <puts@plt> 0x080483a7 <Fonction+19>: 0x080483aa <Fonction+22>: add leave $0x10,%esp 0x080483ab <Fonction+23>: ret End of assembler dump. On voit que l'adresse de début de la fonction est 0x08048394, par conséquent il suffit d'écrire 14 fois «a» suivie de cette adresse. Il faudra aussi penser au fait que nous sommes en «Little Indian». Voyons cela plus concrètement en testant notre théorie. (gdb) run `python -c 'print "aaaaaaaaaaaaaa\x94\x83\x04\x08"'` Starting program: /root/a.out `python -c 'print "aaaaaaaaaaaaaa\x94\x83\x04\x08"'` Cherche la Faille!! Stack Overflow exploited!! Program received signal SIGSEGV, Segmentation fault. 0xbfc9a500 in?? () (gdb) Et voila un beau «Stack Overflow» mis à mal. Pour cet exemple, nous avons exécuté une fonction interne au programme qui n'était pas censée s'exécuter en situation normal car elle n est jamais appelée, mais il est tout aussi possible d'injecter du code permettant l'exécution d'un shell avec les droits du programme. 18
8. Hooking avec LD_PRELOAD Encore une fois : Qu est-ce que LD_PRELOAD? C est une variable d'environnement sous Linux, tout comme %SYSTEMROOT% ou %PROGRAMFILES% sous Windows. Elle permet de spécifier au système quelle bibliothèque partagée sera chargée avec un programme lors de son exécution. Si cette variable est définie, l'éditeur de liens s occupera de charger notre bibliothèque avant toutes les autres. L'utilité de tout ça? Si on charge une bibliothèque de fonction supplémentaire dans la mémoire d'un programme, contenant des fonctions portant exactement le même nom que les fonctions ayant été appelées par ce même programme, ce sont alors nos fonctions qui vont être exécutées à la place des fonctions d origines. Ce genre de pratique porte un nom, c est le «hooking». Autrement dit, créer une fonction portant le nom d'une fonction du système, et ordinairement appelée par un programme ; si nous pré-chargeons nos fonctions avant toutes les autres lors d'une exécution, ce sont nos fonctions qui auront la «priorité» pour s'exécuter. Voici un programme de démonstration qui va simplement afficher un UID lors de son exécution. Code Source C #include <stdio.h> #include <unistd.h> int main() { int i = getuid(); printf("(uid)=%i\n", i); return (0); } Vérifions à présent afin de mieux comprendre comment cela réagit. root~# gcc getuid.c root~#./a.out (uid)=0 root~# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk) 19
Le programme «id» inclut dans le système nous permet de vérifier que notre programme fonctionne correctement, étant donné que je suis bien «root» au moment ou j'exécute le programme. Je vais maintenant créer un nouvel utilisateur sur le système, me loguer sous cet utilisateur, et regarder l'uid qui m'a été attribué par le système. Nous allons ensuite commencer notre travail de contournement de fonction système. root~# adduser magicien User ID ('UID') [ defaults to next available ]: 951 Initial group [ users ]: Additional groups (comma separated) []: Home directory [ /home/magicien ] Shell [ /bin/bash ] Expiry date (YYYY-MM-DD) []: New account will be created as follows: --------------------------------------- Login name...: magicien UID...: 951 Initial group...: users Additional groups: [ None ] Home directory...: /home/magicien Shell...: /bin/bash Expiry date...: [ Never ] This is it... if you want to bail out, hit Control-C. Otherwise, press ENTER to go ahead and make the account. Creating new account... Changing the user information for magicien Enter the new value, or press ENTER for the default Full Name []: Magicien Room Number []: Work Phone []: Home Phone []: Other []: Changing password for magicien Enter the new password (minimum of 5, maximum of 127 characters) Please use a combination of upper and lower case letters and numbers. New password: Bad password: too short. Warning: weak password (enter it again to use it anyway). New password: Re-enter new password: Password changed. Account setup complete. root~# su magicien magicien~$ id uid=951(magicien) gid=100(users) groups=100(users) 20
Nous allons maintenant écrire une librairie et définir LD_PRELOAD avec le chemin de cette nouvelle librairie. Le but sera de faire afficher au programme «id» du système, ainsi qu'à notre programme écrit plus haut, la valeur «0» ; qui je le rappel est l UID du compte «root» sur Linux. Code Source C #include <stdio.h> int getuid() { return (0); } int geteuid() { return (0); } int getgid() { return (0); } Une fois compilé avec la commande «gcc -shared lib.c -o falseid.so», il ne nous reste plus qu'à charger notre nouvelle bibliothèque dans LD_PRELOAD, et vérifier si tout fonctionne comme nous le voulons. root~# su magicien magicien~$ pwd /root magicien~$ id uid=951(magicien) gid=100(users) groups=100(users) magicien~$ export LD_PRELOAD=/root/falseid.so magicien~$ id uid=0(root) gid=0(root) egid=100(users) groups=100(users) magicien~$ /root/a.out (id)=0 magicien~$ exit 21
Comme on peut l observer, notre détournement de fonction «getuid» fonctionne à merveille. Pour cette exemple, je n'ai fait que mettre en avant le principe final, mais sachez que nous pouvons faire bien plus que déconcerter des fonctions d'affichage d'uid ou de GID. Nous pouvons par exemple reprogrammer une fonction pour lui faire afficher un shell, copier le fichier /etc/shadow, et bien plus encore. En y repensant, on aurait même pu reprogrammer ptrace() afin qu'il retourne toujours «0», ce qui aurait eu pour effet d'annuler l'action réel de la fonction dans l'explication détaillé plus haut. Cela pourrait aussi servir à valider un logiciel en recodant certaines fonctions critique comme malloc(), en lui faisant retourner «NULL» dans tout les cas! Pour finir, il est bon de savoir que pour vider le contenu de LD_PRELOAD afin de rendre aux programmes leurs fonctionnement normal, il suffit simplement de taper «LD_PRELOAD=""» après avoir effectué les actions souhaitées. root~# LD_PRELOAD="" root~# id uid=951(magicien) gid=100(users) groups=100(users) 22
9. Contourner le Stripping Le stripping est une technique qui permet de détruire la «Table des Symboles» sous Linux. Une table de symboles contient entre autre les adresses des variables, les noms des fonctions et les labels. L'outil permettant d'effectuer cette action est «strip». La démonstration ci-dessous utilise un programme au hasard, il n y a pas de code à montrer parce que nous en avons pas besoin ici. Prenez n importe quelle bout de code ou programme et essayez, vous constaterez le même résultat. root~# gcc prog.c root~# objdump -d./a.out a.out: file format elf32-i386 Disassembly of section.init: 08048254 <_init>: 8048254: 55 push %ebp 8048255: 89 e5 mov %esp,%ebp 8048257: 83 ec 08 sub $0x8,%esp 804825a: e8 75 00 00 00 call 80482d4 <call_gmon_start> 804825f: e8 cc 00 00 00 call 8048330 <frame_dummy> 8048264: e8 c7 01 00 00 call 8048430 < do_global_ctors_aux> 8048269: c9 leave 804826a: c3 ret Disassembly of section.plt: [...] 08048354 <main>: 8048354: 8d 4c 24 04 lea 0x4(%esp),%ecx 8048358: 83 e4 f0 and $0xfffffff0,%esp 804835b: ff 71 fc pushl -0x4(%ecx) 804835e: 55 push %ebp 804835f: 89 e5 mov %esp,%ebp 8048361: 51 push %ecx 8048362: 83 ec 04 sub $0x4,%esp 8048365: 89 4d f8 mov %ecx,-0x8(%ebp) 8048368: 8b 45 f8 mov -0x8(%ebp),%eax 804836b: 83 38 01 cmpl $0x1,(%eax) [...] Comme nous pouvons le constater, tout semble normal. Nous allons à présent stripper ce programme et observer ce que cela produit. 23
root~# strip./a.out root~# objdump -d./a.out a.out: file format elf32-i386 Disassembly of section.init: 08048254 <.init>: 8048254: 55 push %ebp 8048255: 8048257: 89 e5 83 ec 08 mov sub %esp,%ebp $0x8,%esp 804825a: e8 75 0 [...] 080482b0 <.text>: 80482b0: 31 ed xor %ebp,%ebp 80482b2: 5e pop %esi 80482b3: 89 e1 mov %esp,%ecx 80482b5: 80482b8: 83 e4 f0 50 and push $0xfffffff0,%esp %eax 80482b9: 54 push %esp 80482ba: 52 push %edx 80482bb: 68 b0 83 04 08 push $0x80483b0 80482c0: 68 c0 83 04 08 push $0x80483c0 80482c5: 51 push %ecx 80482c6: 56 push %esi 80482c7: 68 54 83 04 08 push $0x8048354 80482cc: e8 bb ff ff ff call 804828c < libc_start_main@plt> 80482d1: f4 hlt 80482d2: 90 nop [...] Dans ce test, aucun symbole n'est présent. Vous pourriez vous dire : Mais en quoi cela est-il gênant? On va donc essayer d analyser ce programme avec «gdb». root~# gdb a.out (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) disass main No symbol table is loaded. Use the "file" command. (gdb) Et oui, il n y plus de symboles et donc plus aucune références! Plutôt ennuyeux lorsqu'on a un programme de plusieurs centaines de kilo octet à analyser. Il existe tout de même un outil capable de remettre en place la table des symboles, il se nomme «fenris». Mais voyons comment il est possible de se débrouiller sans table des symboles. 24
Voici un dump du code ASM de la section.text Code du Programme. Disassembly of section.text: 080482b0 <.text>: 80482b0: 31 ed xor %ebp,%ebp 80482b2: 5e pop %esi 80482b3: 89 e1 mov %esp,%ecx 80482b5: 83 e4 f0 and $0xfffffff0,%esp 80482b8: 50 push %eax 80482b9: 54 push %esp 80482ba: 52 push %edx 80482bb: 68 b0 83 04 08 push $0x80483b0 80482c0: 68 c0 83 04 08 push $0x80483c0 80482c5: 51 push %ecx 80482c6: 56 push %esi 80482c7: 68 54 83 04 08 push $0x8048354 80482cc: e8 bb ff ff ff call 804828c < libc_start_main@plt> 80482d1: f4 hlt 80482d2: 90 nop 80482d3: 90 nop 80482d4: 55 push %ebp 80482d5: 89 e5 mov %esp,%ebp 80482d7: 53 push %ebx 80482d8: 83 ec 04 sub $0x4,%esp 80482db: e8 00 00 00 00 call 80482e0 <puts@plt+0x44> 80482e0: 5b pop %ebx 80482e1: 81 c3 a4 12 00 00 add $0x12a4,%ebx 80482e7: 8b 93 fc ff ff ff mov -0x4(%ebx),%edx 80482ed: 85 d2 test %edx,%edx 80482ef: 74 05 je 80482f6 <puts@plt+0x5a> 80482f1: e8 86 ff ff ff call 804827c < gmon_start @plt> 80482f6: 58 pop %eax 80482f7: 5b pop %ebx 80482f8: c9 leave 80482f9: c3 ret 80482fa: 90 nop 80482fb: 90 nop 80482fc: 90 nop 80482fd: 90 nop 80482fe: 90 nop 80482ff: 90 nop 25
8048300: 55 push %ebp 8048301: 89 e5 mov %esp,%ebp 8048303: 83 ec 08 sub $0x8,%esp 8048306: 80 3d a8 95 04 08 00 cmpb $0x0,0x80495a8 804830d: 74 0c je 804831b <puts@plt+0x7f> 804830f: eb 1c jmp 804832d <puts@plt+0x91> 8048311: 83 c0 04 add $0x4,%eax 8048314: a3 a4 95 04 08 mov %eax,0x80495a4 8048319: ff d2 call *%edx 804831b: a1 a4 95 04 08 mov 0x80495a4,%eax 8048320: 8b 10 mov (%eax),%edx 8048322: 85 d2 test %edx,%edx 8048324: 75 eb jne 8048311 <puts@plt+0x75> 8048326: c6 05 a8 95 04 08 01 movb $0x1,0x80495a8 804832d: c9 leave 804832e: c3 ret 804832f: 90 nop 8048330: 55 push %ebp 8048331: 89 e5 mov %esp,%ebp 8048333: 83 ec 08 sub $0x8,%esp 8048336: a1 b4 94 04 08 mov 0x804 [...] On observe très facilement qu'à chaque fois des NOP apparaissent, c est en réalité la coupure entre chaque section. Cela nous permet déjà de connaitre le nombre de section, et donc de savoir combien de lignes il faudra analyser lorsque nous aurons trouvé le «main». Une autre chose à savoir est qu'il est vraiment très rare que nous puissions trouver des références de fonctions de type < gmon_start @plt-0x28> ou encore < libc_start_main@plt>. Dans une fonction aucune indication n'apparait, si un appel de fonction est présent il se fera comme d'habitude, à savoir quelque chose du type <puts@plt>, autrement dit directement par le nom de la fonction. 26
10. Obfuscation de Code en C L'obfuscation de code est une technique dont l objectif est de rendre aussi difficile que possible la compréhension d un code source. Il existe même des concours, comme le «International Obfuscated C Code Contest» qui possède son propre site internet : http://www.ioccc.org Dans un but didactique, je vais jouer avec la directive «#define» du préprocesseur C afin d alourdir légèrement la syntaxe du code généré. Code Source C #include <stdio.h> #define A int #define B main #define C printf #define D return #define Z "Bonjour Root...\n" A B(){C(Z);D (1337);} root~# gcc obfusc.c root~#./a.out Bonjour Root... root~# Comme on peut l'observer, c est vraiment un jeu d'enfant à mettre en œuvre. Il faut tout de même faire attention à bien comprendre que l objectif n est pas de protéger le code machine du programme, mais bien le code source. Le programme compilé sera structuré et exécuté de la même façon. 27