According to Google, Android was designed to give mobile developers “an excellent software platform for everyday users” on which to build rich applications for the growing mobile device market. The power and flexibility of the Android platform are undeniable, but where does it leave developers when it comes to security?

In this talk we discuss seven of the most interesting code-level security mistakes we’ve seen developers make in Android applications. We cover common errors ranging from the promiscuous or incorrect use of Android permissions to lax input validation that enables a host of exploits, such as query string injection. We discuss the root cause of each vulnerability, describe how attackers might exploit it, and share the results of our research applying static analysis to identify the issue. Specifically, we will show our successes and failures using static analysis to identify each type of vulnerability in real-world Android applications.

At the HP Fortify office, we have a casual event every week where the company orders lunch and a brave soul gives a presentation on a subject of interest. It's where we all come for the food and stay for the cool stuff we learn. One of the topics from a while ago was an overview of Joey Tyson's talk at NoVa Hackers. I think the video is well worth a watch, because he does a great job at presenting the material in a both entertaining and educational way. It has become one of my favorite links to share with my tech-savvy friends, as it showcases all the fun (and frightening) things we can do with JavaScript.

The video looks at ways to abuse the loose typing and dynamic nature of JavaScript to produce heavily obfuscated code. I'll let you watch for yourselves, as he explains the topic much better than I can. Instead, I will focus on discussing the morals of the story. What do such "powers" of JavaScript mean for us security-minded folks?

Code Execution

One of the main points of the talk was highlighting the many ways to turn a string into executable code. From a security standpoint, this is the backbone of injection vulnerabilities, such as DOM-based XSS. DOM-based XSS is a type of cross-site scripting vulnerability that appears and is exploited entirely on the client-side—typically entirely in JavaScript. This is in contrast with reflected and persistent XSS, which are server-side vulnerabilities.

The most obvious way for an attacker to execute code is using functions made just for this - eval(), setTimeout(), new Function(), and so forth. In a similar vein, though not covered in the talk, event handlers for DOM objects - e.g., window.attachEvent(), assignments to document.forms[0].action - achieve the same effect. Of course, simply writing out the stream without any sort of validation - document.write() or DOMObj.innerHTML - is the classic XSS attack. Those who know or have experienced a little bit of Web history will know that browsers accept URIs prepended with "javascript:" and execute them as JavaScript code. Attackers often use this to their advantage to redirect victims to a "javascript:" URL.

The talk also discusses another, less obvious way, to inject code. In browsers, the global namespace resides in the window object, so that if we have access to the window object, we can call on anything within it, including functions. Furthermore, in JavaScript, window['foo'] is identical to window.foo. Thus, if an attacker were ever in a position to control the value of x in window[x](), he would be able to successfully launch a cross-site scripting attack.

In short, JavaScript's flexibility allows for many different and often subtle ways to execute a string as code. Web application developers need to be especially careful to dodge the many avenues for XSS execution.

Attack strings in URLs

The canonical XSS attack involves embedding the payload in the URL of the page that eventually gets executed via one of the methods above. In DOM-based XSS, the practice is no different. In the JavaScript talk, the presenter spends a good amount of time discussing different ways to embed code in the URL. It's a very common and easy way to pass malicious code to the victim's browser.

What this means for us that we need to be especially careful when reading URL values out of the page. This often means reading window.location or its properties, such as window.location.href, window.location.hash, or window.location.search. The data therein may well contain an XSS attack string, so it is always crucial to validate any data that your code reads out of these objects.

Escaping and blacklisting characters are insufficient

The techniques in the talk are concrete examples of why escaping or blacklisting individual characters is not enough to prevent cross-site scripting attacks. The presenter was able to give several different character sets that enable arbitrary script execution. With a highly flexible language like JavaScript, it's often possible for an attacker to circumvent blacklisted characters, yet it's very difficult for a developer to be aware of and defend against every means of code injection.

In general, whitelisting is an almost certainly better alternative to blacklisting. It is easier for us to justify any options we explicitly allow, than to try to enumerate and account for every possibility to disallow. Rejecting certain characters or names can help prevent the most basic code injection attacks, but will not guard against obfuscated payload strings.

Lastly, in spirit of the holiday season, I'll leave you with something a little more whimsical. Yosuke Hasegawa is one of the earliest and most prominent JavaScript gurus to bend and abuse the language in various ways. He has written (in JavaScript, of course), among other things, a JavaScript-to-Japanese-Smileys encoder - if you happen to be a fan of Japanese emoticons.

Happy Holidays!

