Off by On

HTML5

Fri, 27 Apr 2012 17:56:38 -0700

One of the hottest topics among the members of web and security communities is HTML5. Lately, we've been getting a lot of requests from our customers regarding the ability to scan HTML5 applications with our static analysis products. Everyone wants to say that they've done something to secure their HTML5 apps, but few know what that actually means. I think the problem stems from the fact that HTML5 spec is not even complete, and yet the browsers already provide implementations for the proposed features. Plus, HTML5 isn't a completely new language – it's a collection of new features that present themselves through new HTML tags and attributes, JavaScript APIs, and HTTP headers.

In this post I won't go into detailed analysis of HTML5 security, but I would like to say that in my opinion the most sensitive areas of this new technology are going to be Cross-Origin Resource Sharing (CORS) policy that allows for communication between scripts running on different domains and client-side storage. We've already seen evidence that this can be abused in two alarming ways: storing sensitive information insecurely and storing code that gets eval'ed without proper sanitization. The latter is especially problematic when an application also contains a vulnerability that allows an attacker to inject malicious code into the client-side storage.

There are a number of other HTML5 features that I think will have a lot of security ramifications, such as cross-origin messaging, web sockets, file system APIs, as well as various others. However, I do not know whether anyone is using these primitives right now. What I do know is that the two features I mentioned above are already being used and abused. As it was pointed out here, there are already several cases of applications using local storage code caching with one of the scripts vulnerable to reflected XSS seen in the wild. On the other hand, according to the HP ESP’s 2011 Top Cyber Security Risks Report, 5% of sampled applications are CORS-enabled, and 75% of them allow any domain to be able to communicate to scripts running on their domains.

Going back to the question of statically scanning HTML5 applications for security vulnerabilities, I'd like to point out that it's not trivial. Mostly due to the dynamic nature of JavaScript: doing dataflow analysis on callbacks and anonymous functions is a challenge. Nevertheless, we have begun to address some of the relevant features in one of our older releases, and our next rulepack update will contain support for CORS and client-side storage, and potentially others. So, stay tuned.

RTA Customization: The power of being inside the application

Fri, 13 Apr 2012 10:06:48 -0700

HP Fortify RTA is very similar to a WAF, but it has one big advantage: Where a WAF protects outside of the perimeter, RTA protects from within the application. As always, we recommend to fix the known problems in code first, but when that’s not immediately possible, an RTA tool can help you out. On top of that, RTA can also be seen as an additional layer of protection.

In this blog post, I would like to show you an example of customization. More specific, let’s show an example how to protect by means of white-listing against command injection. Let’s say our customer has a web application which executes a couple of OS and other application commands where each command takes exactly one argument from the user. Taking data from the user, database, WS call or any other input and bluntly adding it to the command line will expose the application to command injection of course.

By default, RTA protects against Command Injection by parsing the command and validating it. However, as this default mechanisms does not take the entire context of the application in to consideration, it may be a good idea to add a white-listing rule to tighten the security. Assume that all commands executed in your application look like:

backup.exe user_provided_backup_file.backup
ping user_provided_host_or_ip_address
whois user_provided user_provided_domain_name
…

Then, the following rule can be inserted:

<Rule>
   <RuleID>RULE_ID_CUSTOM1</RuleID>
    <ProgramPoints>
       <SetReference id="CommandInjection"/>
    </ProgramPoints>
    <Monitors>
       <MonitorSpec class="com.fortify.runtime.monitor.Guard" monitorID="MONITOR_ID_CUSTOM1">
          <Attributes>
             <Attribute name="category">Command Injection</Attribute>
          </Attributes>
          <Predicate>
             not input matches /(backup\.exe|whois|ping) [^a-zA-Z0-9_\.\/\-]/
          </Predicate>
          <Configuration>
             <Property name="TriggerPicture">
                <Value>The executed command %{input} did not match the predefined white-list</Value>
             </Property>
          </Configuration>
          <Bindings>
             <Binding name="input" capture-ref="execute"/>
          </Bindings>
       </MonitorSpec>
    </Monitors>
</Rule>

Simply put, this rule will look at all the API’s that can lead to a Command Injection (like java.lang.runtime.Exec(), … ) and check if the executed command matches the predefined white-list ((backup\.exe|whois|ping) [^a-zA-Z0-9_\.\/\-]). If it does not match, the command will not be executed and an event will be generated which states that “The executed command %{input} did not match the predefined white-list”.

Blackhat Europe 2012 roundup

Mon, 19 Mar 2012 05:30:23 -0700

Last couple of years, I've seen various mobile talks which always attracted a lot of people and the mobile talks at Blackhat Europe weren't any different. Actually, the mobile talks at Blackhat were different in another aspect. While most mobile talks have something interesting to say, they can only fascinate me for a portion of the talk. The content presented during the talks "The Mobile Exploit Intelligence Project" by Dan Guido and Mike Arpaia and "The Heavy Metal That Poisoned the Droid" by Tyrone Erasmus fascinated me from start to finish. While the first one determines in an intelligent way what attackers focus on, the latter gives you a collection of tools to gather runtime information from your Android. In two talks, you'll first of all understand from a high level what platform and information is most useful to an attacker and what kind of attacks are really out there. Second, you'll get an overview and demo on how secure the information is kept on one specific platform, the Android (which turns out to be the most likely attack platform for an attacker).

Last but not least, I enjoyed the workshop Samurai WTF given by Justin Searle. Where distributions like Backtrack focus on network security, the Samurai WTF focuses on application security. While I've literally spend days finding out which free tools and Firefox plugins I could use to make my life easier and get my work done, the Samurai WTF distribution simply gives you a liveCD with the free tools and even the plugins installed in Firefox ready to use. So even if you think you're using the best free tools and plugins available right now, check out Samurai WTF and be surprised.

RSA : End to End Security

Thu, 15 Mar 2012 15:00:03 -0700

I attended three sessions at RSA in San Francisco last week. I started the day with an interesting presentation on embedded systems titled "Hacking Exposed: The Dark World of Tiny Systems and Big Hacks" by Stuart McClure, CTO of McAfee. He shared real life examples of how vulnerable embedded systems can be and how far reaching the security breaches on these systems can be with our current day dependence on these tiny devices that are present everywhere around us.

He discussed real life examples like a simple hijacking of a Red Cross donation poster by replacing a chip using NFC (Near Field Communication) Technology and a sophisticated trojan mouse (the pointing device, not the animal) which could serve malicious websites and inject malware updates to the host. But the two examples I related to the most involved consumer devices that all of us carry around (Android and iOS devices). First, the demonstration of a seemingly harmless Android application requiring zero permissions from the user, opening up a Linux zero shell to acquire enhanced permission without the user knowledge or consent. And second, the demonstration of how easily user data could be compromised on the iPad over a WiFi connection, due to an underlying vulnerability on the device. The session concluded with McClure showing how medical devices, such as an insulin pump, can be remotely controlled to take cyber crimes to another level.

The second session by Tom Teller of Check Point Software Technologies, demonstrated a network application, called Protoleak, that used man-in-the-middle attacks on SSL to collect information leaked by everyday applications such as Facebook, LinkedIn and Gmail. It was fascinating to see how, within minutes, the tool was able to successfully harvest and correlate the collected data to create what he called "technical profiles" of users on the network.

It struck me as I watched these two presentations that while we worry and hear a lot about security at the web and application level, this may not be sufficient. To successfully tackle security challenges in the future, we need to address end to end security for the system as a whole: device, network and application.

RSA Roundup: SSL, and How to Annoy Your Attackers

Thu, 15 Mar 2012 11:44:48 -0700

Continuing with our series on RSA 2012, I had the opportunity to attend the final two days of the conference. I ended up staying for the closing keynote by Tony Blair, which was a real treat in itself, though his speech (unsurprisingly) only marginally touched upon security at all. However, his speech was widely covered and I will instead focus on the talks that I sat in on.

I took this as an opportunity to branch out and opted for talks that focused on areas other than application security. My most memorable talk on Thursday was a rather amusing one, titled Offensive Countermeasures: Making Attackers Lives Miserable. What I found particularly interesting was that many of the methods in the presentation describe ways to exploit the attackers' psyche, often using their very own methods against them. For instance, one countermeasure involved planting a deliberately malicious Java applet—anything from a rootkit to something that helps identify who they are—tucked away somewhere on a non-production server. As it turns out, computer illiterate users aren't the only ones who blindly click on "Run" on unknown Java applets. Many hackers are so curious to probe out the internals of a network that they are willing to run anything, even if a browser pops up a warning about any unsigned Java applets. Talk about giving attackers a taste of their own medicine!

My favorite talk on Friday described many of the issues with SSL, titled SSL and Browsers: The Pillars of Broken Security. It was the last session slot on the last day of the conference and packed to the brim. It certainly deserved the audience, as I felt it was very well-presented, organized, and informative. The crux of the issue is that SSL depends on several different entities working together, from the protocol designers themselves, to the vendors (both server and browser), to the CAs, to the sysadmins. Therefore, the protocol relies on each party to do its part correctly—as the saying goes, the chain is as strong as the weakest link. The presenters then went on and described past failures in each part of the chain. It was certainly an eye-opening and alarming revelation how deep-seated the issues are, and I highly recommend checking this one out. If you're interested, one of the presenters, Ivan Ristić, also did a more detailed webcast at last year's RSA on this topic.

In all, I had a great time at RSA, with quite fascinating speakers and panels. For someone as fresh out of university as myself, it was a great way to see all the different areas that security encompasses.

Secure in 2010? Broken in 2011!

Mon, 12 Mar 2012 08:54:17 -0700

The time an application in production is secure can be very short! Check us out at Black Hat Europe, Thursday March 15 at 5pm where I'll be talking about Denial-of-Service attacks, gray box analysis and how it affects the security of a popular open source application called Apache OFBiz.

Vulnerabilities Enabling Mobile Exploits

Fri, 9 Mar 2012 07:00:00 -0800

