¿Cómo hacer un pentest archivo de Flash en la aplicación web con alowscriptaccess = samedomain?

7

En el curso de un pentest encontré un archivo de película Flash (swf) que carga otra película Flash a través de loadMovie . El HTML es este:

<embed width="388" height="350" src="http://www.domain.com/first_flash.swf?videoload=http://www.domain.com/videos/second_flash" quality="high" 
pluginspage="http://www.macromedia.com/go/getflashplayer" align="middle" 
play="true" loop="true" scale="showall" wmode="window" devicefont="false" 
bgcolor="#ffffff" name="interior" menu="true" allowfullscreen="false" 
allowscriptaccess="sameDomain" salign="" type="application/x-shockwave-flash">

Como puede ver, existe el directive allowscriptaccess="sameDomain" . Además, si accede directamente al archivo Flash, entiendo que los complementos recientes de Flash usan esta configuración como predeterminada.

En el first_flash.swf, encontré este código que carga la segunda película:

_root.videourl = _root.videoload + '.swf';
video.loadMovie(_root.videourl);

He probado que realmente puedo cambiar la variable de carga de video para cargar swf desde otros dominios. Pero parece que no puedo ejecutar javascript con getURL en un second_flash.swf controlado por mí.

Entonces, mi pregunta es, ¿qué puedo hacer para explotar este diseño deficiente? ¿Cómo puedo demostrar que, de hecho, es peligroso?

    
pregunta chmeee 07.08.2012 - 21:18
fuente

2 respuestas

5

Fuente original - enlace

2.4.1. Abusando de crossdomain.xml de Flash

La misma política de origen a menudo se puede considerar demasiado restrictiva, lo que hace que los desarrolladores de aplicaciones reclamen la capacidad de que dos dominios diferentes trabajen interactivamente entre sí. Uno de los primeros complementos populares del navegador que admite esta interacción entre dominios fue Flash de Adobe. Adobe comprendió los peligros de permitir el acceso arbitrario entre dominios e implementó una medida de seguridad para determinar si Flash permitiría la interacción entre dominios. Esta medida de seguridad se implementa a través del archivo de políticas entre dominios.

El archivo de políticas de dominio cruzado de Flash define las "reglas" para la interacción entre dominios. El archivo de políticas entre dominios es simplemente un archivo XML llamado crossdomain.xml. Aquí hay un ejemplo de un archivo crossdomain.xml:

<?xml version="1.0" encoding="UTF-8" ?>

<cross-domain-policy
    xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
    xsi:noNamespaceSchemaLocation=
    "http://www.adobe.com/xml/schemas/PolicyFile.xsd">

    <allow-access-from domain="*" /> </cross-domain-policy>

Este archivo de política crossdomain.xml debe estar alojado en el servidor que desea permitir la interacción entre dominios. Antes de permitir la interacción entre dominios, Flash verificará la presencia de un archivo de política entre dominios en el dominio de destino. Si no existe un archivo de políticas, Flash utiliza de manera predeterminada la política restrictiva del mismo origen y no permite la interacción entre dominios. Si existe un archivo crossdomain.xml en el dominio de destino, Flash lee las "reglas" contenidas en el archivo de políticas y permite la interacción entre dominios según las reglas establecidas. Una vez más, toda la premisa se basa en el hecho de que el archivo de políticas de dominios cruzados debe servirse desde el dominio que desea permitir la interacción entre dominios. De forma predeterminada, Flash verificará la presencia de un archivo de política de varios dominios llamado crossdomain.xml en la raíz web de la aplicación web (http://www.example.com/crossdomain.xml).

A partir de Flash 7, puede hacer que Flash compruebe si existe crossdomain.xml en ubicaciones arbitrarias (no solo la raíz de la raíz web) cuando el componente Flash invoque loadPolicyFile() con una URL como parámetro (que contiene la ubicación del dominio cruzado). .xml en el servidor de destino).

NOTA

Puede encontrar más información sobre System.Security.loadPolicyFile() en el siguiente sitio web:

un

El concepto de la política de dominio cruzado de Flash se basa en unas pocas premisas simples. Una versión simplificada de la lógica es la siguiente:

El archivo de políticas entre dominios debe estar ubicado en una ruta de acceso web del servidor web para permitir el acceso de dominios cruzados desde Flash a ese servidor.

La única forma en que alguien puede colocar un archivo arbitrario en una ruta de acceso del servidor web a través de la web es si tiene acceso administrativo al servidor web.

Por lo tanto, si el servidor web tiene un archivo de políticas de dominio cruzado en una ruta accesible en el servidor web, un administrador debe haberlo colocado allí.

