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?

Figura 1: Análisis de un HPP (HTTP Parameter Polluiton) en Apple.com

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.

Figura 5: Comportamiento con selección múltiple 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!

Formaciones para hax0rs en hacking y auditoría

En poco tiempo van a tener lugar tres formaciones en Seguridad Informática y Técncias Hacking que merece la pena resaltar, así que aquí os las dejo:

FTSAI 7th

Mañana viernes 20, y a lo largo de muchos meses, va tener lugar la siguiente edición de la Formación Técnica en Seguridad y Auditoría Informática que damos en Informática64. El curso está formado por 6 módulos repartidos en diferentes disciplinas de este trabajo. Tienes toda la información en FTSAI.

Black Hat Webcast: HTTP Parameter Pollution

El día 25 tendrá lugar un webcast gratuito, en inglés, sobre las Técnicas de HPP, de las que hemos hablado alguna vez, y de las que Carmen, una de las creadoras de Papas, nos hizo un artículo [HPP: Http Parameter Pollution]. Aunque es gratuito, debes registrarse.

Seguridad en GSM/UMTS

Los días 1, 2 y 3 de Junio tendrá lugar en Valencia el Curso de Seguridad en GSM/UMTS que los "maquinotes" de Taddong impartirán. Este curso permitirá, durante tres días, tocar y practicar las técnicas hacking en estas tecnologías. De todo su trabajo hemos ido recogiendo algunas pinceladas:

- Ataques mitm a dispositivos móviles con redes flasas GPRS
- Riesgos en la predicción de direciones Bluetooth en dispositivos Apple
- iPhone no alerta de redes GSM sin cifrar
- Ataques selectivo con estaciones base GSM/UMTS falsas

Tienes el temario completo del curso en: Curso de Seguridad GSM/UMTS

Saludos Malignos!

HPP: Http Parameter Pollution

Recientemente hemos visto una vulnerabilidad de HTTP Parameter Pollution afectando al sistema de Blogs de Blogger que permitía convertirse en administrador de cualquier blog. Las tecnicas HPP son mucho más peligrosas de lo que la gente está evaluando, y debido a la poca cantidad de herramientas que las buscan, hoy en día hay muchas aplicaciones web vulnerables ahí fuera.

Carmén Torrano, una investigadora de seguridad española, está trabajando en PAPAS, una aplicación que evalúa online la existencia de vulnerabilidades HPP en aplicaciones web. Ella se comprometió conmigo a hacer un artículo sobre HPP y PAPAS y aquí lo tienes. Gracias Carmen.

Saludos Malignos!

Conceptos previos: Precedencia

En gran parte de las páginas web actuales, cuando un usuario visita una página web, necesita proporcionar datos de entrada a dicha aplicación. Los parámetros de las aplicaciones web permiten traspasar datos de entrada de los usuarios a la aplicación. En algunas ocasiones, el navegador envía una petición en la que un parámetro con el mismo nombre aparece repetido varias veces. Por ejemplo, el caso de una aplicación en la que aparezca un checkbox en el que es posible seleccionar múltiples opciones. Para estos casos, muchos lenguajes de programación proporcionan métodos que devuelven una lista con todos los valores asociados a un parámetro.

Supongamos que un desarrollador espera recibir un solo valor para un parámetro y por tanto, utiliza un método que devuelve un único valor. En el caso de que la petición contenga múltiples valores para el parámetro en cuestión, se pueden dar tres posibilidades:

1. Que el método devuelva el primer valor del parámetro
2. Que devuelva el último
3. O que devuelva una combinación de todos los valores.

No hay un estándar para ello y como se puede ver en la tabla, el resultado depende del lenguaje de programación y del servidor web empleado.



El hecho de que el método devuelva un solo valor no es una vulnerabilidad por sí sola, sin embargo, la presencia de múltiples valores para un parámetro abren la posibilidad de que el método no obtenga el valor esperado para el parámetro.

Si el desarrollador no es consciente del problema, se podrían producir comportamientos anómalos, que podrían ser aprovechados por un atacante. Como se verá más adelante, esto se puede utilizar junto con las vulnerabilidades HPP para sobrescribir el valor de un parámetro.

