Soroush Dalili – Computer Security Is My Interest!

Introduction:

This post is a result of reading the following useful report:

The other reason to beware ExternalInterface.call() (http://lcamtuf.blogspot.com/2011/03/other-reason-to-beware-of.html)

The issue that I want to discuss here is not something different; however, I want to add something to the current materials.

Description:

According to the Adobe website, ExternalInterface.call() can accept a JavaScript function name as the first argument and a string which would be sent to that JavaScript function. Adobe says “When the call is to a JavaScript function, the ActionScript types are automatically converted into JavaScript types; when the call is to some other ActiveX container, the parameters are encoded in the request message.”. Therefore, in our case, the string would be converted into JavaScript type.

All we are trying to say is that it is possible to inject a specific parameter to an input and change the way of running the JavaScript. I should say it is very similar to the current code Injection methods in which we actively change the queries/requests to run whatever we want!

Proof of Concepts:

I want to explain it by using the example that Adobe has put in its document. I have put all the files in the following URL: http://0me.me/demo/adobeflash/ExternalInterface.call/ . Please use Mozilla Firefox if you want to see the same error messages as this PoC.

Now follow these steps:

1- Open this link: http://0me.me/demo/adobeflash/ExternalInterface.call/demo.html

2- Enter “\”” in the flash box (dark box) and press the gray button in front of it:

3- Now, you should be able to see this error in Error Console:

As you can see, we could escape the slash character “\” which was for escaping the double quotation character. Therefore, we are able to inject our JavaScript here now.

4- Now, try to enter “\”));alert(/XSS/)}catch(e){}//” in that box and press the gray button. You should be able to see the alert message:

It is because of the fact that we could complete the main functions and comment the remaining bits which is the method of code injection.

Now, you may think that we need to have a valid JavaScript function in the page or you may even think we always need to have a HTML file. I will explain this in the next section and I will prove that you can execute a JavaScript code even by running the SWF file directly without using any HTML file or JavaScript function.

Run the flash file directly now:

Now I want to add this bit that we do not need to have a real JavaScript function or a HTML page to execute a JavaScript code under the website content. In this case we only need to put the JavaScript code inside the “catch” section. This is the PoC:

1- Open this URL: http://0me.me/demo/adobeflash/ExternalInterface.call/ExternalInterfaceExample.swf

2- Now, enter the following text in the box and press the button:

“\”));alert(/XSSThis/);}catch(e){alert(/XSSOr/)}//”

3- You should be able to see this message now:

As a result, we can do a XSS attack just by opening a vulnerable or malicious/uploaded SWF file.

Note: you may have problem with closing the alert window in some browsers.

Why can this be a risk?

The websites which are using ExternalInterface.call() with the user’s provided input -without having input validation- can be in risk of having XSS vulnerability. Besides, an attacker can upload a malicious SWF file when a website lets him/her do so in order to make the website vulnerable to XSS attack – in this case I should say, an attacker might be able to do more than a XSS by uploading a SWF file.

Solution(s):

If we think about this code injection, it is really another input validation issue. It again says that the developers must not trust the provided inputs and we certainly need to have input validation when we receive the user’s input.

Note: Regarding the main reference of this text, Adobe has not accepted this as an issue to fix it fundamentally yet.

References:

- The other reason to beware ExternalInterface.call() http://lcamtuf.blogspot.com/2011/03/other-reason-to-beware-of.html

- Agora 3.0.0 RC1 Rev.4 XSS Vulnerability http://jeffchannell.com/Joomla/agora-300-rc1-rev4-xss-vulnerability.html

- Finding Vulnerabilities in Flash Applications http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt

- Cross-Site Scripting through Flash in Gmail Based Services http://blog.watchfire.com/wfblog/2010/03/cross-site-scripting-through-flash-in-gmail-based-services.html

- ActionScript 3.0 Language and Components Reference http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/external/ExternalInterface.html

- Code Injection http://en.wikipedia.org/wiki/Code_injection