En este writeup vamos a resolver la máquina Doctor de dificultad Low de Doctor.

TL;DR – RESUMEN DE LA MÁQUINA DOCTOR (VULNYX)

Te resumo a continuación la resolución de la máquina pero si quieres ver el detalle, te invito a leer el resto del write-up:

Comenzamos realizando reconocimiento de la máquina objetivo mediante escaneo de puertos con Nmap, detectando los servicios SSH (puerto 22) y Apache (puerto 80). La web alojada, un portal médico llamado Docmed, revelaba visualmente posibles nombres de usuario. Durante la inspección del código fuente y las URLs parametrizadas, identificamos una variable include en PHP sin validación, confirmando una vulnerabilidad de Local File Inclusion (LFI).

Aprovechando el LFI mediante path traversal, accedimos al contenido de /etc/passwd, confirmando la existencia del usuario admin, y extrajimos su clave privada SSH cifrada desde /home/admin/.ssh/id_rsa. Utilizando ssh2john junto con John The Ripper contra el diccionario rockyou, crackeamos la passphrase unicorn, obteniendo acceso inicial a la máquina como admin.

Una vez dentro del sistema, descartamos la explotación por binarios SUID al no encontrar ninguno aprovechable, y buscamos archivos con permisos de escritura incorrectos. Detectamos que el archivo /etc/passwd era escribible por el usuario admin. Aprovechando esta misconfiguration crítica, generamos un hash de contraseña con openssl e inyectamos un nuevo usuario con UID y GID 0, equivalentes a root, escalando privilegios y accediendo a la root flag con éxito.

Resumen de conceptos trabajados

  • Enumeración de servicios con Nmap.
  • Descubrimiento de vulnerabilidad LFI con path traversal.
  • Extracción y crackeo de clave privada SSH cifrada con John The Ripper
  • Escalada de privilegios mediante /etc/passwd writable

Si es tu primera máquina de VulNyx y no sabes cómo conectarte a la máquina del laboratorio, te recomiendo que visites este post donde te cuento paso a paso cómo empezar en esta plataforma.

Cómo Verificar que estamos conectados a la máquina víctima

Lo primero que tendrás que hacer cuando vayas a trabajar sobre alguna de las máquinas de VulNyx, es descargarla en tu equipo. Una vez descargada y descomprimida, irás a tu VMWare o VirtualBox y la importarás para virtualizarla.

Después de importarla, configura la conexión de red a Adaptador Puente, para que nuestra máquina atacante tenga acceso y la encuentre.

Comenzando con el reconocimiento de la máquina víctima

Iniciamos sesión siendo root y creamos previamente una nueva carpeta dentro de nuestro Kali para esta máquina y poder crear allí todo lo que analicemos.

Para asegurarnos de que la máquina víctima está conectada en la red (192.168.1.197)

arp-scan -I eth0 --localnet

y de esta forma vemos todas las IPs conectadas para empezar a analizarla (podemos comprobar que se encuentra la IP de la máquina VulNyx cuando la ejecutamos anteriormente). Vemos que la IP «is up» está activa y su ttl es de 64, es decir, SO Linux.

Fase de Enumeración / Escaneo de Puertos

Comenzamos el análisis con la fase de enumeración y escaneo de puertos mediante el comando:

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 192.168.1.197 -oG Escaneo_TCP

Ya en el escaneo encontramos los típicos puertos abiertos en máquinas de laboratorio como son el puerto 22 ssh y el puerto 80 http.

En este punto vamos a analizar un poco más en detalle cuáles son los servicios y versiones que corren para esos tres puertos abiertos.

nmap -sCV -p22,80 192.168.1.197 

Revisando esas versiones y servicios en searchsploit no veo a priori ningún exploit público por lo que paso a investigar el puerto web en busca de credenciales.

Investigando potenciales usuarios o credenciales

Y vemos una web llamada «Docmed» que parece ser un portal médico…

Hago ahora una investigación activa revisando algunos ficheros como robots.txt, analizando el código fuente buscando enlaces filtrados o comentarios, etc.

Encuentro por el momento algunos potenciales nombres de usuarios tanto visualmente en la parte de «Expert Doctors» como a la hora de «Pedir una consulta»: mirazul alom ; emilly blunt y asana korim son los que más se repiten…

Y otra cosa interesante es el nombre de la plantilla que está usando la web llamada «Colorlib» en su versión 3.0 que podemos analizar si tiene alguna vulnerabilidad pública.

Descubriendo un LFI con path traversal

También veo que tiene una parte de usuarios y comentarios dentro del blog del sitio, que podríamos probar con fuerza bruta. De hecho en los comentarios, el usuario que se repite para cada persona que quiere dejar un comentario en el post es el mismo y se llama «emilly blunt».

Pruebo a suscribirme a la newsletter para ver si recibo algún correo con algunas pistas, pero nada, y también pruebo a dejar un comentario en los artículos, y tampoco se registra el comentario.