Our collaboration on Google Android with UC Berkeley is an example of a very successful endeavor: as of Q4’11 update to the HP Fortify Secure Coding Rulepacks, we can statically detect overprivileged Android applications. But what does overprivilege mean in the world of Android?

As part of its security model, Google Android platform defines an elaborate system of permissions. Permissions can protect access to three things:

1. Sensitive APIs,
2. Application components (e.g. content providers), and
3. Inter-and-intra-component communication.

If an application requests too few permissions, it is underprivileged and won’t be able to execute correctly because privileged calls will fail at runtime. This problem is much easier to detect during testing than the problem of overprivilege – that is, an application requesting more permissions than it needs. Overprivilege is bad for a number of reasons, the first one being violation of the principle of least privilege that says that one should not have more authority than he or she needs in order to perform a task. If the same application has other vulnerabilities, an attacker who exploits them and takes control of the application will have the same permissions the application requested, and therefore can further misuse them. Also, overprivileged applications make it easier for the end-user to end up with malware on their device because many users can become desensitized by benign applications requesting scary permissions. On the other hand, overprivileged applications can scare away security-savvy users from downloading benign applications just because they request more permissions than they need.

Our analysis of real-world Android applications showed that over 30% of all the apps we looked at are overprivileged. The most shocking cause of overprivilege is the lack of documentation from Google: as determined by our Berkeley colleagues, version 2.2 of the platform documents permission requirements for only 78 out of 1207 API calls, and 6 out of these 78 instances turned out to be incorrect. Developers are left with either figuring out permission requirements by trial and error or turning to forums and message boards, which often provide incorrect answers as well.

Static analysis is faced with some challenges when detecting overprivilege in Android applications. Specifically, aggressive use of third-party APIs (e.g. advertising APIs) and Java reflection API may result in false alarms. However, we think that static analysis can still be of great help to developers, so please take advantage of this new and exciting capability from the HP Fortify SCA.

Technorati Tags: application frameworks struts spring sca internal

We have just released the Q4 2011 update to the HP Fortify Secure Coding Rulepacks and the HP Fortify RTA Rulepack Kit.

With this release the HP Fortify Secure Coding Rulepacks now detect 502 unique categories of vulnerabilities across 20 programming languages and over 700,000 individual APIs. I would like to share with you a quick summary of the latest offerings from this release.

HP Fortify Secure Coding Rulepacks

Spring 3.0 – Support for the latest version of the Spring framework, including the following major features:

   Spring MVC – Updated support includes enhanced coverage of specific vulnerabilities related to the Spring    Framework and Spring Annotations. The update also allows Fortify to identify web service taint from REST    templates, locate resource injection errors in Spring applications, and detect three new vulnerability categories:

      - Often Misused: Spring Remote Service

      - Often Misused: Spring Web Service and

      - Spring MVC Bad Practices: Request Parameters Bound into Persisted Objects

   Spring Web Flow – New support for the Spring Web Flow framework includes identifying sources of web taint    from the framework and reporting vulnerabilities specific to Spring Web Flow applications.

Google Android – Updated support now provides improved detection of underprivileged Android applications, including missing permissions for privileged API calls, as well as sending and receiving intents. In addition, Fortify now detects overprivileged Android applications that request unnecessary permissions. This update introduces three new categories related to privilege management:

      - Privilege Management: Missing API Permission

      - Privilege Management: Missing Intent Permission and

      - Privilege Management: Unnecessary Permission.

File Disclosure – Misconfiguration and poor input validation in modern web frameworks can accidentally disclose sensitive files, including configuration and application code. Fortify now identifies File Disclosure vulnerabilities in applications that rely on Core EE Java APIs, Apache Struts, Spring and Spring Web Flow.

HP Fortify RTA Rulepack Kit – This quarter’s update adds three new categories for Fortify RTA:

Insecure Randomness – Added the ability to detect and replace uses of insecure random number generators with cryptographically-strong alternatives.

JavaScript Hijacking – We now detect JavaScript Hijacking and provide protection against Ajax/JSON/JSONP Hijacking in applications that rely on JavaScript for data transport.

Cookie Security: HTTPOnly not Set on Session Cookie – Added support for detecting and remediating insecure settings of the HTTPOnly flag during cookie creation.

This week I’m attending a conference for the participants of the BSIMM project, which seeks to objectively measure the software security assurance activities conducted by leading ISVs, financial services firms, and a variety of other development organizations.

