SERVER-SIDE REQUEST FORGERY

La Falsificación de Peticiones del Lado del Servidor (SSRF) es una vulnerabilidad que tiene lugar cuando una
aplicación recupera recursos remotos sin validar la entrada del usuario. Un atacante puede suministrar su propia
entrada, en forma de URL, para controlar los recursos remotos que son recuperados por el servidor objetivo.
Cuando se tiene control sobre los recursos que solicita un servidor, se puede obtener acceso a datos confidenciales o,
lo que es peor, comprometer completamente un host vulnerable. SSRF es actualmente el número 10 en la lista
OWASP Top 10 de 2021 y es una amenaza creciente para las API.

SSRF IMPACT
El impacto de esta vulnerabilidad es que un atacante sería capaz de aprovechar el servidor de destino para realizar
y procesar las solicitudes que suministran. El atacante podría suministrar URLs que expongan datos privados,
escanear la red interna del objetivo o comprometer el objetivo a través de la ejecución remota de código. Tenga en
cuenta que los pagos por recompensas de errores para SSRF se basan en el impacto que puede demostrarse con una
prueba de concepto. En otras palabras, asegúrese de experimentar con sus hallazgos SSRF y ver lo que se puede
comprometer con ellos.

Para más información, consulta las directrices de las recompensas por errores de SSRF en Facebook
(https://m.facebook.com/whitehat/payout_guidelines/ssrf/):
 40.000 $ - SSRF en producción y lectura de la respuesta (debe incluir la alerta canaria en su informe)
 30.000 $ - SSRF ciego en producción y sin leer la respuesta (debe activar la alerta canaria)
 10.000 $ - Ataque a puntos finales arbitrarios dentro de una red corporativa (por ejemplo, a través de un CVE sin
parchear en un sistema de terceros).
 1.000 $ - Si sólo puede atacar un pequeño número de puntos finales dentro de la red corporativa (por ejemplo,
un pequeño conjunto de hosts o sólo loopback).

TYPES OF SSRF
Existen dos tipos de vulnerabilidades SSRF, In-Band SSRF y Blind SSRF.

 In Band SSRF, significa que el servidor responde con los recursos especificados por el usuario final. Si el
atacante especifica la carga útil como http://google.com a un servidor con una vulnerabilidad In-Band SSRF el
servidor haría la petición y respondería al atacante con información servida desde google.com.

 La Blind SSRF tiene lugar cuando el atacante proporciona una URL y el servidor realiza la solicitud pero no envía
información de la URL especificada de vuelta al atacante. En el caso de la SSRF ciega, necesitarás un servidor
web que capture la solicitud del objetivo para demostrar que has forzado al servidor a realizar la solicitud.
IN-BAND SSRF EXAMPLE
Para un SSRF In-Band, se especifica una URL como ataque. La solicitud se envía y el contenido de la URL
suministrada se muestra de vuelta en una respuesta.

Intercepted Request:
POST api/v1/store/products
headers…
{"inventory":"http://store.com/api/v3/inventory/item/12345"}

Attack:
POST api/v1/store/products
headers…
{"inventory":"§http://localhost/secrets§"}

Response:
HTTP/1.1 200 OK
headers...
{"secret_token":"crapi-admin"}

Una vez que haya descubierto una vulnerabilidad In-Band SSRF, podría aprovechar el control sobre la URL para
escanear el entorno de red interno, recopilar información confidencial del localhost o intentar realizar un ataque de
ejecución remota de código.

BLIND SSRF EXAMPLE

La Blind SSRF (o fuera de banda) tiene lugar cuando un servidor vulnerable realiza una petición a partir de la
entrada del usuario pero no envía una respuesta de vuelta al usuario indicando el éxito del ataque. La aplicación
no proporciona una respuesta inusual al usuario, pero el servidor sí realiza la petición a la URL especificada por el
atacante. En este caso, para saber si la petición se ha realizado necesitarás tener algún control sobre el servidor web
que se especifica en el ataque.

Intercepted Request:
POST api/v1/store/products
headers…
{"inventory":"http://store.com/api/v3/inventory/item/12345"}

Attack:
POST api/v1/store/products
headers…
{"inventory:"§http://localhost/secrets§"} 

Response:
HTTP/1.1 200 OK
headers...
{}

En este caso, se devuelve la respuesta y no tenemos ninguna indicación de que el servidor es vulnerable. En lugar de
http://localhost/secrets, necesitaremos proporcionar la URL a un servidor web que nos permita ver si realmente
se realiza una petición. Burp Suite Pro tiene una gran herramienta llamada Burp Suite Collaborator. Collaborator se
puede aprovechar para configurar un servidor web que nos proporcionará los detalles de cualquier solicitud que se
haga a nuestra URL aleatoria. Para ceñirnos a las herramientas gratuitas, utilizaremos http://webhook.site.
También puede utilizar uno de estos otros sitios gratuitos:
 http://pingb.in/
 https://requestbin.com/
 https://canarytokens.org/

Navegando a webhook.site se creará una URL aleatoria. A continuación, puede utilizar esa URL aleatoria como
payload y rastrearla para ver si se realiza alguna solicitud a la misma. Así, nuestro ataque SSRF ciego se vería más
como esto.

Attack:
POST api/v1/store/products
headers…
{"inventory":"§https://webhook.site/306b30f8-2c9e-4e5d-934d-48426d03f5c0§"}

Una vez que enviemos esta solicitud no dependeremos de la respuesta, en su lugar, comprobaremos webhook.site
para cualquier nueva solicitud.

Elegí demostrar SSRF usando webhook.site porque es gratis, no requiere una cuenta, y le permite crear respuestas
personalizadas. Puede utilizar el botón de edición (arriba a la derecha) para crear su propia respuesta
personalizada.
En el cuerpo de la respuesta, he emulado lo que podría ser un servidor web que podría formar parte de la
arquitectura crAPI. Esta URL puede ser aprovechada tanto para ataques In-Band como Blind SSRF.

INGREDIENTS FOR SSRF

A la hora de detectar vulnerabilidades SSRF en una API, deberá buscar solicitudes que presenten alguna de las
siguientes características:

 Incluir URLs completas en el cuerpo del POST o en los parámetros.

 Incluir rutas URL (o URL parciales) en el cuerpo o los parámetros POST.
 Cabeceras que incluyan URLs como Referer.
 Permitir la entrada de datos por parte del usuario que puedan dar lugar a que un servidor recupere recursos.

Busquemos objetivos potenciales en la colección crAPI. Al revisar la colección podemos ver tres peticiones
potenciales que involucran URLs.

 POST /community/api/v2/community/posts
 POST /workshop/api/shop/orders/return_order?order_id=4000
 POST workshop/api/merchant/contact_mechanic

Cada una de estas tres peticiones permite entradas de usuario que pueden ser procesadas y algunas incluyen
cabeceras Referer. La entrada del foro de la comunidad permite que cualquier usuario autorizado envíe un título y
una entrada al foro de la comunidad. Podría ser una exageración, pero tal vez haya algún filtro de contenido
involucrado que enviaría una solicitud a cualquier URL proporcionada. Las solicitudes return_order y
contact_mechanic implican URLs de alguna manera. La petición return_order no parece una opción obvia, sin
embargo, la respuesta incluye una URL. Probar esta petición incluirá intentar manipular la URL que se envía en la
respuesta. Por último, la solicitud contact_mechanic parece la más obvia, ya que la solicitud capturada contiene
una URL para la "Mechanic API".
TESTING FOR SSRF
1. Ya sea utilizando Postman o el navegador web, proxy de las solicitudes que usted está apuntando a Burp Suite. Y
envía la petición al Repeater.
2. En el caso de la solicitud return_order, podemos devolver un artículo una vez. Si intentamos devolver el artículo
dos veces, recibiremos la respuesta de que el artículo ya ha sido devuelto.

3. Para poder probar con éxito esta solicitud necesitaremos un order_id válido. Por lo tanto, necesitaremos
comprar varios artículos para poder realizar varias peticiones de devolución de un artículo. Utilice la solicitud
POST /workshop/api/shop/orders para comprar varios artículos. Si necesitas aumentar el saldo de tu cuenta,
vuelve a la hazaña de Asignación Masiva. Compra suficientes artículos para poder intentar varios ataques.
4. Para probar esto con éxito tendremos que cambiar el tipo de ataque a Pitchfork. Tenga en cuenta que Pitchfork
nos permite emparejar cargas útiles separadas. En el caso de esta petición, querremos emparejar un order_id
válido con un payload SSRF. Esto nos permitirá incrementar el item_id mientras enviamos simultáneamente
varios intentos de ataque.

5. Ponemos los Ids de los productos que hemos comprado:

6. Establezca el segundo payload en URLs potencialmente interesantes, incluyendo la URL de su webhook.site.
Para más ideas sobre payloads SSRF, consulta PayloadAllTheThings SSRF List.

7. Revisar los resultados. Busque anomalías y cualquier indicación dentro de la respuesta que indique que
pudimos controlar los recursos remotos procesados por el servidor. En este caso, no hay ninguna indicación en
la respuesta.
8. A continuación, asegúrese de comprobar el webhook.site y ver si un ataque SSRF ciego tuvo éxito. De nuevo, la
URL no fue solicitada y esta solicitud no parece ser vulnerable. Observa que las peticiones muestran 0/500 y el
mensaje "Esperando la primera petición...".

9. Probemos esto con la petición contact_mechanic. Establece la posición de ataque, copia y pega las cargas
útiles que utilizaste anteriormente para las URL y envía el ataque. Revisa los resultados y mira si hay algo
interesante.
10. Efectivamente, las peticiones localhost fallan, pero las otras URLs proporcionadas tienen éxito. En cuanto a la
revisión de anomalías, podemos ver que hay una variedad de códigos de estado y longitudes de respuesta. Al
revisar las respuestas de las solicitudes exitosas, podemos ver que los recursos remotos que solicitamos fueron
enviados de vuelta a través de la solicitud de API.

11. También podemos verificar que se ha realizado una petición desde el servidor visitando nuestra página
webhook.site.
Enhorabuena, has explotado con éxito una vulnerabilidad SSRF. Si volvemos a la directriz de recompensas por SSRF
de Facebook, se trataría de un caso en el que el SSRF está en producción, la respuesta se nos devuelve y tenemos
pruebas de que se ha realizado la solicitud al servidor web. En otras palabras, ¡máxima recompensa!
 PRÁCTICAS
- Accedemos a Postman y encontramos que la API Arena/Server Surfer contiene una URL incrustada en la propia
URL, lo que nos hace pensar que puede ser vulnerable a SSRF.

- Enviamos la petición y la capturamos con Burp Suite, para intentar vulnerarla con la herramienta Intruder.

Cambiando la URL incrustada por un web server que usemos para recibir la petición. Como pueden ser
http://pingb.in/ y https://webhook.site.
- Lanzamos la carga y observamos las respuestas:

- Observamos que nos manda una cantidad inconmensurable de datos, así que preveemos que están
encriptados. Probamos Base64, para ver si están bajo esta encriptación, siendo satisfactoria la prueba.
Decodificamos los datos obteniendo un código html, con el título de la página Tushar Kulkarni, y que contiene un
código html con la página web.

- Renderizamos el código HTML: