Web Cache Poisoning(Envenenamiento de caché); Explicación y PoC

¿Qué es la Envenenamiento de caché web?

El envenenamiento de caché web es una técnica avanzada mediante la cual un atacante explota el comportamiento de un servidor web y su caché para que una respuesta HTTP dañina sea entregada a otros usuarios.

Fundamentalmente, el envenenamiento de caché web involucra dos fases. Primero, el atacante debe averiguar cómo obtener una respuesta del servidor de backend que contenga, sin querer, algún tipo de carga útil peligrosa. Una vez lo tenda, se debe de asegurarse de su respuesta quede almacenada en caché y se sirva a las víctimas previstas.

Una caché web envenenada puede ser, potencialmente, un medio devastador para distribuir numerosos ataques diferentes, explotando vulnerabilidades como XSS, inyección de JavaScript, redirección abierta, entre otras.

¿Cómo funciona una caché web?

Para entender cómo surgen las vulnerabilidades de envenenamiento de caché web, es importante tener una comprensión básica de cómo funcionan las cachés web.

Si un servidor tuviera que enviar una nueva respuesta a cada solicitud HTTP por separado, probablemente sobrecargaría el servidor, lo que resultaría en problemas de latencia y una mala experiencia para el usuario, especialmente durante los períodos de alta demanda. La caché es principalmente una forma de reducir tales problemas.

La caché se encuentra entre el servidor y el usuario, donde guarda (cacha) las respuestas a solicitudes particulares, generalmente por un período de tiempo fijo. Si otro usuario envía una solicitud equivalente, la caché simplemente sirve una copia de la respuesta almacenada directamente al usuario, sin ninguna interacción con el servidor de backend. Esto alivia enormemente la carga del servidor al reducir el número de solicitudes duplicadas que tiene que manejar.

¿Cuál es el impacto de un ataque de envenenamiento con caché web?

El impacto del envenenamiento de caché web depende en gran medida de dos factores clave:

1. Qué exactamente puede ser exitosamente almacenado en caché por el atacante
   Dado que la caché envenenada es más un medio de distribución que un ataque independiente, el impacto del envenenamiento de caché web está intrínsecamente vinculado a cuán dañina es la carga útil inyectada. Al igual que con la mayoría de los tipos de ataque, el envenenamiento de caché web también puede combinarse con otros ataques para aumentar aún más el impacto potencial.
2. La cantidad de tráfico en la página afectada
   La respuesta envenenada solo será servida a los usuarios que visiten la página afectada mientras la caché esté envenenada. Como resultado, el impacto puede variar desde inexistente hasta masivo, dependiendo de si la página es popular o no. Por ejemplo, si un atacante logra envenenar una respuesta almacenada en caché en la página de inicio de un sitio web importante, el ataque podría afectar a miles de usuarios sin necesidad de interacción posterior por parte del atacante.

Cache keys ¿Que son?

Cuando la caché recibe una solicitud HTTP, primero tiene que determinar si existe una respuesta almacenada que pueda servir directamente, o si debe reenviar la solicitud para que sea manejada por el servidor de backend. Las cachés identifican solicitudes equivalentes comparando un subconjunto predefinido de los componentes de la solicitud, conocido colectivamente como la «clave de caché». Típicamente, esta clave incluiría la línea de solicitud y el encabezado Host. Los componentes de la solicitud que no se incluyen en la clave de caché se consideran «no indexados».

Para empezar el laboratorio cogeremos la primera petición de home y la vamos a enviar al repeater para empezar a trastear:

Si enviamos una primera peticion tenemos una cache key que nos indica que no esta almacenado en cache al ser la primera peticion(miss). E indica que la edad del cache es 0(Age: 0) y que la edad maxima del cache es de 35 segundos (Cache-Control:35), es decir que cada 35 segundos se reinicia la cache.

Pero si la reenviamos varias veces obtenemos un cache key hit, es decir que esta almacenado, además vemos que a pasado un segundo desde que hemos enviado la petición y recargado la cache