The group from CrowdStrike, headed up by Dmitri Alperovitch and George Kurtz, gave a great presentation on Remote Access Toolkits (RAT) relating to mobile platforms at RSA last week. Underlying the “Hacking Exposed: Mobile RAT Edition” presentation was the deeply rooted issue of software vulnerabilities existing in software running on mobile platforms. Specifically, CrowdStrike purchased 20 WebKit 1/2 day vulnerabilities, combined the browser attack with an existing root vulnerability exploit, used an APK ‘repurposed’ RAT, and some good old-fashioned hard work to make the RAT attack succeed. When the presentation concluded with the communication of a mobile phone being monitored by a third party, without the knowledge of the phone's owner, there was little doubt in the room that the game had been taken to the next level.

The following two fundamental questions need to be asked as we deal with the hot topics of the year (obviously including Mobile and Cloud):
(1) Can software or hardware vulnerabilities exist without an exploit?
(2) Can software or hardware exploits exist without underlying vulnerabilities?

Since vulnerabilities can easily exist in systems, known or unknown at the present time, exploits simply may not have been created yet to take advantage of the underlying vulnerabilities. These previously unknown vulnerabilities are the basis of 0-day, 1/2-day, and 1-day vulnerabilities. Exploits, however, cannot be created without the necessary precondition of vulnerabilities existing in order for an exploit to be written. The enabling factor of the RAT exploit that was demonstrated at RSA was a vulnerability existing in the software running on the mobile phone. Without the vulnerability, the attack would not have been possible and the exploit therefore would not exist.

In summary, exploits rely on the existence of vulnerabilities in target systems. As the landscape shifts to target Cloud and Mobile technology our focus on detecting, verifying, and removing exploitable vulnerabilities through tools and techniques built into a secure development lifecycle continues to be of critical importance.

RSA Cryptographers’ Panels

Thu, 1 Mar 2012 11:28:31 -0800

I spent Tuesday of this week at RSA Conference 2012 in San Francisco. Somehow, I ended up going to three panel discussions rather than actual talks. The most entertaining, in my opinion, was the Cryptographers' Panel. To begin with, it had an outstanding list of panelists none of which require any special introductions: Whitfield Diffie (most know for Diffie-Hellman key exchange), Ron Rivest (the "R" co-author of RSA), Adi Shamir (the "S" co-author of RSA), and Stefan Savage (most known for his work on network worms, malware propagation, and distributed denial of service attacks).

The discussion started with dissection of a paper titled, appropriately for this panel, "Ron was wrong, Whit is right". The main idea behind the paper is to check how secure keys found in the wild are. Turns out that unlike keys that are used in Diffie-Hellman based algorithms, RSA keys available on the internet are less secure: two out of about one thousand public keys share common factors, probably due to insecure random number generators used for their creation. Another point raised during this discussion was the fact that there are no studies of malicious pseudo-random number generators, and that in general, traditional cryptography is based on the assumption that the keys are secure and are kept secure, which is clearly not the case. Defining a model for cryptanalysis in which this assumption does not hold is one of Shamir's latest research areas.

A number of other interesting questions were brought up. Savage and Shamir disagreed on whether it's harder to keep secrets now, with Stefan saying "no", and Adi saying "yes". However, all agreed that while cybersecurity will never become a science, security practitioners should apply scientific methods, such as rigorous gathering of experimental data, to many more scenarios than we do now.

The panelists also highlighted several major achievements that have occurred in the world of theoretical cryptography recently. The list is topped by the first key recovery attack on the full AES-128, which you can read about here. This is huge, even though it is not practically possible! The next one is the fact that ГОСТ – the Russian alternative to triple DES and AES-256 -- has also been theoretically broken in May 2011 after being thought secure for the past 20 years. Finally, SHA-3 competition is down to 5 finalists, and the winner should be announced later this year.

In the closing remarks, Rivest and Shamir touched upon more down to earth topics. Being one of the biggest names behind research in electronic voting, Rivest emphasized once again that online voting is a bad idea, and that we are simply not ready for it. And Shamir ridiculed Iranian government for shutting down internet access to its citizens.

All in all, it was a great discussion, which led me to the following thought: even though the number of security breaches rises with every year, none of these breaches have anything to do with breaking cryptographic algorithms. Even though, both AES-128 and ГОСТ have been broken, it’s nothing to lose your sleep over because the attacks are not possible in practice. This means that we're doing well on the crypto side. This is an incredible achievement! Of course, the other side of the coin is less bright – application-level flaws are still a problem and are usually the causes of these breaches. Which is why we are still here, doing our job at HP Fortify.

Q1 2012 Update

Wed, 29 Feb 2012 18:07:21 -0800

One of the primary responsibilities of the Security Research Group is keeping the security content of our products up to date. Today we released the first quarterly release of 2012, which includes updates to our static analysis, a new runtime product, and additional premium content for our customers. Details below:

HP Fortify Secure Coding Rulepacks- The Fortify Secure Coding Rulepacks detect 503 unique categories of vulnerabilities across 20 programming languages and over 705,000 individual APIs. In summary, our latest update includes the following exciting features:

Microsoft .NET MVC - Support identifies database, environment and web input in .NET MVC applications and assist in identifying issues across common dataflow categories, including Cross-Site Scripting and SQL Injection.
Context-Sensitive Ranking (CSR): Number Input - Issues produced by tainted numeric values are now reported at a reduced priority, which allows less dangerous issues to be easily triaged and handled differently than those originating from tainted string or object data. This capability impacts the following six vulnerability categories in all supported languages: Command Injection, Dangerous File Inclusion, Header Manipulation, Path Manipulation, XML Injection and XPath Injection.
HP Fortify Java Annotations - The latest version of HP Fortifyâs Java annotations identify dataflow sources, sinks, and passthroughs by annotating method parameters. A lightweight alternative to custom rules, this feature allows developers to model custom APIs for analysis without leaving their code. Categories supported include Cross-Site Scripting, SQL Injection, Command Injection and Privacy Violation. The ability to identify and cleanse web, database, private data, and file system taint is also included in this update.
Contextual Remediation Guidance - Vulnerability descriptions have been updated to provide context-sensitive examples and remediation guidance specific individual issues. Whenever possible, framework-specific examples are provided for the following categories: Cross-Site Scripting, SQL Injection, and Access Control: Database.

HP Application Security Monitor (AppSM) Runtime Rulepack Kit - The latest addition to the runtime family integrates HP Fortify Real-Time Analyzer (RTA) with HP ArcSight Enterprise Security Manager (ESM) to give IT real-time visibility into application security threats. HP AppSM delivers centralized searching, reporting and analysis while covering applications in most popular Java and Microsoft .NET configurations. This rulepack kit, integrated with HP AppSM, monitors applications for many common attacks as well as the following forensic events:

Context and session start and stop
User Logon and Logoff
File create, delete, read, and write
Socket bind, connect, shutdown, and close
Process create
Registry create, delete, read, and write
Framework validation failures

PCI DSS 2.0 Report - Support for the latest version of the Payment Card Industry's Data Security Standards. Available soon through Premium Content.

Mobile Operating Systems and their Role in Security

Thu, 16 Feb 2012 15:26:21 -0800

About a month ago the NSA released SEAndroid, a hardened version of Google Android based on SELinux (Security-Enhanced Linux). The focus of the first release is to limit the damage a malicious or inadvertently vulnerable app might cause to other apps or the underlying operating system. This effort is likely to call attention to the substantial differences surrounding communication and permissions between Apple IOS and Google Android. Of even more interest, however, is the question of how much of the security problem can be addressed by platform vendors at all?

As we saw with Microsoft’s push on Windows security in the early 2000s, building a more secure operating system isn’t enough to secure the software systems running on them. In the same way early users of the Web had to learn not to download and run arbitrary software of unknown provenance, securing our mobile devices is going to require a combination well-though out platforms, secure applications, as well as the right processes and technologies to ensure both are built, configured and used securely.

The question I’m most interested in is where will corporate users get their apps from? Some large enterprises are creating private app stores for their employees. A major driver behind this is to leverage shared buying power for discounts on commonly used apps, but the potential to enforce a corporate security policy on app downloads offers a tangible benefit. What sorts of assurance can or should secure app stores provide? Will generic providers like Apple and Google follow suit and use security as a differentiator? Only time will tell, but it’s certainly going to be fun figuring out the answers.

If you want to discuss this or other mobile security topics, join me at RSA Conference 2012 where I’m telling the Software Security Goes Mobile story on Tuesday 2/28 at 2:40PM in Orange Room 302 or the ISB White Boarding session on the same subject on Monday 2/27 at 4:30PM in Moscone North Hall E Room 134.

Handling Session Statically

Fri, 10 Feb 2012 14:38:17 -0800

Time and time again, customers complain about our static analyzer doing a poor job of doing dataflow analysis through the HTTP session. We do acknowledge our customers’ concern, and figuring out how to do a better job of tracking taint that marks untrusted data through the session attributes maps is the focus of an on-going research and improvement on our end. This actually turns out to be a non-trivial problem in the general sense, and the focus of our research is tuning the rules and the engine to improve our analysis in specific scenarios.

I thought it would be interesting and useful to look at the history of our session support, see how it evolved over the years, and understand where we currently stand. So, let’s start by looking at a very simple example.


<%

  taint = request.getParameter("foo"); 

  session.setAttribute("foo", taint);

  t = session.getAttribute("foo");

  out.println(t);

%>

In the example above, we have untrusted data enter the application via an HTTP request parameter. The data get put into an HTTP session map as an attribute with the key "foo" without being validated. Then the data are retrieved from the session and, again, without being validated, are printed to the page. This is a classic cross-site scripting vulnerability, which we would like to be able to detect statically. Our original solution consisted in writing four rules that drive the detection of the vulnerability by the engine:

Source rule for the return of the getParameter(...) call,
Passthrough rule that propagates taint from taint to session on the setAttribute(...) call,
Passthrough rule that propagates taint from session to the return of the getAttribute(...) call, and
Sink rule that actually generates a vulnerability at the println(...) call.