¿Qué es HTTP Parameter Pollution(HPP)?

Un ataque de polución de parámetros HTTP consiste en la inyección de delimitadores de query string codificados en otros parámetros existentes. Si el parámetro en el que se ha realizado la inyección no se valida correctamente y se utiliza decodificado para generar una URL, el atacante puede insertar uno o más parámetros en dicha URL.

Los ataques de polución de parámetros HTTP son relativamente recientes, fueron presentados por Stefano di Paola y Luca Carettoni en OWASP 2009 y no se han estudiado con demasiada profundidad hasta el momento.

Las consecuencias de este ataque dependen de la lógica de la aplicación y pueden tener desde un leve impacto hasta una gran importancia.
Algunas de estas consecuencias son:

- Sobreescritura de parámetros con codificación fuerte para modificar el comportamiento de la aplicación.

- Salto de los puntos de validación de los datos de entrada.

- Acceso y posible explotación de variables fuera del alcance directo.

Para que la vulnerabilidad sea explotable es necesario que la precedencia sea tal que el método no devuelva el parámetro esperado ante la presencia de parámetros duplicados. Las vulnerabilidades HPP pueden explotarse para realizar tanto ataques del lado del servidor como ataques del lado del cliente.

Respecto a los ataques del lado del servidor, es posible burlar la defensa de los Cortafuegos de Aplicación Web (WAFs) y también pueden influir en la reescritura de la URL.

En el lado del cliente, es posible inyectar parámetros en los enlaces y en los formularios. Típicamente, en este tipo de ataques, el atacante trata de persuadir a la víctima para que visite una URL que explota la vulnerabilidad HPP.

Un ejemplo de HPP en una aplicación

Por ejemplo, consideremos una aplicación web de votaciones que permite a los usuarios participar en diferentes elecciones y votar a su candidato favorito. La aplicación está escrita en JSP. En caso de múltiples instancias de un parámetro, el método Request.getParameter("par") de JSP devuelve el primer valor del parámetro.

La aplicación recibe un parámetro (“eleccion_id”) que es el identificador de la elección concreta en la que está participando el usuario. En función de los valores del parámetro, la aplicación genera una página que contiene un enlace para cada uno de los candidatos de la elección correspondiente.

Por ejemplo, en este fragmento se muestra una página de una elección con dos candidatos en la que el usuario puede votar a su candidato pinchando en el enlace deseado:

Url : http :// servidor / eleccion . jsp ? eleccion_id =4568
Enlace1 : <a href =" votar . jsp? eleccion_id =4568& candidato = white ">
Voto para Mr. White </a>
Enlace2 : <a href =" votar . jsp? eleccion_id =4568& candidato = green ">
Voto para Mrs. Green </a>

Supongamos que Pedro, que es un seguidor de Mrs. Green, quiere modificar el resultado de las elecciones. Analizando la página se da cuenta de que la aplicación no valida correctamente el parámetro “eleccion_id”. Por tanto, utiliza la vulnerabilidad HPP para inyectar el parámetro “candidato” en el parámetro “eleccion_id”, de la siguiente forma:

http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%4Dgreen

Pedro envía esta URL a Alicia. Cuando Alicia pincha en el enlace, es dirigida al sitio original de las elecciones donde puede votar a su candidato para esa elección. Sin embargo, como la aplicación utiliza el parámetro “eleccion_id” para formar los enlaces, cuando Alicia visita la página, el valor inyectado para el candidato se incluye en las URLs:

http :// servidor / eleccion . jsp? eleccion_id =4568%26candidato%3Dgreen
Enlace 1: <a href = votar . jsp ? eleccion_id =4568&candidato=green&candidato =white >
Voto para Mr. White </a>
Enlace 2: <a href = votar . jsp ? eleccion_id =4568&candidato=green& candidato =green >
Voto para Mrs. Green </a>

No importa en qué enlace pinche Alicia, el script “votar.jsp” recibirá dos instancias del parámetro “candidato”. El primer valor del parámetro siempre es “green”. Si el desarrollador de la aplicación utiliza la funcionalidad básica de Java para obtener un solo valor para el parámetro “candidato”, sólo se obtendrá el primer valor del parámetro (es decir, “green”) y el segundo valor (que tiene el voto de Alicia) es descartado.

