Análisis de un HPP (HTTP Parameter Pollution) en Apple @Owasp #Apple #HPP #pentesting
Las técnicas de HPP (HTTP Parameter Pollution) llevan ya un tiempo entre nosotros. Fueron publicadas por Stefano Di Paola y Luca Carretano en la conferencia OWASP 2009, y desde entonces han sido utilizadas en muchos ataques distintos. Se basan en conseguir un comportamiento anómalo en las aplicaciones web duplicando (polucionando) los valores de los parámetros de entrada. Es decir, vamos a suponer que una aplicación recibe el parámetro1 con valor 23. Lo que se preguntan las técnicas de HPP es... ¿Qué pasa si le enviamos a la aplicación web el parámetro1 dos veces con valores 23 en el primero y 24 en el segundo? ¿Usará el primero? ¿El segundo? ¿Todos?
Con esa idea de polucionar los parámetros, en este caso los parámetros de las cadenas de conexión a bases de datos, construimos las técnicas de Connection String Parameter Pollution [PDF] que me tocó explicar en detalle en el libro de Hacking Web Technologies. Todo partió de la idea de polucionar todo lo que teníamos por delante, gracias a la aparición del HPP, y de eso hablamos Stefano y yo cuando nos conocimos.
Figura 2: Comportamiento con parámetros polucionados según las tecnologáis |
En el caso de las aplicaciones web, el comportamiento que se va a obtener en cada caso depende de la tecnología de backend que tengamos. Según el estudio inicial realizado, esta tabla sería la lista de casos que se esperan cuando se poluciona un parámetro en el QueryString de una aplicación web.
Un bug de HPP en los foros de Apple
Nosotros tenemos un plugin en nuestro sistema de Pentesting Persistente Faast creado exclusivamente para descubrir este tipo de bugs, y a veces te lo encuentras de forma muy sencilla en sitios como los Foros de Apple, como es el caso de hoy.
Figura 3: El buscador de temas por etiquetas en los foros de Apple |
Vamos a ver este ejemplo en detalle. En esta imagen tenemos la lista de etiquetas con las que han sido marcados los diferentes temas del foro. Con el interfaz, basta con seleccionar una de las etiquetas para ver que queda añadida el QueryString con el parámetro tags que coge como valor el de la etiqueta pulsada. Esta etiqueta es pintada en el buscador y recibimos la lista de temas que la tienen asignada.
Figura 4: Se elige la etiqueta, se envía en el Querystring, se imprime y salen los artículos |
Esto es un funcionamiento normal y habitual, pero quería remarcarlo para explicar que hay una aplicación en el backend que está recibiendo el QueryString, extrayendo el valor de tags, buscando los temas y pintando la página de respuesta en función del valor de tags.
Si seleccionamos dos etiquetas, vemos que la aplicación está preparada para ello, añadiendo las dos etiquetas en el mismo parámetro tags separándolas por el operador de suma. Algo bastante habitual. Esto significa que la aplicación en el backend está preparada para procesar el string que le llega en el parámetro tags y sacar la lista de etiquetas.
Pero ¿qué pasaría si polucionamos el parámetro tags? Pues bien, en este caso la tecnología del backend ha generado una lista con todos los valores separados por commas. Esto es interesante, porque cuando el QueryString ha procesado la lista CSV (Comma Separated Values) generada en el parámetro tags, ha sido capaz de descubrir las dos tags, pero luego no ha sido capaz de imprimirlas correctamente.
Figura 6: Comportamiento con polución del parámetro tags |
Esto quiere decir que la tecnología en el backend está generando una lista CSV con los valores de los parámetros polucionados, que la aplicación en el backend está preparada parcialmente para procesarlos, y parcialmente no está preparada.
¿Es esto un bug?
Visto el entorno, no parece que sea un "security bug" de ninguna manera, pero sí que existen casos sin controlar, por lo que podría darse una situación no deseada más allá del fallo de impresión de las etiquetas en el campo de texto en otros entornos, como ya se ha visto con estos bugs de HPP en el pasado.
Corolario tecnológico
Para terminar, tras ver que se generaba una lista de valores separada por comas, siguiendo la tabla de casos publicada en HPP, decidí comprobar si había algún cambio, así que pasé por BuiltWith el sitio web para ver qué tecnologías son las que hay detrás y que han generado este comportamiento.
Figura 7: Tecnologías detrás de Forum.Apple.com |
Como podéis ver, sale que es un Apache con J2EE, que no estaba contemplada en la tabla, pero que si nos basamos en este comportamiento funciona igual que un servidor IIS o un servidor Apache con Python.
Saludos Malignos!
5 comentarios:
Hola Chema,
he leido atentamente el articulo de hoy, parece que el HPP en el parámetro tags no genera ningún riesgo en la aplicación, por lo tanto ¿por que debería considerarse una vulnerabilidad?
Además ¿Con que objetivo haces uso de builtwith?
Thank you ;)
@Eduardo. Es lo que he dicho, existe un pequeño "bug" de funcionalidad pero no un bug de seguridad. Lo que me parecía interesante es explicar cómo funciona el descubrimiento de HPP y cómo sacarle valor. Lo de Builtwith era para comprobar que un Apache con J2EE también genera CSV en los parámetros polucionados, que no estaba en la tabla de comportamientos iniciales.
Saludos!
@maligno a lo que entiendo es que el bug permite conocer la tecnología detrás del front end permitiendo así la generación de inteligencia. y que adicional este comportamiento no estaba contemplado en la aplicacion de modo inicial ya que no se previó que funcionase así.
@Johnatan, no. Relee el artículo en detalle y lee las referencias a HPP.
Muy interesante e ilustrativa la entrada, una de las cosas que propone OTG de OWASP es comprobar si una aplicación web es vulnerable a ataques de tipo HTP (OTG-INPVAL-004). Coincido con @maligno en que esto de por sí no podemos decir que sea una vulnerabilidad de seguridad pero está exponiendo por si misma ciertas lógicas de la aplicación que pueden ser aprovechadas por un atacante para comprender mejor como funciona esta. Gracias por el aporte.
Publicar un comentario