This was a good start, however the approach results in the entire session object becoming tainted even if only one of its attributes is tainted. This means that the analyzer reported a vulnerability even in the example below, where the retrieved attribute is different from the one that was put into the session as untrusted.


<%

  taint = request.getParameter("foo"); 

  session.setAttribute("foo", taint);

  t = session.getAttribute("bar");

  out.println(t);

%>

In order to get rid of false positives like the ones shown above, we enhanced the engine to do simple tracking of attribute keys in the case where they are known statically. If the keys are not statically known, then the original solution becomes a fall back mechanism.

One important thing to point out is that code in both examples above executes in the context of the same JSP page. For the purposes of this discussion, this means that the same session object is used to both put attributes into the session and retrieve them from it. Correctly handling a more complicated example like the one below becomes tricky.


JSP Page 1:

<%

  taint = request.getParameter("foo"); 

  session.setAttribute("foo", taint);

%> 



JSP Page 2:

<%

  t = session.getAttribute("foo");

  out.println(t);

%>

Before being analyzed, JSP pages get translated into Java classes, and the analysis is performed on the generated Java code. Each page becomes a separate class with its own instance variables and fields. Each of these classes will have access to its own session object, which means that tracking taint across pages is impossible with the approach described above, unless the engine is enhanced once again in some clever way. This is exactly what happened, and this is where we are today. There is now a new type of rule that can specify to the engine that all instances of a particular class (in this case, the session class) should be treated as the same instance.

As I said earlier, we are constantly working on finding ways to improve our static results, and this chronicle of our session support is a good example of our progress.

Voices that Matter: Katrina O'Neil on Building Secure Android Apps

Wed, 11 Jan 2012 16:03:53 -0800

Katrina O'Neil, the founding member of HP Fortify's Security Research Group, will be speaking on Building Secure Android Apps at the Voices that Matter: Android Developers Conference in San Francisco from 11:30 - 12:45pm on Friday, February 10. Specifically, the talk will spend 75 minutes covering the following:

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.

For a special early-bird discount, please use the priority code ANDSP36 and register for the conference before Friday the 13th of January.

JavaScript With No Letters or Numbers (and what it teaches us about JavaScript security)

Tue, 27 Dec 2011 04:25:28 -0800

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!

Let’s Talk About Overprivilege

Fri, 16 Dec 2011 11:15:06 -0800

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:

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

Sensitive APIs allow developers to access important services provided by the platform, such as accessing the Internet and sending SMS messages. Content providers serve as application internal databases, while a communication system lets internal and external components send messages to each other. In order to use privileged platform services, Android applications have to explicitly request permissions at install time, which is when it’s also decided whether they are granted or denied. The enforcement happens at runtime.

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.

Watch Us on YouTube

Mon, 5 Dec 2011 12:56:11 -0800

Remember our DEFCON talk on Android that we talked about here? Now you can watch it on YouTube -- enjoy!

Application Frameworks and Static Analysis (Part Ein)

Fri, 2 Dec 2011 15:04:44 -0800

Fortify SCA and the custom rules associated with application frameworks provide deep coverage of application frameworks. It may not be perfect, as no product is, but our research team is probably one of the strongest that I have worked with and they understand how to vet and analyze frameworks. I want to reveal some of our secret sauce when it comes to analyzing an application framework for vulnerabilities. I am hoping that by giving you insight into how a framework is analyzed you will understand how we support application frameworks. When analyzing frameworks, there are 3 primary areas of focus: architectural flows and components, dataflow analysis (sources of input, pass through methods, and output sinks) and framework specific vulnerabilities (error prone API methods).

Architectural Flows and Components

When analyzing an application framework, a security researcher has to understand the architectural components which make up the framework and the data flows between each component. This helps with understanding the big picture. You’ve got to understand what a framework does and how it does it if you hope of find weaknesses in it. For example, if you are looking at Struts 2, the researcher has to understand the Struts2 filters, interceptors, Actions, Results, configurations files, and custom tags. The following picture sums things up:

Copyright Apache Software Foundation. Picture is from http://struts.apache.org/2.0.6/docs/architecture.data/s2-arch-big-old.png

Understanding the big picture gives you an understanding of what is going on at a macro level but developing support for an application framework requires you to dig deeper. One of the basic rules that you write to support frameworks are dataflow rules. These rules define the input sources, pass through methods, and sinks (where vulnerabilities can be exploited).

Dataflow Analysis

Any application framework will usually define alternate ways of retrieving input. For example Spring MVC utilizes Command classes, WebRequest, NativeWebRequest, and annotations (on top of the standard JEE HttpServletRequest and ServletRequest ) to define inputs for web requests. But the Spring framework itself also provides input into the application via web services (Spring WS, XFire, JAX-RPC, etc.), remoted objects (Burlap, Hessian, Http, RMI, JMX, etc.) and other services. Identifying these entry points requires the analysis of configuration files, class hierarchies, and annotations. All of which are possible with the Fortify static code analysis (SCA) engine.

In the last 2 months I have the opportunity to write some pretty advanced SCA rules to support frameworks. I discovered that the SCA engine is a pretty amazing creation. There are actually five phases of scanning which occur where 3 of the phases deal with scripting rules (rules written entirely in a scripting language having direct access to core SCA data structures, functions, and entities) and the other two phases dealing with standard rules (rules which are represented in xml format which pass input to specific SCA analyzers to produce findings). Script rules are raw script blocks which hold the script code used by SCA to carry out a specific task such as parsing application configuration files and setting up the data structures containing this information. Standard rules are analyzer specific but can also execute script logic to customize the rule definition and inputs based on application information identified in pre-phase scripts. Standard rules are primarily focused on directing one of the many analyzers to find vulnerabilities. The SCA engine also supports a process called labeling where mid-phase scripts or labeling rules (running in phase 2) can tag classes, methods, and fields with an arbitrary identifier. Once labeling is complete, standard rules (which run after mid-phase script rules) can turn labeled items into findings or use labels to taint entry points or taint labeled methods as sources/sinks for dataflow analysis. Standard rules can also directly utilize annotated code structures to turn annotated methods into findings or taint entry points for dataflow analysis. The ability to work with annotations is important for a static analysis engine because modern frameworks such as Spring MVC (version 2.5 and above) are turning away from rigid class hierarchies and moving toward annotated POJOs (plain old java objects). Annotations are used to identify controller classes and request mapped methods for web request entry points. The SCA engine is especially well adapted to work with annotations and our rule set reflects this. Finally, post-phase scripting rules are run after vulnerabilities are identified and can be used to clean up/prune identified vulnerabilities or add additional information to identified vulnerabilities (such as which configuration file triggered the finding).

Labeling is an important feature of the SCA engine so let me give you an example:

If a web application utilizes a Hibernate or JPA persisted entity as its request bound object (commandClass in Spring MVC or Action attribute in Struts 2) then an attacker could use request parameters to update information in associate (foreign key related) entities/tables of the persistent entity.

In order to find this vulnerability a pre-script runs to collect all of the Hibernate and JPA entities as well as the Spring commandClasses or Struts 2 Actions within the application. Then mid-scripts add a label such as “persistentEntity” or “reqBoundClass” to the classes which are used as Hibernate/JPA persisted entities or request bound objects. Finally, standard rules would find all classes which had labels “persistentEntity” and “reqBoundClass” to identify objects as request bound persistent entities.

A security researcher not only needs to understand the architecture of an application framework and its inputs but he/she also needs to understand how framework APIs are utilized to pass data through the architecture of the framework (the “big” picture above). Most applications that are scanned will not provide the source code for 3^rd party frameworks. In order to trace data flows correctly, pass-through rules need to be created which cover tainted data as it passes through framework code. This allows the dataflow analyzer to correctly trace dataflow through components where the source code was not provided.

Finally, framework specific sinks need to be added to support the specific application framework. An example related to hibernate would be session.createSQLQuery(“SQL string…”); The Hibernate specific method “createSQLQuery” could be used to execute a SQL injection attack if a user controlled string is passed to the method.

Conclusion

This is probably a lot to take in one setting. We have covered two of the three steps required to analyze application frameworks. You have also gained insight into some of the inner workings of the SCA engine. Next week we will continue our discussion of application frameworks and static analysis by looking at framework specific vulnerabilities.

Q4 2011 Rulepack Update

Wed, 23 Nov 2011 13:15:58 -0800

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.

From an Undisclosed Location in Washington State

Tue, 15 Nov 2011 14:25:57 -0800

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.

No correlation is interesting too. Part 2: SCA customization: Custom Source rules

Fri, 11 Nov 2011 03:56:21 -0800

As discussed in part 1 of this blog post WI misconfiguration can lead to no correlation. Now, we show how SCA misconfiguration can also lead to no correlation.

For a particular application, WI was showing issues in the category "Privacy Violation: Credit Card Number Disclosed" and "Privacy Violation: Social Security Number Disclosure". While the SSN issues correlated nicely with SCA issues, the CCN issues did not. In fact, SCA wasn't finding a single issue in the CCN Disclosed category in the first place, so no wonder there was no correlation.

The underlying problem was fairly obvious too. By default the HP Fortify SCA rules keep track of CCN and SSN when they are stored in variables which are unambiguous. For example, the SSN in this application was stored in a field called "ssn" which was tracked by default. However, the CCN was stored in a field "ccNum" which is not one of the field or variable names which we track by default. To resolve this, a characterization rule can be written to keep track of these custom field and variable names. An example of such rule is:

            <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>

When the field in the class is retrieved through a getter, a even more trivial rule can be written (more trivial, because click through the wizards and the rule will be written for you):

            <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>

By inserting the rule, SCA was able to find the issues shown by WI. More importantly, SCA was able to find issues which weren't found by WI. Turned out that WI only scanned a portion of the application.

