Gobox - HackTheBox

Comencé con un escaneo de Nmap para detectar puertos abiertos.

┌──(root💀kali)-[/home/kali/HTB/Gobux]
└─# nmap -sS --min-rate=5000 -n -vvv --open -Pn 10.10.11.113 -oG allPorts 
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-09-01 10:33 EDT
Happy 24th Birthday to Nmap, may it live to be 124!
Initiating SYN Stealth Scan at 10:33
Scanning 10.10.11.113 [1000 ports]
Discovered open port 8080/tcp on 10.10.11.113
Discovered open port 22/tcp on 10.10.11.113
Discovered open port 80/tcp on 10.10.11.113
Completed SYN Stealth Scan at 10:33, 0.37s elapsed (1000 total ports)
Nmap scan report for 10.10.11.113
Host is up, received user-set (0.047s latency).
Scanned at 2021-09-01 10:33:20 EDT for 1s
Not shown: 994 closed ports, 3 filtered ports
Reason: 994 resets and 3 no-responses
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE    REASON
22/tcp   open  ssh        syn-ack ttl 63
80/tcp   open  http       syn-ack ttl 63
8080/tcp open  http-proxy syn-ack ttl 63

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.48 seconds
           Raw packets sent: 1003 (44.132KB) | Rcvd: 997 (39.892KB)

Hice otro escaneo para saber la versión de cada puerto abierto encontrado.

┌──(root💀kali)-[/home/kali/HTB/Gobux]
└─# nmap -sC -sV -p22,80,8080 10.10.11.113 -oN targeted                  
Starting Nmap 7.91 ( https://nmap.org ) at 2021-09-01 10:33 EDT
Nmap scan report for 10.10.11.113
Host is up (0.066s latency).

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 d8:f5:ef:d2:d3:f9:8d:ad:c6:cf:24:85:94:26:ef:7a (RSA)
|   256 46:3d:6b:cb:a8:19:eb:6a:d0:68:86:94:86:73:e1:72 (ECDSA)
|_  256 70:32:d7:e3:77:c1:4a:cf:47:2a:de:e5:08:7a:f8:7a (ED25519)
80/tcp   open  http    nginx
|_http-title: Hacking eSports | 
8080/tcp open  http    nginx
|_http-title: Hacking eSports | Home page
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.36 seconds

Habían dos servidores web, el que corría por el puerto 80 tenía lo siguiente.

Al parecer no había nada interesante, en el segundo encontré algo distinto.

Habían dos “buffers” pero no tenía credenciales, intente ver si era vulnerable a SQLi pero no hubo suerte, me pedía que introduzca un correo.

Había un botón llamado “Forgot Password”, le di y me llevo a otro “buffer”.

Envíe una petición por GET y gracias a las cabeceras identifique que corría Go en el servidor web, esto me llamo la atención.

En este “buffer” también intenté SQLi pero igual no hubo suerte.

Me inventé un correo y lo introduje, me puso que se envió.

Quise interceptar la petición para ver como corre todo por detrás, para ello use burp.

Sabiendo que corre GO en el servidor me acordé de nmap, vi que me reportaba un título de la página sospechoso de una vulnerabilidad.

Busque si podía ser vulnerable a SSTI un servidor con GO y encontré lo siguiente.

Se podía identificar y confirmar si era vulnerable con “ “, inmediatamente lo probé en el campo de email y me reporto lo siguiente.

Al parecer si es vulnerable, me reporto en texto plano unas credenciales que al parecer podían ser de los “buffers” del inicio, las introduje y me redirigió a una página con un código.

Lo que más me llamo la atención es la función DebugCmd.

Al parecer me permitía ejecutar código en el sistema pasándole los argumentos, lo probé en burp.

Y funciono, intente ver la IP que tenía, pero no existía el comando ifconfig, también quise verificar si la máquina podía tener conectividad conmigo pero tampoco existía el comando ping ni el comando wget.

Esto me hizo pensar que estaba en un contenedor, mire el archivo /proc/net/fib_trie y efectivamente estaba en un contenedor.

Tras un tiempo desesperado encontré que tenía el comando aws habilitado, eso me llamo la atención, esto me permitiría enumerar y copiar depósitos, realmente se pueden hacer más cosas, pero no me interesa.

Probé a enumerar los depósitos y encontré uno llamado website.

Accedí a él y encontré algo que me llamo mucho la atención, los archivos que habían al parecer se estaban comunicando con el servidor web que corre por el puerto 80, entonces pensé que si conseguía incluir algún archivo podía tener acceso a él desde el servidor web, antes de eso probé a enumerar las credenciales de aws que se almacenaban en ~/aws/credentials.

Y pude enumerarlas.

Me servían para tener conectividad desde mí máquina, pero eso no me interesaba, así que probé a incluir una webshell en PHP al servidor web, tuve que codificarla en urlencode sino no me dejaba, la exporte a /tmp con el nombre reversess.php.

Y la conseguí incluirla en el depósito con el parámetro cp de aws.

Fui al servidor web y gané ejecución de código arbitrario.

Para entablarme una reverse shell cree un archivo txt con el código que me iba a permitir ganar acceso al sistema y abrí un servidor web por el puerto 8000.

Le hice un curl desde la webshell.

Y ahora tan solo pipee el código con bash y gané acceso como el usuario www-data.

Hice un tratamiento de la TTY y ya pude visualizar la “flag” del usuario.

---

ESCALADA DE PRIVILEGIOS

Ahora solo faltaba la escalada de privilegios, enumere los privilegios SUID pero no encontré nada interesante.

Enumerando un poco más encontré un servidor web en escucha por el puerto 8000, lo que más me llamo la atención es que solo es accesible desde localhost, decidí investigar en los módulos de nginx y encontré uno que me llamo la atención mucho, llamado 50-backdoor.conf, le hice un cat y me reporto una ruta en texto claro, tras investigarlo en internet encontré que había una puerta trasera.

Pero para activarla necesitaba el parámetro que se configuró, para encontrar el parámetro necesitaba una copia, para ello filtre con find el nombre del archivo y lo encontré.

Le hice un strings y filtré por run para encontrarlo de una manera más rápida y lo conseguí encontrar.

Ahora solo faltaba enviar una petición al servidor en localhost haciendo uso del parámetro encontrado y ganaría ejecución de comando como el usuario root.

Y ya pude visualizar la “flag” de root.