IBM Application Security Insider

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.

Use Traffic Viewer to Unlock Ultimate AppScan Power-User Secrets

If you have ever worked with an AppScan expert they probably got you to install the AppScan Traffic Viewer. This tool is the Swiss army knife of the AppScan Power user containing a multitude of support features and giving you ultimate visibility on what happens under the covers.

If you didn't use the tool yet you should definitely give it a try. Starting with AppScan 8.6 the tool will be located in the AppScan tools folder ([AppScan Installation Directory]\Tools\Traffic Viewer\TrafficViewerSetup.msi) or can be downloaded from the AppScan Enterprise portal (by going to http://[appscan_server]/appscan_instance/downloads/TrafficViewerSetup.msi).

Built using the model of other HTTP Debuggers such as Fiddler or Paros, it can actually work in both online and offline mode, by loading the AppScan traffic dumps and can give you a post mortem of the security scan without interfering with the scan itself. For example, if your site crashed during the scan and you want to find out which request is responsible for this Denial of Service, Traffic Viewer is ideal to do that.

To obtain the AppScan Standard traffic log you will need to enable it from Tools > Options > Enable Request/Response Logging. In AppScan Enterprise you enable it from the Scan Properties > Log Settings and can download it from the Scan Statistics screen.

I started building this tool when I was part of the AppScan support team and over the years every time when we needed an extra tool or capability in a troubleshooting situation I would add it to Traffic Viewer, so the tool kind of adapted to our support needs. Latest version allows you to text diff HTTP traffic, reproduce HTTP requests, do regex searches, replacements, export traffic to various formats, encode/decode strings and many many other things.

Please watch the video to see a demo of Traffic Viewer and take full advantage of this tool in this release of AppScan Standard and AppScan Enterprise.

 

 

Static Analysis Users are People Too

Over the years we've had many cases where AppScan users approached our support teams with what they claimed were false positive reports. But when our security experts looked into the details, they turned out to be actual security problems. It happens. We refer to such cases as perceived false positives. These are cases where AppScan found correct issues, but failed to communicate them to the users clearly enough.

At the end of the day, our end users are just people. If AppScan fails to explain itself clearly, it's our problem, not the user's. It's important that we find ways to explain our security findings clearly, simply, and in a convincing way.

So when we set out to write the JSA component in AppScan, we looked for a fresh new way of presenting static analysis results in a manner that is readable and understandable in the simplest possible way.

Some background: the kind of results we deal with involve a data-flow trace. This is somewhat similar to a debugger stack trace, but showing a sequence of locations in source code where data flows through. How do you visualize such data?

The Automated Human Pentester

In the security industry we’ve been dealing with Cross-Site Scripting (XSS) vulnerabilities for more than a decade now. It is still the #2 web application vulnerability according to OWASP TOP 10. Our friends at IBM X-Force show that XSS vulnerabilities appear in 41% of applications out there.

What is XSS? In a nutshell, it allows a bad guy to perform actions on your behalf. The hacker does that by injecting JavaScript that your browser executes when you view the page. Just imagine how bad that could be if it happened on your banking site, social network or your web mail provider.

Since it is clear that XSS isn’t going away, IBM is shipping a brand new XSS detection mechanism in the latest release of IBM Security AppScan 8.6. The new XSS Analyzer applies human-like learning techniques, allowing it to find vulnerabilities that were previously undetectable by automatic scanners.

Out with the old, in with the new - IBM Security AppScan Standard 8.6 released!

If you’re the kind of person that likes taking a look under the hood, then get ready to dive into the new IBM Security AppScan Standard 8.6 and take a peek at what we did for this release.

By the end of this blog you’ll be convinced AppScan Standard 8.6 has some cool new features to help you do your job - download a trial and take it for a test drive.

First, let’s shortly summarize the main enhancements and improvement, and then delve into each one further:

