Reconocimiento

Empezamos con nmap para ver los puertos abiertos de la máquina:

1

 nmap -p- --open -T5 -Pn -n 10.10.11.194 -oG openTCPports

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

## Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-14 15:28 CET
## Nmap scan report for 10.10.11.194
## Host is up (0.048s latency).
## Not shown: 62421 closed tcp ports (conn-refused), 3111 filtered tcp ports (no-response)
## Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
## PORT     STATE SERVICE
## 22/tcp   open  ssh
## 80/tcp   open  http
## 9091/tcp open  xmltec-xmlmail
## 
## Nmap done: 1 IP address (1 host up) scanned in 15.92 seconds

Ejecuto la utilidad “grePorts” para obtener los puertos abiertos directamente en la “clipboard”:

1

 grePorts

1

## [!] Open ports: 22,80,9091

Y ejecutamos una serie de scripts de reconocimiento con nmap para ver los servicios disponibles y su versión:

1

 nmap -p22,80,9091 -sVC -oN servicesTCPports 10.10.11.194

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

## Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-14 15:33 CET
## Nmap scan report for soccer.htb (10.10.11.194)
## Host is up (0.047s latency).
## 
## PORT     STATE SERVICE         VERSION
## 22/tcp   open  ssh             OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
## | ssh-hostkey: 
## |   3072 ad0d84a3fdcc98a478fef94915dae16d (RSA)
## |   256 dfd6a39f68269dfc7c6a0c29e961f00c (ECDSA)
## |_  256 5797565def793c2fcbdb35fff17c615c (ED25519)
## 80/tcp   open  http            nginx 1.18.0 (Ubuntu)
## |_http-title: Soccer - Index 
## |_http-server-header: nginx/1.18.0 (Ubuntu)
## 9091/tcp open  xmltec-xmlmail?
## | fingerprint-strings: 
## |   DNSStatusRequestTCP, DNSVersionBindReqTCP, Help, RPCCheck, SSLSessionReq, drda, informix: 
## |     HTTP/1.1 400 Bad Request
## |
## ...

Vemos un dominio al que apunta el servidor por el puerto 80, por lo que lo inlcuimos en nuestro archivo hosts. Vemos que además hay un servicio en el puerto 9091 relacionado con correo electrónico “xmltec-xmlmail?” que nmap no es capaz de reconocer.

Vamos a empezar echando un vistazo a la página web y veremos después.

Obteniendo acceso a la máquina víctima

La página principal no tiene contenido relevante, por lo que vamos a enumerar recursos disponibles o subdominios válidos vamos a usar la herramienta gobuster:

1

 gobuster dir -w /usr/share/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -u http://soccer.htb/

Vemos un directorio “tiny/” al que podemos acceder y nos lleva a la página de un gestor de ficheros al que podemos acceder con las credenciales de administración por defecto admin/admin@123. Además podemos obtener información relevante como que por detrás se está ejecutando php.

Ganando RCE

Una vez que hemos accedido lo primero que se me ocurra es subir un fichero y ver si puedo acceder desde el navegador y el contenido se ejecuta … y efectivamente:

He de decir que hay una tarea cron por detrás que elimina aquello que subamos al cabo de unos minutos. Ahora vamos a subir un simple fichero php que nos permita obtener ejecución arbitraria de comandos (RCE) y por ende una reverse shell.

Escalada de privilegios … (a medias)

La escalada de privilegios es sencilla; haciendo una breve búsqueda por posibles agujeros del sistema, nos encontramos con lo siguiente:

Sí, el binario de bash tiene permisos suid, por lo que haciendo lo siguiente, ya podemos obtener las flags de usuario y root:

Escalada de privilegios … (completa)

NOTA: Resulta que la máquina no se hace del todo así … ¿os acordáis del puerto del principio? El 9091. Me extrañó mucho que la máquina tuviera el suid en el binario de bash así de primera, y efectivamente debió ser porque los otros usuarios ya lo habían conseguido…

De todos modos, para ser honesto volví a hacer la máquina de nuevo, lo que me sirvió para aprender a hacer pentesting de web-socket y a entender como funcionan … ¡es increíble! adjunto algunas capturas del camino a seguir:

Como me quedé extrañado con la resolución, miré el foro de discusión de la plataforma y vi que hablaban sobre otro subdominio; miré el fichero hosts y … eureka… no había completado la máquina del todo

Accediendo a ese subdominio me registré y comprobé que la petición era enviada a un web socket ( el puerto desconocido de antes)

Con websocat establecí comunicación para asegurarme y efectivamente me devolvía la misma respuesta al introducir cualquier cadena de texto. Echando un vistazo al fuente de la página se tramita un apartado “id” y había visto antes que se estaba ejecutando mysql en la máquina víctima, lo que me hizo pensar en una SQLi.

Encontré por internet un script e información con la que acontecer la inyección a través del websocket, por lo que una vez ejecutado, solo tuve que extraer la información. Básicamente el programa actúa de intermediario y traduce las peticiones.

Podemos ver usuario y contraseña, lo cual nos servirá para establecer conexión a través de ssh.

La escalada de privilegios es similar a la anterior: abusamos de los privilegios como root y a raíz de eso habilitar la flag suid en bash. Lo hacemos con un script llamado doas (me costó la misma vida encontrarlo en la máquina).