At the conference, Gary McGraw, Sammy Migues, and Brian Chess (who created BSIMM) are sharing the results of the third round of measurements spanning 42 different firms with representatives of those firms. Most of the results make sense and fit with a motherhood-and-apple-pie understanding of the industry and what counts. However, as the number of participants increases and the set of measured data points grows, so to does the risk of misconstruing the results to promote pet arguments or other fallacies.

Now things are getting fun. As I write this, the group is preparing to spend the bulk of the afternoon discussing how measurement efforts like BSIMM could be used to assess and compare vendors in terms of software security maturity. Do the activities measured in BSIMM provide a meaningful differentiator? Do strong maturity levels correlate to better security? Do third-party vendors behave the same way as internal efforts?

I will enjoy debating these topics, but more importantly, I’m excited that the debate is occurring. The more energy we spend discussing these topics, the more likely we are to collect and share data that will help us reach better answers.

            <CharacterizationRule formatVersion="3.7" language="dotnet">
                <RuleID>SAMPLE_RULE_ADDING_PRIVATE_FLAG_001</RuleID>
                <StructuralMatch><![CDATA[
                    FieldAccess fa: fa.field.name matches "ccNum" and
                    not fa in [AssignmentStatement: lhs.location is [Location l: l.transitiveBase === fa.transitiveBase]]
                    ]]></StructuralMatch>
                <Definition><![CDATA[
                    TaintSource(fa, {+PRIVATE})
                    ]]></Definition>
            </CharacterizationRule>

            <DataflowSourceRule formatVersion="3.2" language="dotnet">
                <RuleID>SAMPLE_RULE_ADDING_PRIVATE_FLAG_002</RuleID>
                <TaintFlags>+PRIVATE</TaintFlags>
                <FunctionIdentifier>
                    <NamespaceName>
                        <Value>App.Name.Space</Value>
                    </NamespaceName>
                    <ClassName>
                        <Value>CCProcessing</Value>
                    </ClassName>
                    <FunctionName>
                        <Pattern>GetSavedCC</Pattern>
                    </FunctionName>
                    <ApplyTo implements="true" overrides="true" extends="true"/>
                </FunctionIdentifier>
                <OutArguments>return</OutArguments>
            </DataflowSourceRule>

To get the most out of a static analysis scan, one of the important features is the ability to write custom rules. The Custom Rules Editor, available as a part of HP Fortify Audit Workbench, contains wizards that generate templates rules for many common rule types. These templates provide a great starting point for writing more complex custom rules to suit your organization's needs.

One of our last updates to the wizard contains a customizable structural rules for hardcoded, empty, and null passwords. These rules demonstrate one of the fine points of the structural language and the constantValue field. Understanding how the constantValue field works will greatly help you write your own custom structural rules from scratch.

Here is the generated rule for hardcoded passwords:

   FieldAccess fa: fa.field.name matches "password" and
       fa in [AssignmentStatement: lhs.location is fa and
               not rhs.constantValue.null and
               not rhs.constantValue is [Null: ] and
               not rhs.constantValue == ""] and
       fa.field is [Field f:]*

One of the most common points of confusion is the difference between not rhs.constantValue.null, not rhs.constantValue is [Null: ], and not rhs.constantValue == "". Looking at the structural type reference, it tells us that AssignmentStatement.rhs is an Expression, which in turn contains the following structural property:

With this definition in mind, let's look at each of them in turn and discuss what each of the clauses mean.

1. First, let's look at constantValue.null. From the structural type definition above, we see that the constantValue field is null if the expression does not have a constant value. In other words, not rhs.constantValue.null matches an expression whose value is a constant.
2. constantValue is [Null: ]. Again, according to the structural type reference, constantValue is of type Value, of which Null is a subtype. Null simply refers to "A null program value." Thus, not rhs.constantValue is [Null: ] simply means that the right-hand side is a non-null constant value.
3. constantValue == "". It signifies that the value is a non-null empty string. Therefore, not rhs.constantValue == "" refers to an expression that is a non-empty constant string.

To summarize:

One of my favorite talks from OWASP AppSec USA 2011 was Brakeman and Jenkins: The Duo Detect Defects in Ruby on Rails Code. Justin Collins and Tin Zaw have written a static analysis system for Ruby on Rails. (Here's a link directly to Brakeman.)

What I particularly like about their work is that they didn't focus exclusively on analysis algorithms. They saved some of their energy and creativity for creating a solid build integration framework and an audit interface. The typical mistake for a first-time static analysis builder is to become fascinated with syntax trees and fixed point calculation. Justin and Tin have (wisely) chosen to make an end-to-end working system instead. Good stuff!