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.

JSON-based XSS exploitation

JSON rendering in Internet Explorer

In the world of Web2.0 and mash web applications, security researchers come across more and more XSS vulnerabilities that are reflected in non HTML responses.
For example, JSON responses are becoming more and more common, but exploiting XSS vectors in those pages is considered theoretical because browsers pop up the file download dialog instead of rendering the response when the returned content-type is application/json or application/javascript.

There are a few known methods to indirectly exploit these issues:

 

1. Attacking the JSON parsing mechanism:
Some applications use JS evaluation functions in order to create an object from the returned JSON content. If the attacker is able to inject, for example, a quote sign, he can break out of the JS string surrounding the value and exploit the XSS through the eval function. For example:

"name":"Foo "+alert(/XSS/.source)+"Bar"

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. Movie link  
2. Attack: Remote DNS poisoning via Java Apples: NTLM credentials and Clipboard theft.
   Environment: Windows 2008, Internet Explorer 9.  Movie link
3. Attack: Remote DNS poisoning via Java Applets: Firewall bypass.
   Environment: Windows 2008, Firefox 7.0.1. Movie Link
4. Attack: Local DNS poisoning via port exhaustion. Movie link
   Environment: Windows 2008. 

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

-Roee Hay and Yair Amit

Google App Engine Code Execution Vulnerability (CVE-2011-1364)

We have recently identified an interesting code execution vulnerability in the Google App Engine SDK for Python. By combining a CSRF vulnerability in the administration web UI, with some other vulnerabilities we found in the Google python libraries, a remote hacker could gain remote code execution privileges on victim's machine. This vulnerability affects all operation systems running Google App Engine SDK for python (i.e. Windows, Mac OS, etc.).

The full advisory can be found here.

As always, Google has been very quick with fixing the issue. According to the company, the fix was provided in version 1.5.4, which was released on Sep 12th.

 

Dolphin Browser HD Cross-Application Scripting

We have identified that Dolphin Browser HD is also vulnerable to Cross-Application Scripting, by using the same attack vector as of the Android Browser vulnerability we disclosed last month. This vulnerability can be exploited by a non-privileged application in order to inject JavaScript code into the context of an arbitrary domain.

Dolphin Browser HD 6.1.0 has been released, which incorporates a fix for this bug. 

The full advisory can be found here.

Demo of the PoC:

  

We would like to thank the Dolphin team for the efficient and quick way in which it handled this security issue.

Opera Mobile Cache Poisoning XAS

Recently we detected a security vulnerability in Opera Mobile for Android 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.

Opera Mobile 11.1 update 2 has been released, which incorporates a fix for this bug.

The complete advisory can be found here.

Demo of the PoC:

 

We would like to thank the Opera Team for the efficient and quick way in which it handled this security issue.

The Ultimate Web App Security Scanner Comparison Published - AppScan Standard Leads the Pack

>>>> See the most recent results of the 2012 WAVSEP benchmark! <<<<

Shay Chen, an Information Security consultant and blogger, recently published the latest results of his ultra-thorough web application security scanner comparison. The survey, covered 60(!) different open source and commercial scanners, and summarized some of the most critical features and capabilities of each scanner, such as:

• Audit features and capabilities
  • Active vulnerability detection features
  • Complementary scanning features (passive analysis, known issues, etc.)
  • Usability, Coverage and Scan Initiation Features
  • Authentication, Scan Control and Connection Support Features
  • Advanced and Uncommon Features
• Accuracy benchmark (performed against WAVSEP)
• Cross-site scripting success & false positives rate
• SQL Injection success & false positive rate

Needless to say, AppScan Standard Edition led the pack in most aspects - especially around Audit Features and Scanning Capabilities, where no other scanner came even close:

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 [email protected] 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.

Microsoft Internet Explorer 'toStaticHTML' HTML Sanitizing Information Disclosure Vulnerability (CVE-2011-1252)

HTML Sanitizing Information Disclosure - CVE-2011-1252
Introduction
The JavaScript function toStaticHTML, which is found in Internet Explorer 8 and Internet Explorer 9 is used to sanitize
HTML fragments from dynamic and potentially malicious content.
If an attacker is able to break the filtering mechanism and pass malicious code through this function, he/she may be
able to perform HTML injection based attacks (i.e. XSS).

Vulnerability

An attacker is able to create a specially formed CSS that after passing through the toStaticHTML function will contain

an expression that will trigger a JavaScript call.

 

The following JavaScript code will demonstrate the vulnerability:

Close Encounters of the Third Kind

As promised in my last blog post, we recently published a new whitepaper on the subject of client-side JavaScript vulnerabilities.

Below you can find a short excerpt from the whitepaper:

In the past 10 years, many whitepapers, research articles, and blogs have been published on the subject of server-side web application vulnerabilities such as SQL Injection, Cross-Site Scripting, and HTTP response splitting. In addition, several projects such as the WASC Web Hacking Incident Database or the WASC Statistics project have tried to estimate the incidence of such issues in the real world. On the other hand, there is a dearth of information and statistics on the incidence of client-side JavaScript vulnerabilities in web applications, even though these vulnerabilities are just as severe as their server-side counterparts. We suspect that the main reason for this lack of information is simply because client-side vulnerabilities are harder to locate, and require deep knowledge of JavaScript and the ability to perform code review for HTML pages and JavaScript files.

As Web 2.0, AJAX applications and rich internet applications (RIAs) become more common, client-side JavaScript vulnerabilities will probably become more relevant, and we foresee a rise in the amount of such issues being exploited by malicious hackers.

This whitepaper presents the results of a research recently performed by the IBM Rational Application Security group into the prevalence of client-side JavaScript vulnerabilities. For this research, we used a new IBM technology called JavaScript Security Analyzer (JSA), which performs static taint analysis on JavaScript code that was collected from web pages extracted by an automated deep web crawl process. This kind of analysis is superior to and more accurate than regular static taint analysis of JavaScript code, as it includes the entire JavaScript codebase in its natural environment: fully rendered HTML pages and the browser’s Document Object Model (DOM).The research used a sample group of approximately 675 websites, consisting of all the Fortune 500 companies and another 175 handpicked web sites, including IT, Web application security vendors, and social networking sites.

The whitepaper can be downloaded at the following address: Close Encounters of the Third Kind

* I would like to thank Amit Klein & Jeremiah Grossman for reviewing the whitepaper and sending me their feedbac

 

BTW – we have a problem with the blogging platform, and cannot accept any comments at this time