Si nos fijamos en las urls que va montando la web cuando hacemos hover sobre los enlaces del menú, vemos que muchos tienen un # al final sin nada más que concatene a modo de anchor con alguna parte concreta de la página, y por ejemplo en el enlace de la sección «Doctors» vemos que la url está parametrizada => http://192.168.1.197/doctor-item.php?include=Doctors.html donde hay una variable include con el valor «Doctors.html».

Esta variable «include» en lenguaje PHP sirve para cargar archivos dentro de una página, en concreto «include()».

Esto significa que si la aplicación hace eso sin validar bien el valor, podríamos tener una vulnerabilidad de LFI o Local File Inclusion.

Una forma que podemos hacer es mediante un escaneo de seguridad web con la herramienta llamada Skipfish que sirve para analizar una aplicación web en busca de posibles vulnerabilidades, rutas ocultas, formularios inseguros, errores de configuración y comportamientos sospechosos. Es como un “crawler + scanner” para webs. Recorre la página, descubre enlaces, prueba parámetros y genera un informe con posibles problemas.

La herramienta está instalada por defecto en Kali, por lo que si ejecutamos este comando y esperamos a que termine el escaneo nos guardará todas las evidencias en la carpeta de Kali desde donde la ejecutemos:

skipfish -o reporte_skipfish -d 3 -c 50 http://192.168.1.197/

Tenemos todas las evidencias en nuestra carpeta del reporte, por lo que si ahora nos levantamos un servidor en python3 por nuestro localhost en el puerto 8000, podemos ver el fichero html con todo el reporte:

Y efectivamente nos encuentra una vulnerabilidad de LFI donde podemos aplicar path traversal y conocer los usuarios.

Para comprobarlo, de nuevo vamos a ver si acepta ese comando en el navegador:

http://192.168.1.197/doctor-item.php?include=/../../../../../../../../../etc/passwd

esto ya nos confirma que sí es vulnerable a LFI y sabemos que el usuario «admin» existe.

Clave privada SSH cifrada

Vamos a probar a inyectar la siguiente petición para ver si podemos extraer alguna clave privada rsa para ese usuario admin mediante el comando:

curl -s "http://192.168.1.197/doctor-item.php?include=../../../../../../../../home/admin/.ssh/id_rsa"

con este comando nos descargamos la clave en nuestro Kali para poder descifrarla porque aparece encryptada:

curl -s "http://192.168.1.197/doctor-item.php?include=../../../../../../../../home/admin/.ssh/id_rsa" -o id_rsa

Vamos a darles permisos de lectura y escritura con chmod a esa clave para así poder convertir la clave a formato crackeable con la herramienta John The Ripper :

ssh2john id_rsa > hash_id_rsa.txt

y ahora usando John The Ripper contra el diccionario de contraseñas rockyou tratamos de crackear esa hasd id:

Y nos encuentra la contraseña «unicorn» para ahora sí, poder acceder por ssh como admin:

Y haciendo un listado de archivos podemos ver la user.txt flag.

Ahora tenemos que escalar privilegios a root.

Para ello vamos a ver quiénes somos, qué permisos tenermos, etc.

Con whoami vemos que somos el usuario admin . Si tratamos de ejecutar «sudo -l» nos devuelve «orden no encontrda»

Como no podemos ejecutar «sudo -l», el siguiente paso típico es buscar binarios con permiso SUID.

find / -perm -4000 -type f 2>/dev/null

pero no nos sale ningún binario raro que podamos explotar.

Analizando potenciales ficheros writables

En este punto revisamos si es posible escribir sobre archivos o carpetas siendo usuario admin con el comando:

find / -writable -type f 2>/dev/null | grep -vE "/proc|/sys|/dev|/run|/home/admin"

y lo más relevante es esta línea del /etc/passwd . Esto significa que es escribible por admin, por lo que podríamos añadir un usuario root.

En Linux, /etc/passwd define los usuarios del sistema. El campo UID 0 equivale a root independientemente del nombre, por lo que escribir directamente en este archivo con permisos incorrectos es una misconfiguration crítica.

Crearemos el usuario root de esta forma:

1. Generamos un hash de contraseña:

openssl passwd -1 hacked123

Y nos devuelve => $1$gzOApGAp$puMN.1eRs5DgXWPWJKCSU0

2. Añadimos un usuario root falso a /etc/passwd:

echo 'pwned:$1$gzOApGAp$puMN.1eRs5DgXWPWJKCSU0:0:0:root:/root:/bin/bash' >> /etc/passwd

El UID y GID 0:0 le dan privilegios de root.

3. Cambiamos al nuevo usuario:

su pwned
# contraseña: hacked123

4. Verifica que ya eres usuario root y puedes leer la root flag.

id
# uid=0(root) gid=0(root) grupos=0(root)
cat /root/root.txt

Otros posts relacionados