Write-ups

Resolución del CTF GIMNASIO

💢CTF DISPONIBLE EN TheHackersLabs💢

❌Nombre: GIMNASIO
📈Nivel: Profesional
💻OS: Linux
💢Caregoría: Seguridad Ofensiva
🙋🏽‍♂️Creador: d4redevil
https://thehackerslabs.com/gimnasio/

Enumeración

Escaneo de puertos

Realizamos un escaneo de todos los puertos para saber cuáles están activos.
Los parámetros utilizados son:

  • -p- : Escaneo de todos los puertos. (65535)
  • -sS : Realiza un TCP SYN Scan para escanear de manera rápida que puertos están abiertos.
  • -sC : Realiz una escaneo con los scripts basicos de reconocimiento
  • -sV : Realiza un escaneo en buqueda de los servicios
  • –min-rate 5000: Especificamos que el escaneo de puertos no vaya más lento que 5000 paquetes por segundo, el parámetro anterior y este hacen que el escaneo se demore menos.
  • -n: No realiza resolución de DNS, evitamos que el escaneo dure más tiempo del necesario.
  • -Pn: Deshabilitamos el descubrimiento de host mediante ping.

Los servicios detectados son:

  • 22/tcp: OpenSSH 9.2p1 Debian 2+deb12u4 (protocol 2.0)
  • 80/tcp: Apache httpd 2.4.62 ((Debian))
  • Puerto 3000: Servicio no reconocido, pero parece ser Gitea (plataforma de gestión de repositorios Git).

Puerto 80: Sitio Web del Gimnasio

Al acceder al puerto 80, encontramos un sitio web de un gimnasio llamado Neogym.

Acciones realizadas:

  1. Registramos el dominio neogym.thl en el archivo /etc/hosts: echo "192.168.1.20 neogym.thl" >> /etc/hosts
  1. Exploramos el sitio web y encontramos un formulario de contacto vulnerable a XXE (External Entity Injection). Os dejo mas sobre XXE (External Entity Injection) en el siguiente articulo.
  1. Interceptamos la petición del formulario con Burp Suite y confirmamos que los datos se envían en formato XML.

Explotación de XXE:

  1. Modificamos la petición XML para leer archivos del sistema, como /etc/passwd.
  1. Leemos el archivo .bash_history del usuario steve y encontramos una referencia a un archivo credenciales.txt.
  1. Credenciales obtenidas:
  • Usuario: steve
  • Contraseña: Sup3rP4$sw0rd123!

Fuzzing de Subdominios

Realizamos fuzzing de subdominios:
Encontramos el subdominio admin.neogym.thl. Registramos el subdominio en /etc/hosts:

Acceso al Sistema de Gestión de Socios

  1. Accedemos a admin.neogym.thl y utilizamos las credenciales de steve para iniciar sesión.
  1. Encontramos un formulario para registrar nuevos socios, vulnerable a SQL Injection.
  1. Interceptamos la petición con Burp Suite y confirmamos que el motor de base de datos es PostgreSQL.

Explotación de SQL Injection:

  1. Utilizamos un script que he creado basado en tiempo para enumerar las bases de datos: Dejo aqui el script https://github.com/CuriosidadesDeHackers/Neogym-Data-Extractor

Obtención de Credenciales

  1. Extraemos los usuarios y contraseñas de la tabla users:
    • Usuario: david
    • Hash de contraseña: $2y$10$93725bcf4547d4a46bbffdb5388d04384d8c2d5d2d388abcf88f27bda8ca43343bdbdb987e821c7773b3858fef3e2683da3c

Rompemos el hash con John the Ripper:

Realizamos fuerza bruta con Hydra para encontrar usuarios que reutilicen la contraseña:

  • Usuario: james
  • Contraseña: manchesterunited

Entramos por ssh

Enumeramos permisos de sudo y encontramos que james puede ejecutar perl como el usuario kyle:

  1. Escalamos al usuario kyle gracias a la utilización de Gtfobins.

Elevación de Privilegios

  1. Enumeramos permisos de sudo para kyle y encontramos que puede ejecutar un script de Python como root:

Script: /usr/bin/python3 /opt/scripts/systemcheck.py

  1. Analizamos el script systemcheck.py y encontramos que ejecuta full_check.sh, el cual a su vez llama a start_server.sh de forma relativa.

Miramos con el comando container-inspect sobre el cualquiera de los contenedores, podemos encontrar las variables de entorno con las credenciales para conectarnos a la base de datos.

sudo /usr/bin/python3 /opt/scripts/systemcheck.py container-inspect gitea

Nos conectamos a la base de datos.

Y encontramos el usuario adminitrador.

Luego, ejecutamos el siguiente comando para crear un formato valido:

cat hash  | while read data; do digest=$(echo "$data" | cut -d'|' -f1 | xxd -r -p | base64); salt=$(echo "$data" | cut -d'|' -f2 | xxd -r -p | base64); name=$(echo $data | cut -d'|' -f 3); echo "${name}:sha256:50000:${salt}:${digest}"; done | tee gitea.hashes 

Con el formato adecuado, Hashcat podrá reconocer estos hashes y comenzará a procesarlos para intentar descifrarlos. La clave es asegurarse de que el formato sea compatible con los requerimientos de Hashcat. En este caso, el hash incluye el nombre de usuario seguido de un : (dos puntos), lo cual es esencial para que Hashcat identifique correctamente la estructura

Rompemos el hash

Y podemos entrar en Gitea.

Vemos que el usuario administrador tiene un repositorio llamado scripts, analizamos los scripts en el respositorio, vemos que en el script full_check.sh hay algo que nos llama la atención.

La función start_server esta ejecutando un script llamado start_server.sh pero lo particular de esto es que lo esta ejecutando de forma relativa, lo cual nos hace pensar que podemos abusar de esto para escalar nuestros privilegios.

Asignamos permisos de ejecución.

Y por ultimo ejecutamos la opción full-check , la cual se encarga de ejecutar el script full_check.sh .

De esta forma, logramos escalar nuestros privilegios.

Especial agradecimiento al compañero d4redevil por la creación y el conocimiento aportado en esta máquina. Además de su ayuda a la hora de crear este write up

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *