Hackademic.rtb2 un solucionario with nails

En vista que en varias ocasiones me han preguntado cual es mi blog y cosas por el estilo, he decidido iniciar con este, asi que sean todos bienvenidos y espero sea de agrado para ustedes.

Para iniciar me he inclinado por un solucionario que realice de el entorno publicado en sec-track por 4v4t4r hackademic.rtb2, asi que no siendo mas iniciamos...

Una vez ha iniciado los entonos target y atacante iniciamos realizando un típico barrido de pings root@bt:~/hackademic2# nmap -sP 192.168.209.1-255

Donde se identifican 3 host activos (pueden haber mas) de los cuales descartamos los 2 últimos debido a que el de IP .131 es nuestra maquina atacante y el .254 es la interface que configura vmware cuando usamos el modo solo host, haciendo uso de la misma herramienta (nmap) y con base en la información recolectada realizamos un escaneo de puertos a partir del cual tenemos 2 puertos activos 1 abierto y 1 filtrado.

Mirando los resultados que nos da nuestra herramienta tenemos el puerto 80 abierto y en vista que es un servicio de http ingresamos a través de nuestro navegador web.

Como podemos ver nos presenta una página de inicio de sesión la cual al ingresar cualquier parámetro (no valida al parecer) "procesa" la información y muestra que las credenciales no son correctas.

La verdad inicialmente aquí fue donde me quede varado (después de probar varias cosas con el phpMyAdmin que narro más adelante) pues a mi parecer y según la información que nos muestra la interface inicial una vez lograra saltar el logueo se iba quitar el filtrado del puerto.

