IBM Application Security Insider

Scanning for Client-Side JavaScript Vulnerabilities

In a few weeks, our team is going to publish a new research whitepaper, which explores the prevalence of client-side JavaScript vulnerabilities such as DOM-based XSS, in real world web applications. 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. JSA is included in Rational AppScan Standard Edition v8.0, which was recently launched.

Here’s a short summary which explains how JSA works:

JSA goes over all URLs visited by AppScan’s web crawler, one by one. For each URL, JSA saves the entire HTTP response stream. JSA then looks for JavaScript entry points in the current visited URL, and applies a set of JavaScript-specific taint analysis rules. These rules include specifications of source, sink, and sanitizer functions. JSA reports on data flows from source to sink that do not go through a sanitizer. JSA reports on six different issue types: DOM-based XSS, JavaScript Code Injection, JavaScript Open-Redirect, CSRF Bypass, Dual Session Issues, Port Manipulations, Protocol Manipulations.

Issues reported by JSA appear in AppScan Standard Edition. Trace information for each issue is displayed in the issue information pane in AppScan (see image below)

Vtiger CRM Path Traversal & Malicious Code Execution Vulnerabilities

Summary:

A Path Traversal vulnerability exists in Vtiger CRM release 5.1.0 (Linux) and 5.2.0RC (Windows), which allows a malicious user to view the contents of any file that resides on the machine on which Vtiger CRM is installed. In addition, when the malicious user can place his/her own PHP file on the same machine, this vulnerability can be used in order to execute the contents of that PHP file under the permissions used by the Vtiger CRM application.

Description:

the vulnerability exists in the parameter 'login_theme', which is passed as a part of the login request to the application, as can be seen below:

[Login, HTTP Request - Line Wrapped]

POST /vtigercrm/index.php HTTP/1.1
Content-Length: ...
Content-Type: application/x-www-form-urlencoded
Host: www.vuln.site
Connection: Keep-Alive

module=Users&action=Authenticate&return_module=Users&return_action=Login&
user_name=standarduser&user_password=user&login_theme=[MALICIOUS_PAYLOAD]&
login_language=en_us&Login.x=41&Login.y=20

[End of HTTP Request]

In order to exploit this vulnerability, a malicious user can manipulate the value of the 'login_theme' parameter, to a value such as:

Babylon Cross-Application Scripting

Hey,

Recently Yair Amit and I have discovered a Cross-Application Scripting (CAS) vulnerability in Babylon which can lead to Remote Code Execution.

The advisory can be downloaded here.

A video which demonstrates the issue:

 

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

-Roee

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

Why Your Static Analysis Scanner Should Use String Analysis

I just read an awesome blog post at “Schmoilitos Way”, that describes a scenario, in which, someone ran a static analysis tool, found a vulnerability, patched it using a faulty input validation routine, and then re-ran the scan, this time telling the scanner that the validation routine clears taint input – Big Mistake!

This application had been pen-tested before. It had also been scanned using a popular commercial static analysis tool, and had gotten a clean bill of health. So, let's just say that management was a little, um, curious about why this bug was still alive and well. And by curious, I actually mean furious.

So what went wrong? After the first pen-test, the blatant directory traversal bug was "fixed" with a new validation routine that scrutinized the end of the file name. This new routine was declared a validation routine in the static analysis tool, and any subsequent data flows that passed through it were considered safe. Game over. Hooray for tools!

Last year, when IBM came out with the first edition of AppScan developer edition, it contained a new and promising technology called “String Analysis”. There was some buzz around it, but most people didn’t quite understand why they need it, and what is it good for. The scenario described in the blog post above, is a text-book example for why String Analysis is important.

String analysis removes the need to configure input sanitizers and validators when scanning your code. This is done by understanding the limitations on a certain string, and the possible value a string might have at a certain point in the program.

This basically means, that even if a developer wrote a piece of code, that performs input validation, String analysis will be able to validate this code, and see if the vulnerability still exists.

Make sure to check AppScan Source Edition’s upcoming versions, which will probably include more cutting edge technologies from IBM research.

Technical & Logical Vulnerabilities == Design & Implementation Vulnerabilities

Hi,

While at the OWASP DC conference, an interesting thought came to me, which I’d like to hear people’s opinion about. So you all probably know about technical vs. logical vulnerabilities, right? I think it was Jeremiah Grossman who came up with this classification. Anyway, while thinking about this classification, I noticed that (almost) all technical vulnerabilities stem from insecure software implementation and (almost) all logical vulnerabilities, stem from insecure software design and/or architecture. If you think about it some more, most technical vulnerabilities, are fixed by repairing your code, and most logical vulnerabilities, are fixed by applying secure design patterns (fixing your design), or modifying your architecture to be more secure.

So, IMHO:

Technical vulnerabilities == Implementation vulnerabilities

Logical vulnerabilities == Design & Architecture vulnerabilities

What do you think? I’d love to hear your comments.

Web Application Security Scanner Evaluation Criteria v1.0 released!

Hey there,

I’m happy to announce the availability of a new WASC project I have been working on for a long time – WASSEC:

