AMF y Cross Site scripting vulnerabilty confusion

Question

Acabo de recibir una auditoría de seguridad por parte de Deloitte en nombre de SFDC. Básicamente usamos flex y nos comunicamos a través de AMF. Utilizamos FluorineFX para esto (a diferencia de LCDS y Blaze). Se nos dice que debido a que la respuesta AMF no está codificada y que alguien puede manipular los parámetros AMF e insertar Javascript, esta es una vulnerabilidad XSS. Estoy luchando por entender cómo la respuesta de AMF, que podría hacerse eco de la pasada en JS en un mensaje de error, puede ser ejecutada por el navegador o por cualquier otra cosa. Tengo bastante experiencia con XSS con HTML y JS, pero ver cómo se etiquetó con AMF fue un poco sorprendente. Estoy en contacto con el equipo FluorineFx y también están perplejos.

Me sorprendería ver que una biblioteca de AMF codifica los datos de respuesta, Fluorine seguramente no lo hace. Sin embargo, parece que las aplicaciones de seguridad como PortSwigger e IBM AppScan incluyen este tipo de prueba en su cofre de herramientas. ¿Te has encontrado con esta vulnerabilidad con AMF y puedes explicar cómo se puede manifestar el problema de XSS? Sólo curioso. Necesito discutir mi salida de esto si existe una discusión o arreglar el agujero. Dado el uso de AMF con Flex, pensé que podrías tener alguna idea.

Información adicional ...

así que un poco más en esto desde el proveedor real, PortSwigger. Les hice la pregunta y neta, neta, reconocen que este tipo de ataque es extremadamente complicado. Inicialmente están clasificando esto como un problema de seguridad de Alta Severidad, pero creo que su tono está cambiando ahora. Pensé que publicaría el contenido de su respuesta para todos ustedes, ya que creo que la perspectiva es interesante, sin embargo.

--- De PortSwigger sobre el tema ---

Gracias por su mensaje. Creo que la respuesta es que esta es potencialmente una vulnerabilidad , pero no es trivial de explotar.

Tienes razón, no se plantearía el problema cuando la respuesta es consumida por un cliente AMF (a menos que se haga algo tonto), sino más bien si un atacante podría diseñar una situación en la que la respuesta es consumido por una navegador. La mayoría de los navegadores pasarán por alto el encabezado HTTP Content-Type, y mirarán el contenido de respuesta real , y si se ve como HTML, felizmente lo procesará como tal. Históricamente, han existido numerosos ataques donde las personas incrustan contenido HTML/JS dentro de otros formatos de respuesta (XML, imágenes, otros contenidos de la aplicación ) y esto es ejecutado como tal por el navegador.

Así que el problema no es tanto el formato de la respuesta, sino el formato de la solicitud requerida para producirlo. No es trivial para un atacante diseñar una solicitud entre dominios que contenga un mensaje AMF válido. Algo similar ocurre con las solicitudes/respuestas XML que contienen un comportamiento similar al XSS . Sin duda, es posible crear una respuesta XML válida que obtenga el tratado por el navegador como HTML, pero el desafío es cómo enviar XML sin formato en el dominio cruzado del cuerpo HTTP. Esto no se puede hacer usando un formulario HTML estándar, , por lo que un atacante necesita encontrar otra tecnología de cliente, o peculiaridad del navegador, al hacer esto. Históricamente, cosas como esta han sido posibles en varias ocasiones, hasta que fueron arregladas por los proveedores de navegadores/plugins. No tengo conocimiento de nada que lo permita en este momento.

Así que en resumen, se trata de un ataque teórico, que en función de su perfil de riesgo se podía ignorar por completo o bloquear el uso de validación de entrada del lado del servidor, o mediante la codificación de la salida en el servidor y decodificación de nuevo en el cliente.

Creo que Burp debería marcar el formato de solicitud AMF como atenuante para este problema, y ​​rebajar el impacto a bajo - Lo arreglaré.

Espero que ayude.

Saludos PortSwigger

--- más información sobre la auditoría ---

lo que hace portSwigger no es necesariamente meterse con la carga útil binaria, lo que hacen es meterse con los parámetros reales de AMF que se publican el controlador para dirigir la solicitud. Por ejemplo, aquí es un fragmento de la auditoría y que muestra parte de la respuesta a una solicitud AMF ...