Aquí les comento que probé con técnicas de SQL-Injection, LDAP-Injection y hasta X-Path-Injection (con esto solucionan el reto de dragonjar para principiantes) en realidad en este punto me sentí bastante frustrado, al punto que descargue por 2da vez la imagen del reto.
De la misma manera con el fin de recolectar más información mientras a la par probaba con las técnicas antes mencionadas corrí nuestro escáner de vulnerabilidades para aplicaciones Web nikto cuyo resultado fue el siguiente
root@bt:/pentest/web/nikto# ./nikto.pl -h 192.168.209.128 -Cgidirs all -mutate 1 -mutate 2 -mutate 3 -mutate 4
- Mutate is deprecated, use -Plugins instead
- Nikto v2.1.4
---------------------------------------------------------------------------
+ Target IP: 192.168.209.128
+ Target Hostname: 192.168.209.128
+ Target Port: 80
+ Using Mutation: Enumerate user names via cgiwrap (/cgi-bin/cgiwrap/~user type requests)
+ Start Time: 2011-12-16 22:40:25
---------------------------------------------------------------------------
+ Server: Apache/2.2.14 (Ubuntu)
+ Retrieved x-powered-by header: PHP/5.3.2-1ubuntu4.7
+ Apache/2.2.14 appears to be outdated (current is at least Apache/2.2.17). Apache 1.3.42 (final release) and 2.0.64 are also current.
+ DEBUG HTTP verb may show server debugging information. See http://msdn.microsoft.com/en-us/library/e8z01xdh%28VS.80%29.aspx for details.
+ OSVDB-12184: /index.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.
+ OSVDB-3092: /phpmyadmin/: phpMyAdmin is for managing MySQL databases, and should be protected or limited to authorized hosts.
+ OSVDB-3268: /icons/: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ 6448 items checked: 1 error(s) and 7 item(s) reported on remote host
+ End Time: 2011-12-16 22:41:20 (55 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

A partir del cual ya teniamos un poco más de información de nuestro objetivo en este caso le di importancia al phpMyAdmin, pero para poder realizar cualquier acción y establecer si este es un posible punto de intrusión era necesario recolectar algo más de información por lo cual y con el fin de automatizar las cosas procedí cual principiante (muchas veces he pasado cosas por alto por pensar que eran demasiado obvias), así que tomando la ruta completa del phpMyAdmin procedí a realizar una enumeración con dirbuster y uno de sus tantos diccionarios.

Como podemos ver no solo me obtuvieron los directorios y archivos que estaban a su nivel sino que también se logro enumerar los de la raíz como lo es check.php; en este punto me incline por la URL http://192.168.209.128/phpmyadmin/Documentation.html la cual nos revela información del phpMyAdmin que está en la maquina objetivo en este caso 3.3.2

Teniendo información detallada del phpMyAdmin realice la búsqueda de varios exploits iniciando por metasploit, cuyo exploit no aplicaba para la versión de nuestro objetivo

De inmediato el paso a seguir fue buscar en la base de datos de exploitdb (actualizada claro está) donde se encontraron varias opciones de las cuales se seleccionaron los que correspondían a la versión de phpMyAdmin en este caso tenemos 17510.py & 17514.php

Los cuales fallaron y como lo dijo @nonroot en su solucionario del presente entorno, lo más probable es que fue debido a que estos requerían de un directorio especifico con permisos de escritura.

En este punto ya lo único que faltaba por descartar era el puerto 666 cuyo estado es filtrado una vez más volviendo al punto en el cual me quede prácticamente varado, pues no sabía cómo acceder al puerto filtrado (quizá como su estado lo indicaba, había algún tipo de filtrado que permitía solo recibir peticiones de cierto tipo o desde un determinado origen) así que envié peticiones al mismo de diversas formas, pero ni su estado ni la respuesta del mismo cambiaba.
En el momento en que @nonroot publico su solucionario pude verificar que el procedimiento que llevaba era el adecuado, así que de inmediato verifique el paso a seguir y me di cuenta que el escaneo SYN que había hecho previamente sobre el puerto era el adecuado (había visto el video que publico en dragonjar mi amigo Javier Gaviria) sin embargo no sabía que se debía realizar el escaneo SYN sobre todos los puertos; así que procedí a ejecutar el escaneo de la siguiente manera (la verdad me toco hacerlo 2 veces para que el puerto cambiara su estado, ¿por qué?, ¿sería por eso que no abrió cuando hice el escaneo SYN inicial?)

Como se puede ver una vez el puerto cambió de estado, se procedió a verificar que Servicio era el que gestionaba este puerto.
De inmediato se accedió a través del navegador web Firefox, el cual nos presento una aplicación en joomla como nos lo mostraba el logo de la URL, así como la información del mismo en el footer en este caso joomla 1.5

Sin embargo era necesario realizar la respectiva verificación accediendo al código fuente de la página, en el cual se encontró la misma información más detallada.

Al identificar la versión del joomla sonreí debido a que hace un tiempo a través de una vulnerabilidad en el modulo para restablecer las contraseñas de una versión de joomla similar logre cambiar la contraseña del administrador, y acceder de manera satisfactoria, de modo que en esta ocasión al verificar las URL /administrator y /configuration me desinflo ya que no se podía iniciar sesión a través de estas. Siguiendo de la misma forma que en el puerto 80 ejecutamos nuestro scanner de vulnerabilidades nikto sobre el mismo host pero en el puerto 666

No siendo mas probé de nuevo con los exploits que se había probado para el phpMyAdmin ya que este también correspondía a la misma versión 3.3.2 pero como con el anterior los exploits no funcionaron, de esta forma no quedaba más que analizar la aplicación basada en joomla buscando alguna vulnerabilidad en alguno de sus componentes, buscando en exploitdb filtrando por el nombre Joomla encontramos 861 exploits potenciales
root@bt:/pentest/exploits/exploitdb# ./searchsploit joomla | grep -c Joomla
861
Sin embargo no todos aplican para la versión objetivo, así que filtrando se obtuvieron menos opciones de las cuales se procedió a probar los exploits genéricos (sin componentes).

(Si es de utilidad para alguien ahí esta seleccionado el exploit para cambiar el password que mencione antes)
Después de modificar y lanzar varios exploits como el del tiny sin éxito, no quedaba más que verificar los componentes de la aplicación y buscar información de fallos y exploits para estos. Explorando la aplicación se encontraron los componentes (como la idea es hacer todo casi a mano lo hago recorriendo la aplicación y mirando en la URL)
detectando com_user

detectando com_abc

detectando com_mailto

Buscando en la base de datos de exploitdb encontramos que con el filtro mailto no aparecen exploits, con user aparecen varios pero ninguno para el componente com_user y el único encontrado y potencial es el del com_abc

Al lanzar el exploit este nos retorna el volcado de usuarios y passwords del sistema, sin embargo al mirar con detalle podemos verificar que este lo que realiza es un SQL-injection, el cual podemos usar para obtener información adicional (modificándolo).

Una vez tenemos el volcado procedemos a mirar el resultado desde nuestro navegador web usando en mi caso la URL http://192.168.209.128:666/index.php?option=com_abc&view=abc&letter=AS§ionid=-null+union+select+1,concat%280x3a,username,0x3a,password,0x3a%29+from+jos_users--

En este punto vamos volver a una injection básica para desde aquí iniciar como si fuese cualquier otra appWeb.

Verificamos el usuario de acceso a la DB (un fallo garrafal)

Verificamos la versión del MySQL

Intentamos leer el archivo /etc/passwd con la URL http://192.168.209.128:666/index.php?option=com_abc&view=abc&letter=AS§ionid=-null+union+select+1,load_file%28%27/etc/passwd%27%29--

El reto nos dice que debemos leer el archivo key.txt del directorio de root, así que de inmediato tratamos de acceder a él a través de esta página, sin embargo no fue posible, así que la única opción por el momento era ser un poco mas intrusivos de modo que usando el mismo load_file trataremos de leer los archivos de configuración de joomla teniendo en cuenta la estructura de directorios de ubuntu que es el sistema en cuestión (Existen diversas formas y herramientas que permiten esto, pero en este caso lo encontramos en el reporte del nikto y al verificar la versión de MySQL).
El paso a seguir en este punto es intentar leer el archivo /var/www/index.php

Como la lectura fue exitosa solo quedaba leer el archivo de configuración para extraer el nombre de usuario y contraseña de conexión a la base de datos

Como podemos observar tenemos el nombre de usuario root y el password yUtJklM97W
Accedemos a través de nuestro navegador web

Y exploramos la base de datos de joomla, donde podemos ir directamente a la tabla de usuarios jos_users, en la cual podemos editar y de la misma forma agregar o eliminar usuarios como vemos en la imagen a continuación.

Lo anterior se puede decir que es el santo grial para algún chico con ganas de darse golpes de pecho modificando un sitio web y poner su nombre en el mismo, algo como lo que hice a nuestro entorno y que se nuestra en la imagen a continuación en la cual edite el contenido inicial desde la tabla jos_content.

Aunque lo que quiero en lugar de modificar la aplicación es insertar código php para que sea interpretado y ejecutar comandos desde la aplicación Web

Sin embargo nuestra prueba de concepto falla, debido a que todo este contenido se va en un echo y no alcanza a ser interpretado, así que no queda de otra más que aprovechar los privilegios que se tienen y tratar de exportar con outfile en el directorio de publicación de apache, así que probamos con una consulta simple que exporta a un archivo de nombre salida2.txt

Cuyo resultado se pudo accesar través de la URL http://192.168.209.128:666/salida2.txt

De la misma forma creamos un archivo php para verificar si los archivos que se crean tienen permisos de ejecución

Verificamos en la url http://192.168.209.128:666/info.php

Y como el resultado es satisfactorio solo creamos nuestro intérprete de comandos de la misma forma

A la cual accedemos de mediante la URL http://192.168.209.128:666/interprete.php?cmd=pwd

De esta manera verificamos el usuario actual

Procedemos a subir una webshell(my conocida) usando el comando wget

Accedemos a nuestra webshell
Y a parte de navegar entre los directorios, ejecutar comandos, etc; tratamos conectamos usando la shell inversa

Sin embargo no fue posible establecer la conexión debido a que esta presentaba un error de lectura y escritura, así que lo único que quedaba era recurrir a una de las shell inversas en php que encontramos en la parte de backdoors de backtrack, de manera que la subimos en el servidor y la ejecutamos desde el navegador de a través de su URL correspondiente
Para esta conexión era necesario poner en escucha el puerto configurado en la Shell en este caso haciendo uso de la navaja suiza netcat

Una vez tenemos la conexión verificamos el usuario de la misma asi como la ubicación y lo que en este punto más nos interesa información detallada del sistema.

Con base en esta información buscamos un exploit para escalar privilegios de forma local y lo subimos al servidor, esta parte me falto documentarla pero les comento que exploit cuyo nombre en los directorios de exploitdb es 14814.c, con el cual se logro de manera satisfactoria elevar privilegios en el sistema y de esta forma leer al archivo Key.txt

Este archivo contiene un texto que es una codificación en base64 de un gran tamaño, así que lo copiamos en el directorio /var/www y desde la maquina atacante lo descargamos

Como ya se dijo este es una codificación en base 64 la cual decodificamos de la siguiente manera

Como se puede observar al inicio del texto tenemos que este es un archivo .png motivo por el cual volvemos a decodificar pero exportando todo a un archivo que llamare imagen.png
root@bt:~/hackademic2#base64 –d key.txt >>imagen.png
La imagen resultado de la decodificación se presenta a continuación.

Espero y les haya gustado a pesar que se usaron los mismos fallos que uso @nonroot en su solucionario, sin embargo la idea a parte de presentar la solución detallada de este escenario, era realizar las cosas de la manera más manual posible (with nails) ya que existen múltiples herramientas que permiten agilizar las cosas, pero cuando se está arrancando ayudan mas este tipo de guías.

Saludos a todos y gracias por el tiempo que le dedicaron a esta lectura
Att: @crodallega (R0gu3r comunidad DragonJAR)

PD: Gracias a D7n0 porque me motivo a escribir esta guía y me iba a dar el espacio en su blog pero ahora está un poco corto de tiempo y claro a nonroot que me desvaro (la verdad el hecho de que es muy facil kedarse en un punto eso es lo que no me gusta de los CFT)!!!