Immersion – Write-Up OFICIAL (Español)

Immersion – Write-Up OFICIAL (Español)

Hoy vamos a resolver mi segunda máquina vulnerable creada, esta máquina se llama Immersion, en ella, gracias al reconocimiento podremos identificar un posible LFI y, con ello, obtener la contraseña de un usuario del sistema, donde una vez dentro deberemos abusar del sudoers repetidas veces hasta llegar al usuario root.

Ip de la máquina en mi caso: 10.10.1.64

Voy a saltarme la configuración previa, si es que se descarga la máquina y se usa en local, es recomendable que veas cómo configurarla en VirtualBox como lo mostré en el Write-up de la ColddBox: Easy.

Reconocimiento

Lo primero, como siempre, es lanzar un furious, esta vez lanzaré “rec0ldd” es una utilidad que cree (le puse “rec0ldd” por reconocimiento y coldd, lo sé un nombre magnífico, no cabe duda), donde básicamente esta utilidad recibe un parámetro (la ip de la máquina a resolver), una vez obtenido este parámetro, ejecutará furious y analizará los 65535 puertos, nos lo mostrará por pantalla, arrojará un fichero llamado “furiousScan” donde nos muestra el output por defecto de furious y no el personalizado que yo agregue a la utilidad y, finalmente, con xclip, nos copiará automáticamente los puertos abiertos separados por comas a la clipboard, de forma que podamos ejecutar con ellos un nmap luego u otro reconocimiento más profundo sin necesidad de copiarlos de forma manual, pronto subiré el código por github para que la puedan usar, de mientras:

escaneo con rec0ldd
Resultado de ejecución de recoldd contra la máquina immersion

También, para mostrar la funcionalidad de la utilidad un poco más, este sería el fichero que nos devuelve (el output por defecto de furious):

resultado de furious

Contenido del fichero “furiousScan” generado por la utilidad rec0ldd.

Bien, a lo que vamos, la máquina tiene dos puertos abiertos, el 80 (HTTP) y el 3042 (Desconocido), ya con estos puertos en el portapapeles, vamos a ejecutar un escaneo más profundo con nmap, para ello:

nmap -sC -sV -T3 -p80,3042 <ip> -oN <nombre_salida>

escaneo de nmap

Resultado de escaneo con nmap

Podemos ver que, efectivamente en el puerto 80 corre un servicio HTTP, en este caso un apache y, que el puerto 3042 corre un SSH, en este punto, vamos a revisar el servicio HTTP:

pagina de inicio

Página de inicio del servidor web.

A simple vista es solo una página con un enlace a mi Twitter, en el código fuente no hay mucha información tampoco, solo más código que personaliza la página principal:

codigo fuente pagina de inicio

Código fuente de la página de inicio

En este punto ¿qué se puede hacer?, vamos a hacer fuzzing con gobuster para identificar recursos que puedan estar ocultos, para ello:

gobuster dir -u http://<ip>/ -w <wordlist>

clear ya funciona

Resultado del fuzzing con gobuster

Como vemos, hemos detectado varios directorios, el de css y js son un poco irrelevantes en este caso, ya que centraremos nuestra atención en los directorios “login”, “secure” y, “wp”, vamos a revisar uno por uno, empezando con wp:

contenido de wp

Contenido de “/wp”

contenido de secure

Contenido de “/secure”

Hasta aquí todo normal, son dos páginas normales, una de ellas que esperemos que consiga ser un WordPress algún día y, otra que es la página por defecto de apache solo que con algunas modificaciones en los títulos, lo verdaderamente interesante aquí es el siguiente directorio:

pagina de login

Contenido de “/login”

Como vemos, es un simple formulario de login, no podemos registrarnos ni nada, simplemente debemos poner unas credenciales, pero, si miramos en el código fuente veremos lo siguiente:

cometario codigo fuente

Código fuente de la página de login

Vemos que el formulario envía la información a account.php, esto siempre es interesante porque podemos intuir que al ser un php, está ejecutando acciones de las cuales nos podemos aprovechar, anidado a esto, hay un comentario que traducido al español dice algo como:

Hola Carls, si lees esto, me he ido de viaje, déjame decirte, después del último ataque que recibimos (gracias a tu inactividad como web desarrollador) tuvimos que hacer cambios en las contraseña, pero como no usa un teléfono móvil o computadoras en casa (un poco raro ya que eres un desarrollador web), dejé pistas en la “page” para que encuentres tu contraseña, sé que será fácil porque estás bueno para detectar fallas de seguridad (o eso pensaba antes del ataque :D), te deje tu contraseña en un fichero llamado carls.txt que está dentro de /var, cuando la consigas, inicia sesión y termina tu trabajo preparando mi bash.