Si la clave de caché de una solicitud entrante coincide con la clave de una solicitud anterior, entonces la caché las considera equivalentes. Como resultado, servirá una copia de la respuesta almacenada que fue generada para la solicitud original. Esto se aplica a todas las solicitudes posteriores con la clave de caché coincidente, hasta que la respuesta almacenada expire.

Identificar y evaluar las entradas no indexadas

Cualquier ataque de envenenamiento de caché web se basa en la manipulación de entradas no indexadas, como los encabezados. Las cachés web ignoran las entradas no indexadas al decidir si sirven o no una respuesta almacenada en caché al usuario. Este comportamiento significa que puedes usarlas para inyectar tu carga útil y generar una respuesta «envenenada» que, si se almacena en caché, será servida a todos los usuarios cuyas solicitudes tengan la clave de caché coincidente. Por lo tanto, el primer paso para construir un ataque de envenenamiento de caché web es identificar las entradas no indexadas que son soportadas por el servidor.

Puedes identificar entradas no indexadas de forma manual agregando entradas aleatorias a las solicitudes y observando si tienen o no un efecto en la respuesta. Esto puede ser obvio, como reflejar la entrada directamente en la respuesta o activar una respuesta completamente diferente. Sin embargo, a veces los efectos son más sutiles y requieren algo de trabajo de detective para descubrirlos. Puedes utilizar herramientas como Burp Comparer para comparar la respuesta con y sin la entrada inyectada, pero esto aún implica una cantidad significativa de esfuerzo manual.

En la siguiente imagen vemos como la primera peticion, esta almacenando la cache mediante la clave cache hit, mientras que en la segunda petición nos indica que no esta almacenado en cache mediante la clave cache miss.

Al añador un parametro nuevo valido nos identifica que no esta almacenado con la clave cache miss, pero si reflejado.

Param Miner

Afortunadamente, se ouede automatizar el proceso de identificación de entradas no indexadas agregando la extensión Param Miner. Para usar Param Miner, simplemente haces clic derecho sobre una solicitud que quieras investigar y seleccionas «Guess headers» como se indica en la siguiente imagen. Param Miner luego se ejecuta en segundo plano, enviando solicitudes que contienen diferentes entradas de su extensa lista integrada de encabezados. Si una solicitud que contiene una de sus entradas inyectadas tiene un efecto sobre la respuesta, Param Miner registra esto en Burp, ya sea en el panel de «Issues» si estás usando Burp Suite Professional, o en la pestaña de «Output» de la extensión («Extensions» > «Installed» > «Param Miner» > «Output») si estás usando Burp Suite Community Edition.

Por ejemplo, en la siguiente captura de pantalla, Param Miner encontró un encabezado no indexado X-Forwarded-Host en la página de inicio del sitio web:

En este caso al ser en burpusite commiunity tras hacer el escaneo, tendremos que ir a verlo a un apartado distinto que si fuese en Burpsuite Professional. Vemos que el encabezado no indexado es X-Forwarded-host asegurándonos de que en esta prueba no afecte a todos los usuarios.

Provocar una respuesta dañina desde el servidor de backend

Una vez que has identificado una entrada no indexada, el siguiente paso es evaluar cómo exactamente el sitio web procesa esa entrada. Comprender este proceso es esencial para poder provocar una respuesta dañina con éxito. Si una entrada se refleja en la respuesta del servidor sin ser adecuadamente sanitizada, o se utiliza para generar dinámicamente otros datos, entonces esta es una posible vía de entrada para el envenenamiento de caché web.

Tendremos que añadir nuestra url en el encabezado detectado por Param Spider donde tengamos el exploit y ver que se puede reflejar en la respuesta sin problema, en este caso se usa como parte de un archivo javascript.

Utilizaremos la ruta entera indicando que se refleja, y añadiremos en el cuerpo un «alert(document.cookie);»

Hacer que la respuesta se almacene en caché

Manipular los inputs para obtener una respuesta dañina es solo un parte, pero no sirve de nada a no ser que consigamos que la respuesta se almacene en cache

