Existe una cosa llamada SSRF. Mucho se ha escrito sobre ella, pero aún así, te lo contaré brevemente.
Supongamos que va al sitio, completa el perfil y accede al elemento "cargar avatar". Y tiene una opción: cargar un archivo o especificar un enlace.
En este caso, estamos interesados en el segundo punto. Si proporcionamos un enlace a un recurso que contiene una imagen, la aplicación web:
- Lo descarga
- Comprueba que la imagen es la imagen
- Verifique los tamaños, porque pueden no encajar
- Se lo muestra al usuario (para cortar)
Entonces aquí. Si el sitio no comprueba desde dónde está intentando descargar la imagen, esto es una vulnerabilidad (como regla). Además, los vectores de ataques a una función tan pequeña como la descarga de imágenes son tan extensos que no hay suficiente reunión en la barra para ver todas las opciones.
Una vez me preguntaron: "¿Qué puedo hacer si puedo poner solo un enlace http (s)? ¡No da nada! "
Te digo
La opción más fácil es tratar de identificar los servicios dentro. Si hablamos de la imagen, puede intentar mirar las rutas estándar como favicon.ico, logos o el directorio de iconos, lo que sugiere que se utiliza Apache. Al enviar solicitudes, podemos iterar sobre direcciones locales populares, así como subdominios del sitio que funcionan en la infraestructura interna. Estos son todo tipo de bambú, jira, gitlab y otras cosas queridas por todas las empresas.
¿Para qué es necesario? Pero porque el conocimiento es poder. Después de todo, incluso a ciegas, puede usar varias vulnerabilidades y exploits. Al conocer el proveedor o la versión del servidor web o servicio utilizado, reduce el rango de ataques que puede aplicar. Tal vez ni siquiera ahora, pero en el futuro, conocer la información técnica sobre la infraestructura interna lo ayudará a explotar otras vulnerabilidades.
Bueno, se nos prohibió ingresar direcciones IP. Supongamos que tenemos un recurso importante dentro de la infraestructura y su dirección IP es 192.168.1.1
En primer lugar, iniciamos mentalmente un dominio al que asignaremos esta IP. Deja que sea my-test-site.com. En la vida real, debe crear subdominios cuya dirección se dirigirá a la IP que necesitamos, pero más sobre eso más adelante.
Contraseña fuerza bruta
Soñemos que tenemos un enrutador adentro. El directorio / admin / está en autenticación básica. Al cambiar el enlace, podemos seleccionar inicios de sesión y contraseñas para el enrutador. Pero aquí es bastante simple, solo formamos un enlace del formulario
http://login:password@my-test-site.com/admin/Por lo tanto, el valor antes de los dos puntos será el inicio de sesión, después de eso, la contraseña. Y a través del signo @ habrá un dominio donde se enviarán estos datos. Tenga en cuenta que no funciona con todo tipo de personas de contacto donde necesita completar un formulario. Por lo tanto, se necesita autenticación básica: una ventana emergente con una respuesta 401 del servidor.
Si tuvimos suerte y el sitio devolvería al menos el código de respuesta (200, 401, 503), sería mucho más fácil. Entonces podemos observar claramente el proceso y ver nuestra victoria:
http://admin:password@my-test-site.com/admin/ - 401
http://admin:admin@my-test-site.com/admin/ - 401
http://admin:123456@my-test-site.com/admin/ - 200Al enviar una docena o dos de tales solicitudes, puede intentar encontrar la contraseña para este enrutador. Y luego recurra al script para guardar su propio DNS o incluso /reboot.cgi
¿Y si no hay respuesta y siempre es la misma?
Aquí los horarios nos ayudarán.
Tiempos
Todo lleva tiempo. Como me tomo su tiempo para leer un artículo, los servicios se toman su tiempo para responder.
La peculiaridad es que podemos intentar acceder a los recursos internos y medir los tiempos para responder a la pregunta: ¿hay un servicio allí o no?
Después de haber enviado muchas solicitudes, puede clasificar a ciegas los servicios internos, los puertos e incluso los directorios y archivos, basándose en una anomalía de respuestas.
1302 ms - http://test.company.com
1307 ms - http://db.company.com
5483 ms - http://jira.company.com
1410 ms - http://docs.company.com
1366 ms - http://kafka.company.comEl subdominio jira respondió más tiempo, lo más probable es que esté dentro, y la diferencia es notable debido al hecho de que el servidor web intentó cargar la página, y luego se dio cuenta de que esto no era una imagen. Y lo que nos importa no es el hecho de "¿Quién respondió más tiempo?", Sino precisamente "¿Quién respondió no como todos los demás?" Porque el tiempo puede ser como un retraso, por ejemplo, si encuentra un archivo o secuencia de comandos de gran tamaño que tarda mucho tiempo en ejecutarse. O viceversa, una respuesta rápida.
1302 ms - http://test.company.com
1307 ms - http://db.company.com
423 ms - http://jira.company.com
1410 ms - http://docs.company.com
1366 ms - http://kafka.company.comEn este caso, la respuesta dice que es 401 o una redirección que no procesa el analizador de imágenes. O tal vez el sitio sea accesible, pero después de verificar los primeros bytes o tipo de contenido, nuestra aplicación web lo rechazó antes de descargar la página por completo. Otros sitios en este ejemplo no esperaron una conexión (o el nombre de host no se mostró sobrio)
Mecanismos de verificación de IP
Muchos sitios han ingresado una verificación de que la dirección IP no es interna. Pero la lógica puede ser incorrecta y, a veces, aún puede hacer que la aplicación se conecte a la dirección IP interna. Por ejemplo, un sitio verifica en dos bloques lógicos. Primero, verifica si el host que apunta a la IP externa me fue proporcionado con precisión. Si después de pasar con éxito la primera verificación, el sitio establece una conexión, mientras no almacena en caché la dirección IP del párrafo anterior, puede hacer un truco divertido.
A la primera solicitud del dominio my-test-site.com, proporcione una IP externa, por ejemplo 123.123.123.123
Y tan pronto como pase la validación, comience a enviar IP interna al mismo dominio.
En este caso,
Emil Lerner hizo un servicio genial: ¡1u.ms!
El dominio 1u.ms responde con las direcciones IP que especificó.
El formato del dominio debe ser el siguiente:
make-%IP%-rebind-%IP-rr.1u.msPor ejemplo
make-123.123.123.123-rebind-127.0.0.1-rr.1u.msla primera solicitud será respondida con la dirección 123.123.123.123, y la segunda solicitud ya será respondida en 127.0.0.1 (si son una tras otra, en 5 segundos).
Por cierto, la dirección IP se puede escribir sin puntos, en caso de que necesite un subdominio:
make-123-123-123-123-rebind-127-0-0-1-rr.1u.msPor cierto, antes de hacer y después de rr, puede escribir palabras arbitrarias para evitar el uso de datos en caché:
bo0om-make-123-123-123-123-rebind-127-0-0.1-rr-test.1u.msY para ver el registro, el análogo de tail -f:
curl http://1u.ms:8080/log(o el mismo enlace en el navegador)
Escaneo de puertos usando DNS
De hecho, al administrar registros DNS, puede intentar escanear puertos. Un pequeño truco nos ayudará con esto.
Supongamos que tenemos un dominio my-test-site.com.
Por lo general, contiene al menos un registro A para que se abra el recurso.
Digamos que la IP de nuestro sitio es 172.217.20.46 (tomada de google.com). ¡Pero podemos especificar varias entradas de este tipo! Imagine que los creamos y nuestros registros DNS se ven así:
my-test-site.com 172.217.20.46
my-test-site.com 192.168.1.1¿Se abrirá nuestro recurso? Sí lo hará Y todo porque el primer disco va primero.
Ahora cambie los registros DNS de esta manera:
my-test-site.com 192.168.1.1
my-test-site.com 172.217.20.46¿Se abrirá nuestro recurso? Volveremos :)
Y todo porque el recurso primero intentará arrancar desde la primera IP especificada, y si hay algún problema con él, irá a la segunda.
curl "my-test-site.com" -v
* Trying 192.168.1.1...
* TCP_NODELAY set
* Immediate connect fail for 192.168.1.1: Host is down
* Trying 172.217.20.46...
* TCP_NODELAY set
* Connected to my-test-site.com (172.217.20.46) port 80 (#0)
> GET / HTTP/1.1
> Host: my-test-site.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=UTF-8
< Referrer-Policy: no-referrer
< Content-Length: 1561
< Date: Tue, 21 Jan 2020 16:35:08 GMTCon esta función, puede averiguar qué puertos están abiertos y cuáles no. De hecho, muchas (pero no todas) las bibliotecas intentarán llegar primero al primer recurso, que se enumera primero en los registros DNS, y luego al segundo.
Aquí hemos indicado el enlace a nuestro recurso para cargar el avatar.
Al especificar nuestro dominio y cambiar el puerto, intentamos usar el método de excepción para determinar qué puerto está disponible.
http://my-test-site.com:22 - 172.217.20.46:22
http://my-test-site.com:80 - 172.217.20.46:80
http://my-test-site.com:8080 -
http://my-test-site.com:9200 - 172.217.20.46:9200
http://my-test-site.com:3306 -Como especificamos 192.168.1.1 como la primera entrada, concluimos que esta dirección respondió a la biblioteca en 192.168.1.1 (puertos 8080 y 3306), incluso si era incorrecta, pero respondió. Entonces, estos puertos están abiertos y hay servicios en ellos. En este caso, no cambiará a la segunda dirección.
El servicio 1u.ms aquí también puede ayudar, en este caso tendremos la siguiente configuración:
make-%IP%-and-%IP%rr.1u.msde tipo
make-192.168.1.1-and-172.217.20.46rr.1u.msDevolverá dos entradas, todas las demás características a partir del párrafo anterior.
Por cierto, este enfoque se puede utilizar para un Rebinding de DNS más rápido, lo que obliga al navegador a cambiar de un servidor "colgado" a uno que funcione. Creo que será más rápido que esperar un minuto para actualizar el caché de DNS. Sin embargo, con Chrome, por ejemplo, este truco no funcionará, ya que toma una IP aleatoria.
Otro inconveniente es que el servidor DNS con el que la aplicación web determina que las direcciones de dominio pueden tener una operación por turnos incorporada: cambie el orden de los registros, distribuyendo de manera uniforme la carga en todos los servidores. Por ejemplo, 8.8.8.8 rechazó esta característica, pero en 1.1.1.1 está presente.
Redireccionamientos
¡Prueba redirecciones! Bueno, en primer lugar, los redireccionamientos pueden reducir la cantidad de solicitudes de una aplicación web, por ejemplo, al escanear puertos utilizando DNS. Si la respuesta llega a usted, redirija a otro puerto o dominio. Si no, tal vez tropezó en un puerto abierto.
Pero lo mejor, por supuesto, es intentar cambiar el protocolo utilizando la redirección. En mi práctica, hubo casos en que una redirección al archivo: /// etc / passwd funcionó y mostró el contenido del archivo. En la versión con ssrf ciego, puede intentar cambiar el protocolo a Gopher (mientras todavía exista), y ya puede enviar cartas usando comandos a SMTP y otra magia.
Denegación de servicio
¿Se detendrá el gestor de arranque si le doy un archivo de entrada de 10 GB de tamaño? O una imagen de 225,000 por 225,000 píxeles, que ocupa 141.4 GB de RAM. Esto puede afectar el rendimiento del sitio. Es cierto que un servidor bloqueado no nos traerá ninguna diversión, así que tenlo en cuenta.
Y un montón de todo
Esto es probablemente todo lo que puedo nombrar ahora. Esto no tiene en cuenta las vulnerabilidades asociadas con la descarga (dónde se carga, cómo se guarda, qué se verifica al mismo tiempo) y piezas de terceros (recuerde
imagetragick y
gifoeb ). Si tienes alguna otra idea, deja un comentario.
No puedo evitar darle a la
SSRF una biblia que describe la mayoría de los casos en este ataque. Y también una página con SSRF en el repositorio de
PayloadsAllTheThings favorito de
todos , que cuenta con el apoyo activo de la comunidad.
Por cierto, muchos ataques son aplicables tanto al lado del servidor (en el servidor) como al lado del cliente (en el navegador). Atacante: ataca, sé creativo. Defender: defiéndete, sé más astuto que atacar.
https://bo0om.ru/blind-ssrfZen