In short, it is important to exactly model your application in a static analysis tool to find the best results (reduce false positives and find all true issues). As it is not always obvious where a static analysis tool is missing true issues, a pen testing tool can help pointing out shortcomings in the result set. These shortcomings can then be modeled through custom rules. To write custom rules, the tools and documentation which SRG uses on day-to-day basis is available for our customers too.

Common Pitfalls in Custom Rules -- constantValue and null

Fri, 4 Nov 2011 08:00:00 -0700

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:

Name	Type	Description
constantValue	Value	The constant value of this expression. Will be null if this expression doesn't have a constant value or if SCA is unable to determine it.

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

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.
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.
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:

`not rhs.constantValue.null`	means	right hand side is a constant value,
`not rhs.constantValue is [Null: ]`	means	right-hand side is non-null,
`not rhs.constantValue == ""]`	means	right-hand side is a non-empty string.

Brakeman

Fri, 21 Oct 2011 09:30:37 -0700

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!

Reflections on Mobile Trends

Tue, 11 Oct 2011 14:58:53 -0700

I posted a lot on Google Android in the last year, and even though Android is getting more and more popular, it is not the only mobile platform out there. Naturally, another big one is Apple’s iOS, and I am looking at it right now. But, before I dive into the intricacies of iOS, I wanted to take a look at some of the other players in the mobile market.

Windows Mobile is basically dead, so for Microsoft’s platform I focused on Windows Phone. WP7 uses Silverlight and XNA, which is a framework for writing games. However, Microsoft’s story is confusing: Windows 8, which will be released at the beginning of 2012 for desktops and tablets, is based on JavaScript and HTML5, but it is unclear what the next Windows Phone will be based on. Is Microsoft moving away from Silverlight and .NET? Or Windows Phone and tablets will be using different technologies?

I also looked at Blackberry (RIM) and learned that in addition to being able to write mobile applications in Java (which is what everyone seems to know about), you can also use Flash and ActionScript for tablet development, as well as JavaScript and HTML5 for web development.

Do these data points suggest that the mobile world is moving in the direction of HTML5 and JavaScript rather than native applications? Looks like it. Does this mean that Google Android and Apple iOS will too? Probably not. One of the biggest selling points of both platforms is their inventory of applications. Drastically changing the underlying technology, towards web standards and away from native applications, could threaten the stability and breadth of functionality offered by Apple’s and Google’s app stores. Only time will tell.

No correlation is interesting too. Part 1: WI is not configured right

Fri, 7 Oct 2011 03:34:25 -0700

With the introduction of Web Inspect Real Time, we improved our correlation mechanism for the third time. Obviously, everybody wants to see correlation when running the suite on their application. However, no correlation may be a good indicator that not everything is set up right...

No correlation means something is off. In a perfect world, each issue found by product A has to have 1 or more correlated issue found by product B. If the issue is only found by product A, then

the issue found by product A is a FP or