Como se ha visto en el ejemplo, al ser esta aplicación vulnerable a HPP es posible para un atacante modificar un enlace, que cuando se visita, falsifica el contenido de la página y genera enlaces que fuerzan el voto para Mrs. Green.

Se trata de ataque bastante reciente pero que como se ha mostrado, el ataque HPP puede tener graves consecuencias, por lo que es importante que los desarrolladores sean conozcan este ataque y tomen las contramedidas oportunas.

Nuestra herramienta: ¡Pruébala online!

Hasta donde sabemos, no se han presentado herramientas automáticas hasta la fecha que detecten este tipo de vulnerabilidades en las aplicaciones web. Además, no se ha estudiado cuantitativamente en qué medida afecta la vulnerabilidad HPP en las páginas web.

Por tanto, en la conferencia NDSS (Network and Distributed System Security Symposium) presentamos PAPAS (PArameter Pollution Analysis System), una herramienta que permite detectar automáticamente las vulnerabilidades HPP en aplicaciones web.

Realizamos experimentos en más de los 5000 sitios web más importantes y populares (según Alexa). Los resultados del análisis muestran que casi el 30% de los sitios web contienen al menos una página vulnerable a HPP. Esto significa que la herramienta fue capaz de inyectar automáticamente un parámetro codificado dentro de unos de los parámetros existentes y de verificar que fue incluido decodificado en uno de las URLs (enlaces o formularios) de la página resultante.

Es más, casi el 47% de las vulnerabilidades encontradas (14% del total de sitios web) se pueden explotar por medio de ataques HPP. Nuestros experimentos nos revelaron que la vulnerabilidad HPP afecta a sitios tan conocidos como Microsoft, Google, etcétera.

¿Quieres saber si tu aplicación web es vulnerable a HPP? La herramienta se puede probar online gratuitamente en: http://papas.iseclab.org. ¡Espero que os guste!

Saludos,
Carmen Torrano

Ponle PAPAS a tu web para que no pique

Las técnicas HPP - HTTP Parameter Pollution – salieron a la luz pública en la presentación que Stefano di Paola y Luca Carettoni dieron en la OWASP de 2009 y en la que añadieron un nuevo vector de ataque a las aplicaciones web. La idea de estas técnicas es tan sencilla como peligrosa.

Http Parameter Pollution, a new category of web attacks

View more presentations from Wisec.

El objetivo es inyectar nuevos parámetros o duplicar los parámetros existentes, para poder cambiar el comportamiento de una aplicación web. Esto puede ser utilizado para acceder a configuraciones ocultas de una aplicación o saltar filtros de control a la hora de generar exploits entre otras cosas. Esta presentación fue la que nos dio la idea de polucionar cosas, que acabó en las técnicas de Connection String Parameter Pollution.

La historia es que ha salido un proyecto para detectar vulnerabilidades HPP en aplicaciones web haciendo fuzzing a las URLs de una aplicación web y, solo por el nombre, merecía pasar por este blog, pero es que además en él trabaja Carmen Torrano, una joven investigadora del CSIC, especializada en seguridad informática y que hemos tenido el placer de tener en varios eventos, como el Asegúr@IT Camp 2, debatiendo de sus cosas.

El proyecto, del que me avisó cuando se puso online el gran Peter Lagoon, se llama PAPAS, y aunque tiene muy poco tiempo de vida, permite hacer el envío de una URL para que sea procesada según se describe en el paper del motor del sistema: Automated Discovery of Parameter Pollution Vulnerabilities inWeb Applications

Puedes enviar tu URL desde el siguiente formulario: PAPAS Online. De momento el sistema está pensado para que solo los webmasters puedan escanear sus paginas web, por lo que, una vez solicitado el escaneo de un sitio se debe crear un fichero PAPAS.TXT en la raíz del dominio con un token generado para cada sitio.

Desde aquí le deseo mucho éxito al proyecto, y espero que nuestra amiga Carmen cumpla su palabra y nos pase una serie de artículos detallando las técnicas HPP, tal y como me prometió tiempo ha };P

Saludos Malignos!