HTTP/1.1 200 OK 
Server: Microsoft-IIS/6.0 
X-Powered-By: ASP.NET 
X-AspNet-Version: 2.0.50727 
P3P: CP="CAO PSA OUR" 
Content-Type: application/x-amf 
Vary: Accept-Encoding 
Expires: Tue, 06 Apr 2010 18:02:10 GMT 
Date: Tue, 06 Apr 2010 18:02:10 GMT 
Connection: keep-alive 
Content-Length: 2595 

......../7/onStatus....... 
.SIflex.messaging.messages.ErrorMessage.faultCode.faultString 
.faultDetail.rootCause.extendedData.correlationId.clientId.destination 
.messageId.timestamp.timeToLive body.headers.#Server.Processing..kFailed 
to locate the requested type 
com.Analytics.ca.Services.XXX5c2ce<script>alert(1)</script>9ccff0bda62.. 
....I506E8A27-8CD0-598D-FF6E-D4490E3DA69F.Id95ab281-d83b-4beb-abff-c668b9fd42d5 
..fluorine.I04165c8e-f878-447f-a19a-a08cbb7def2a.A.q..@............ 
.  DSId.Aeb5eeabcbc1d4d3284cbcc7924451711.../8/onRes 
...[SNIP]... 

nota el guión de "alerta" allí ... lo que hicieron fue anexado una secuencia de comandos adjunta JS a uno de los parámetros que se pasan que contienen el método para llamar a saber 'com.Analytics.ca.Services.XXX'. Al hacerlo, el JS volvió en un mensaje de error, pero hay muchas cosas que deberían suceder para que JS llegue a algún punto cercano a la ejecución. Parece una amenaza indirecta en el mejor de los casos.

- última perspectiva del auditor de seguridad -

que he discutido con el equipo más grande y todos creemos que es un ataque válido. Como menciona PortSwigger en su primer párrafo, aunque teóricamente desde que configuraste el tipo de contenido en x-amf, y espero que no se represente en el navegador, la mayoría de los navegadores ignorarán esta solicitud y la renderizarán de todos modos. Creo que los proveedores confían mucho en el hecho de que el tipo de contenido está configurado; sin embargo, los navegadores populares como IE y algunas versiones de Safari ignorarán esto.

El ataque puede desencadenarse fácilmente explotando CSRF o cualquier otra forma de iniciar un ataque XSS.

Answer 1

Parece que ha respondido sus propias consultas aquí.

Tiene una implementación del lado del servidor que lleva los argumentos a una llamada de función amf e incluye los datos de entrada en algún lugar de la salida devuelta.

Aprecio que esto es en gran medida un ataque teórico, ya que implica que el navegador muestre la carga útil y no la haga en un cliente amf. Es posible que se necesiten otras vulnerabilidades en los navegadores/complementos incluso para habilitar este escenario. Tal vez una publicación CSRF a través de los gustos de un gateway.php o similar haría que esto fuera bastante fácil de abusar, siempre y cuando el navegador procesara la salida como html/js.

Sin embargo, a menos que necesite que la persona que llama pueda pasar corchetes angulares en la respuesta, solo html-encode o quítelos y este escenario de ataque desaparece.

Esto es interesante. Normalmente se realizaría una codificación de salida únicamente para el consumidor esperado de los datos, pero es interesante considerar que el navegador a menudo podría ser un caso especial. Esto realmente es un infierno de un caso extremo, pero estoy totalmente a favor de que las personas adquieran el hábito de desinfectar y codificar sus insumos que no son de confianza.

Esto me recuerda, de muchas maneras, a la forma en que la inyección de protocolos cruzados se puede utilizar para abusar de las capacidades de reflexión de protocolos como smtp para lograr XSS en el navegador. Ver http://i8jesus.com/?p=75

Answer 2

No puedo explicar cómo alguien podría aprovechar esta "vulnerabilidad".

Pero, ¿puede resolver el problema a su satisfacción pasando datos a través de una conexión HTTPS en lugar de HTTP directo? Suponiendo que tiene un certificado SSL instalado en su servidor y HTTPS habilitado, esto debería ser un cambio menor en el archivo services-config.xml que compila en su Aplicación Flex.

Hice una llamada a un colega de Adobe con la esperanza de que pueda ofrecer más información.

Answer 3

