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. Mi charla en el pasado Hack&Beers de Tamarite (Huesca), 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.
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:
Una 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.
¡Hasta la próxima!