Armitage

¿Que es armitage? armitage es una herramienta gráfica para automatizar los ataques de metasploit, muy útil al momento de realizar una penetración a un servidor, ya que al momento de realizar un escaneo a un objetivo te dice que exploits son lo que podrían servir contra el objetivo, cuenta con muchas mas opciones que explicaremos mas adelante.

TUTORIAL:

Primero debemos sacar la dirección IP de nuestra victima, a través de un ping a su servidor web,debemos abrir una terminal y hacerle ping a la Pagina web.

# ping www.paginaweb.com

El cual nos devolverá la ip (72.32.231.8) del servidor en el cual esta alojada la pagina web.

A continuación trabajaremos directamente con Armitage,para ello abriremos otra terminal e iniciaremos el armitage

# armitage

Le daremos a connect

Aquí nos dice que el servidor rpc no se esta ejecutando y nos pregunta si queremos iniciarlo nosotros, le damos a yes y comenzara a iniciarse, si es la primera vez que ocupan armitage se demorara un poco en conectarse.

Bueno una vez abierto iremos a Hosts/Add hosts...

Ingresamos la direccion IP de nuestro objetivo y le damos a  Add

una vez que adhieran la dirección IP les saldrá un icono de un monitor y la ip debajo de el, le damos click derecho y click en scan para realizare un escaneo al servidor, el escaneo nos dirá que puertos están abiertos,que sistema operativo es que esta instalado y que servicios corren por los puertos,etc... 

Esperamos a que el escaneo finalice.

Como se puede ver en la imagen el servidor es linux, si subimos al principio podremos ver los puertos que se encuentran abiertos.

Bueno sigamos, iremos a attacks/find attacks , para ver que ataques podrían servir contra el objetivo le damos click y esperamos ya que demora un poco, una vez finalizado nos saldrá un recuadro diciendo que el escaneo de ataques finalizo.

Una vez finalizado el escaneo de posibles ataques le damos click derecho al objetivo y nos saldrá la lista de todas las posibles vulnerabilidades a explotar, si se fijan aparece una opción para probar si el exploit sirve con la vulnerabilidad encontrada (check exploits) pero no todos los exploits soportan esta opción.

Le dan a check exploits para probarlos, esta es la mejor parte de armitage ya que nos ahorra el tiempo de ir probando los exploits uno por uno, bueno si probaron los exploits y ninguno sirvió pueden seguir probando con los distintos servicios .

(el objetivo no es explotable)

como vemos encontró una vulnerabilidad y se puede explotar :) iremos al objetivo nuevamente y le daremos

click derecho attack y  buscamos la vulnerabilidad encontrada en este caso (tikiwiki_graph_formula_exec) y le damos click, se nos abrira esta consola en donde podremos configurar nuestro exploit.

Le damos a Launch para lanzar el exploit, una vez listo el exploit nos dará la opción de abrir una shell al servidor y  al icono de nuestro objetivo le saldrán rayos al mas puro estilo de una película de hackers de hollywood xd.

esta la opción de subir un archivo podríamos subir una backdoor si queremos mantener el acceso al servidor, un troyano o un keylogger, hay depende de las intenciones que tengan, pero por ahora lo dejaremos hasta aquí.

Explotando vulnerabilidad en Java 7 – PoC

A estas alturas creo que todo el mundo está ya al tanto acerca de la vulnerabilidad en Java 7, y de la cual Oracle aún no ha publicado una actualización de seguridad. Ayer mismo anunciábamos en este blog la criticidad de esta vulnerabilidad y de la gravedad de la misma.

La gravedad se acentúa cuando ya se ha publicado un exploit capaz de aprovecharse de esta vulnerabilidad y explotándola, permitiendo al atacante ejecutar código remoto en la máquina vulnerada.

Explotando vulnerabilidad en Java 7 – PoC

odo esto, y gracias a que en Metasploit ya tenemos disponible el exploit, me he decidido a hacer una PoC (Proof of Concepto, prueba de concepto) para comprobar realmente la criticidad de facilidad de explotación de la nombrada vulnerabilidad.

Para empezar, decir que he actualizado Metasploit hoy mismo para tener todos los módulos actualizados. También he vuelto a instalar y habilitar Java 7 en un Internet Explorer para realizar las pruebas, ya que lo tenía deshabilitado desde que salió la noticia de la vulnerabilidad.

Una vez actualizado MSF buscamos el exploit, en este caso podemos observar que es bastante reciente, data de ayer y su ranking es excelente. Perfecto!