Esta lógica es inherentemente defectuosa porque muchas aplicaciones web permiten a los usuarios cargar contenido en el servidor web. Si la aplicación posteriormente sirve ese contenido bajo su nombre de dominio, esa aplicación web se ha puesto en riesgo sin saberlo debido a las capacidades de dominio cruzado de Flash. Si un atacante puede cargar un archivo de política crossdomain.xml, el atacante puede usar un applet Flash malvado en su servidor web para atacar a la aplicación vulnerable. Este malvado Flash applet podrá realizar solicitudes de dominio cruzado a la aplicación web vulnerable y esas solicitudes se realizarán con las cookies de sesión de cualquier usuario desafortunado que se tope con el sitio web del atacante. Para empeorar las cosas, el archivo de políticas entre dominios no necesita tener la extensión .xml. Los criterios de seguridad de Flash respetarán cualquier extensión de archivo.

NOTA

Adobe Flash 9.0.115.0 permite la especificación de "meta-políticas". Estas políticas definen qué archivos de políticas en el servidor deben respetarse. Puede encontrar más información sobre las meta-políticas en enlace .

    
respondido por el atdre 16.10.2012 - 09:41
fuente
4

Todo aquí depende de la versión de su Flash Player. Aquí hay una lista de cosas que deberías probar en este archivo .swf.

Nuestra primera suposición fue Secuencias de comandos de sitios cruzados , por lo que deberíamos probar XSS, especialmente si notamos que uno de los métodos no seguros es: loadMovie .

Secuencias de comandos de sitios cruzados

Hay algunos tipos de funciones inseguras. Cada uno de ellos tiene una carga útil diferente:

  • getURL - carga útil: javascript:alert('XSS')
  • load* (en este caso: loadMovie ) - payload: asfunction:getURL,javascript:alert('XSS') [ asfunction funciona en este contexto hasta que se lanza Flash Player 9 r48]
  • TextField.htmlText - payload: <img src='javascript:alert("XSS")//.swf'> [.swf es muy importante aquí: otras extensiones no pasarán por alto el filtro interno de Flash Player].

Intermitencia de sitios cruzados

nuestra segunda suposición debería ser XSF . La primera película flash intenta cargar la segunda. Cuando obtiene el acceso a la misma parte del recinto de seguridad, somos vulnerables a XSF. Esto significa que podemos cargar el archivo flash externo y maligno, que puede llevar a XSS o películas flash falsas (por ejemplo: forma flash falsa, tipo de phishing). Ahora pensemos por un momento cuando podríamos obtener esos defectos.

Flash Player 7 o posterior permite la creación de secuencias de comandos entre dominios solo entre el mismo dominio. Podemos cargar archivos .swf de diferentes dominios, pero esos archivos no podrán intercambiar datos. Para obtener más detalles, debe verificar System.security.allowDomain .

Ahora hablemos de:

AllowScriptAccess

Este parámetro se puede encontrar dentro de la etiqueta param o embed y decide sobre la capacidad de realizar el acceso de URL saliente desde dentro del archivo SWF. Hay tres valores posibles:  - sameDomain : el acceso a la comunicación está permitido cuando el archivo .swf y la página HTML de incrustación están en el mismo dominio.  - always : igual que sameDomain , pero el archivo .swf también podría comunicarse con .swf desde el dominio diferente (que está incrustado).  - never - el archivo .swf no puede comunicarse con ninguna página. El protocolo de capa de aplicación, el nombre de dominio y el número de puerto definen el origen. Cuando el archivo .swf obtiene el código JavaScript para ejecutar desde el navegador, se ejecutará dentro del origen del sitio web de incrustación. Consideremos dos situaciones [ allowScriptAccess = sameDomain ]:

  • .swf alojado en A.com está incrustado en el sitio web HTML en B.com: origin: B.com
  • B.com tiene un iframe que carga el archivo .swf desde A.com: origin: A.com

El valor predeterminado se establece en sameDomain . Esto significa que .swf sin el atributo AllowScriptAccess debe considerarse como .swf con la propiedad sameDomain . En 2008 se notó que sameDomain podría llevar a falsificación de solicitudes en sitios cruzados . Realmente te recomiendo que leas la publicación del blog sobre esto ( más detalles - aquí ) y mire PoC .

No debes olvidarte de la contaminación de los parámetros de Flash.

Contaminación de parámetros flash

No todos los archivos .swf pueden cargarse sin el HTML original. Si el programador se olvidó del saneamiento, podríamos inyectar variables globales en flash:

print '<object type= (...) data="'.$_GET['flash'].'"></object>'

URI: http://example.com/?flash=flash.swf?var=bum

HTML: <object type= (...) data="flash=flash.swf?var=bum"></object>

    
respondido por el p____h 19.08.2012 - 00:45
fuente

Lea otras preguntas en las etiquetas