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
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
9 comentarios:
Muy buena la web del ISECLAB:
http://bit.ly/ebjIYc
http://exposure.iseclab.org/cgi-bin/search.py?domain_name=uvqfbm.info&domain_name=uvqfbm.info
Muy bien explicado! no había leído info tan buena sobre esto...
Saludos!
Felicidades por el articulo! muy bueno.
Estos son articulos de calidad no los que escribe el Chema :P
Saludos!
No sé si lo he entido bien.
No veo esto "tan" novedoso, al final es un ataque de XSS o CRSF (según lo que puedeas hacer).
¿Es así?
Muy buen post!!!, como siempre, claro...
Gracias por el trabajo.
En la forma en la que se ha usado en este post a mi entender no deja de ser un XSS, quizás pueda ser útil para cuando se filtran determinados caracteres que impiden meter javascript o para saltarse este filtro.
El HPP lo veo mas interesante para saltarse WAF como se mostro en sbd:
http://www.securitybydefault.com/2009/06/bypasseando-modsecurity-mediante-hpp.html
Amigo del otro lado del mal!!!! Seguimos tu lucha pro Microsoft y contra linux, siendo un aliado mas, te nombramos aliado honorifico por decision unanime de Casimiro, Guillermo y Vicente y abstencion de Klondike
http://casimiro-vista.blogspot.com/2011/03/nuevo-aliado-en-la-lucha-contra-linux.html
Publicar un comentario