Saludos, c0ldd.

Por partes, este comentario lo deje con la intención de que el usuario que estuviese resolviendo la máquina pudiese intuir que vulnerabilidad debía aprovechar, en el comentario se le indica a “carls” que debe encontrar su contraseña leyendo el fichero carls.txt ubicado en /var, además que se menciona que debe “detectar un fallo de seguridad en la web” por ende, ¿cuál vulnerabilidad web permite principalmente leer ficheros del sistema?, eso es, un Local File Inclusion, pero para ello necesitamos indicarle a través de una variable, el nombre del fichero en cuestión, dicha variable suele ser  “filename”, “page”, entre otras, por eso en el comentario se le dice “deje pistas en la “page””, haciendo alusión a dicha variable, pero ¿dónde se podría probar esto?, pues, en el mismo código se ve que los datos se envían a account.php, así que, sea rellenando y enviando datos por el formulario o accediendo a ese recurso directamente, el usuario debería llegar ahí y con toda la información anteriormente dada y pensando un poco, debía probar un LFI por medio del fichero account.php.

Así que, basándonos en esto, vamos a entrar a account.php y ahí cambiamos en la url la variable a “page” y, por ejemplo, buscamos el recurso que se nos indica en el comentario, “/var/carls.txt”:

resultado de prueba de lfi

Resultado del LFI

Al hacerlo, vemos que logramos leer dicho fichero, verás igualmente que me fui al directorio padre muchas veces, eso pasa porque si se prueba directamente “?page=/var/carls.txt”, no nos mostrará  nada, esto porque a lo mejor en el fichero hay una pequeña y mínima sanitización de los datos y solo está buscando la información solicitada en el directorio que se le indico en el código, pero igualmente, tirando para arriba en la estructura de directorios logramos llegar a la raíz (/) y una vez ahí, solicitar el recurso que queríamos, en este caso, el fichero “carls.txt”.

Ahora bien, vemos que tenemos unas credenciales, el nombre de usuario “carls” y una contraseña encodeada en base64, para decodificarla es muy simple, puede ser con una herramienta online o desde el propio sistema operativo teniendo base64 instalado con el comando:

echo “Y2FybG9z” | base64 -d

Sea como sea que lo hagas, verás que nos arroja lo que parece ser la contraseña del usuario carls, de hecho, para comprobar si el usuario “carls” existe en el sistema y así poder intentar logearnos en él, podemos consultar el fichero /etc/passwd de la misma forma que consultamos el fichero “carls.txt” gracias al LFI:

fichero passwd

Resultado del fichero /etc/passwd

Efectivamente “carls” es un usuario del sistema, por lo que ahora ya tenemos sus credenciales y nos disponemos a iniciar sesión, para ello debemos recordar que teníamos un SSH corriendo el puerto 3042, así que para iniciar sesión basta con solo ejecutar:

Explotación

ssh [email protected] -p3042

Recuerda que el -p se usa cuando el puerto donde corre el SSH no es el por defecto (22), una vez ponemos la contraseña, veremos que accedemos sin problema al sistema:

primer acceso al sistema

Primer acceso al sistema como el usuario “carls”

En este punto, intentemos leer la bandera de user que, no está en /home/carls, por ende podemos intuir que está en /home/c0ldd (el que dejó la nota), pero no tenemos permisos para acceder a su directorio:

directorio de c0ldd

No se tienen los permisos para acceder al directorio home del usuario c0ldd

Ahora bien, intuimos que debemos escalar privilegios, ya sea a c0ldd o en su defecto a root, ahora mismo quiero que recuerdes el comentario que vimos en el servidor web, en concreto la última parte:

“inicia sesión y termina tu trabajo preparando mi bash”

Ahí el usuario c0ldd da una pista más, “preparando mi bash” ¿podemos usar la bash para escalar privilegios?, en este punto podemos intentar buscar recursos por permiso SUID vamos a hacer lo más básico de la escalación de privilegios en sistemas Linux, hacer un sudo -l para ver que nos asignó en el sudoers que podemos ejecutar como otro usuario:

sudoers del usuario carls

Resultado del comando “sudo -l”

Escalación de privilegios