Si una respuesta se almacena o no en caché puede depender de diversos factores, como la extensión del archivo, el tipo de contenido, la ruta, el código de estado y los encabezados de respuesta. Probablemente necesitarás dedicar algo de tiempo simplemente experimentando con las solicitudes en diferentes páginas y observando cómo se comporta la caché. Una vez que logres hacer que se almacene en caché una respuesta que contenga tu entrada maliciosa, estarás listo para entregar el ataque a las víctimas potenciales.

Una vez realizada reenviamos(tantas veces sea necesaria) la petición asegurándonos de recibir una clave cache «hit», lo que significara que la respuesta a sido almacenada en cache.

Por lo que si entramos a la url completa de la web junto al parámetro, vemos que la respuesta quedo almacenada, por lo que lo único que tendríamos que modificar seria eliminar nuestro parámetro y almacenar nuestro exploit en la raíz.

En la primera petición enviada no queda almacenada, recibiendo una clave cache miss, pero si volvemos a enviar la petición quede almacenada y reflejada.

Recibimos una clave cache hit sabiendo que la cache queda almacenada. Por lo que en este momento sabemos que nuestro exploit a quedado almacenado y reflejado en la raíz de la url.

Si visitamos la url original vemos que quedo realmente almacenada.

Cómo prevenir vulnerabilidades de envenenamiento con caché web

La forma definitiva de prevenir el envenenamiento de caché web sería deshabilitar completamente la caché. Aunque para muchos sitios web esto no sea una opción realista, en otros casos podría ser factible. Por ejemplo, si solo usas caché porque se activó por defecto al adoptar un CDN, podría ser útil evaluar si las opciones de caché por defecto realmente se ajustan a tus necesidades.

Incluso si necesitas usar caché, limitarla a respuestas puramente estáticas también es efectivo, siempre que tengas cuidado con lo que consideras «estático». Asegúrate de que un atacante no pueda engañar al servidor de backend para que recupere su versión maliciosa de un recurso estático en lugar de la versión genuina.

Esto también se relaciona con un punto más amplio sobre la seguridad web. La mayoría de los sitios web ahora incorporan una variedad de tecnologías de terceros tanto en sus procesos de desarrollo como en sus operaciones diarias. No importa cuán robusta sea tu postura interna de seguridad, en el momento en que incorporas tecnología de terceros a tu entorno, dependes de que sus desarrolladores también sean tan conscientes de la seguridad como tú. Dado que solo eres tan seguro como tu punto más débil, es vital asegurarte de entender completamente las implicaciones de seguridad de cualquier tecnología de terceros antes de integrarla.

Específicamente en el contexto del envenenamiento de caché web, esto no solo significa decidir si dejar la caché activada por defecto, sino también observar qué encabezados son soportados por tu CDN, por ejemplo. Varias de las vulnerabilidades de envenenamiento de caché web discutidas anteriormente se exponen porque un atacante puede manipular una serie de encabezados de solicitud oscuros, muchos de los cuales son completamente innecesarios para la funcionalidad del sitio web. Nuevamente, podrías estar exponiéndote a estos tipos de ataques sin darte cuenta, simplemente porque has implementado alguna tecnología que soporta estos insumos no indexados por defecto. Si un encabezado no es necesario para que el sitio funcione, debería deshabilitarse.

También debes tomar las siguientes precauciones al implementar caché:

• Si estás considerando excluir algo de la clave de caché por razones de rendimiento, reescribe la solicitud en su lugar.
• No aceptes solicitudes GET grandes. Ten en cuenta que algunas tecnologías de terceros pueden permitir esto por defecto.
• Parchea las vulnerabilidades del lado del cliente, incluso si parecen no ser explotables. Algunas de estas vulnerabilidades podrían ser explotables debido a peculiaridades impredecibles en el comportamiento de tu caché. Podría ser cuestión de tiempo antes de que alguien encuentre una peculiaridad, ya sea basada en caché o de otro tipo, que haga que esta vulnerabilidad sea explotable.