• Next-Generation Dynamic Analysis Security Testing (DAST) Engine
• XSS Analyzer - the last word in XSS security testing
• Usability improvements
• Powerful utilities and integrations
• Additional advanced security testing capabilities:
  • Glass box automatically adjusts environmental definitions
  • JSA – integrated into the new engine, enabled in ASE.

The New Frontier - Securing Mobile Apps (WEBCAST)

Let's talk about mobile security, shall we?

We can see that smartphones and tablets are everywhere, taking their place as dominant collaboration devices in enterprises. Many organizations are struggling with understanding the implications of developing and deploying apps to new mobile platforms such as iOS and Android. Which risks should app developers be concerned with? What are the new vulnerabilities to test for, and how to find them effectively?

In this webcast I talk about this new frontier of application security, and discuss how IBM Security AppScan tools can help.

Click the following link to go to the webcast (registration required):

You may also read our new whitepaper "Ensuring application security in mobile device environments":

What are your thoughts about scanning for vunlerabilities in mobile apps? Leave a comment!

The Most Comprehensive Web Application Security Scanner Comparison Available Marks AppScan Standard as the Leader (Again)

Once again, AppScan has proven to be the leader of web application security testing tools, in a recent benchmark of over 60 commercial and open-source tools published by Shay Chen.

Attack vector comparison (taken from the WAVSEP benchmark review)

The benchmark covered several categories aimed to help choose the web application scanner right for you. A few of the more important categories are the different input vectors a scanner is capable of attacking, the different attack vectors that are in-effect used against the site, and the coverage features included in order to successfully crawl and scan the web application.
This is the 2nd year in a row that AppScan is found to be on top, and we are of course very excited, though not surprised due to AppScan's track record.

F4F Technology Helps You Analyze Applications For Security

By Babita Sharma, Michael Hua Xiao

Most modern web applications are built using web application frameworks, such as Enterprise JavaBeans (EJB), Apache Struts and JavaServer Faces (JSF). These frameworks simplify web application development by providing higher-level abstractions for common tasks. For example, many frameworks are based on the model-view-controller pattern and there is clear separation between business data storage, business rules configuration and the UI components of the application. In the framework-based web applications, the interactions between components are primarily invoked via configuration files and source code annotations. Interactions specified through configuration files are challenging to identify by traditional static analysis tools since they are not source code and vary from framework to framework. Without the information from configuration files, related control flow and data flow are missed and would lead to loss of vulnerability findings.

Framework for Frameworks (F4F) is an approach used by IBM Security AppScan Source to effectively analyze framework-based web applications. F4F processes configuration files and code annotations used by a framework-based application and extracts all the relevant information into a Web Application Flow Language (WAFL) file. WAFL is independent of any framework and program language. A WAFL file describes data flow and control flow extracted from configuration files.

Android DNS Poisoning: Randomness gone bad (CVE-2012-2808)

Recently we discovered a very interesting vulnerability in Android’s DNS resolver, a weakness in its pseudo-random number generator (PRNG), which makes DNS poisoning attacks feasible. 

DNS poisoning attacks endanger the confidentiality and integrity of the target victim’s machine. For instance, DNS poisoning can be used to steal the victim’s cookies, or tamper with weak applications’ update mechanisms in order to execute malicious  code.

The official advisory with full details can be found here.

This blog post summarizes the advisory.

Microsoft Windows Shell Command Injection - MS12-048 (CVE-2012-0175)

CVE-2012-0175

Background

Windows File Association allows an application to define a handler that should be called for each operation on a specific file type.

For example, WinRAR registers the file type .RAR in the following manner:

The Open action defined for this file type dictates how the handler should be called upon opening the file.

The command that will be executed for this example of WinRAR is:

"C:\Program Files\WinRAR\WinRAR.exe" "%1"

(Where the %1 is replaced with the filename that the client clicked on)

Theoretically if an attacker was able to create a file called

Stu"ff.rar

He will be able to break the command string.