Introducción
Siguiendo con la serie de máquinas de Vulnhub que tienen un nivel parecido al laboratorio del OSCP, ahora es el turno de ver cómo se soluciona «FristiLeaks» (https://www.vulnhub.com/entry/fristileaks-13,133/).
En el post anterior «Welcome to kioptrix vm 2014» está explicada la solución de Kioptrix, y también se muestra con más detalle algunas de las prácticas que se utilizan aquí.
Information gathering
Recordamos una de las reglas más importantes a seguir para realizar un pentest: Obtener Información, la información es la clave.
Lo primero es obtener la dirección IP de la máquina objetivo: 192.168.8.140
Una vez ya se sabe la dirección IP el siguiente paso es realizar una enumeración de puertos e identificación de servicios. Es necesario conocer cómo la máquina se comunica con el exterior, ya que estas comunicaciones serán los potenciales vectores de entrada.
1-Se realiza un scan de los 100 puertos más importantes: nmap -T4 -Pn -F –open –reason $Ip
Se han obtenido los siguiente resultados:
a) Puerto 80 con un servicio http
2- Obtener más información de los servicios detectados en el paso 1. El comando es: nmap -T4 -Pn -sV -O -p 80, –open –reason $IP
Se han obtenido los siguiente resultados:
a) Hay un Apache httpd 2.2.15
b) Hay un PHP 5.3.3
c) El sistema operativo es, probablemente, un Linux CentOS 2.6.32-3.10
3- Realizar un scan de todos los puertos. Tal y como se comentó en el post de Kioptrix hay diferentes opciones:
a) Utilizar el script «One-two punch» de superkojiman
b) Escanear todos los puertos TCP con nmap y utilizar el parámetro -A
c) Escanear todos los puertos UDP con la tool «unicorn» o el auxiliary scan UDP de Metasploit
Al finalizar todos los scans, se realiza una recopilación de toda la información obtenida para su análisis y definición de los posibles vectores de ataque y su priorización.
En base al análisis de los resultados , los vectores de ataque definidos son:
1- Puerto 80 abierto con un servicio HTTP (web)
2- Software Apache 2.2.15
3- PHP 5.3.8
4- Sistema operativo Linux CentOS 2.6.32 – 3.10
Análisis de vulnerabilidades
En este punto, la atención se va a centrar en cada uno de los vectores descritos intentando obtener información más específica de cada uno de ellos y así determinar las probabilidades de explotación.
A) Puerto 80 con un servicio HTTP (web)
La batería de pruebas que se ha de realizar siempre a un servicio web es la siguiente:
1- Navegar por la web y el fichero robots.txt
2- Análisis de las cabeceras
3- Análisis del código fuente
4- Enumeración de directorios
5- Nikto
Los resultados son los siguientes:
1- La navegación por la web
curl -i -L -s 192.168.8.140
b) El fichero robots.txt:
El fichero robots.txt muestra que hay 3 recursos a considerar:
a) cola
b) sisi
c) beer
Al ver el nombre de estos directorios, es fácil comprobar que los nombres de «cola» y «beer» son bebidas. ¿Pero sisi? ¿No era una emperatriz? Pues resulta que SiSi es el nombre de una especie de «fanta» originaria de Holanda. Esto nos da una idea que los directorios de la aplicación son nombres de bebidas.
c) Si se utiliza otras opciones de curl es posible obtener algo más de información. En este caso no hay información novedosa.
2- Se utiliza la herramienta gobuster para realizar la enumeración de directorios :
No hay resultados que valgan la pena.
3- Con la tool Nikto tampoco se ha obtenido informacion relevante.
B) Software obsoleto
Los pasos a seguir siempre que se trate de software desactualizado son:
1- Identificación de la versión
2- Búsqueda de vulnerabilidades y exploits
3- Analizar si el exploit aplica o no en el escenario y a los objetivos
En esta ocasión se va a proceder a buscar exploits utilizando Google y searchsploit
a) Apache 2.2.15
El único exploit que se ha encontrado no aplica para conseguir acceso a la máquina.
b) PHP 5.3.3
En este caso se puede observar como hay 2 exploits de denegación de servicio y uno con múltiples vulnerabilidades (18370.txt). Las vulnerabilidades detalladas en este fichero tampoco proporcionan un acceso a la máquina.
Resumen del análisis de los vectores de ataque
Una vez se ha realizado un análisis preliminar de los vectores de ataque, vale la pena valorar toda la información en su conjunto.
1- Hay un servicio web en el puerto 80 y disponemos de los siguientes recursos:
a) index.html
b) sisi
c) cola
d) beer
2- No hay exploits útiles del Apache 2.2.15 que nos permita acceder a la máquina
3- No hay exploits útiles de PHP 5.3.3 que nos permita acceder a la máquina
Por lo tanto, el único vector de ataque «factible» es el servicio http en el puerto 80 y se descartan los vectores 2 y 3.
Explotación del servicio HTTP – Puerto 80
Bien, la primera acción es visitar los recursos encontrados. En los 3 casos (sisi, beer y cola) lo que se encuentra es la siguiente imagen:
Parece que no se ha tenido éxito. Se revisa el código fuente y los metadatos de la imagen y el resultado es el mismo: No hay nada. El siguiente paso es visitar la página principal, y se obtiene el siguiente resultado:
¿Cómo? ¿Otra imagen? De nuevo, se analiza el código fuente, los metadatos de la imagen esperando encontrar algo….pero el resultado es que no hay nada. En este punto, existe la tentación de empezar a dar vueltas y más vueltas y acabar probando cosas altamente improbables. La recomendación en estos casos es simple: parar y analizar.
Se ha de analizar todo lo que ya se ha encontrado, los vectores de ataque, repasar que no se haya descuidado algún detalle. Si se ha sido metódico, este proceso es sencillo. Entonces, ¿qué es lo que sabemos y tenemos?
Tenemos que habían 4 vectores de ataque y sabemos que 3 de ellos no eran posibles. Por lo tanto, si o si, el vector del puerto 80 y concretamente en esa imagen ha de haber algo. Uhmmm «Drink Fristi», antes se ha comentado que el nombre de los directorios eran bebidas. Podría ser una pista, o simplemente una idea feliz chorra.
Gracias a Google se encuentra que Fristi es una bebida de yogur desnatado con frutos rojos original de Holanda. Todo hace indicar que podría ser un directorio «oculto». Se accede a él y si, por fin, hay un login:
Cuando se ve un login las primeras acciones suelen ser comprobar si hay una SQLi o es vulnerable a brute-force (probando el clásico admin/admin). Recordemos, la información es la clave. Es mejor, antes de nada, analizar el código fuente, intentar identificar si es un CMS, comentarios etc…en resumen, «conocer» el asset.
En este caso, en el código fuente se encuentra la siguiente información:
En un comentario hay escrita una pequeña anotación con lo que parece ser el nombre de un usuario: eezeepz.
Además, más abajo, en otro comentario hay lo que parece ser código en base64 (es fácil de identificar por su estructura o utilizando el Decoder de Burp):
Para decodificar este código es posible utilizar varios mecanismos.
a) Desde consola, copiando el código a un fichero y utilizando comandos:
Y la imagen que se obtiene es:
b) Utilizando Burp, la consola de Firefox, modificando en local el archivo .html…
En ambos casos se obtiene la misma imagen. Ya se dispone de un nombre de usuario (eezeepz) y un password (keKkeKKeKKeKkEkkEk). Prego! login exitoso!
En la zona autenticada se encuentra un «file upload». En este caso, la acción a realizar es intenta subir una webshell/reverse shell al servidor y así tener acceso al mismo. Con todos los datos recopilados es automático saber que la webshell ha de estar en código php. En el primer intento de subir un archivo .php, se produce un fallo porque la extensión no es la correcta:
Creación y acceso con una webshell
Hay múltiples opciones de crear una webshell en php. Desde las que ya incorpora Kali, o la php-reverse-shell de pentestmonkey (link) hasta la creación con msfvenom. Para esta ocasión, se muestra la creación de dos shells diferentes:
a) Con Meterpreter:
b) Sin meterpreter, únicamente una reverse shell:
Las 2 opciones son válidas. Hay que detallar que dado que la funcionalidad del «File Upload» indica que la extensión ha de ser de un tipo en concreto, el nombre de las shells creadas finalizan con *.php.png
Con el objetivo de ver más comandos y funciones de Metasploit se ha preferido utilizar la shell simple (opción b, reverse shell sin meterpreter) y mostrar cómo es posible, una vez ejecutada la shell, hacer un update de la misma a meterpreter. En Google es muy fácil encontrar información sobre qué ventajas conlleva esta técnica.
1- Así pues, se procede a subir la reverse shell esperando que únicamente con el truco de indicar una extensión autorizada (.png) sea posible evadir el mini check de seguridad (siempre que se pueda, lo primero a probar son las cosas más simples).
2- Perfecto, el upload ha sido un éxito. El siguiente paso es configurar el handler:
3- Ahora, se ha de acceder al archivo y que se ejecute correctamente:
4- Una vez ya se ha establecido la conexión, se realiza el update a Meterpreter:
5- Ya se dispone de una sesión en Fristileaks. 🙂
Elevación de privilegios
Una vez ya se está dentro del sistema se ha de volver a iniciar todo el proceso de investigación para determinar qué vector de ataque es el más idóneo para alcanzar root. En esta fase es muy importante el orden e ir de menos a más, de lo más simple a lo más complicado.
Information gathering
Una vez dentro del sistema se ha de recopilar el máximo posible de información con el objetivo de poder responder a la mayoría de estas preguntas (siempre priorizando):
1- ¿Qué información sabemos ya?
2- ¿Qué sistema operativo es?
3- Si es obsoleto, ¿Tiene vulnerabilidades conocidas y hay exploits públicos?
4- ¿Quién soy?
5- ¿Qué usuarios hay?
6- ¿Qué se puede encontrar en /home?
7- ¿Se puede ejecutar el comando sudo?¿Cómo está configurado?
8- ¿Hay algún history disponible?
9- ¿Hay algún SetUID o SetGID?
10- ¿Cómo está configurado el PATH?
11- ¿Qué lenguajes están soportados?
12- ¿Qué comandos están permitidos para establecer comunicaciones al exterior?
13- ¿Qué interfaces de red tiene?
14- Si hay una aplicación web con un login ¿Hay algún fichero de configuración/conexión con credenciales a la base de datos?
15- ¿Qué procesos están corriendo en la máquina?¿Alguno como root?
16- ¿Hay algo en el Cron?
17- ¿Hay información útil en los logs de máquina?
18- ¿Qué ficheros/directorios puedo leer/escribir?
Mediante el análisis de las respuestas se podrán empezar a pensar y diseñar los vectores de ataques (ordenados de más simple a más complejos) con más posibilidades para realizar la escalada de privilegios.
En el caso concreto de Fristileaks, se muestra alguna de la información obtenida más relevante:
a) ¿Quién soy? ¿Qué kernel es? (y spawn con python):
– Usuario Apache
– Kernel 2.6.32
b) Sistema operativo: CentOS release 6.7
c) ¿Qué usuarios hay, además de root?
– eezeepz
– admin
– fristigod
– fristi
d) Fichero de conexión a la BD, con credenciales:
Lamentablemente, estas credenciales no funcionan para cambiar de usuario en Fristi.
e) Home de cada user:
admin:
eezeepz:
En el Home de eezeepz hay lo que parece ser un listado de comandos y un fichero «notes.txt«. Interesante
d) Además, analizando el contenido de la carpeta /var se encontró otro fichero «notes.txt»:
Es otro detalle más que hace sospechar que en el homedir del usuario eezeepz pueda haber algo interesante. Además, se obtiene el nombre (jerry) del que podría ser el usuario admin.
Análisis de vulnerabilidades
Las primeras vulnerabilidades que se han de probar son:
1- Comprobar el funcionamiento de sudo, y que el password del usuario no sea trivial.
No funciona
2- Que el usuario «root» no tenga como password…»root»
No funciona
3- Si el sistema operativo está desactualizado, ¿Hay exploit directo de elevación de privilegios?.
Este podría ser una opción: Linux Kernel 2.6.32 < 3.x.x (CentOS) – ‘PERF_EVENTS’ Privilege Escalation (1)
Sin embargo, las referencias continuas al homedir del usuario «eezeepz» se hacen merecedoras de ser estudiadas. Además, si bien esto es un juego, en el mundo real un usuario que codifica su password en base 64….hace pinta de ser un pelín desastre. Seguro que algo interesante hay.
Explotación
El contenido del fichero «notes.txt» del homedir del usuario eezeepz es el siguiente:
Vaya con Jerry….tampoco es un genio no. Visto lo visto, vale la pena seguir por este vector.
Explotación del Runthis
El procedimiento es el siguiente:
1- Conseguir acceder a la homedir del usuario admin
2- Dentro de esta home se hallan ficheros que contienen lo que parecen ser credenciales cifradas así como el script responsable del cifrado:
3- Se busca algo de información sobre la función «codecs.encode» para ver cómo se puede hacer el proceso reversible y obtener los datos en claro:
4- Se realiza un script cutre para proceder al descifrado:
5- Se accede al usuario fristigod con las credenciales obtenidas:
6- Bien, pero el usuario «fristigod» no es lo mismo que root. Tal y como se ha comentado varias veces, de nuevo, la información es esencial. En este punto, es necesario conocer todo lo posible acerca de este usuario, como su «history»:
O la configuración de «sudo»:
Con esta información en la mano, está claro que el usuario «fristigod» realiza acciones con el usuario «fristi» e interaccionando con el fichero «doCOM» . Algo más de información sobre este fichero se puede obtener con el comando «file»:
7- Solo resta por hacer una prueba más y esperar los resultados:
8- Et voilà ! Root y acceso al flag.
Disfrutad de la máquina 😉
La obtención del fichero se realiza de la siguiente manera:
Parte III: Caso Práctico – Atacando con Metasploit a la víctima
Testpurposes 