Vamos a usar este exploit, ejecutamos los comandos necesarios y observamos que por defecto no hay que modificar ninguna opción del exploit.

Para el payload vamos a usar uno del tipo meterpreter:

Como se observa en la imagen, sólo hay que especificar la opción LHOST que hace referencia a la IP de nuestro equipo, el equipo atacante. Sólo falta lanzar el exploit y esperar que la víctima se conecte:

Copiamos la URL y la vamos a escribir en el navegador de la máquina víctima, en este caso con un Internet Explorer:

En esta caso mi antivirus Avira ha detectado el exploit, bueno ya que Oracle no lo ha solucionado, parece que las firmas AV sí lo detectan. Una vez más, la importancia de mantener actualizado nuestro antivirus. ¿Y si deshabilito el antivirus?

Bingo! Ya tenemos sesión Meterpreter, ya podemos “trastear” en la máquina víctima. Poder ver información del sistema u obtener una shell para acceder a su línea de comandos.

,

 Resumiendo, en primer lugar se aconseja deshabilitar Java, también mantened actualizados vuestros antivirus y comprobar que funcionan correctamente, como habéis podido comprobar, mi última actualización de la base de firmas de Avira (hoy) me lo ha detectado.

Resumiendo, en primer lugar se aconseja deshabilitar Java, también mantened actualizados vuestros antivirus y comprobar que funcionan correctamente, como habéis podido comprobar, mi última actualización de la base de firmas de Avira (hoy) me lo ha detectado. - See more at: http://hacking-etico.com/2013/01/12/explotando-vulnerabilidad-en-java-7-poc/#more-1393

Resumiendo, en primer lugar se aconseja deshabilitar Java, también mantened actualizados vuestros antivirus y comprobar que funcionan correctamente, como habéis podido comprobar, mi última actualización de la base de firmas de Avira (hoy) me lo ha detectado. - See more at: http://hacking-etico.com/2013/01/12/explotando-vulnerabilidad-en-java-7-poc/#more-1393

Exploit para SugarCRM y sus demos 2 parte

La idea es poder comprobar lo que recoge res.get.cookies y la expresión regular.

El problema es que la Cookie no incluye la cadena “path” del final, tal y como intenta comparar la expresión regular, de ahí que, incluso escribiendo las credenciales correctas y obtener una sesión, el código devuelva siempre “false” en esta condición y provoque el error en el exploit.

Modificamos esa línea, dejándola de la siguiente forma:

na vez realizado el cambio y almacenado el exploit, volvemos a lanzarlo.

¡Bingo! Ahora sí hemos logrado explotar la vulnerabilidad y obtener una sesión meterpreter. Comprobamos que estamos usando el usuario www-data, estamos situados en /var/www/sugarcrm del servidor y podemos listar el contenido de este directorio.

A partir de aquí, el límite está en nuestra imaginación y de momento en los privilegios del usuario. Como muestra, un pequeño defacement.

Por último, y a modo de sensibilización y conciencación, cabe destacar que muchos de los sitios Web que ofrecen “demos” (facilitando usuario y contraseña) de SugarCRM con versiones vulnerables, están alojados en servidores Web compartidos. Por lo tanto, estamos ante un hecho bastante grave ya que no sólo se puede compremeter el sitio Web con SugarCRM, también los sitios Web alojados en ese mismo servidor Web. Y aunque se trate de una vulnerabilidad con más de 2 años, desgraciadamente aún hay muchos (muchísimos) sitios Web afectados por esta vulnerabilidad.

Como siempre, espero que resulte de vuestro interés, y si tienes un SugarCRM vulnerable, actualiza lo antes posible, por tu seguridad y por la de tus “neighbours” de servidor.

Exploit para SugarCRM y sus demos

En este artículo os hablaré sobre cómo detecté y corregí un pequeño “error” en un exploit para SugarCRM que no funcionaba correctamente.
 trató precisamente sobre esto. Supongo que algo habrá cambiado en el tratamiento de URLs y Cookies de este CRM desde que se publicó su vulnerabilidad y exploit, exactamente el 25 de Junio de 2012, que a día de hoy cause el error en un exploit que se publicó al día siguiente de la publicación de la vulnerabilidad.
 Enlace a información de la vulnerabilidad:
 http://www.securityfocus.com/bid/54169

