Insecure DockerLabs (Hard)
Instalación
Cuando obtenemos el .zip nos lo pasamos al entorno en el que vamos a empezar a hackear la maquina y haremos lo siguiente.
unzip insecure.zipNos lo descomprimira y despues montamos la maquina de la siguiente forma.
bash auto_mount.sh insecure.tarInfo:
## .
## ## ## ==
## ## ## ## ===
/""""""""""""""""\___/ ===
~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~
\______ o __/
\ \ __/
\____\______/
___ ____ ____ _ _ ____ ____ _ ____ ___ ____
| \ | | | |_/ |___ |__/ | |__| |__] [__
|__/ |__| |___ | \_ |___ | \ |___ | | |__] ___]
Estamos desplegando la máquina vulnerable, espere un momento.
Máquina desplegada, su dirección IP es --> 172.17.0.2
Presiona Ctrl+C cuando termines con la máquina para eliminarlaPor lo que cuando terminemos de hackearla, le damos a Ctrl+C y nos eliminara la maquina para que no se queden archivos basura.
Escaneo de puertos
Info:
Si nos metemos en la pagina que viene con el puerto 80, veremos que podremos descargar un "software" que tiene la pagina, si nos lo descargamos veremos que el archivo se llama secure_software.
Si vemos que tipo de archivo es, ya que no viene con una extension:
Info:
Vemos que es un .elf un ejecutable para linux, si lo ejecutamos parece ser que esta a la escucha generando un socket a la espera de alguna peticion, pero no hace mucho mas.
Podremos probar a revisar las seguridades de la aplicacion por si fuera vulnerable a un Buffer Overflow y poder sobreescribir la aplicacion en alguna direccion de memoria en la que se pueda escribir haciendo ingenieria inversa:
Info:
Vemos que las protecciones mas criticas estan desactivadas, por lo que podremos sobrescribir algun codigo de memoria que este dentro de la aplicacion, por lo que utilizaremos GDB pero utilizando un entorno llamado PEDA dentro del GDB, la cual nos proporciona herramientas para facilitar este tipo de explotacion.
Ingenieria inversa (secure_software)
Instalacion de GDB con PEDA/GDB con pwndbg
Lo que primero tendremos que hacer sera lo siguiente:
Y si iniciamos el programa con GDB pasandole como parametro el programa, se nos pondra el gdb-peda...
Pero si diera error por las versiones, podremos instalar esta otra herramienta que es mas poderosa:
Y si iniciamos gdb veremos lo siguiente:
Info:
Comprobacion de desbordamiento de Buffer
En el host, generamos una cadena de caracteres diseñada para intentar desbordar el buffer de la aplicación. Esto se logra con la herramienta pattern_create.rb:
Info:
Este patrón se usará como entrada en la aplicación para identificar cómo se maneja el buffer.
Conectamos al servicio vulnerable usando netcat:
Host:
Info:
Introducimos los 400 caracteres generados previamente. Para automatizar este paso, creamos un script en Python:
step1.py
Este script automatiza la conexión y el envío del patrón:
Antes de ejecutar el script, inicia la aplicación en GDB (preferentemente con pwndbg):
gdb (pwndbg)
Ahora en el host ejecutamos:
Resultado esperado en GDB: La aplicación debería mostrar un error de segmentación (SIGSEGV), indicando que el buffer fue desbordado. Observa el valor de EIP en los registros, que reflejará parte del patrón enviado.
Y en el GDB veremos algo asi:
Veremos que hemos conseguido pasarnos del buffer y nos muestra la direccion de memoria que nos importa llamado EIP que seria 0x41306b41.
Identificación del Offset
Para determinar el desplazamiento exacto (offset) donde ocurre la sobrescritura, usamos pattern_offset.rb, proporcionando la dirección en hexadecimal obtenida en EIP:
Host
Info:
Esto indica que el offset es de 288 bytes, por lo que haremos lo siguiente, para automatizar todo este proceso:
step2.py
Creamos un nuevo script que utiliza el offset para sobrescribir el registro EIP con un valor controlado (BBBB):
Antes, tendremos que hacer lo siguiente en GDB para iniciar la aplicacion:
gdb (pwndbg)
Y ahora en el host ejecutaremos el script:
host
Resultado esperado en GDB: El registro EIP ahora debería estar sobrescrito con 0x42424242 (BBBB).
Por lo que veremos lo siguiente en el GDB:
Vemos que funciona y sobrescribe con B el EIP por lo que ahora tendremos que injectar un shellcode para que se nos haga una reverse shell al servidor aprovechando esta vulnerabilidad.
Verificación del Espacio Después del EIP
Queremos comprobar qué ocurre con los datos introducidos después del EIP. Para ello, añadimos datos adicionales (CCCC) al final del payload creando una variable after_eip y automatizaremos todo esto con un script:
step3.py
Ahora en el GDB tendremos que poner de nuevo run para ejecutar la aplicacion:
gdb (pwndbg)
Y en el host ejecutamos el script:
host
En el GDB tendremos que ver algo asi:
Resultado esperado: En GDB, verifica la pila (stack) para comprobar que los CCCC aparecen después del EIP. Usa este comando (x/300wx $esp)
Si ejecutamos x/300wx $esp para ver la información que hay en el pila vemos que nuestras Cs se están introduciendo al principio de la pila (stack), por lo que en este punto lo que debemos hacer es encontrar un OpCode el cual nos permita realizar un salto al ESP, es decir al principio de la pila.
Info:
Y solo nos interesara estos de aqui:
Vemos que se esta realizando todo correctamente al principio de la pila y llenando esos huecos con la C que se corresponden con 0x43434343.
Identificación del OpCode para JMP ESP
Para redirigir la ejecución al principio de la pila (ESP), necesitamos identificar el código de operación (opcode) de un salto (JMP ESP). Usamos nasm_shell.rb:
Nos metera en una shell interactiva de la herramienta:
Y ejecutamos lo siguiente:
Info:
Esto indica que el opcode para JMP ESP es FFE4.
Ahora usaremos objdump para saber cual es la dirección de memoria la cual nos permite realizar el JMP ESP
Info:
Y veremos que la direccion de memoria es 0x08049213.
Generar un Shellcode (Reverse Shell)
Ahora generaremos un shellcode con msfvenom de la siguiente forma:
El flag -b '\x00\x0a\x0d' excluye los caracteres nulos y de salto de línea, ya que podrían interrumpir la ejecución del payload. El flag -f py genera el código en formato Python para facilitar su inclusión en scripts.
Info:
Obtener una shell como el usuario securedev
Por lo que crearemos un script para automatizar todo esto y tambien añadiremos en el script una cadena de NOPS para que salte todo hasta nuestro shellcode y se ejecute nuestra rever shell.
step4.py
Desbordamiento del buffer: El payload comienza con A's para llenar el buffer hasta alcanzar el offset donde se sobrescribe el EIP (288 en este caso).
Dirección de retorno: Utilizamos la dirección de una instrucción jmp esp para redirigir la ejecución hacia nuestro shellcode. Esta dirección se obtiene mediante análisis del binario vulnerable usando herramientas como gdb.
NOP sled: Se añade una "pista" de NOPs (\x90) antes del shellcode para garantizar que cualquier variación en la dirección de salto no interfiera con la ejecución del payload.
Por lo que ahora tendremos que hacer lo siguiente:
gdb (pwndbg)
host
Y finalmente en otra terminal de nuestro host tendremos que ejecutar el script y asi obtender la shell:
Y si nos vamos a la escucha veremos lo siguiente:
Escalate user johntheripper
Primero tendremos que sanitizar la shell (TTY):
Si listamos la misma carpeta en la que estamos, podremos ver un archivo llamado hashfile, su contenido seria el siguiente:
Si intentamos crackearlo con john no conseguiremos nada, pero si seguimos enumerando, encontraremos lo siguiente en la siguiente ruta:
Primero buscaremos archivos creados por el usuario johntheripper:
Info:
Vemos que hay un archivo interesante en esa ruta y ese archivo contiene lo siguiente:
Podemos deducir que alguna de esas palabras puede ser la contraseña del usuario johntheripper, por lo que nos descargaremos un script para hacer fuerza bruta a un usuario con su:
URL = Download suBrutefoce.sh
Ahora cogemos esas palabras y las metemos en un archivo .txt:
dic.txt
Y ahora utilizaremos la herramienta de la siguiente forma:
Info:
Por lo que vemos esa es la contraseña, por lo que haremos lo siguiente:
Y metemos la contraseña tset0tevst!, por lo que ya seremos dicho usuario.
Escalate Privileges
Si buscamos permisos SUID vemos lo siguiente:
Info:
Vemos que tenemos un archivo en nuestra carpeta llamado show_files y que tiene permisos SUID.
Si por ejemplo ejecutamos dicha aplicacion de esta forma:
Info:
Por lo que vemos nos lista los archivos cuando lo ejecutamos, por lo que haremos lo siguiente.
Primero nos vamos a pasar la herramienta a nuestra maquina atacante, para analizarla mucho mejor:
Maquina victima
Maquina atacante
Ghidra Tool
Podremos utilizar una herramienta para analizar un binario compilado o este tipo de cosas, para poder verlo en texto plano y decompilarlo, si utilizamos Ghidra de la siguiente manera:
Y lo ejecutamos:
Se nos abrira una aplicacion, en la cual tendremos que cargar el archivo que nos pasamos a la maquina atacante, de la siguiente forma:
Le daremos al siguiente boton:
Se nos abrira otra ventana mas grande en la cual tendremos que cargar el archivo show_files, le daremos a File -> Import File... -> seleccionamos el archivo a decompilar y nos mostrara la informacion en texto plano de basicamente la funciona de la aplicacion en la parte derecha del programa, viendo lo siguiente:
PATH Hijacking
Por lo que vemos esta ejecutando el ls de forma insegura, ya que no pilla la ruta absoluta, por lo que podremos realizar la tecnica de PATH Hijacking, de la siguiente forma, nos iremos a la maquina victima y haremos esto:
Y con esto ya habremos puesto con permisos SUID la bash, podremos verificarlo de la siguiente forma:
Info:
Por lo que ahora pondremos lo siguiente:
Y con esto ya seremos root.
Last updated