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