Enlace al exploit: http://www.exploit-db.com/exploits/19403

 SugarCRM es un sistema para la administración de la relación con los clientes (CRM) basado en LAMP (Linux-Apache-MySQL-PHP), desarrollado por la empresa SugarCRM, Inc. ubicada en Cupertino, California.

 La vulnerabilidad que estamos tratando permite la ejecución de código remoto.

 Para esta prueba de concepto, tenemos preparado un SugarCRM con una versión vulnerable, con un usuario creado con las siguientes credenciales: sugarcrm/sugarcrm.

Se requiere saber las credenciales de un usuario de SugarCRM para explotar esta vulnerabilidad. Esto puede hacer pensar que el número de exposición de sitios Web con SugarCRM vulnerables es muy limitado, sin embargo, hay que tener en cuenta que son muchos (muchísimos) los sitios Web que ofrecen probar SugarCRM en una demo, facilitando el usuario y contraseña para probar el CRM.

 En la imagen anterior podemos ver una captura de una búsqueda en Google que muestra resultados de sitios Web con SugarCRM que ofrecen una demo y además facilitando un usuario y contraseña. Justo lo que nos requiere el exploit que vamos a usar.

El exploit para SugarCRM que vamos a utilizar es de Metasploit: sugarcrm_unserialize_exec.

 Después de poner en uso el exploit, lo configuramos con las opciones requeridas: USERNAME (sugarcrm), PASSWORD (sugarcrm) y RHOST (192.168.1.39, dirección IP del servidor con SugarCRM). Los valores son los correctos para el sitio SugarCRM que tenemos preparado para la prueba de concepto. Como payload hemos seleccionado una sesión meterpreter vía PHP, mediante conexión inversa (reverse_tcp).

 Al ejecutar el exploit, obtenemos un mensaje de error durante el “Login“, aún habiendo introducido las credenciales correctas (sugarcrm/sugarcrm). No se obtiene una ID de sesión. Procedemos a repasar el código del exploit y localizamos que el mensaje de error lo muestra cuando no se cumple una condición.

 Por alguna razón, con las credenciales correctas, la variable res.get.cookies no contiene la expresión regular que el código del exploit propone, para descubrir si se ha obtenido una sesión (PHP).

En primer lugar, con un proxy Web local como ZAP, comprobamos el formato de la cookie que se genera cuando hacemos “Login” en SugarCRM a través del navegador.

 En principio, tal y como nos muestra ZAP Proxy, el formato de la Cookie generada cumple exactamente lo que la expresión regular del código intenta “matchear“. Falta comprobar cuál es el valor que recoge la variable. Para ello incluiremos una línea nueva en el código para hacer un “print” del contenido de la variable.

trató precisamente sobre esto. Supongo que algo habrá cambiado en el tratamiento de URLs y Cookies de este CRM desde que se publicó su vulnerabilidad y exploit, exactamente el 25 de Junio de 2012, que a día de hoy cause el error en un exploit que se publicó al día siguiente de la publicación de la vulnerabilidad. - See more at: http://hacking-etico.com/tag/exploit/#sthash.F4F23lBf.dpuf

Parando Metasploit con Snort

Hoy vamos a ver como podemos detectar cualquier tipo de ataque a una aplicación vulnerable de nuestro servidor, simplemente analizando aquellos posibles exploit que puedan ser lanzados contra este y añadiendo una regla en nuestro IDS para detectarlos y pararlos, en nuestro caso utilizaremos Snort. El escenario sería el siguiente:

La idea es identificar una característica única del exploit a detectar con el IDS y crear una regla con Snort para detectarlo. Para ello previamente lo que hacemos es lanzar el exploit para explotar la vulnerabilidad y capturar el tráfico para analizarlo.

En este momento tenemos que identificar una característica única/particular de este exploit. Debemos ser capaces de obtener la máxima información de como funciona el exploit, para ello podemos analizar el código del propio exploit así como examinar su documentación.

Exploit –> http://www.exploit-db.com/exploits/28681/

Concretamente hemos usado un exploit bajo metasploit para explotar el puerto 21 de un FreeFTPd con una vulnerabilidad que lleva a cabo un PASS Command Buffer Overflow, es decir, introducir una contraseña no esperada para provocar un desbordamiento de buffer. Lanzamos el exploit varias veces y obtenemos varios ficheros .pcap que nos disponemos a analizar exhaustivamente:

