¿Cómo puede una simple etiqueta convertirse en un alto riesgo para una empresa?

La seguridad con ejemplos reales siempre es interesante.

Hoy hablaremos sobre el ataque SSRF, cuando puede obligar al servidor a realizar solicitudes arbitrarias a Internet a través de la etiqueta img.



Entonces, recientemente participé en pruebas de penetración en dos proyectos simultáneamente, en dos de ellos se reveló esta vulnerabilidad. Las capturas de pantalla se toman directamente de los informes, por lo tanto, toda la información innecesaria se borra.

Descripción del ataque

Nombre del ataque: el servidor realiza solicitudes arbitrarias a Internet durante la generación de un documento PDF.

Descripción: el PDF se genera en el lado del servidor desde una página html totalmente representada con todos los recursos externos. Los documentos contenían datos ingresados ​​por el usuario. Sin un filtrado adecuado, puede sustituir sus recursos externos en la representación del servidor. En este caso, deje que sea el archivo it-band.by/10gb.blob (supuestamente de 10 Gb de tamaño).

Peor escenario:

1. Los ataques DDO desde el interior cuando el sistema necesita descargar 100 gigabytes de datos para renderizar con el fin de representar varios documentos PDF a la vez. Como resultado, esto conduce a una falta de recursos de red o memoria, lo que a su vez puede provocar la caída del sistema.
2. Un usuario malintencionado puede usar el servidor como plataforma para atacar otros recursos.
3. Un usuario malintencionado obtiene las direcciones IP externas de los servidores internos para ataques directos, evitando los cortafuegos y equilibradores de aplicaciones web (WAF).

Evaluación de riesgos (Probabilidad * Impacto): Medio (5) * Alto (7) = Alto (35) (en ambos sistemas, el riesgo se calificó como alto, aunque con diferentes proporciones)

Lo que es interesante:

1. Un sistema usó wkhtmltopdf para representar html2pdf, el segundo ejecutó Firefox, cargó la página allí y tomó una captura de pantalla. En cualquier caso, ambos sistemas procesan inmediatamente ambas páginas, ejecutan todo el código allí y solo luego crean PDF a partir de esto.
2. La protección del servidor XSS se instaló en ambos sistemas, pero en lugar de utilizar el escape de datos de entrada, ambos sistemas utilizaron la purificación html, que borró todos los iframes, scripts, css, formularios, etc. Pero la purificación html en ambos sistemas se considera img src="https://it-band.by/10Gb.blob?t=12345.1"/ código html seguro.

Ahora sigue los pasos y las capturas de pantalla

1) Cree dicho archivo localmente, en un intento de rellenarlo en su totalidad o en parte.



2) Al principio, necesita encontrar campos de usuario vulnerables.

Sistema 1. Error al insertar solo una etiqueta img





Sistema 2. Logré insertar unas 20 etiquetas de inmediato



3) A continuación, generamos el documento PDF.

Sistema 1. PDF generado



Sistema 2. PDF generado



4) Y ahora subimos a nuestro servidor para ver si hubo solicitudes para nuestro gran archivo de 10 Gb.blob.

Sistema 1. Obtenemos la dirección IP y el software del servidor, con la ayuda de la cual se generó el documento PDF, nmap mostró otro puerto abierto, que nadie había visto antes, por la dirección IP encontrada.



Sistema 2. Se puede ver que el servidor intentó descargar 20 archivos de 10 gigabytes. También obtenemos la dirección de uno de los servidores y la versión de Firefox utilizada.



El resultado En ambos sistemas, los errores ya se han corregido. En el primer sistema, en lugar de la purificación html, el escape se realiza tanto durante el procesamiento de los datos del usuario como durante la generación de un documento PDF; en el segundo sistema, cualquier enlace absoluto a recursos externos se corta durante el procesamiento de datos del usuario.

Actualizado

Mientras llegaba a la publicación del artículo, se agregaron casos de 2 sistemas más.

Otro sistema (llamemos al Sistema 3) no pasó la comprobación de este tipo de vulnerabilidad en dos lugares a la vez: a través de la inyección HTML y la inyección CSS.

Sistema 3. Inyección html con descarga 20 veces de una imagen en vivo 13 Mb (en el total de 260Mb)



Sistema 3. Inyección CSS



Sistema 3. ¿Qué vemos en el servidor atacante cuando renderizamos un PDF (las 20 descargas de una imagen de 13Mb son exitosas)



Cuál fue la salida para el Sistema 3:

1) Obtuve las direcciones de los servidores que procesan y lo que usan para renderizar. En este caso, HeadlessChrome.

2) La generación de un documento PDF tomó aproximadamente 5 minutos, luego el cromo simplemente cayó. Imagínese, si ejecuta 10K de tales solicitudes, entonces, por un tiempo, los servidores de generación, en principio, dejarán de responder a las solicitudes de otros usuarios.

Sistema 4. El ataque SSRF aquí se llevó a cabo no a través de la etiqueta img, sino a través de XSS, cuando mi carga útil favorita se ejecutó en el servidor durante la representación y el servidor lanzó un código Javascript arbitrario al generar el documento PDF. En comparación con casos anteriores, es posible llevar a cabo ataques más complejos en otros sistemas.



Sistema 4. PDF renderizado con código JS arbitrario ejecutado en el lado del servidor



Premisa 1. Los sistemas requieren el desarrollo no solo de las reglas del firewall entrante, sino también del saliente, o el desarrollo de infraestructura con segmentos de red o servidores separados, de los cuales generalmente no hay acceso al exterior.

Premisa 2. Al encontrar incluso la vulnerabilidad más pequeña, siempre debe buscar los peores escenarios de su uso e impacto en el negocio. Las empresas solo pueden trabajar con riesgos, la parte técnica, desafortunadamente, les interesa poco.

La información anterior se proporciona solo con fines educativos y educativos, no es necesario cómo hacer sus sistemas.

Denis Koloshko, CISSP, probador de penetración