product B is not configured right One user case that I saw a couple of times now, was SCA pointing out multiple "Parse Double Precision" issues in the code while WebInspect(WI) (and consequently SecurityScope) fails to report such issues. The reason why WI was not finding these issues was simply WI misconfiguration. As the Double Precision problem leads to a DoS, the check for it is not part of the default policy. Only when the "Assault Policy" or the "All Check Policy" is chosen in WI, the Denial of Service attacks are sent out. You can also manually add the Parse Double attack to the policy by choosing: Policy manager: Logical Attacks -> Denial of Service: (end of the list) Java (or PHP) Double-Precision Parsing Denial of Service. (On a side note, please hit SmartUpdate as we've added more attack patterns to the WI check Java/PHP Double-precision Parsing Denial of Service)

UPDATE Oct 24:
When making this policy manually, it's important to switch on the necessary Audit Engines. This can be done by going to the Policy Manager and clicking on "Threat Classes" and go to "Attack Groups". Choose: Audit Engines -> Adaptive Agents

BSIMM 3

Tue, 27 Sep 2011 20:57:22 -0700

We published BSIMM3 today. The full model is here, and there's a summary article here.

We've now got 42 measurements (and more in the pipeline.) This is the first year of BSIMM where we've re-measured some of the early participants. To put it in fancy terms, we're now a longitudinal survey. It's cool to see some quantifiable evidence of progress within some of these software security initiatives. We worked hard to add at least one more example to each of the 109 activities. I'm happy about how it came out.

If you're new to the BSIMM, here's just a little bit of background:
The Building Security In Maturity Model (BSIMM, pronounced "bee simm") is an observation-based scientific model directly describing the collective software security activities of forty-two software security initiatives. Participants include Adobe, Intuit, Bank of America, Microsoft, EMC, SAP, Google, Visa, Wells Fargo, and VMWare. We measure an organization by conducting an in-person interview with the executive in charge of the software security initiative. We convert what we learn during the interview into a BSIMM scorecard by identifying which of the 109 BSIMM activities the organization carries out. (Nobody does all 109.)

As always, the BSIMM comes with a Creative Commons license that allows you to use it for your own purposes so long as you include a pointer back to the BSIMM.

FoD 3.0!

Tue, 20 Sep 2011 09:12:48 -0700

The new release of Fortify On Demand (FoD) is just about ready to be released and it has a big new set of exciting features. If you are unfamiliar with FoD it's worth getting to know what it's about. FoD is our cloud based security solution. It's designed for customers who want to scan their products once in a while. There is nothing to install, you just upload your source code or binaries to our server and we do all of the auditing for you, usually in about a day. We can also do dynamic scans if you give us the URL of the site you want us to test. Another use for FoD is as a gatekeeper for companies who want a third party to verify the security of libraries or applications they are going to use.

The new version of FoD has three key new features. The first is the dashboard. This new landing page for the product presents you with a four panel overview of how your projects are trending from a security standpoint, what the most prevalent types of issues are, how your entire portfolio of projects rates in terms of security and more. Not only does it provide a lot of great information. It also looks great as you can see below.

Sweet! Right? The most important aspect of the dashboard is that it provides a complete overview, a heat map if you will, about the projects you have going and where they stand from the security standpoint. This will be invaluable to security leads and managers who want a larger view on their security stance.

Next up is the collaboration module. This is a straight port of some code from Fortify 360 that gives you a detailed look into each of the vulnerabilities we found in the code and allows you to identify if these are issues or not. You can see a screenshot of that UI below.

If you are familiar with F360 or AWB then this should be really familiar to you.

The third important new feature is trending. Trending means that you can track how you project is improving (hopefully) security wise. The metrics from each audit are captured and you can see how these progress over time as shown in the example screenshot below.

These may seem like rudimentary features if you are familiar with our entire product suite, but to see this in the On Demand product is really exciting for us. Our customers have been asking for this for a while and it's great to be able to get these new features into their hands.

Comodo Hacker Takes Us Back to Security 101

Mon, 12 Sep 2011 16:42:25 -0700

A presumably lone-but-patriotic hacker, known only as the Comodo Hacker, has been making the rounds in the news recently for compromising several of the most widely-used certificate authorities (CAs). The attacker forged certificates of several well-trafficked sites including Gmail, Microsoft, and Skype, which allowed intermediate proxies to spoof as the target website. As a result, email communications of some 300,000 Iranian users may have been monitored.

While the incident has sparked much political debate as well as an interest in the identity of the hacker, it reminds us of one of the basic security tenets: a chain is only as strong as the weakest link.

For instance, Google is known not only for its technical merits, but for its track record of protecting user privacy in spite of pressures from Big Brother-type governments. This self-proclaimed "do no evil" philosophy has attracted many users in politically sensitive regions to trust Gmail to keep their emails secure. In fact, over the course of this incident, Google was proactive on protecting the security of its users, carrying out its due diligence with constant updates in its blog and urging Iranian users to double-check their account settings. In this case, however, personal email messages were able to be compromised because Google, as a web company, is unavoidably reliant on web browsers to handle digital certificates. The victim of Comodo Hacker's attacks was one of the many other CAs trusted by popular browsers—one that wasn't even used by Google in the first place!*

Of course, building on top of the work of others is not only a fact of life, but is what drives technology forward at such a rapid pace. The series of intrusions are a grim reminder that we must be mindful when trusting third-party libraries and components. It is important, but not enough, to secure just your own applications, but also take into account possible vulnerabilities in any components that you use.

* Edit: The original text stated that the compromised CA was the one used by Google. This was not the case, as the attack was on a different (but browser-trusted) CA. Thanks to Desperate Olive for pointing out the error!

Fortify Insider Threat Rulepack now supports .NET

Thu, 1 Sep 2011 07:00:00 -0700

The Fortify Insider Threat Rulepack is for detecting malicious codes intentionally introduced by malicious insiders. This malicious code can be in the form of common application vulnerabilities, such as a buffer overflow or a SQL injection. These vulnerabilities will be detected by standard Fortify rulepacks. Another form of intentionally introduced malicious codes are not standard “vulnerabilities”, they look like regular program logic but with hidden, malicious “intentions”. With our new version of the Fortify Insider Threat rulepack we can detect the following classes of malicious intentions:

Logic or Time Bomb (e.g. comparing date/time)
Backdoors and Secret Credentials (e.g. comparing user name with a hardcoded value)
Nefarious Communication (e.g. network port listening)
Dynamic Code Injection/Manipulation (e.g. executing external command)
Obfuscation and Camouflage (e.g. decrypting a constant string)

Fortify released the Insider Threat rulepack for Java back in 2008, the latest version of Insider Threat rulepack is just released as part of the quarterly rulepack update with the following enhancements:

Support for Microsoft.NET APIs: Now with 13 common categories that exist in both Java and .NET, 9 Java only vulnerabilities and 9 .NET only vulnerabilities
CWE Support: each Insider Threat category is now mapped with a CWE reference number
Improved descriptions and examples to help developers to understand the underlying risks
Redesigned project template to adapt to the new Fortify Priority Order

Detecting insider traps is not as straight forward as detecting standard application vulnerabilities. We are constantly looking into different approaches to improve the Insider Threat Rulepack. Please don’t hesitate to contact us if you have any comments/queries/questions.

Android Permissions in Motion

Fri, 26 Aug 2011 17:26:35 -0700

Ho Chen and Lian Cai, of University of Califonia Davis, just published a paper showing they could determine the keystrokes on a touchscreen phone just using the accelerometer. Their over 70% accuracy on a 10-digit keypad makes it clear this is a completely feasible attack that most mobile phone users would never think to worry about.

When we took a look at Android security earlier this year, we quickly focused on the permissions model as being one of the most interesting areas of research. We presented at DefCon with some friends from University of California Berkeley earlier this month on just that topic.

Given our focus on the development of software, one of the challenges of this model that we've talked less about is the fact that it relies on users to review the permissions an application is requesting and make an educated decision about risk. It might be obvious that you shouldn’t let a free game make telephone calls, but what about motion sensors?

This attack is not specific to Android, any device with accelerometers and gyroscopes could be exploited (including iOS devices and laptops, which do not share Android’s permission model), but it does raise questions about how a user should decide whether to install an application.

(For those interested in a summary of the paper, ExtremeTech has an article.)

Seven Ways to Hang Yourself with Google Android

Fri, 19 Aug 2011 20:10:08 -0700

Remember my earlier post on Android permissions where I complained about our inability to detect overprivileged Android applications due to the lack of documentation from Google? Well, guess what? A few days after the post went up, I was passed a link to this paper. Turns out our colleagues at UC Berkeley have been working on the same problem for the past year.

We quickly got together and decided to collaborate. We think this work is a great example of collaboration between industry and academia on a problem that is so incredibly prevalent today. The first milestone of our collaboration is a talk at this year’s DEFCON convention in Las Vegas, which I co-presented with Erika Chin. The talk was very well received. Check out the slides.

As I said, the talk is just the first milestone of our collaborative efforts – we are working together on incorporating research that has been done by the Berkeley team into Fortify SCA. Stay tuned for more updates on our Android support in the near future.

XKCD on passwords

Wed, 10 Aug 2011 13:24:33 -0700

Adding X-Ray technology to black box analysis tools: Part 2

Thu, 4 Aug 2011 00:00:00 -0700

As discussed (link to part 1), more accurate results can be found by introducing a hidden communication channel between HP WebInspect and Fortify SecurityScope. But wait, there more. Improving coverage to find issues on “hidden” pages is trivial when such communication channel exists. SecurityScope can point HP WebInspect to everything that is hard or impossible to find by an advanced web crawler. Pages that weren’t penetrated before can now be placed under attack. Pages that were visited before are now deeply penetrated, as the communication channel can point the black box analysis to hidden or hard to find parameters. These hard to find links and parameters will be found by a determined attacker with enough time on his hands. Now, they are simply exposed to the black box analysis tool and tested for security. As an example, a previously not found administrator page is now placed under attack:

Getting the code fixed faster is another benefit from the underlying communication channel. As a security person, discussing the results from a black box analysis tool with the developer team can be quite frustrating. All the developers want to hear is how to fix their software; all the security person can provide is how to break it. As SecurityScope can observe the code being executed on the server, it’s able to transmit detailed point-of-exploit back to the black box analysis tool. The detailed source-level information can be incorporated with the regular report, which makes it more actionable for the developers.

In fact, it is not uncommon that multiple findings have a single point-of-exploit in the applications itself. As such, the information provided by the observer can be used to group duplicate findings and make the report much more actionable.

Power of Customization

Thu, 28 Jul 2011 18:18:16 -0700

Many of our customers use organization-specific coding standards and proprietary libraries in their software. The HP Fortify Secure Coding Rulepacks model a wide range of general security idioms and public APIs, but might leave analysis involving proprietary or unsupported third-party libraries incomplete and/or inaccurate. HP Fortify Custom Rules are designed to help address this gap and mitigate the risk.

Custom rules are a powerful tool for security auditors to expand on the current analysis capabilities. Custom Rules allow you to arm the analysis engine with the knowledge of your proprietary security standards and libraries that are not covered by the HP Fortify Secure Coding Rulepacks. Custom rules help tailor the analysis to the needs of your software and organization.

Writing custom rules can be intimidating since it requires knowledge of the standard APIs to model, vulnerabilities that these APIs might cause, and knowledge of the rules schema and constructs. The Custom Rules Editor, a GUI tool built into HP Fortify Audit Workbench, provides various rule wizards and templates that guide the user through the rule writing process. The auto-completion and type checking features within the editor are nice additions that help make the rule writing process easier.

The Fortify Security Research Group periodically updates the Custom Rules Editor wizards and templates to make the latest rules and enhancements available to the end user. The following new custom rule wizards were added last quarter: characterization rule for generic taint, characterization rule for private taint, structural rule for hardcoded passwords and control flow rules for memory leak. Starting last quarter these updates are now also made available as a separate content bundle through Premium Content. This means you can get the latest custom rule writing capabilities without having to upgrade your HP Fortify SCA installation. The Custom Rules Editor, along with the SCA Custom Rules Guide provide a very effective tool to enhance and tailor the analysis to meet your specific business needs.

Critical Infrastructure

Mon, 25 Jul 2011 20:01:09 -0700

Pundits often speak of critical infrastructure. Does the database of license plates qualify, I wonder?

NPR on Anonymous Arrests

Thu, 21 Jul 2011 10:06:32 -0700

Recently, while listening to NPR, I was surprised to hear a reasonably informed, coherent discussion of "cyber security" from a mainstream media outlet. I especially like the "what if" scenarios from Hugh Thompson. Here's an excerpt, but I recommend listening to the piece online:

The arrest Tuesday of 14 suspected members of the "Anonymous" hacking group was the result of what an FBI official calls "good old fashioned investigative work" over several months. The effort put into cracking the Anonymous group shows that U.S. authorities considered the hackers a potential national security threat, even if most of their activity to date has been relatively harmless. But it is not yet clear whether Tuesday's arrests netted the organizers of the group or merely those who had not been careful to cover their own tracks.

IEEE Security & Privacy Special Issue on Static Analysis

Sat, 16 Jul 2011 14:45:28 -0700

Chris Wysopal and I have signed up to be guest editors for a issue of IEEE Security and Privacy Magazine focused on static analysis. The call for papers is here.

Static analysis for both security and reliability is in the midst of a golden age. There’s significant interest from academia, vendors big and small, and for the first time ever, thousands of programmers and security professionals. S&P is an excellent forum for talking about what’s going on from any and all of those perspectives. It doesn’t move at the speed of twitter, so you can actually present a complete and coherent thought, but it’s not nearly as stuffy as the IEEE Proceedings on Things That Happened a Decade Ago.

If you have an idea for a submission that you’d like to discuss, please feel free to get in touch with Chris or with me. No need to wait for the August 15 deadline for abstracts.

Educating the Next Generation to Build Secure Software

Thu, 14 Jul 2011 09:56:18 -0700

Last fall I had the pleasure of participating in the Summit on Education in Secure Software, a two-day workshop conducted by Dr. Diana Burley of the George Washington University and Dr. Matt Bishop of the University of California, Davis. The workshop brought dozens of experts from academia, industry, and government together to discuss the challenges and opportunities for education to help address the challenges of building secure software systems. The result of the workshop is a hefty report outlining the summit’s goals and describing its findings.

While some schools have begun to introduce targeted courses or lectures to address software security topics, even the most progressive schools are still a long way off from the kind of integrated and comprehensive treatment of secure software that most participants in the summit felt is required. Having graduated from a top CS program (UC Berkeley) not so long ago, I can say that teaching future computer scientists to build secure software remains a difficult problem.

I hope that this project has helped shed light on some of the challenges that lie ahead, but I’m convinced that more work in this area will be necessary. I'm also convinced that industry is going to play a critical role in both motivating efforts like these and providing expertise in practical ways to address the biggest issues in software security.

Adding X-Ray technology to black box analysis tools: Part 1

Mon, 27 Jun 2011 04:47:54 -0700

Black-box analysis tools, like HP's WebInspect (WI), rely on the response returned by the Web Server to analyze the impact of an attack on the behavior of a Web Application being assessed. However, in the absence of sufficient understanding of the server-side state of the Web Application, WI can only speculate the correlation between the variations in the application’s response content and the attacks sent to it. In fact, a web server or web application with proper error handling might make it virtually impossible for a black-box analysis tool to spot the exploits. So how can this be overcome?

Fortify SecurityScope(SS) can be installed in the web application server to observe the execution of the web applications deployed on it. For example, every API call which executes a query against the database can be inspected. This provides SS with an insight into the behavior of the Web Application which WI lacks, thus allowing SS to accurately report successful vulnerability exploits to WI. Also, WI can leverage SS by communicating to it the purpose of a particular attack. SS can use this information to verify the successful execution of the action intended by WI through this attack. This hidden communication channel between WI and SS makes results way more accurate! (More to come in a follow up blog post, as accuracy is only one out of four big advantages this hidden communication channel provides)

In action, the interaction between WI and SS goes as follow. First, the attack web request (http://web/index?name=a' or '1'='1) is made by WebInspect to the web server. In addition, WI informs SS that it is trying to exploit a SQLi by means of the attack vector

' or '1'='1

Second, SecurityScope inspects the executed code java.sql. Statement.executeQuery() with parameter

select * from db where first = 'a' or '1'='1' (NewClass.java:27)

Regardless of what's sent back in the response stream, WI will know about this vulnerability through the hidden communication channel between WI and SS.

This technique works great to improve the results of injection bugs. As such, this exists today (in 360 v 3.1.0) for SQLi, XSS, Command Injection, LFI, RFI and Arbitrary File Upload.

Tackling Android Inter-Process Communication and Permissions

Tue, 14 Jun 2011 17:01:33 -0700

With more and more attention on mobile platforms, and Google Android specifically, Fortify’s Security Research Group decided to re-visit our Android support in the second quarter of the year. As a result, the main headline for the latest update to the Fortify Secure Coding Rulepacks is just that – enhanced rules support for the Google Android mobile platform. In addition to expanded rules coverage of the APIs, which results in the addition of 20 existing Fortify SCA categories, the new support also contains two big improvements. One of them is better modeling of attack surface specific to a mobile platform, and another is enforcement of best practices around Android provided and custom permissions.

After spending so much time in the world of server-side enterprise code, thinking about mobile application security can be a challenge. In my opinion, the main difference between the two beasts is the fact that in the mobile world, in addition to having the same problems that exist in the server-side code model, one has to worry about two additional risks:

A much higher chance of hardware loss
Inter-component communication

The consequences of the first should affect how and what kind of data should be stored on the device. For example, applications should not be writing sensitive data to external storage, since it will be accessible to anyone who gets a hold of the device. In the same manner, since mobile platforms are all about applications (potentially malicious) that can communicate with each other, applications should be careful about accepting input from and sharing sensitive data with other applications on the device. This UC Berkeley paper does an excellent job explaining security risks involved in component interaction. In order to model this additional attack surface, which is not considered in the traditional server-side code model, Fortify SCA treats APIs related to inter-component communication as sources of untrusted data on the one hand, and privacy violation and system information leak sinks on the other.

In order to protect components from each other and shield sensitive APIs from abuse by malicious applications, Android provides a sophisticated system of permissions. Permissions required by the application are requested at install time by the AndroidManifest.xml configuration file that accompanies every Android application. When permissions are misused, however, a number of bad things can happen:

Sensitive information can leak between applications
Untrusted input from a malicious application can trigger cross-site scripting, SQL injection, and other types of vulnerabilities in the target application
The application can be over-permissioned, which can be exploited by a malicious application
The application can simply fail if it does not have permissions it requires for proper execution

Fortify SCA addresses three out of four problems listed above: the first two and the last one. The first two are addressed by the modeling of attack surface, which I describe earlier. The idea behind the solution to the last two problems is very simple: all we need to know is the mapping between the sensitive APIs that require permissions to be accessed and permissions themselves. Unfortunately, due to the lack of documentation from Google and various intricacies of the permissions system implementation, we were only able to generate a partial mapping. This partial mapping allows us to tell precisely which applications will fail at runtime because they don’t request the necessary permission, but the problem of over-permissioning can only be addressed when a complete mapping is available.

I am extremely proud of what we managed to do and how enormously useful our solution is to developers, whose only choice up until now to figure out which permissions their application should request was trial and error. We are still working on and extremely interested in generating the full mapping between permissions and APIs that require them, so we will gladly accept any input from people out there who have stumbled upon the same problem.

Success

Tue, 17 May 2011 09:38:56 -0700

The third and final part of my discussion with Gunnar Peterson. Parts one and two.

GP: So if the right answer is NOT to risk rank and cycle through, and I agree, what I think this also is saying is that the static analysis *team* should be building up real skills; because they are going deeper into a subset of apps. Beyond the wonders of the tools and process, I have come to think that success in technology projects is about people and teams. What factors have you observed that make people and teams succeed in software security over the long haul?

BC: I'll tell you what's worked for me.

For people:
Being smart is important, but if you know how to program a computer, you're smart enough. Now you have to put in a lot of hours. A LOT OF HOURS. Do something you really love because it's easier to sink all that time into it.

If you're like me and you'd rather be sitting in front of a keyboard instead of dealing with people, figure out how you're going to get out and share your ideas. Feedback makes a world of difference.

Ever wonder why so many programmers are so bad at security? Part of the problem is that most of them don't know they're bad. Generally speaking, people are bad at assessing their own strengths and weaknesses (read this: http://people.psych.cornell.edu/~dunning/publications/pdf/unskilledandunaware.pdf). That means you need to seek objective measures of your work. If it doesn't sting sometimes, you're not doing it right.

I like most of what Austin Kleon has to say in his How to Steal Like an Artist talk. He uses the word “artist” a lot. Most of the artists out there haven’t figured out just how much they have in common with engineers. Shhh.

For teams:
About a year after we hired the third round of people at Fortify, I wondered if we'd really screwed up. They hadn't come up the curve the way the first two rounds had. I thought maybe we'd gotten lax with our interview process, or maybe we had just gotten really lucky in the first two rounds, and the third round was payback. Eventually I figured out that what had gone right with the first two rounds is that we'd invested an incredible amount of time with them. We'd worked shoulder-to-shoulder in a cramped little office. We'd had lunch together almost every day for more than a year. By the time round three arrived, all the old hands were either flying around speaking and visiting with customers (that was me), or they were desperately trying to type in all of the code people like me were saying absolutely must exist as of yesterday. As a consequence, the new crowd didn't get anything close to the same amount of attention.

Moral to the story: building a great team takes a lot of interaction. Work with people you like. If you don't, that interaction will never happen, and you'll never form a good team. But here's what makes interaction a really tough pursuit: the work we do requires a lot of concentration over an extended period, so everyone needs a quiet place to work. There's tension between the need for interaction and the need for solitude. A great team figures out how to get both.

The modern trend is towards distributed teams. There is an unquestionable advantage to being able to pull people from any geography, but the ramp to being a good team is much longer because it's hard to accumulate the necessary amount of interaction.

Regarding hiring for software security assurance jobs, look for software skills first and security skills second. Security is not easy, but software is a bitch.

Priorities

Tue, 17 May 2011 09:31:34 -0700

Part two of my discussion with Gunnar Peterson. See also parts one and three.

GP: I really like your point about how companies should maximize their strengths. After all, why play a losers' game? I can easily beat Michael Jordan. I just need to not play him at basketball. Instead of trying to outgun attackers, companies should look to focus on their core strengths.

A risk equation contains assets, threats and vulnerabilities. It’s highly likely for most companies that attackers will know current threats and vulnerabilities far better than the company, but the company _should_ know their assets better than the attacker, so why not play that game instead?

For companies that are getting started with static analysis, how should they prioritize assets when getting started with static analysis?

BC: The whole Advanced Persistent Threat thing was a real eye-opener for me last year. I'm about a decade into this computer security gig, and all this time I thought I was primarily concerned with smart and capable attackers who think they have something to gain by going after the systems I'm protecting. Judging by the way APT was covered in the press, most of the computer security industry was still trying to protect against Code Red.

But now that we're all on the same page, I think it's pretty easy to see that the attacker has a few big advantages, namely:

Time. You have to ship the software eventually. The attacker gets from then on to find just one problem with what you built.
Security knowledge. Because the defender has to move first and because the world will know more about security tomorrow than it does today, it's reasonable to assume that your attacker will know about more vulnerabilities and attacks than you do.
Resources. If Anonymous decides to draw a bead on you, then they can spend more CPU cycles and engineering hours on the attack than you spent creating a defense.

What to do? You spelled out the first two moves:

Use the defender's one natural advantage: we own the playing field.
Since we can't do everything, there's no choice but to prioritize.

On the topic of prioritization, what if you were given one million dollars and told to defend your country's borders? A million bucks is a lot of money, but it doesn't go very far when you're buying military hardware. Would you prioritize and decide to defend the Canadian border rather than the Mexican border? They're both thousands of miles long, so maybe your prioritization exercise would suggest that you can only really be effective at protecting the Vermont border. Pretty silly, huh? The right thing to do with that million dollars is to spend it figuring out what a real defense would look like and then explaining the problems that stem from not getting the job done.

Applying the same idea to getting started with static analysis (or any other proactive security technique), the projects to get started with are the ones that will get you visibility into what's really going on in the organization's code, what's easy and what's difficult about working with the developers, and what you need to do to build the case for a full-fledged rollout. Sometimes this means going after the flagship product because that's where new approaches have to prove their mettle. Sometimes it means working with the team your friend manages because they're the ones who will return your phone calls. In any case, the right answer is NOT trying to risk-rank your apps and chew through them one at a time until the universe cools.

Man Plus Machine

Mon, 16 May 2011 21:38:02 -0700

Gunnar Peterson (of 1 Raindrop fame) asks good questions. This week I tried to answer some of them. Here's where we got started. (The rest of the conversation is in parts two and three.)

GP: There are some recent studies of average chess players with a good process and computers, being able to beat chessmasters far above their ability, computers’ analytical ability extend the player’s competence. In most software security groups one of the biggest challenges is to scale. The software security team is typically a single digit percentage of the size of the development staff. How does automation on static analysis help these teams? What ways can software security teams scale out to maximize their impact on the development organization?

BC: I wasn't a particularly good math student when I was a kid. All through grade school my mother (a math professor) would tell me "you'll get better at it." It turns out she was right, but not because I needed more practice. She had figured out that I wasn't a reliable performer when it comes to the repetitive stuff--working a page of long division problems, for example. Instead of practice, I just needed to get to the math classes where there was more concept and less grinding. By the time I hit calculus, the balance tipped.

Computers are good at grinding. In 2011 people are still a lot better at making intuitive leaps. So the challenge for any team that needs to protect a big frontier is to find ways to let the computer do its thing and free them up to do theirs. On the software security front, there are two big jobs to organize:

Standardization. Get your development teams to address the same security needs in the same way every time. Help them share the best solutions. Kick and scream when they decide to do things their own way. It's a heck of a lot easier to figure out when someone is not using the standard solution than it is to figure out exactly how an attacker is going to outwit their homegrown hairball of a protection mechanism.
Automation. Check all of the code for all of the dumb security mistakes programmers can make. That means static analysis and dynamic analysis. When you get good at standardization, you can rely less on having the automation find vulnerabilities and switch over to having it look for places where standards aren't being followed. We're never going to automatically find all of the security problems in a piece of software, but we can take on some of the more tedious and error-prone work and give the security team more time to work on problems where humans do best.

NoSQL == no injections?

Wed, 27 Apr 2011 05:03:24 -0700

NoSQL databases are typically non-relational and as a result, do not employ SQL. However, some—but not all—do use SQL-like SELECT statements to form queries. The NoSQL movement has been gaining traction in recent years, touting better simplicity, performance, and scalability over their relational counterparts. With the movement's growing popularity, a mishmash of NoSQL implementations cropped up on the scene with varying approaches to managing data, running the entire gamut from document stores (such as MongoDB) to key-value stores (such as Google's BigTable) to graph databases (such as Twitter's FlockDB).

There has been some confusion as to whether NoSQL databases are vulnerable to SQL injection-style attacks. After all, how would we inject SQL into something that does not use SQL? MongoDB, which does not use SQL-esque SELECT statements for database queries, even has an FAQ that weighs in on this: "Generally, with MongoDB we are not building queries from strings, so traditional SQL Injection attacks are not a problem." While this statement is technically true, it is somewhat misleading. Many misinterpret this to mean that they are safe from all other kinds of injection exploits, without noting the keyword here: traditional.

Let's take a step back and look at a SQL injection attack from its core. The SQL structured language contains a mix of data, such as column names, and code, such as operators and conditionals. SQL injection occurs when unescaped meta characters—often single quotes—trick the parser into interpreting attacker-supplied data as code. When viewed this way, it's easy to understand why NoSQL databases may also be vulnerable to their own types of injections. A NoSQL database's query language, whatever that may be, inevitably must contain representations of both data and code. As long as attackers are able to exploit meta characters in a data string to force a context switch between data and logic, there is fertile ground for injection exploits.

In other words, not employing SQL explicitly does not make NoSQL databases secure against other types of injection attacks against their own query languages.

Consider the Amazon Web Services SimpleDB service, which does use a SQL-esque SELECT syntax. The following code snippet might be from an application that allows previously-authenticated customers to search for their own invoices that match a user-specified category.

AmazonSimpleDBClient sdbc = new AmazonSimpleDBClient(appAWSCredentials);
String query = "select * from invoices where productCategory = '"
            + productCategory + "' and customerID = '"
            + customerID + "' order by '"
            + sortColumn + "' asc";
SelectResult sdbResult = sdbc.select(new SelectRequest(query));

The intended query might look something like this:

select * from invoices
where productCategory = 'Fax Machines'
and customerID = '12345678'
order by 'price' asc

But what if an attacker supplies the string Fax Machines' or productCategory = \" as his product category, and to sort by the column named \" order by 'price? SimpleDB would then see the following statement (newlines added for human readability):

select * from invoices
where productCategory = 'Fax Machines'
or productCategory = "' and customerID = '12345678' order by '"
order by 'price' asc

Note that this completely bypasses the customerID = '12345678' clause, allowing an attacker to view Fax Machine invoices of every other customer.

Databases that use SQL-like SELECT statements aren't the only ones susceptible to injection attacks. Going back to MongoDB above, Phil in his Web App Security blog cautions against injection attacks when MongoDB is deployed in conjunction with PHP. He provides the following example MongoDB query:

$collection->find(array(
    "username" => $_GET['username'],
    "passwd" => $_GET['passwd']
));

What happens if an attacker passes in login.php?username=admin&passwd[$ne]=1? In this case, PHP "helpfully" turns passwd[$ne]=1 into an associative array, resulting in the following query:

$collection->find(array(
    "username" => "admin",
    "passwd" => array("$ne" => 1)
));

In other words, it will return every admin whose password is not 1, which is (hopefully) likely to be most admins.

The takeaway message is that it's never safe to assume that a piece of software is secure just because it doesn't appear to contain any familiar vulnerabilities. No matter how many times this piece of advice has been rehashed, it's always worth repeating: Always validate your input!

An Important Tool in an Auditor's Toolbox

Thu, 14 Apr 2011 07:13:14 -0700

Security auditors today are faced with large numbers of vulnerabilities that they must organize and prioritize. In HP Fortify products, Filter Sets and Folders provide auditors with the right tools to tackle this formidable task in a systematic and efficient way.

Out-of-the-box, we provide default filter sets to focus auditors' attention on critical issues, but users aren't limited to using these. Instead, you can modify the default filter sets or create customized filter sets that best address your organization's needs.

To help demonstrate the power of this capability, I will share a few examples here.

Let's say your organization considers persistent cross-site scripting (Cross-Site Scripting: Persistent) issues to be at a lower risk than reflect cross-site scripting (Cross-Site Scripting: Reflected) issues. As shown below, Folder Filters allow you to re-categorize the Cross-Site Scripting: Persistent issues from a higher priority folder, in this case, Critical, to a lower priority folder such as High or even to a custom folder that you can create.

In another example, consider the security team has audited the result set and marked all the must fix issues as Exploitable. You may want to file these issues into one folder, label it 'Must Fix' and send it to the development team for remediation. Here is an example filter that will allow you to do just that:

In large enterprises, where multiple teams are often involved in the development effort, you may want to further categorize the issues by the development team to whom the issue belongs. If the organization name is noted in the issue comment, the example below shows how a query can be constructed to search for all Exploitable issues owned by the Core Development team and place them under the 'Must Fix Core Dev Team' folder.

As a last example, we will consider a scenario where auditors want to restrict the result view to a certain subset of issues. This is especially useful in the case of very large result sets and can be accomplished using a Visibility Filter.

An example of the visibility filter is shown below. We have created a new Filter Set called Team Filter Set. It uses a visibility filter to restrict the view to issues belonging to the Core Development Team. The Filter Set then further categorizes the issues into two folders, Must Fix and Review to help prioritize the work.

These are but a few examples of the multitude of applications for filter sets, which are among the most powerful tools in the auditor's toolbox for managing a stream of incoming issues. HP Fortify Audit Workbench GUI, provides an easy interface to help quickly customize and test filter sets and, once created, customized filter sets can be exported and/or uploaded to HP Fortify 360 Server for reuse by other users and projects.

The Amazing Life, Death, and Rebirth of Software Security Assurance

Mon, 4 Apr 2011 12:21:02 -0700

Checkout this two minute teaser from a recording I did at RSA Conference 2011 of the talk formerly known as the Amazing Life, Death, and Rebirth of Software Security Assurance (aka The Evolution of Software Security Assurance for the boring marketing types).

Common Unzip Pitfall

Thu, 31 Mar 2011 17:48:16 -0700

A few weeks ago, I investigated a customer report of a false positive. The issue was a Path Manipulation found in a web application that allows users to upload zip files. The program validates the uploaded filename, ensures it is alphanumeric and ends with “.zip”. The program then opens the zip file and unzips everything into a specific folder. Here is some representative code:

		ZipInputStream zin = new ZipInputStream(...);
		while((entry = zin.getNextEntry()) != null) {
			// SCA reports Path Manipulation in the following line
			File file = new File(dir, entry.getName());			
		}

It took me just 10 minutes to write a test program to prove to the customer the file name stored in ZipEntry is an unvalidated string and can contain anything, including "../". The reported Path Manipulation is a true positive because an attacker can cause a file to be written to an arbitrary location.

And then I realized he would not be the only developer who believes ZipEntry is “safe”. I did some simple tests with the following zip files and unzip implementations:

Test case1: a zip file with a dot-dot-slash entry "../abc.def"
Test case2: a zip file with Unicode dot-dot-slash entry "%C0%AE%C0%AE/abc.def"
Test case3: a zip file with an absolute entry name "/abc.def"
Test case4: a zip file with a special character between dot-dot ".%03./abc.def"

Name*	Vulnerable?	Comment
7zip 9.2	No	It will strip “../” and continue to run without error
WinXP SP2 Built-in Uncompress	No	It will prompt error message and stop
WinRAR 3.71	No	It will strip “../” and continue to run without error
Win32 unzip 5.42	YES
Linux unzip 5.52	No	It will strip “../” and display a warning message
JDK 1.6.0_23 "jar"	YES
Tomcat 5.0, 5.5, 6.0	YES
Tomcat 7.0.8	No	It will throw exception

* These are zip programs already installed on my laptop

For Tomcat, I created a WAR file with an entry “../ROOT/index.html” and successfully overwrote the ROOT home page in Tomcat 5.0, 5.5 and 6.0. However, Tomcat 7 is not vulnerable and will throw an exception. But even if you are running a vulnerable version of Tomcat, you probably don’t need to rush to upgrade to Tomcat 7 unless you are running a J2EE web hosting service. If anyone can deploy an application to your Tomcat server, you have a bigger problem than Path Manipulation.

Context Sensitive Ranking

Wed, 23 Mar 2011 11:13:41 -0700

Time and time again, we hear complaints from our SCA customers about reporting vulnerabilities without taking validation logic into consideration. While deciding whether the data are properly validated is out of the question for any automatic tool (a discussion worthy of a separate blog post), there are a number of things the tools can do to aid the auditor in deciding the criticality of the finding. To start off, the analyzer can reprioritize the findings based on whether any kind of validation mechanism is detected during the scan. Obviously, the analyzer needs to base its decision on some piece of evidence, so why not show this additional information to the auditor? That way, instead of spending time digging through the application source code looking for this information, the auditor can concentrate on actually determining whether the validation mechanism is doing the right thing. Finally, it would also help a lot if the auditor could quickly search for reprioritized findings and easily distinguish them from those that were not.

We call this feature Context Sensitive Ranking (CSR). And guess what? You can take advantage of it now if you use Fortify 360 v3.0 together with Q1’11 update to the Fortify Secure Coding Rulepacks. At this point, we support four validation frameworks: Struts I and II on the Java side and Microsoft ASP.NET Request Validation and WCF on the .NET side. To further illustrate this exciting feature, let’s consider an example.

Above is a screenshot of a cross-site scripting finding in a sample web application scan project opened in the Fortify Audit Workbench. The application is written with Struts I framework. In Struts I, the application defines a set of action forms that represent input supplied by the user, a set of actions that can be performed on the data, and, optionally, a set of corresponding validators that get invoked implicitly by the framework and make sure that the data supplied by the user are well-formed. Cross-site scripting findings are usually prioritized as critical, but if we zoom in on the Issues view of the AWB, we can see that this particular cross-site scripting finding appears under the High folder. This is because it has been reprioritized by CSR.

The finding shows that the application is vulnerable to cross-site scripting because user input enters the application via the name field of the XSS20Form and gets written to the web page. So how does context-sensitive ranking help the auditor decide the criticality of the issue?

If we expand the arrow next to Struts Validation in the Analysis Evidence view, we get to see additional evidence accompanying the finding. We can see that the application defines the validator for the name field of the XSS20Form. The auditor can now review the logic behind the validator to decide whether it is sufficient to prevent cross-site scripting. And to top it all, the auditor can use the Data Validation filter set in order to quickly identify the findings that are reprioritized when validation logic is detected by the SCA engine. The cross-site scripting issue we are discussing here appears under the Struts Validation folder.

Context Sensitive Ranking applies to any type of vulnerability and any type of context. Even though in the first incarnation of the feature the focus was on validation frameworks, we are planning on extending CSR to other types of contexts. And of course, we’ll keep you posted on our progress.

Introducing Real-Time Hybrid Correlation: SAST-DAST Issue Correlation

Mon, 7 Mar 2011 12:00:32 -0800

Real-Time Hybrid Correlation addresses the problems of individual vulnerability detection techniques by correlating vulnerability data from multiple sources. The most common complaint a security practitioner has when looking at results from a black-box analysis, like HP's WebInspect, is that the results are hard to act on. The most common complaint when looking at static analysis results (like Fortify SCA) is that they are prone to false positives. Correlating the results of both of these techniques overcomes the shortcomings of both to produce reliable, actionable results.

We have shown that we can enhance SCA to produce information which can glue black-box analysis results and static analysis issues together. Now we are providing a second key element, called Fortify SecurityScope, that produces the "glue" information required for correlation. SecurityScope has the unique capability to see both web request and the execution of the code. The complete workflow, and how all of these pieces fit together is shown below.

In action, the information gathering and correlation process goes as follow. First, the attack web request (http://company.com/index?name=â or '1'='1) is made by WebInspect to the webserver and is recorded by both WebInspect and SecurityScope. A unique id (ID=234) is used to correlate the WebInspect with the SecurityScope results. Second, SecurityScope inspects the executed code (NewClass.java:27) and searches for similar, known issues produced by SCA. SCA reveals the analysis evidence in the code (Source: in.jsp:33:getParameter(), ..., Sink: NewClass.java:27:java.sql.Statement.executeQuery()). The result is three pieces of solid evidence for one issue.

This approach is extremely valuable in rooting out server-side injection bugs. Black-box analysis tools do a great job sending out attack vectors to the application, but they have problems validating the intended impact of the attack on the server-side components and pointing out the problem in code. SecurityScope augments black-box testing by validating the attack. SCA does great job pointing out the problem in code. Combined, these three techniques will revolutionize the way we do software security.

Java Denial of Service Vulnerability (Double Trouble)

Tue, 8 Feb 2011 13:03:39 -0800

The Back Story
Most versions of Java and some versions of PHP enter an infinite loop trying to turn the string "2.2250738585072012e-308" into a double precision floating point value. (Remember scientific notation? Floats and doubles are good for representing really big and really small numbers. Very important for getting the physicists to shell out for supercomputers.) Here are the details on the bugs.

This is a recipe for a quick and easy denial of service attack. If you have a Java application that does something as simple as this:
Double.parseDouble(request.getParameter("d"));
attackers can wedge a thread every time they make an HTTP request. Now Anonymous doesn't need a botnet army to take your app offline. A laptop with an AOL dialup connection should be plenty.

From a language perspective, the situation for PHP is worse because of PHP's type coercion (Looks like a double? Parse it like a double.) But only versions 5.2 and 5.3 of PHP are vulnerable, and the PHP team released a patch last month.

For Java, the problem isn't a single number. There is a small range of numbers that cause the conversion to hang. But there are lots of ways to write any given floating point number, so those itty-bitty numbers turn into an enormous volume of potential input strings. (For example, the strings "2.2250738585072012e-308" and "0.022250738585072012e-00306" are equally problematic.) The upshot is that an attack is difficult to block from the network layer without catching some legitimate values too.

The Tomcat Twist
Think you're not vulnerable because your program doesn't use any doubles? Wrong answer. Tomcat uses parseDouble() on the value of the Accept-Language HTTP header when an application calls request.getLocale(). If your application takes locale into account, chances are it's vulnerable. This isn't the only under-the-covers place doubles are lurking, so the absence of direct calls to methods such as Double.parseDouble() or Double.valueOf() doesn't mean you're guaranteed safe. And chances are good Tomcat isn't the only bit of Java middleware or framework code that uses a double.

The Punchline
This bug is an excellent example of the evolving software security landscape. Until this problem came along, calling parseDouble() looked like an ideal way to validate input. Now parseDouble() is yet another weak point to protect. And so it goes. When you ship software, you have to make sure it's protected against the risks we know about today. But when you wake up tomorrow, new risks may well have emerged during the night. Building secure systems means more than just avoiding foreseeable mistakes. It means preparing for the unforeseeable too. That means being ready to respond when new vulnerabilities emerge.

Next Steps
Oracle and Tomcat have released patches this week. We expect other Java providers (such as IBM) to follow suit. But it will be quite a while before those fixes are widely deployed. Until then, here's what we're doing:

We have released a Fortify Real-Time Analyzer (RTA) rulepack that protects against the attack at the code level. It monitors calls to the underlying class and flags calls that will cause the thread to hang. If desired, it can patch the code so that the vulnerability no longer exists. All without taking the app offline. Just saying.
Next week the HP Application Security Center (ASC) will release a check for WebInspect so that vulnerable applications can be identified during security testing.
The next Fortify Secure Coding Rulepack update for SCA (to be released at the end of February) will include static analysis rules to detect code that is vulnerable to an attack on methods such as parseDouble() and getLocale().

Fortify at RSA Conference 2011

Thu, 13 Jan 2011 15:54:23 -0800

We here in the Fortify corner of HP will be giving several talks at the RSA Conference 2011 in San Francisco next month and I wanted to take an opportunity to tell you about two of them that excite me the most.

At 10:00AM on Wednesday 2/16 I’ll deliver a talk titled The Evolution of Software Security Assurance and Its Relevance Today. We all know secure software means threat modeling, code review, penetration testing, and a plethora of other activities we take for granted. Right? Starting with Saltzer and Schroeder, this talk explores the origins, evolution, and use of these activities and others. Throughout, we share deployment experience and relate the discussion to living standards, such as Microsoft SDL, OWASP Top 10, and PCI DSS.

Immediately following my talk at 11:10AM (still Wednesday 2/16) Brian Chess and I continuing the tradition we started with the Iron Chef series of security competitions (conducted at Black Hat shows past) by leading a panel of experts in Extreme Makeover: Open Source Edition. In the spirit of ABC's reality TV show, we will bring the combined experience of our panel to bear on a critique of the open source project’s security. This lighthearted session is for newbies who want to watch a real live dissection take place and pros who need a dose of schadenfreude.

Handling Managed Beans

Fri, 17 Dec 2010 10:10:11 -0800

Fortify SCA has built-in support for a number of web frameworks: Struts 1 and 2, Spring, JSF, ADF, and various others. More and more frameworks adopt the notion of managed beans – the type of beans that contain the data and underlying logic of the application, and can be accessed by the UI components on the page through bindings to bean properties. Analyzing applications written in such frameworks is tricky. In this post, I’d like to give you an idea of what Fortify SCA does under the covers in order to trace data flow through managed beans.

Let’s start by looking at an example. Here is an excerpt of a JSP page from a sample application written using JSF:


<h:inputTextarea id="reply" label="Magic Number Comment" value="#{Garbanzo.comment}"/>

…
  
Your comment was:
  
#{Garbanzo.comment}

This piece of code is clearly vulnerable to cross-site scripting, since the value of textarea can end up containing a malicious script injected by the user that later gets reflected back to the page. In this case, the analyzer does not even need to know what the Garbanzo managed bean binds to. The analyzer can simply keep track of the fact that Garbanzo.comment is tainted because it is accessed in an input tag, and report a vulnerability when it is accessed in an output tag. .

A more complicated scenario requires the analyzer to know exactly what Garbanzo binds to. The following configuration entries provide the necessary information:


   <managed-bean>
      
    <managed-bean-name>Garbanzo</managed-bean-name>
      
    <managed-bean-class>com.foo.Garbanzo</managed-bean-class>
      
    <managed-bean-scope>session</managed-bean-scope>
   
</managed-bean>

The com.foo.Garbanzo class looks like this:


class Garbanzo {
    
    private String comment;

    
    Garbanzo() {
        
        comment = “”;
    
    }

    
    String getComment() {
        
        return comment;
    
    }

    
    void setComment(String comment) {
        
        this.comment = comment;
    
    }

    
    String getComment2() {
        
        return comment;
    
    }

    
    void setComment2(String comment) {
        
        this.comment = comment;
    
    }

}

The definition of the class makes it possible to access the comment property via two different sets of getters and setters. Consider modifying the original example in the following way (changes are marked in bold):


<h:inputTextarea id="reply" label="Magic Number Comment" value="#{Garbanzo.comment}"/>

…
  
Your comment was:
  
#{Garbanzo.comment2}

In this case, the simple solution for tracking data flow through the Garbanzo bean fails to catch the cross-site scripting vulnerability. A better solution is to let Fortify SCA emulate what the framework does underneath. Namely, the engine knows that accessing the bean property in an input tag actually means calling the setter of the corresponding field of a bean class, and accessing the bean property in an output tag means calling the corresponding getter. And the best part is, the mechanism for determining the bean class on which to call the right setter and getter is externalized to the rules, which makes it possible to support more than one framework that follows the same pattern of managed bean usage without updates to the SCA engine!