Una vez que somos capaces de sacar información que identifique al exploit unívocamente nos disponemos a generar una regla en Snort. Las reglas en Snort constan de dos partes: la cabecera y las opciones. El objetivo de este artículo no es explicar el funcionamiento de Snort, ni tampoco el de como crear una regla, para ello podéis consultar

http://manual.snort.org/

Si analizamos cada uno de los paquetes que lanza el exploit veremos que se están inyectando operaciones tipo NOPs (No-Operation, instrucciones que no hacen nada, como por ejemplo sumarle 0 a un registro) para rellenar instrucciones además del Payload inyectado. Esto se suele hacer por muchos tipos de malware para reconducir la ejecución del programa, caso de caer en una posición de memoria donde haya una NOP, se ejecutarán todas las instrucciones que no hacen nada hasta llegar al trozo de código malicioso que realmente quiere ejecutar el atacante. Vemos con Wireshark las NOPs y lo que realmente inyecta el Payload.

Con toda esta información ya podemos crear un regla en nuestro IDS Snort para detectar este exploit. A continuación mostramos la regla creada según las peculiaridades encontradas en el exploit:

drop tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:”Exploit FreeFTPd  PASS Command Buffer Overflow detectado by Hacking-Ético”;  content:”USER anonymous”; content:”PASS “; pcre:”/^PASS\s[^\n]{100}/smi”; classtype:shellcode-detect; sid:1000001; rev:1; nocase;) ;

Hemos visto que el exploit va dirigido al puerto 21, que hace uso del usuario anónimo y que introduce varios caracteres raros en la parte de la PASS, por tanto esas serán nuestras características concretas para nuestra regla.

Analicemos pues la parte de la cabecera:

drop tcp $EXTERNAL_NET any -> $HOME_NET 21

Se aplicará la regla de eliminación de paquete (drop) a todos aquellos paquetes que vengan vía tcp desde una red exterior ($EXTERNAL_NET es una variable que identifica cualquier IP externa) desde cualquier puerto de comunicación en el origen (any); y cuya petición vaya destinada a una IP interna ($HOME_NET idem IP interna) sobre el puerto 21.

Dentro de la parte de las opciones:

(msg:”Exploit FreeFTPd  PASS Command Buffer Overflow detectado by Hacking-Ético”;  content:”USER anonymous”; content:”PASS “; pcre:”/^PASS\s[^\n]{100}/smi”; classtype:shellcode-detect; sid:1000001; rev:1; nocase;) ;


En este apartado determinaremos que características tienen los paquetes que deben ser eliminados. Dejaremos constancia del bloqueo de paquetes en el log de Snort con el mensaje que aparece en msg.

El paquete debe ser una petición de usuario anónimo y que la clave contenga alguno de los datos contenidos en la expresión regular (pcre). Dicha expresión regular debe estar escrita en perl, podéis encontrar diferentes expresiones regulares y reglas en el fichero policy.rules de Snort. El resto de las opciones determinan la clase de paquete (classtype), el identificador de la regla local (sid) y revisión (rev); y por último añadimos la palabra nocase para indicar al motor de Snort que la aplicación de la regla no sea “case-sentitive“.

La regla se añadirá al final del fichero de configuración de snort (snort.conf). Una vez añadida se comprueba su funcionamiento con los .pcap capturados del ataque para ver si es efectiva en caso de producirse nuevo ataque.

snort -A fast -c /ruta/snort.conf –pcap-dir=”/ruta/pcaps/” -l .

-A modo de la alerta, rápida en este caso (fast)

-c fichero de reglas, en este caso el snort.conf que hace referencia a todos los ficheros de reglas de que se encuentra en la carpeta de snort (/rutaSnort/rules) y además contiene al final nuestra regla. Debe ponerse todo en una sola línea.

–pcap-dir indicamos la carpeta donde están los pcap para comprobar.

-l indicamos la carpeta de salida del log (se creará un fichero llamado alert)

Una vez comprobado el funcionamiento de las reglas con los pcaps que contienen la captura del exploit, obtenemos el siguiente resultado:

Vemos como además de nuestra regla, hay otras reglas dentro de snort que detectan el uso del usuario anonymous o el overflow en la PASS. Ahora sólo tendremos que coger un exploit de un 0day y analizarlo para crear una regla de Snort y que no afecte a nuestro servidor hasta que podamos parchear la vulnerabilidad en cuestión. También se suele analizar el tráfico que genera ciertos malware y crear reglas en función de las peticiones que realicen.

Bueno ahora sólo queda que os pongáis a jugar con algunos exploits y los analicéis para poder detectarlos.