Omitir las protecciones SSRF

Hola,

Ha pasado un tiempo desde la última vez que publiqué. Quería compartir un bypass SSRF ordenado que encontré mientras buscaba en un programa privado.

SSRF significa falsificación de solicitud del lado del servidor. La falsificación de solicitudes del lado del servidor permite a un atacante abusar de las solicitudes HTTP para solicitar información sobre el servidor interno o la red interna.

¿Cosas a tener en cuenta? Parámetros como url= next= host= image= img= etc. Cualquier cosa que parezca estar haciendo una solicitud web a un servidor. Luego se puede abusar de esto para apuntar la solicitud internamente.

¿Cómo encontré el punto final vulnerable?

Mientras cazaba en un programa privado, estaba haciendo un reconocimiento extenso. Reuní una lista enorme de subdominios, principalmente extraídos de censys. Después de esto, hice fuerza bruta y busqué URL en todos los hosts en Wayback Machine. En ese momento, ssrf era mi enfoque, así que reuní mi directorio y la salida del punto final y busqué "proxy.php". Por suerte tuve un golpe.

Al estudiar la solicitud, esta estaba realizando una solicitud HTTP saliente a una URL específica. Si ingresé mi enlace de colaborador de eructo, no recibí una búsqueda. Probé los conceptos básicos habituales, ingresando 127.0.0.1 y las notaciones IP de los hosts internos, cada solicitud se bloqueó a menos que la solicitud tuviera el nombre de host del sitio web.

Aquí es donde las cosas se ponen técnicas. al enviar una solicitud de este tipo con mi colaborador de Burp, junto con el formato de las credenciales del navegador, por ejemplo, url=https: //hostnameofwebsite.com@myburpcollablink , recibí un golpe de vuelta.

Luego traté de explotar esto cambiándolo porque actualmente lo anterior estaba usando el navegador para enviar el nombre de host del sitio web como credenciales a myburpcollablink, lo cual no fue bueno.

Recientemente, acababa de ver un video ssrf en google cuando se explicaba que si usaba \ esto dejaría de analizar en el backend después del primer host. El front-end interpretaría la solicitud como nombre de host del sitio web como credenciales para myburpcollablink, pero el back-end procesaría solo la solicitud del front-end, por lo que el nombre de host del sitio web. Aquí lo cambié y usé url=http://169.254.1698.254\@hostnameofwebsite.

Vamos a explicar. 169.254 es la dirección IP interna de los metadatos de AWS. La solicitud de front-end ve esto como 169.254 como credenciales para el nombre de host del sitio web, que pasa la verificación de front-end ya que el nombre de host del sitio web debe estar en la solicitud. El backend ignora este formato y procesa comohttp://169.254.169.254\que luego corta y pasa solo la solicitud.

Cerrado como resuelto