Saludos de nuevo conej@s!!
Voy a seguir con esta serie de entradas, que como en la anterior: https://www.fwhibbit.es/bitacora-del-pentester-oracle-reports-services-parte-i, hablaré sobre tecnologías de las que puedes beneficiarte a la hora de tú proceso de pentesting xD. También se realizará la explotación de un Cross-Site Scripting, el cual fue reportado al MITRE.
Quiero destacar que esta entrada no es un ###FULL-DISCLOSURE### como la anterior: https://www.fwhibbit.es/lfi-en-cisco-small-business-sa500-series-cuando-la-seguridad-de-tu-red-esta-hecha-un-cisco.
En esta ocasión le ha tocado el turno a JavaMelody. Se dividirá en los siguientes puntos:
- ¿Qué es JavaMelody?
- Información reflejada.
- Jugando sin permisos en la aplicación.
- Invalidar sesiones HTTP activas.
- Liberar recursos de los objetos.
- Generar un heap dump.
- Explotando vulnerabilidades en la aplicación. (CVE-2018-12432)
1. ¿Qué es JavaMelody?
JavaMelody es un framework para monitorizar servidores de aplicación Java EE, tanto en calidad como en producción.
Es una herramienta para medir y calcular estadísticas sobre el funcionamiento real de una aplicación en función del uso por parte de los usuarios. Se basa principalmente en estadísticas de solicitudes y en gráficos de evolución.
Aporta las siguientes características:
- Datos sobre el tiempo de respuesta promedio y número de ejecuciones.
- Toma de decisiones según la tendencia.
- Optimizar según los tiempos de respuestas.
- Encontrar las causas de los tiempos de respuestas.
- Mejorar la optimización después de las verificaciones.
Incluye gráficos resumidos que muestran la evolución en el tiempo de los siguientes indicadores:
- Número de ejecuciones, tiempos medios, porcentaje de errores, solicitudes sql, etc.
- Java memory.
- Java CPU.
- Número de sesiones de usuario.
- Número de conexiones jdbc.
Para más información sobre el proyecto, puedes visitar su página en Github.
2. Información reflejada.
JavaMelody ofrece bastante información de la que puedes sacar provecho. Puedes tener una monitorización limpia y agradable mediante los gráficos que ofrece o crearte tus propios gráficos. Por defecto, muestra la memoria utilizada, CPU, threads que estén activos, sesiones HTTP, etc. Pero para nosotros esta no es la información más importante. Un ejemplo:
Como información importante, te devuelve el nombre del host de la máquina, el sistema operativo que está utilizando, versiones de JDK, el número de versión del servidor utilizado, etc. Otro ejemplo:
Otra información importante son los registros de logs, que pueden ofrecernos datos importantes acerca de la aplicación que se está monitorizando. Ejemplos:
También podemos ver el número de procesos que hay en ejecución, junto con el PID de los mismos.
En el siguiente ejemplo se muestran las estadísticas de sql, en el cual podemos ver querys que se han ejecutado. Lo que podría darnos datos como por ejemplo tablas, nombre de la db, etc.
Sinceramente podría ser algo extenso de nombrar toda la información que sería de interés, por tanto si queréis profundizar en la visualización de toda la información os recomiendo el uso de la demo que ofrecen.
3. Jugando sin permisos en la aplicación.
Ahora que sabemos más o menos la información que nos puede ofrecer, también podremos realizar algún servicio en la aplicación, no solo visualizar datos.
En vuestras auditorías seguro que hacéis un reconocimiento de directorios/archivos. El directorio donde se encuentra esta herramienta es : /monitoring.
Lo primero que se debe saber es que no deberíamos acceder a este sitio sí el servidor estuviera correctamente securizado. Por tanto, sin permisos no podríamos acceder. Cabe destacar que podría dejarse el libre acceso siempre y cuando las herramientas que proporciona este framework que pueden originar cambios tanto en el propio servidor como en el servidor monitorizado estuvieran securizadas. Ahora entenderéis el porqué del nombre de este punto xD.
Os muestro una captura de la demo que proporcionan, con algunos casos de acciones que no deberíamos realizar: (De todas las que se muestran algunas no se pueden ejecutar en la demo, ya que no tenemos permisos para ejecutarlas.)
-
3.1 Invalidar las sesiones HTTP activas.
Como su propio nombre indica… No mucho que decir, ¿Verdad? Realizando esta ejecución mandaremos a paseo las sesiones HTTP.
-
3.2 Liberar recursos de los objetos.
Lo que se puede hacer con esta opción, (tampoco lo veo grave) es eliminar espacio de la memoria. (Para más información véase Garbage Collector).
-
3.3 Generar un heap dump.
Igual que como los anteriores, lo que viene a decir el título. En este caso, la versión demo no nos deja realizar esta petición, ya que nos restringe el acceso. (Por algo será, ¿No?).
Existen otras peticiones que en la demo por ejemplo no se reflejan, ya que son configurables. Por ejemplo, existe una que es la que más me gusta… Y es generar (no descargar a tú propio equipo) pdfs sobre el estado de la monitorización. Igual algun@s os podéis preguntar que tiene de especial, lo especial es que puedes mandar una gran cantidad de peticiones para que se generen dichos pdfs, con lo cual vas a inundar el espacio de almacenamiento del servidor (Vamos, a petarle toa la memoryyyy!!!!). Pues eso, que mandas el server a paseo por dejarlo sin espacio xD.
4. Explotando vulnerabilidades en la aplicación. (CVE-2018-12432).
Como toda tecnología, JavaMelody no está libre de tener vulnerabilidades. En este caso descubrí una nueva vulnerabilidad Dicha vulnerabilidad parece ser que ya fue descubierta en el 2016. Me comuniqué con el fabricante y después de una larga conversación me mostró (copy-paste) el correo de la persona de quien lo descubrió. La verdad que es un poco raro, ya que se le asignó un CVE el cual no existe, y en la página donde supuestamente se reflejaba esta vulnerabilidad no contenía nada de información, solo mostraba que es un XSS y nada más. Digo raro, porque las demás vulnerabilidades reportadas a este fabricante sí contienen la información necesaria para saber si ha sido descubierta antes o no. Por ello, a pesar de haber reportado dicha vulnerabilidad al MITRE, esta vulnerabilidad no sería mía, ya que otra persona la descubrió antes. En vista de lo ocurrido, he modificado la página de Github y he puesto el nombre del usuario quien la descubrió.
El texto anterior como podéis ver ha sido editado, ya que la entrada ya la tenía preparada hace tiempo. Es por ello que los siguientes textos son anteriores a esta edición, por lo tanto en ellos describo mi experiencia sin tener en cuenta lo anterior mencionado.
Os voy a contar un poquillo la experiencia y la sencilla PoC de la explotación del Cross-Site Scripting que encontré.
En los puntos anteriores, habéis podido observar un poco que es lo que ofrece y lo que puedes hacer con la aplicación. Sé que hay gente que se pregunta cómo puedes encontrar una vulnerabilidad, pues depende. Depende del tiempo que le dediques, y que dicho tiempo sea productivo. Del esfuerzo y las ganas que quieras dedicarle mientras lo haces, como todo en la vida.
Por ejemplo, los casos descritos en el punto 3, si no os habéis fijado bien, se generan cuadros de diálogos… Oye, la propia aplicación ya te está invocando un alert, en otra ocasión puede ser un prompt o un confirm. ¿Por qué no probar?
En este caso es lo que yo hice. En una petición de la aplicación hay un parámetro al que se le puede dar un valor y se refleja en un alert. (Coño!! Ahí te tienes que dar cuenta de que es un vector de puta madre!!).
La verdad que con el simple <script>alert(1)</script> se ejecutó. Dejó de salir el mensaje informativo de alerta que salía junto con el valor que introducías para que únicamente saliera el 1. Pues ya está hecho.
Lo que hice fue (niñ@s, no hagáis esto en casa sin supervisión de un adulto) probar sí en otro JavaMelody se podía reproducir el bug… En efecto así fue, y con una versión inferior que la inicial. Por tanto sabía cual era el siguiente paso.
El siguiente paso fue sin más buscar que dicho producto no tuviera la misma vulnerabilidad publicada. Buscar que los demás XSS que existían en la herramienta no afectasen en el mismo lugar que yo había descubierto. Al parecer por ahora he tenido suerte xD. Ya no lol.
«Lo demás ya es sencillo», dado a mi anterior experiencia, decidí directamente ponerme en contacto con el MITRE y mandar la vulnerabilidad. Ellos ya se encargan de asignarte el identificador y de realizar las gestiones pertinentes. (No solo ellos se encargan de la evaluación de las vulnerabilidades).
La vulnerabilidad fue mandada el 14/06/2018. Por ahora está pendiente de que se analice. Más adelante según vaya sufriendo cambios iré editando la entrada para actualizar dichos cambios.
La vulnerabilidad ya ha sido analizada y confirmada. Dejo los enlaces a ella.
https://nvd.nist.gov/vuln/detail/CVE-2018-12432
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12432
https://www.cvedetails.com/cve/CVE-2018-12432/
Espero realmente que esta entrada haya servido de algo a alguien, con eso me conformo y en realidad es la verdadera gratificación que puedo obtener de ello.
Muchas gracias por vuestro tiempo en leerme a mí y a mis compañer@s. A todo esto, quiero dejar claro que no soy ningún experto, por tanto es probable que me haya podido equivocar en algún dato. Sí es así pido por favor que os comuniquéis conmigo para solventarlo.
Nos vemos en próximas aventuras Conej@s. Y recordad, conejead el mundo xD.