PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.4.18 (Ubuntu)2222/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)| ssh-hostkey:
| 2048 c4:f8:ad:e8:f8:04:77:de:cf:15:0d:63:0a:18:7e:49 (RSA)| 256 22:8f:b1:97:bf:0f:17:08:fc:7e:2c:8f:e9:77:3a:48 (ECDSA)|_ 256 e6:ac:27:a3:b5:a9:f1:12:3c:34:a5:5d:5b:eb:3d:e9 (ED25519)Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
#Nada en UDP
De aquí vemos abiertos dos puertos:
80/TCP: HTTP, el potencial vector de entrada.
2222/TCP: SSH, podemos mirar la versión para ver si hay vulnerabilidades.
Respecto a la versión de SSH (OpenSSH 7.2p2), encontramos una vulnerabilidad que permite enumerar usuarios del sistema (CVE-2016-6210), aunque finalmente resulta no funcionar, por lo que nos centramos en el puerto 80.
Al entrar a la página, encontramos una imagen al lado de un texto “Don’t Bug Me!”, pero nada relevante ni en la imagen ni en el código fuente. Hacemos fuerza bruta para encontrar algo:
Al ejecutar ffuf, encontramos el directorio cgi-bin, que según Google corresponde al estándar Common Gateway Interface, usado para que el servidor ejecute scripts usando como parámetros datos contenidos en la solicitud HTTP.
Ahora sabemos que el directorio contendrá scripts en algún lenguaje, así que buscamos alguno:
curl http://10.10.10.56:80/cgi-bin/user.sh
Content-Type: text/plain
Just an uptime test script
20:55:58 up 5:56, 0 users, load average: 0.00, 0.02, 0.00
Tras un rato buscando qué puede hacerse con el script, descubro que un archivo .sh (ejecutado potencialmente con Bash) dentro de cgi-bin (con parámetros pasados al script a través de las cabeceras HTTP) hacen a la máquina vulnerable a Shellshock (Vulnerabilidad de la que viene el propio nombre de la máquina).
Según InfosecWriteups, Shellshock es una vulnerabilidad de Bash que permite que los atacantes ejecuten código a través de las cabeceras HTTP por una forma errónea de parsearlas.
Los scripts CGI dependen de las cabeceras HTTP para tomar parámetros. Cuando Apache pasa el request a Bash, este toma las cabeceras y las guarda en variables de entorno por si el script las necesita usar.
El problema del que viene la vulnerabilidad es un mal parseo de headers por parte de Bash, que permite que, además de guardar parte de un header en una variable de entorno, se ejecute un segundo comando.
Esto se hace definiendo una función en Bash mientras se guarda como variable de entorno, lo que hace que el shell no deje de parsear y ejecute lo que venga después:
Veo que shelly puede ejecutar /usr/bin/perl como root sin necesidad de contraseña.
1
2
3
4
5
6
shelly@Shocker:/usr/lib/cgi-bin$ sudo -l
Matching Defaults entries for shelly on Shocker:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User shelly may run the following commands on Shocker:
(root) NOPASSWD: /usr/bin/perl
Pruebo a iniciar un shell desde perl:
1
2
3
shelly@Shocker:/usr/lib/cgi-bin$ sudo /usr/bin/perl
exec '/bin/bash', '-i';
#Sin output, no funciona.
No funciona, pero pruebo a crear un script que haga lo mismo:
