Primero, como medida de reconocimiento, se tiene que comprobar la conectividad con el objetivo. Para este propósito se realizarán trazas ICMP con el comando ping hacia el host de destino.

$ ping <ip_objetivo> -c 3

Figura 1: Respuesta del ping confirmando conectividad activa.

Una vez confirmado que tenemos conexión directa con el objetivo, continuamos con el reconocimiento y escaneo de puertos...

Realizamos un Escaneo Stealth (SYN) de manera rápida contra todo el rango de puertos abiertos disponibles (65535) en la máquina objetivo.

$ nmap -sS <ip_objetivo> -p- --min-rate 4000

El escaneo rápido nos informará cuáles puertos están abiertos para poder trazar un vector de entrada inicial.

Figura 2: Identificación de puertos abiertos (SSH y HTTP).

Según los resultados anteriores de NMAP, tenemos los puertos 22 (SSH) y 80 (HTTP) expuestos. Procedemos a realizar un escaneo dirigido de versiones y detección de scripts estándar en esos puertos en específico.

$ nmap -sCV -p80,22 <ip_objetivo>

Figura 3: Análisis enfocado revelando Apache y OpenSSH en el servidor objetivo.

Accedemos a la dirección IP del objetivo a través de nuestro navegador web para inspeccionar la interfaz visual en el puerto 80 en busca de fugas o pistas útiles.

Figura 4: Interfaz web rota imprimiendo un error genérico.

A simple vista se nota que algo está fallando o cargando de manera incorrecta en el código PHP principal:

[!] ERROR [!]

Ejecutamos un fuzzing de rutas y directorios utilizando la herramienta ghostpyder-v3-Linux junto al diccionario de SecLists directory-list-2.3-medium.txt para identificar recursos no enlazados en el home.

[200] http://<ip_objetivo>/index.php
[301] http://<ip_objetivo>/assets

Figura 5: Descubrimiento de index.php y el directorio assets.

Al acceder directamente a index.php podemos visualizar el contenido completo del sitio. Aunque se detecta un posible usuario, no parece ser relevante en esta fase.

Figura 6: Endpoint de index.php en ejecución.

El servidor está procesando scripts en PHP, lo que nos da pauta para intentar buscar vulnerabilidades de inclusión de archivos.

Revisamos la ruta típica del archivo de exclusión de rastreadores en busca de posibles secretos o directorios ocultos.

Figura 7: Lectura del archivo robots.txt sin datos de interés.

El archivo robots.txt no nos proporciona ninguna pista de utilidad en esta ocasión.

Volvemos a utilizar el fuzzer ghostpyder-v3-Linux en busca de parámetros expuestos vulnerables a LFI.

Figura 8: Escaneo de parámetros descartando ruidos mediante el filtro '-fs 2596'.

El fuzzer localiza un parámetro vulnerable que permite la lectura directa de archivos locales del sistema de archivos del servidor.

Figura 9: Lectura exitosa del archivo /etc/hosts.

¡Vulnerabilidad de LFI confirmada en el servidor!

Aprovechando la inclusión de archivos locales, leemos el archivo del sistema /etc/passwd para listar los usuarios que tienen acceso y shell válida.

Figura 10: Inclusión del archivo de contraseñas passwd.

Figura 11: Análisis del archivo passwd.

Se identifican dos usuarios relevantes en el sistema de usuarios: vaxei y luisillo.

Posteriormente, abusamos de la lectura de archivos para buscar llaves SSH privadas en las rutas home predeterminadas de los usuarios encontrados.

Figura 12: Recuperación de la llave SSH de vaxei.

Logramos leer exitosamente la llave privada SSH (`id_rsa`) del usuario vaxei.

Copiamos el bloque de texto completo de la clave y lo guardamos en nuestra máquina de ataque como un archivo llamado id_rsa.

[!] IMPORTANTE: Al copiar la llave asegúrate de no agregar espacios en blanco innecesarios o líneas de sobra al inicio/final, ya que esto dañará el formato criptográfico.

Ejemplo de un copiado con errores:

[!] ATENCIÓN: El espacio en blanco al principio invalidará la autenticación de la clave.

Asignamos los permisos seguros de lectura restrictiva (600) al archivo de llave que requiere el cliente de SSH antes de conectarse:

$ chmod 600 id_rsa

Figura 13: Aplicando los permisos correctos a la llave id_rsa.

Iniciamos sesión vía SSH en la IP del objetivo utilizando la llave privada de vaxei:

$ ssh vaxei@<ip_objetivo> -i id_rsa

Figura 14: Acceso exitoso a la terminal como el usuario vaxei.

Con nuestra shell activa como vaxei, realizamos una enumeración de permisos de ejecución en modo superusuario ejecutando sudo -l.

Trick: El flag sudo -l expone comandos y privilegios delegados sobre otros binarios o usuarios.

Descubrimos que el usuario vaxei tiene permisos para ejecutar el intérprete Perl como el usuario luisillo sin requerir contraseña.

Buscamos un método de evasión o ejecución de shell a través de Perl en el repositorio de GTFOBins:

Abrir GTFOBins - Perl

Explotamos la delegación de permisos de Perl para forzar una shell interactiva como el usuario luisillo:

$ sudo -u luisillo perl -e 'exec "/bin/bash";'

Ahora que estamos operando bajo el contexto del usuario luisillo, volvemos a inspeccionar los privilegios Sudo disponibles:

Trick: Utilizar bash -i para estabilizar y obtener una shell interactiva.

Vemos que luisillo puede ejecutar el script de Python paw.py, ubicado en /opt/, con privilegios del usuario root.

Analizamos los permisos de la carpeta y del archivo utilizando ls -la:

Análisis de Permisos: El script de Python paw.py tiene permisos 644 (lectura global, escritura restringida a su creador). Sin embargo, el directorio contenedor /opt/ tiene permisos 757, permitiendo a cualquier usuario crear, modificar o eliminar archivos dentro de él.

Revisamos el contenido del script paw.py original:

Dado que tenemos control de escritura sobre el directorio /opt/, podemos eliminar el archivo paw.py existente y sustituirlo por uno nuevo diseñado por nosotros para entablar una conexión reversa.

En nuestra máquina local abrimos un puerto de escucha en Netcat (ej: 4444):

$ ncat -nlvp 4444

Reemplazamos el script con un Payload de Reverse Shell básico escrito en Python 3 y ejecutamos el script aprovechando el permiso Sudo asignado a luisillo:

$ sudo /usr/bin/python3 /opt/paw.py

Nota: Al ejecutar el script modificado a través de Sudo, éste se ejecuta bajo el contexto del superusuario (Root), otorgándonos privilegios elevados.

¡Obtenemos la shell reversa como ROOT de manera inmediata! Validamos los privilegios e imprimimos la flag:

# whoami
root

# id
uid=0(root) gid=0(root) grupos=0(root)

# echo 'pwned by hckxr!'

La máquina PSYCO de DockerLabs resulta ideal para comprender la importancia de las configuraciones de permisos en carpetas compartidas y las técnicas de abuso de LFI y SSH.

Si tienes alguna duda o sugerencia, recuerda que puedes unirte a las comunidades de ayuda en Telegram o Discord.

¡Buen hacking y no olvides cuidar tu postura!

Atentamente: @RedSpyderSec

Visítanos en RedSpyderSecurity