Esto es curioso y por eso lo quise configurar así, normalmente en este tipo de maquinas se suele poner que, el usuario con el que estamos intentando escalar privilegios, pueda ejecutar un recurso del sistema como root a través del abuso del sudoers, en este caso no es así, sino que podemos ejecutar el binario bash pero como el usuario c0ldd, por ende al ejecutarlo obtendremos una shell como este, hay que siempre tener en cuenta que el comando “sudo” no siempre se usa para obtener privilegios, de hecho es un comando para ejecutar comandos como otros usuarios, pero su uso frecuente para ejecutar comando con permisos elevados puede hacer que se confunda su cometido, entonces, partiendo de esto, para poder llevar a cabo esta escalación de privilegios, debemos ejecutar el siguiente comando:

sudo -u c0ldd /bin/bash

acceso como c0ldd

Escalación de privilegios al usuario c0ldd

Ahora, como el usuario c0ldd, ya podemos leer la bandera que está en su directorio home:

lectura user txt

Lectura del user.txt

Ahora bien, si listamos lo que hay dentro del directorio, veremos que hay un script en Python que es del usuario root que literalmente nos dice que no lo ejecutemos:

directorio home de c0ldd

Lectura del script en Python

Es algo obvio que non debemos ejecutarlo, el script es simple, un bucle infinito que nos imprimirá por panta “I told you”, aunque claro, eso no está ahí por casualidad, recuerda que en este punto debemos volver a escalar privilegios, pero esta vez al usuario root, por ende, vamos a intentar a lo más básico de la escalación de privilegios en Linux nuevamente, un “sudo -l”, al hacerlo veremos lo siguiente:

sudoers de c0ldd

Recursos que puede ejecutar el usuario “c0ldd” en el sistema como root

Podemos ver que se nos permite en el sistema ejecutar como root y sin contraseña el binario de python3 y a su vez el script de Python que vimos, aunque si lo ejecutamos tal cual, lo que lograremos es ejecutar el bucle infinito como root (nada útil), por ende, haremos algo curioso, si se fijan en los permisos, no podemos escribir en el fichero, pero sí podemos borrarlo, entonces la idea es la siguiente, borramos el fichero “DoNotRun.py”, creamos otro llamado “DoNotRun.py”, dentro de este introduciremos código en python3 que nos devuelva una shell y, finalmente, ejecutaremos como root dicho script así logrando que ese código de la shell se ejecute con permisos elevados y obtengamos una shell como root, entonces, borramos, creamos uno nuevo y dentro del nuevo añadimos la shell:

escalacion de privilegios con python

Procedimiento para escalar privilegios

rm DoNotRun.py

echo ‘import pty; pty.spawn(“/bin/bash”)’ >DoNotRun.py

Una vez hecho todo esto, solo queda ejecutar con sudo este script:

sudo /usr/bin/python3 /home/c0ldd/DoNotRun.py

acceso como root

Shell como root obtenida

Y ya somos root, es importante que lo ejecutes tal cual como lo puse, no sirve ejecutarlo indicándole una ruta relativa al script en Python, ya que si lo haces no lo tomará como lo que se indica en el sudoers y te pedirá la contraseña del usuario “c0ldd” para poder ejecutar (contraseña que no tenemos).

Ya solo queda leer la bandera root.txt

lectura de root txt

Lectura de root.txt

 

Y ya habríamos completado la máquina.

Esta fue solo una de las formas de poder resolver esta máquina, deje algunas más tanto en la intrusión como en la escalación de privilegios que pueden buscar para resolverla de una forma distinta.

Como ya es costumbre, no voy a dar mi opinión sobre la dificultad de la máquina, prefiero ver los Wrute-ups que harán y ver cómo la califican, me los pueden mandar por twitter, sin más, muchas gracias y espero que puedan aprender algo nuevo.

Sobre el Autor

C0ldd

Founder of Coldd Security

2 Comentarios

  1. Avatar

    Vi esta máquina en el twitter de vulnhub, decidí probarla (he de decir que estoy aquí porque me atoré en el lfi, jeje), en realidad una máquina “fácil” para pocos, ha estado interesante, gracias y un saludo!

    Responder
    • C0ldd

      Gracias por probarla 🙂

      Responder

Deja una respuesta

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

Información adicional sobre protección de datos:
Responsable: Martin Frias.
Finalidad: Moderar los comentarios de este sitio web.
Cesión: NO se cederán a nadie, salvo obligación legal.
Derechos: Acceso, rectificación, cancelación y borrado de tus datos.
Legitimación: Tu consentido expreso.

Sponsor By

Coldd Security

REDES SOCIALES

Newsletter

Estadísticas

  • 55.908
  • 43

TheHackerSnow

0

Share This