The Web Application Security Scanner Evaluation Criteria (WASSEC) is a set of guidelines to evaluate web application scanners on their ability to effectively test web applications and identify vulnerabilities.  It covers areas such as crawling, parsing, session handling, testing, and reporting.

The goal of the WASSEC is to create a vendor-neutral document to help guide web application security professionals during web application scanner evaluations.  This document provides a comprehensive list of features that should be considered when conducting a web application security scanner evaluation.  Different users will place varying levels of importance on each feature, and the WASSEC provides the user with the flexibility to take this comprehensive list of potential scanner features, narrow it down to a shorter list of features that are important to the user, assign weights to each feature, and conduct a formal evaluation to determine which scanning solution best meets the user's needs.

The aim of this document is not to define a list of requirements that all web application security scanners must provide in order to be considered a "complete" scanner, and evaluating specific products and providing the results of such an evaluation is outside the scope of the WASSEC project.  Instead, this project provides the tools and documentation to enable anyone to evaluate web application security scanners and choose the product that best fits their needs.  NIST Special Publication 500-269, "Software Assurance Tools:  Web Application Security Scanner Functional Specification Version 1.0", contains minimal requirements for mandatory and optional web application scanner features.  This document can be found at https://samate.nist.gov.

Some of the sharpest minds in the webappsec industry contributed to this (group) effort, and I hope you will find it useful when evaluating scanning products. If you’d like to discuss this document in person, I will be at the OWASP AppSec DC conference next month, and would gladly answer any questions you might have.

-Ory

IBM Acquires Ounce Labs, Inc.

http://finance.yahoo.com/news/IBM-Acquires-Ounce-Labs-prnews-3505446639.html?x=0&.v=1

ARMONK, N.Y., July 28 /PRNewswire-FirstCall/ -- IBM (NYSE: IBM) today announced it has acquired Ounce Labs, Inc., a privately-held company based in Waltham, Massachusetts, whose software helps companies reduce the risks and costs associated with security and compliance concerns. IBM will integrate Ounce Labs, a leading provider of enterprise source code security testing, into its Rational software business. Financial terms were not disclosed.

Exciting news!

Windows Desktop Search – Indirect Script Injection

Background

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

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

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

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

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

Vulnerability

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

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

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

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

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

Attack Flow

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

NOTES:

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

Example of a Possible Attack

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

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

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

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

 

Final Remarks

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

Acknowledgments

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

Proactive Malware Scanning

I'll start with a short personal angle -

I have a friend that works as a freelance web site developer and webmaster. Once in a few weeks he gives me a call, telling me that one of the sites he manages seems to be serving malicious JavaScript code to its users. It appears to me that this problem is getting out of hand these days, sites are getting (silently) hacked into, and JavaScript code is injected and later on served to users.

From what I hear and read, more than 70% of the Malware today is being served or linked from legitimate web sites.

Take a look at this article from InformationWeek, which was posted in January 2009:

Seventy percent of the top 100 Web sites either hosted malicious content or contained a link designed to redirect site visitors to a malicious Web site during the second half of 2008

The common approach to Malware protection and Malware scanning today, puts the (security) responsibility on the end users (browser protections, A/V, etc.) or the organizations (content filtering gateways, A/V gateways) from which the end users browse the web from.

I think that web site owners should start taking responsibility for the contents they are serving to users, and a simple way to do that, is to constantly monitor or scan your own web application for malicious contents.

About two years ago, I had an interesting thought - if you are already scanning your web application with an automated scanner, that has the capability to perform deep crawling and analysis (using automatic form filling, JavaScript and Flash execution, etc.), why not attempt to locate malicious code that is being served to your web users?!

BTW, malicious code can end up in your application in different ways such as -

• Someone hacked into your application and put it there
• You are including web contents (or application code) from a 3rd party. This is oftentimes the case in Web 2.0 scenarios
• You pissed off one of your web developers, and they decided to get back at you by infecting your users with Malware

Enter Malware Scanner AppScan eXtension

The Malware Scanner AppScan eXtension helps you verify that your application is not hosting or linking to malware. The extension couples the deep-scanning capabilities of IBM Rational AppScan with ISS X-Force technology that is used to identify malicious content and links.

The Malware Scanner checks these conditions:

• Files hosted on your application are malicious or not
• Files that are "one click" away from your application are malicious or not
• Links on your site lead to malicious domains (malware sites or phishing sites, for example)
• Links on your site lead to unwanted content (illegal sites, hate sites, adult content, and so forth).

The Malware Scanner works in two phases:

1. It passes all of the visited links through the ISS Virus Prevention System (VPS) engine, to determine whether they are malicious or not. This is similar to browsing every page in your application, including clicking every button and downloading every file, using a machine with updated antivirus software.
2. It passes all of the links that lead to external domains through the ISS WebFilter SDK. This SDK then fetches the classification of each link (news site, porn site, malware site, illegal site, and so forth), based on the constantly updated online classification database. Links that are deemed malicious or unwanted are flagged for your attention.

When something needs to be brought to your attention, a security issue is created in Rational AppScan so that you can benefit from the strength of Rational AppScan results management capabilities, such as creating reports, saving and loading scans, and so forth.

You can read more about the Malware Scanner eXtension and download it from our eXtensions web site (you need to have AppScan installed to run it).