Hola hacketones! Bienvenidos a un nuevo CTF de la ruta completa de Web Fundamentals, en este capítulo veremos: TryHackMe Intro to SSRF
¿Qué es una SSRF?
Resumen de la habitación
En esta sala, aprenderá qué es una SSRF , qué tipo de impacto puede tener, verá algunos ejemplos de ataques SSRF , cómo puede descubrir vulnerabilidades de SSRF , cómo eludir las reglas de entrada y luego tendremos una práctica para que pruebe sus nuevas habilidades.
¿Qué es una SSRF ?
SSRF significa falsificación de solicitud del lado del servidor. Se trata de una vulnerabilidad que permite a un usuario malintencionado provocar que el servidor web realice una solicitud HTTP adicional o modificada al recurso elegido por el atacante.
Tipos de SSRF
Existen dos tipos de vulnerabilidad SSRF : la primera es una SSRF normal , en la que se devuelven datos a la pantalla del atacante. La segunda es una vulnerabilidad SSRF ciega, en la que se produce una SSRF , pero no se devuelve información a la pantalla del atacante.
¿Cuál es el impacto?
Un ataque SSRF exitoso puede resultar en cualquiera de los siguientes:
- Acceso a zonas no autorizadas.
- Acceso a datos de clientes/organizaciones.
- Capacidad de escalar a redes internas.
- Revelar tokens/credenciales de autenticación.
Answer the questions below
What does SSRF stand for?
Server-Side Request Forgery
As opposed to a regular SSRF, what is the other type?
Blind
Ejemplos de SSRF
Haga clic en el botón Ver sitio , que lo guiará a través de algunos ejemplos comunes de SSRF , cómo explotarlos e incluso una simulación para ver si puede aprovechar una vulnerabilidad de SSRF utilizando lo que ha aprendido.
Te mostraremos algunos ejemplos de ataques SSRF y cómo funcionan. Al final de los ejemplos, ¡tendrás que descubrir uno por ti mismo!
El siguiente ejemplo muestra cómo el atacante puede tener control total sobre la página solicitada por el servidor web.
La Solicitud Esperada es lo que el servidor website.thm espera recibir; la sección en rojo representa la URL que el sitio web obtendrá para obtener la información.
El atacante puede modificar el área en rojo con la URL que desee.
El siguiente ejemplo muestra cómo un atacante puede acceder a la página /api/user controlando únicamente la ruta mediante un salto de directorio. Cuando website.thm recibe ../, este es un mensaje para subir de directorio, lo que elimina la parte /stock de la solicitud y la convierte en /api/user.
En este ejemplo, el atacante puede controlar el subdominio del servidor al que se realiza la solicitud. Tenga en cuenta que la carga útil que termina en &x= se utiliza para evitar que la ruta restante se añada al final de la URL del atacante y, en su lugar, la convierte en un parámetro (?x=) en la cadena de consulta.
Volviendo a la solicitud original, el atacante puede forzar al servidor web a solicitar un servidor de su elección. De esta forma, podemos capturar los encabezados de solicitud que se envían al dominio especificado por el atacante. Estos encabezados podrían contener credenciales de autenticación o claves API enviadas por website.thm (que normalmente se autenticarían en api.website.thm).
Con lo aprendido, intente cambiar la dirección en el navegador a continuación para forzar al servidor web a devolver datos desde https://server.website.thm/flag?id=9. Para facilitar las cosas, la barra de solicitudes de servidor en la parte inferior del navegador simulado mostrará la URL que website.thm está solicitando.
Si miras la barra gris de abajo que dice «Server Requesting», puedes ver exactamente qué está intentando hacer el servidor por detrás. Es como si tuvieras visión de rayos X sobre el código del backend:
Para ganar, necesitas que el servidor ignore todo lo que él mismo añade al final. En la estructura de una URL, hay caracteres especiales que sirven para «cortar» o separar partes.
Tienes dos herramientas principales para este bypass:
- El Ampersand (&): Si lo pones al final de tu input, conviertes todo lo que el servidor añade después en un «parámetro adicional» que probablemente sea ignorado.
- Resultado esperado: …/flag?id=9&.website.thm… (El servidor ve el parámetro id=9 y luego una basura que no le importa).
- El Hash / Almohadilla (#): En una URL, lo que va después del # es un fragmento que el servidor suele ignorar por completo al realizar la petición interna.
- Resultado esperado: …/flag?id=9#.website.thm…
Intenta modificar la URL en la barra de direcciones del «navegador simulado» añadiendo uno de esos caracteres al final de tu consulta.
¿Qué pasa con la barra de «Server Requesting» cuando añades un & o un # al final de tu input?
Responda las preguntas a continuación
¿Cuál es la bandera del sitio de ejemplos de SSRF?
THM{SSRF_MASTER}
Encontrar una SSRF
Las posibles vulnerabilidades de SSRF se pueden detectar en aplicaciones web de diversas maneras. A continuación, se muestra un ejemplo de cuatro lugares comunes donde buscar:
Cuando se utiliza una URL completa en un parámetro en la barra de direcciones:
Un campo oculto en un formulario:
Una URL parcial, como solo el nombre de host:
O quizás sólo la ruta de la URL:
Algunos de estos ejemplos son más fáciles de explotar que otros, y aquí es donde será necesario mucho ensayo y error para encontrar una carga útil que funcione.
Si trabaja con una SSRF ciega donde no se le refleja ningún resultado, necesitará utilizar una herramienta de registro HTTP externa para monitorear las solicitudes, como requestbin.com, su propio servidor HTTP o el cliente Collaborator de Burp Suite .
Answer the questions below
Basándonos en una simple observación, ¿cuál de las siguientes URL tiene más probabilidades de ser vulnerable a SSRF?
- https://website.thm/index.php
- https://website.thm/list-products.php?categoryId=5325
- https://website.thm/fetch-file.php?fname=242533.pdf&srv=filestorage.cloud.thm&port=8001
- https://website.thm/buy-item.php?itemId=213&price=100&q=2
3
Derrotando las defensas comunes de la SSRF
Los desarrolladores con mayor conocimiento de seguridad, conscientes de los riesgos de las vulnerabilidades de SSRF , pueden implementar comprobaciones en sus aplicaciones para garantizar que el recurso solicitado cumpla con reglas específicas. Normalmente existen dos enfoques: una lista de denegación o una lista de permisos.
Lista de denegados
Una lista de denegación es donde se aceptan todas las solicitudes, excepto los recursos especificados en una lista o que coinciden con un patrón particular. Una aplicación web puede emplear una lista de denegación para proteger endpoints, direcciones IP o dominios sensibles del acceso público, permitiendo al mismo tiempo el acceso a otras ubicaciones. Un endpoint específico para restringir el acceso es el host local, que puede contener datos de rendimiento del servidor u otra información sensible, por lo que nombres de dominio como localhost y 127.0.0.1 aparecerían en una lista de denegación. Los atacantes pueden eludir una lista de denegación utilizando referencias alternativas a localhost como 0, 0.0.0.0, 0000, 127.1, 127.*.*.*, 2130706433, 017700000001 o subdominios que tengan un registro DNS que resuelva a la dirección IP 127.0.0.1, como 127.0.0.1.nip.io.
Además, en un entorno de nube, sería beneficioso bloquear el acceso a la dirección IP 169.254.169.254, que contiene metadatos del servidor en la nube implementado, incluyendo posiblemente información confidencial. Un atacante puede evitar esto registrando un subdominio en su propio dominio con un registro DNS que apunte a la dirección IP 169.254.169.254.
Lista de permitidos
Una lista de permitidos es donde se rechazan todas las solicitudes a menos que aparezcan en ella o coincidan con un patrón específico, como una regla que exige que la URL utilizada en un parámetro comience por https ://website.thm . Un atacante podría eludir rápidamente esta regla creando un subdominio en el nombre de dominio del atacante, como https://website.thm.attackers-domain.thm . La lógica de la aplicación permitiría esta entrada y permitiría al atacante controlar la solicitud HTTP interna.
Abrir redirección
Si las soluciones anteriores no funcionan, el atacante tiene un as bajo la manga: la redirección abierta. Una redirección abierta es un punto final en el servidor donde el visitante del sitio web es redirigido automáticamente a la dirección de otro sitio web. Tomemos, por ejemplo, el enlace https://website.thm /link?url=https://tryhackme.com . Este punto final se creó para registrar el número de veces que los visitantes hacen clic en este enlace con fines publicitarios. Pero imaginemos una posible vulnerabilidad SSRF con reglas estrictas que solo permiten URL que empiezan por https://website.thm / . Un atacante podría utilizar esta función para redirigir la solicitud HTTP interna a un dominio de su elección.
Responda las preguntas a continuación
¿Qué método se puede utilizar para eludir reglas estrictas?
Open Redirect
¿Qué dirección IP puede contener datos confidenciales en un entorno de nube?
169.254.169.254
¿Qué tipo de lista se utiliza para permitir sólo determinadas entradas?
Allow List
¿Qué tipo de lista se utiliza para detener determinada entrada?
Deny List
Práctica de la SSRF
Durante un ejercicio de descubrimiento de contenido en el sitio web de soporte técnico de Acme , encontramos dos nuevos endpoints . El primero es /private , que genera un mensaje de error que indica que el contenido no se puede ver desde nuestra dirección IP. El segundo es una nueva versión de la página de la cuenta del cliente en /customers/new-account-page, con una nueva función que permite a los clientes elegir un avatar para su cuenta. Para empezar, haga clic en el botón Iniciar máquina para abrir el sitio web de soporte técnico de Acme . Una vez abierto, visítelo en la URL https://LAB_WEB_URL.p.thmlabs.com y siga las instrucciones a continuación para obtener la bandera. Primero, cree una cuenta de cliente e inicie sesión. Una vez iniciada la sesión, visite https://LAB_WEB_URL.p.thmlabs.com/customers/new-account-page para ver la nueva función de selección de avatar. Al ver el código fuente del formulario de avatar, verá que el valor del campo del formulario de avatar contiene la ruta a la imagen. El estilo background-image puede confirmar esto en el elemento DIV anterior, como se muestra en la siguiente captura de pantalla:
Si elige uno de los avatares y luego hace clic en el botón Actualizar avatar , verá que el formulario cambia y, encima, se mostrará su avatar seleccionado actualmente.
Al ver el código fuente de la página, se mostrará que su avatar actual se muestra utilizando el esquema de URI de datos y el contenido de la imagen está codificado en base64 según la captura de pantalla a continuación.
Ahora intentemos realizar la solicitud de nuevo, pero cambiando el valor del avatar a privado con la esperanza de que el servidor acceda al recurso y supere el bloqueo de la dirección IP. Para ello, primero, haga clic derecho en uno de los botones de opción del formulario del avatar y seleccione Inspeccionar .
Y luego edita el valor del botón de opción a privado:
Asegúrate de seleccionar el avatar que editaste y haz clic en el botón «Actualizar avatar» . Lamentablemente, parece que la aplicación web tiene una lista de denegación activada y ha bloqueado el acceso al endpoint /private.
Como puede ver en el mensaje de error, la ruta no puede empezar con /private, pero no se preocupe, aún tenemos un truco bajo la manga para evitar esta regla. Podemos usar un truco de navegación de directorio para llegar al punto final deseado. Intente configurar el valor de avatar en x/../private.
Verás que hemos omitido la regla y el usuario ha actualizado el avatar. Este truco funciona porque, cuando el servidor web recibe la solicitud para x/../private , sabe que la cadena ../ significa subir de directorio, lo que traduce la solicitud simplemente a /private .
Responda las preguntas a continuación
¿Cuál es la bandera del directorio /private?
THM{YOU_WORKED_OUT_THE_SSRF}
Sigan entrenando, Hacketones, Nos vemos en el próximo laboratorio!!!