1. No podría ser una inyección de JavaScript, ya que lo que Flash Player interpretaría JS? La comunidad de flash estaría extasiada si tuviéramos JS nativo o incluso soporte json en el reproductor. No hay una función de evaluación para actionscript y mucho menos javascript

2. Supongamos que significa que se puede inyectar con actionscript. El protocolo AMF no envía código, sino que envía modelos de datos en forma de tipos primitivos u objetos genéricos o tipados. Lo peor que puede pasar es que analicen su modelo y agreguen datos adicionales. Esto sería increíblemente difícil de hacer, ya que no sería capaz de inyectar los datos, sino que tendría que analizar todos los datos, agregar los nuevos datos, analizarlos y conservar los encabezados AMF.Debido a que AMF usa referencias en su serialización de datos, lo que significa que cuando se duplicaron los tipos de objetos, habría tenido que ver el primer objeto. La referencia es entonces un desplazamiento que significa pocas posibilidades de agregar código pero solo cambia los valores a los parámetros existentes.

3. El objeto remoto tiene un controlador de respuestas que está verificando los tipos de datos y espera unir esos tipos de datos a los componentes ui o lo que sea que haga su código. Si esos tipos de datos son incorrectos, obtendrá un error. Si el número de secuencia de respuesta AMF es incorrecto, obtendrá un error. Si algo no está perfectamente formado en el datagrama amf obtendrá un error.

4. El objeto remoto lo intenta de forma automática. Si el código de "inyección" se prolonga, Flex reenviará un mensaje e invalidará el que tardó mucho.

Sólo mis dos centavos. Como desarrollador de AMF, frecuentemente deseé haber sido fácil atornillar con el datagrama de amf para la depuración y las pruebas. Lamentablemente, obtendrá un error.

Wade Arnold

Answer 4

No sé cómo es posible alterar los datos dentro de una secuencia de respuesta AMF, pero es posible que desee asegurarse de que sus puntos finales no pueden ser manipulados a través de la comunicación con el navegador y/o JavaScript. Consulte esto article en la sección de inyección de datos maliciosos .

Answer 5

Creo que es un escenario de ataque válido. Un ataque relacionado es GIFAR, donde se engaña a la JVM para tratar un archivo gif como un contenedor. Además, no creo que la codificación de salida sea la forma correcta de resolver el problema.

La premisa del ataque es engañar al navegador para que piense que la respuesta de AMF es HTML o Javascript. Esto es posible debido a una característica llamada MIME Type Detection, que es esencialmente el navegador que dice "Los desarrolladores pueden no saber acerca de los tipos de contenido, voy a jugar a Dios y (posiblemente de forma incorrecta) averiguar el tipo MIME".

Para que esto funcione, la siguiente necesidad de mantener cierto -

1. El atacante debe ser capaz de hacer una petición GET o POST para su servidor AMF utilizando técnicas de HTML como <script> o <frame> o un <a> etiqueta. Las técnicas como XmlHttpRequest o Flash o Silverlight no cuentan.
2. El atacante debería ser capaz de insertar contenido malicioso en los primeros 256 o más bytes de la respuesta. Además, este contenido malicioso debería ser capaz de engañar al navegador y pensar que el resto de la respuesta es realmente javascript o html.

Entonces, ¿cómo lo previenen?

Lo mejor es asegurarse de que el atacante no pueda realizar una solicitud en primer lugar. Una forma muy simple y efectiva es agregar un encabezado de solicitud http al realizar la solicitud AMF, verificar su existencia en el servidor y denegar la solicitud si está ausente. El valor puede ser un valor codificado y no necesita ser secreto. Esto funciona, porque no hay un método conocido para agregar un encabezado de solicitud personalizado a través de técnicas html estándar. Puedes hacerlo a través de XmlHttpRequest o flash o silverlight, pero luego el navegador no interpretará el tipo de contenido por ti, así que está bien.

Ahora, no sé mucho sobre AMF, pero si ya está agregando un encabezado de solicitud, entonces este escenario de ataque no es posible. Si no es así, es trivial agregar uno.

HTML escapándose del contenido no es una buena solución. Supuestamente, hay varias formas de engañar al navegador para que piense que la respuesta es en realidad HTML. En otras palabras, la entrada maliciosa no necesita estar bien formada HTML. Pruebe una búsqueda en Google en mime sniffing, debería ser capaz de encontrar varias formas de engañar al navegador.