Bicho DockerLabs (Easy)

Instalación

Cuando obtenemos el .zip nos lo pasamos al entorno en el que vamos a empezar a hackear la maquina y haremos lo siguiente.

unzip bicho.zip

Nos lo descomprimira y despues montamos la maquina de la siguiente forma.

bash auto_deploy.sh bicho.tar

Info:

                            ##        .         
                      ## ## ##       ==         
                   ## ## ## ##      ===         
               /""""""""""""""""\___/ ===       
          ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
               \______ o          __/           
                 \    \        __/            
                  \____\______/               
                                          
  ___  ____ ____ _  _ ____ ____ _    ____ ___  ____ 
  |  \ |  | |    |_/  |___ |__/ |    |__| |__] [__  
  |__/ |__| |___ | \_ |___ |  \ |___ |  | |__] ___] 
                                         
                                     

Estamos desplegando la máquina vulnerable, espere un momento.

Máquina desplegada, su dirección IP es --> 172.17.0.2

Presiona Ctrl+C cuando termines con la máquina para eliminarla

Por lo que cuando terminemos de hackearla, le damos a Ctrl+C y nos eliminara la maquina para que no se queden archivos basura.

Escaneo de puertos

Info:

Veremos que solo hay un puerto 80 abierto en el que aloja una pagina web por lo que vamos a entrar dentro de la misma para ver que contiene.

Veremos que hay una web por defecto alojada por apache2 pero si vemos en el escaneo de nmap veremos que redirige a un dominio en concreto llamado bicho.dl por lo que vamos añadirlo a nuestro archivo hosts.

Lo guardamos y volvemos a entrar en la pagina pero esta vez mediante el dominio.

Veremos lo siguiente:

Vemos que esta pagina esta soportada por el software llamado wordpress, por lo que vamos a utilizar la herramienta llamada wpscan.

wpscan

Info:

Veremos que hemos descubierto un usuario llamado bicho por lo que vamos a intentar crackear la contraseña de dicho usuario.

Info:

Pero no encontraremos nada, tampoco ningun plugin que pueda ser vulnerable ni nada, por lo que vamos a seguir realizando un poco de fuzzing.

Gobuster

Info:

Veremos un archivo bastante interesante llamado debug.log, vamos a entrar dentro de dicho archivo a ver que encontramos.

Veremos que podemos visualizar los logs y nos aparecera la fuerza bruta que hemos realizado anteriormente con wpscan, vamos a probar si podemos realizar un Log Poisoning de la siguiente forma:

De primeras vemos que se esta mostrando con un <pre> la informacion del usuario, la IP y el User-Agent, vamos a probar a capturar la peticion del login de wordpress para modificar el User-Agent e intentar injectar codigo PHP para ver si se visualiza en los logs.

Cuando capturemos la peticion, veremos algo asi:

PETICION:

Recargamos el debug.log y veremos lo siguiente:

Veremos que se esta injectando, por lo que esta funcionando, pero si ponemos un exec directamente, no va a funcionar, por lo que vamos a codificar el payload y ejecutarlo de la siguiente forma:

Ahora la peticion tendra que quedar de la siguiente forma:

Antes de enviarla nos pondremos a la escucha:

Cuando la enviemos, tendremos que recargar la siguiente pagina:

Si volvemos a donde tenemos la escucha veremos lo siguiente:

Veremos que hemos obtenido acceso con el usuario www-data por lo que vamos a sanitizar la shell.

Sanitización de shell (TTY)

Escalate user app

Si listamos los puertos del servidor veremos lo siguiente:

Info:

Veremos un puerto interesante que esta en local que seria el 5000 vamos a pasarnos dicho puerto realizando un portforwarding a nuestro host pero como no tendremos el binario socat en la maquina victima, vamos a pasarnos el binario a la maquina victima de la siguiente forma:

Ahora en la maquina victima nos lo descargaremos:

Una vez echo esto vamos a utilizar dicho binario para realizar la tunelizacion del puerto:

Info:

Veremos que nos falta una libreria, por lo que tambien nos la vamos a importar a la maquina victima de la siguiente forma.

HOST

Info:

Vamos a compiar dicho archivo a nuestra carpeta actual:

Echo esto vamos a volvernos abrir un servidor de python3 para pasarnos el archivo.

VICTIM

Ahora vamos a exportar la variable de entorno.

Vamos a comprobar que lo esta pillando de forma correcta:

Info:

Vemos que nos lo esta pillando bien, por lo que ahora si, vamos a ejecutarlo:

Ahora si vamos a nuestro host y ponemos la siguiente ruta que hemos expuesto:

Info:

Veremos que esta funcionando, por lo que vamos a realizar un poco de fuzzing a ver que encontramos.

Gobuster

Info:

Veremos que nos saco un directorio bastante interesante llamado console pero de primeras vemos que esta con un 400 de error, esto no significa que no exista, si no que algun parametro en la peticion esta mal formado y sabiendo que es un servidor Flask podemos deducir por que puede ser, si notros intentamos entrar en dicho servidor veremos lo siguiente:

Por lo que vamos a probar a meter en la cabecera de la peticion el Host adecuado, para que se cera que se esta haciendo a nivel local.

Info:

Vemos que esta vez no nos esta dando el error 400 por lo que vamos a capturar la peticion con BurpSuite y modificar el Host desde el mismo para que nos redirija de forma correcta a la pagina y podamos visualizarlo.

Cuando hayamos capturado la peticion veremos algo asi:

Y lo tendremos que dejar asi:

Ahora si le damos directamente al boton de Intercept on para que se ponga en off y volvemos a la pagina veremos lo siguiente:

Vemos que ha funcionado, ahora estamos viendo una pagina en la que podemos ejecutar lo que parece codigo en python vamos a probar a injectar algun comando basico:

Info:

Veremos que esto se esta ejecutando mediante el usuario app pero cada vez que tengamos que ejecutar un comando tendremos que capturarlo con BurpSuite y cambiarle el Host por que si no, no va a funcionar.

Vamos a crearnos una reverse shell con el siguiente payload:

Antes de enviarlo nos pondremos a la escucha con nc de la siguiente forma:

Ahora cuando enviemos dicho payload y lo capturemos con BurpSuite cambiemos el Host al adecuado y le demos al boton de dejar de interceptar y volvemos a donde tenemos la escucha veremos lo siguiente:

Vemos que hemos obtenido una shell con el usuario app, vamos a sanitizar la shell.

Sanitización de shell (TTY)

Escalate user wpuser

Si hacemos sudo -l veremos lo siguiente:

Vemos que podemos ejecutar el binario wp como el usuario wpuser por lo que vamos a ver que hace dicho binario.

Si buscamos informacion sobre dicho binario veremos que podemos ejecutar comando con el binario bajo el usuario wpuser en este caso, pero si intentamos algo asi:

Veremos que nos da un error de que el PATH al que esta intentando acceder dicho usuario donde contiene el wordpress no es accesible o no esta bien configurado, si nosotros le pasamos como parametro el PATH donde esta el Wordpress tampoco nos dejara ya que hay algo en la maquina que no lo esta permitiendo:

Info:

Pero esto tiene una facil solucion, podemos descargarnos los archivos del wordpress con dicho usuario en una carpeta en tmp para simular que es un wordpress de la siguiente forma:

Una vez creado la carpeta dandole los permisos necesarios y metiendonos dentro de la misma, haremos lo siguiente:

Con esto lo que haremos sera descargar todo el contenido de wordpressa dicha carpeta, una vez que se haya descargado todo, moveremos el archivo de configuracion de la DDBB para que tenga el nombre que necesita para wordpress.

Esto esta claro que estara vacio a nivel de credenciales, no podra realizar la conexion real a la DDBB, ya que si intentamos esto:

Nos va a dar un error de que no consigue acceder a la DDBB mediante el archivo de configuracion de wordpress, pero antes de realizar lo siguiente le daremos permisos para que podamos hacer despues una cosa.

Ahora con estos permisos vamos a ir a la otra terminal con la que tenemos el usuario www-data y vamos a realizar lo siguiente:

Echo esto lo que estaremos haciendo sera pasar la configuracion de la DDBB a la de nuestro wordpress falso, por lo que si nos vamos a la otra terminal y ejecutamos el siguiente comando, si podra establecer una conexion con la DDBB y podremos ejecutar comandos como el usuario wpuser:

Info:

Veremos que ha funcionado, por lo que vamos a ejecutarnos una reverse shell de la siguiente forma:

Antes de ejecutarlo nos pondremos a la escucha:

Ahora si ejecutamos el comando y volvemos a donde tenemos la escucha veremos lo siguiente:

Vemos que ha funcionado por lo que seremos el usuario wpuser y vamos a sanitizar la shell.

Sanitización de shell (TTY)

Ahora leeremos la flag del usuario.

user.txt

Escalate Privileges

Si hacemos sudo -l veremos lo siguiente:

Veremos que podemos ejecutar el script /opt/scripts/backup.sh como el usuario root por lo que vamos a investigar que hace.

Si leemos el codigo veremos lo siguiente:

Vemos que puede tener una vulnerabilidad en el script, que es el echo de concatenar comandos, vamos a probar a realizar lo siguiente a ver si funciona.

Info:

Vemos que efectivamente funciona y nos pondra que es root por lo que vamos a establecer la bash con permisos SUID.

Info:

Vemos que ha funcionado, vamos a comprobarlo de la siguiente forma:

Info:

Vemos que efectivamente ha funcionado, por lo que haremos lo siguiente para ser root.

Info:

Con esto ya seremos root por lo que leeremos la flah de root:

root.txt

PreviousBalufood DockerLabs (Easy)NextGallery DockerLabs (Hard)

Last updated