IBM Application Security Insider

Have you scanned your mobile site for vulnerabilities yet?

Mobile sites - Resurrecting security risks

In today's world any self respecting web site must provide access to its services through a desktop browser as well as a mobile device. This basically means that there are two versions to every site, one for desktop users and one for mobile users. Are both secure? How do we know for sure?

First, let's take a quick look at some of the reasons why companies would prefer to have mobile users visit a mobile-based site instead of directing them to the original desktop site.

• Technologies - There are certain technologies that are not supported on a mobile device (e.g. Flash on iOS) that would have to be re-designed to meet smartphone requirements.
• User experience - The user experience is completely different. For example, take the hover action, a desktop user can hover over a certain area and have menus sliding this way and that. But on a mobile device hovering does not exist.

Old Habits Die Hard: Cross-Zone Scripting in Dropbox & Google Drive Mobile Apps

Recently, as part of a broader research into mobile application security, I discovered a security vulnerability in several file-sharing mobile apps:

App Name	Vulnerable Version
DropBox	1.4.6 (iOS) + 2.0.1 (Android)
Google Drive	1.0.1 (iOS)

Exploiting this vulnerability, an attacker could steal arbitrary files from a DropBox / Google Drive user by tricking him into viewing a malicious HTML file inside the mobile app. By abusing the way in which these app render HTML files, an attacker could bypass Same Origin Policy restrictions and read files that are accessible to the app itself, including sensitive user content and application configuration.

Cross-Zone Scripting was once quite common in Desktop environments until it was mitigated by browser vendors. Unfortunately, this vulnerability type has been carried on to the Mobile world, where it is still a threat. As always, it is interesting to see how old vulnerabillities sneak up to new products.

toStaticHTML: The Second Encounter (CVE-2012-1858)

HTML Sanitizing Bypass - CVE-2012-1858

Introduction

The toStaticHTML component, which is found in Internet Explorer > 8, SharePoint and Lync 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).

It has been a year since the first encounter was published, we've now returned with a new bypass method.

Vulnerability

An attacker is able to create a specially formed CSS that will overcome toStaticHTML's security logic; therefore, after passing the specially crafted CSS string through the toStaticHTML function, it will contain an expression that triggers a JavaScript call.

XSS Analyzer Gives You 700 Million Reasons To Feel Secure

When it comes to detecting Cross-Site Scripting (XSS), AppScan is the industry's #1 tool. Today we're making it even better.

AppScan's "XSS Analyzer" is one of the most significant DAST innovations in recent years. It breaks the mold of the standard way of doing black-box testing, that has been essentially unchanged for the last twelve years, and really does something new. Something fresh. Something exciting.

Here's why we believe XSS Analyzer sets itself apart from any other scanner out there: XSS Analyzer works and thinks like a human pentester does. We've packaged the experience and expertise of the best pentesters in the industry, together with the broadest possible knowledge about the different ways to exploit XSS. Essentially, we've created an "expert human pentester in a box".

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.

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

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:

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:

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