Falsificación de solicitud del lado del servidor (SSRF) en profundidad

Falsificación de solicitud del lado del servidor (SSRF):
SSRF significa falsificación de solicitud del lado del servidor. SSRF es un ataque al sitio del servidor que conduce a la divulgación de información confidencial del servidor back-end de la aplicación. En el sitio del servidor, los atacantes de falsificación de requests envían paquetes maliciosos a cualquier servidor web con acceso a Internet y este servidor web envía paquetes al servidor back-end que se ejecuta en la red interna en nombre del atacante. Esta vulnerabilidad se encuentra principalmente en la aplicación que tiene la capacidad de alimentar la URL para obtener datos de los respectivos servidores, también presente en la aplicación en la que dos o más servidores de diferentes hosts se comunican entre sí para compartir información.

Exploremos el concepto con la ayuda de un ejemplo:
 

En la figura anterior, puede observar que el atacante envía el paquete A elaborado al servidor disponible públicamente y, para cumplir con la consulta de los usuarios, el servidor público envía la solicitud al servidor back-end con el paquete B, ya que esta solicitud proviene del back-end del servidor público. el servidor confiaría en que el Paquete B proviene de la red interna y aceptaría el paquete y enviaría una respuesta. Esto es posible porque el atacante realiza la solicitud en nombre de otros servidores.

Tipos de SSRF:
1. SSRF ciego: 
en un SSRF ciego, los atacantes no pueden controlar los datos del paquete B que se envían a la aplicación en una red interna confiable. Aquí el atacante puede controlar la dirección IP y los puertos del servidor. Para explotar este tipo de SSRF tenemos que alimentar la URL seguida de los dos puntos y el número de puerto, al observar las respuestas y los mensajes de error del servidor podemos encontrar los puertos abiertos y cerrados del servidor. Hemos probado este procedimiento para los diferentes puertos para comprobar su estado.

Ejemplo :

http://example.com:1337
http://example.com:9923
http://example.com:43
http://example.com:22

2. Respuesta limitada/SSRF parcial:
en este tipo de SSRF, obtenemos una respuesta limitada del servidor, como el título de la página, u obtenemos acceso a los recursos, pero no podemos ver los datos. Podemos controlar solo ciertas partes del paquete B que llegan a la aplicación interna. Este tipo de vulnerabilidad se puede usar para leer archivos del sistema local como /etc/config, /etc/hosts, etc/passwd y muchos otros. Usando el protocolo file:// podemos leer archivos en el sistema. En algunos casos, la inyección XXE, DDos, estos tipos de vulnerabilidad pueden ser útiles para explotar la vulnerabilidad SSRF parcial.

Ejemplo :

file:///etc/hosts
file:///etc/config
file:///etc/passwd

3. SSRF de respuesta completa:
en SSRF completo tenemos control completo sobre el Paquete B (que se muestra en la figura). Ahora podemos acceder a los servicios que se ejecutan en la red interna y encontrar las vulnerabilidades en la red interna. En este tipo de SSRF podemos usar protocolos como file://, dict://, http://, gopher://, etc. Aquí tenemos un gran alcance para crear diferentes requests y explotar la red interna, si la hay. las vulnerabilidades están presentes. La vulnerabilidad completa de SSRF puede hacer que la aplicación se bloquee debido a un desbordamiento del búfer; al enviar una string grande en la solicitud, se produce el desbordamiento del búfer.

Ejemplo :

http://192.168.1.8/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

Bloqueos potenciales durante la prueba de vulnerabilidad SSRF:

  • Lista blanca: el servidor solo permite que se usen algunos nombres de dominio en la solicitud, el servidor tiene una lista blanca del dominio si el nombre de dominio de esa lista coincide con un nombre de dominio de la solicitud, entonces solo acepta la solicitud; de lo contrario, el servidor rechaza la solicitud .
  • Lista negra: el servidor descarta todas las requests que contienen direcciones IP, nombres de dominio y palabras clave de la lista negra del servidor.
  • Contenido restringido: – El servidor permite acceder solo a una cantidad particular de archivos para el usuario, solo permite algunos tipos de extensión de archivo para acceso público.

Puntos clave para probar la vulnerabilidad SSRF:

  1. Asegúrese siempre de realizar requests al servidor back-end en nombre del servidor público, no desde el navegador.
  2. Para obtener los datos del servidor, también intente http://localhost/xyz/ con http://127.0.0.1/xyz.
  3. El servidor puede tener protección de cortafuegos, siempre intente eludir el cortafuegos si es posible.
  4. Asegúrese de que la solicitud provenga del servidor, no de su host local.

Publicación traducida automáticamente

Artículo escrito por siddhantgore y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *