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

The Emerging WebSocket Protocol

Tue, 3 Apr 2012 04:51:56 -0700

Simply put, WebSocket (RFC6455) is Raw Socket over HTTP (Web). It allows real-time (e.g. push) and bidirectional communication between the web client and the web application. Consider if you want to write a stock ticker application, instead of periodically polls the server for updates, you can use WebSocket to create an (almost) raw socket to the server and do whatever you want. WebSocket runs over HTTP, therefore, access control rules on existing firewalls will simply work without any modifications. And as of this writing, 3 out of 4 browsers installed on my laptop support WebSocket already (the only exception is IE).

WebSocket doesn't prescribe any particular way to handle authentication, you can authenticate using Session cookie when your first initiate your WebSocket over HTTP, or you can authenticate right after the WebSocket is established (similar to how you handle authentication in FTP). WebSocket supports cross domain communications by mandating the ORIGIN header (but is only available if the client is a browser). Web applications should check the ORIGIN header and refuse the connection if it is originated from an untrusted 3rd party website.

In 2010, Huang et al. reported a vulnerability that can trick a vulnerable proxy server to incorrectly redirect WebSocket connections from a Java Applet or a Flash to arbitrary host (IP hijacking) and hence allowing unauthorized cross domain connections, or can poison the proxy server cache (Cache Poisoning). After that, WebSocket adopted Huang's recommendation and requires XOR on packet payloads with a random key to avoid proxy servers that don't understand WebSocket to incorrectly pick up counterfeit HTTP requests embedded in the raw socket.

The current WebSocket protocol represents a low-level communication channel only, the protocol merely defines how to switch an existing HTTP connection into a low level socket connection without much other add-on features. Furthermore, the protocol itself is not stable and server side API is not standardized yet (Java will support WebSocket in Servlet 3.1). However, with the growing demand on real-time and bidirectional communications in Web 2.0 era, I can foresee many frameworks will build around it and make it a more secure and useable protocol in the future.

Reference:
WebSocket Echo Demo http://websocket.org/echo.html (requires a WebSocket compliant browser)

Mass Assignment - It's Not Just For Rails Anymore

Fri, 23 Mar 2012 20:08:40 -0700

If you haven’t already heard, Github (and Ruby on Rails by default) was shown to have a vulnerability where a web user could change his role and give himself commit rights to the Rails code repository via request parameters. You might be thinking that this is bad but you are safe because you are not using Ruby on Rails. But you might have the same problem. Unfortunately, the cause of the “mass assignment” problem relates to the universal web framework pattern of auto-magically binding request parameters into model objects. If you are using Fortify, we catch this in Spring MVC as Request Parameters Bound into Persisted Objects.

Model Objects

Model objects are an object-oriented representation of database entities. They provide convenience methods to load, store, update, and delete associated database entities. Hibernate and LINQ are examples of Object Relational Mapping (ORM) frameworks that help you build database-backed model objects.

Auto-binding of Request Parameters to Objects

Many web frameworks make life easier for developers by providing a mechanism for binding request parameters into request bound objects based on matching request parameter names to object attribute names (based on matching public getter and setter methods).

Framework	Request Parameter Binding Method
Struts 1	ActionForms
Struts 2	ModelDriven Objects or Action Attributes
Spring MVC < 2.5	Command Objects
Spring MVC 2.5+	Controller method parameters
.NET MVC	Controller method parameters
Grails and Rails	Request parameters directly bound into model attributes

Identifying the Problem

If you are using ORM classes as your request bound objects you probably have a mass assignment problem. Also, if you are only blacklisting (possible in .NET MVC) or whitelisting the wrong columns, this could be a problem.

Where Developers Assumptions Go Wrong

When developers create web pages to update model objects they typically provide a subset of the model attributes as <input> fields in the HTML form page.

Assume that your ORM entities include Customer and Profile:

@Entity

public class Customer {

private long id;

private String fname;

private String lname;

@OneToOne

private Profile profile;

…

//public getter and setters omitted for brevity

}

@Entity

public class Profile {

private long id;

private String username;

private String password;

private String role;

private String publicKey;

//public getter and setters omitted for brevity

}

The corresponding HTML form that updates the Customer information looks like:

…

</form>

The developer makes an assumption that user will not know the schema of the database or attributes of the model object which are updated by the <form> above. The problem is that database schema information is leaked in the other pages of the application from input name attributes or can be guessed (password, role, etc.). So an attacker could create additional parameters to the form post such that the request would look like the following:

…

</form>

The attacker may update an existing profile (change another user’s password) or add a new record (in the profile table) with attacker controlled values or update any arbitrary field in the customer table.

Addressing the Problem

Make sure you whitelist the request parameter names used to update model objects. Or utilize one of the following secure model binding mechanisms:

Framework	Secure Model Binding Mechanism
Rails	attr_accessible
.NET MVC	[Bind(Include=”columnName”)] and [Bind(Exclude=”columnName”)] attributes
Grails	Grails-safebindable plug-in
Spring MVC	DataBinder.setAllowedFields()
Other Frameworks(Struts 1 & 2, etc.)	Avoid request bound model objects

With the other frameworks, it is probably better to not use model objects as request bindable objects. Instead, manually copy over the values until these frameworks come up to speed with implementing a solution.

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.

Browser Based Reflected XSS Protections

Sun, 26 Feb 2012 07:11:08 -0800

Reflected XSS is one of the most prevalent and dangerous web application vulnerabilities in the last decade. Where most injection vulnerabilities attack the server, reflected XSS injects data in to the browser itself. The root cause of XSS is in the application code and it should be there fixed too. However, some instances of XSS are really hard to detects and websites like xssed.com proof that there are still a lot of the vulnerabilities in high profile websites. As such, additional protection mechanisms are always welcome. Recently, browsers improve their protection mechanisms against XSS.

Internet Explorer 8 has a built-in XSS filter that tries to intercept XSS attempts. "The XSS Filter, a feature new to Internet Explorer 8, detects JScript in URL and HTTP POST requests. If JScript is detected, the XSS Filter searches evidence of reflection, information that would be returned to the attacking Web site if the attacking request were submitted unchanged. If reflection is detected, the XSS Filter sanitizes the original request so that the additional JScript cannot be executed." – MSDN [1]

Like ASP.NET RequestValidation, IE8 XSS filter is based on black listing. It is very easy to use, and there is nothing to configure except to turn it on or off. As all complicated things that are simplified to an on-off switch, reports say it is not 100% accurate. The mechanism may accidentally block something it shouldn’t block [5].

Firefox has implemented a similar black-listing XSS filter but the mechanism is currently backed out for further testing [4]. At the moment, if you are using Firefox and want to use the XSS filter, you can install the popular open-source NoScript add-on which, in addition to the ability to en/disable scripts on a per-domain basis, provides some anti-XSS protection even when scripts are enabled.

In addition, Firefox 4 implemented a new XSS protection based on white listing. Firefox 4 uses Content Security Policy (CSP) [6] [7] [8] to quickly identify and block XSS attempts by using the server headers to identify the content it expects. As a consequence, the mechanism knows which content to block based on its lack of adherence to the server's own CSP. For example, the following HTTP header specifies images that can be loaded from anywhere and scripts that can only be loaded from ‘self’ or “scripts.com”.

X-Content-Security-Policy: default-src 'self'; img-src *; script-src scripts.com

CSP is still just a W3C draft. The strongest XSS protection offered by CSP would require websites to migrate all inline JavaScripts to external files which is challenging and time-consuming. However, if implemented correctly, CSP can protect more than just Reflected XSS. Vulnerabilities like Persistent XSS and Click-Jacking can then also be protected by CSP. For now, I believe blacking listing XSS filter will continue to provide a more effective browser based reflected XSS protection.

References

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.

Valentine's Hacker

Tue, 14 Feb 2012 00:00:00 -0800

This is just a joke. But if your system allows users to lock your resources, you should limit the number of items and the period time a user is allowed to lock.

Happy Valentine’s Day :)

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.

Web Server DoS by Hash Collision

Wed, 4 Jan 2012 06:53:44 -0800

For efficiency reasons, most web servers store the request parameters in a hash table. However, when a request contains many parameters, say 10000 parameters, and the hash values for the parameter names are all the same, then the web server will spend a lot of time parsing the request. In such scenario, the hash insertion is very slow because of hash collisions. Some people wrote about this before, but nobody really knew how to generate a large amount of multi-collision strings, until Dec 28th...

“alech” and “zeri” pointed out that most String hashing functions are either based on DJBX33A or DJBX33X algorithms which are vulnerable to “Equivalent substrings” and “Meet-in-the-middle” attacks respectively. DJBX33A has the property that if two strings collide, e.g. hash('ABC') = hash('XYZ'), then hashes having this substring at the same position collide as well, e.g. hash('prefixABCpostfix') = hash('prefixXYZpostfix'). Therefore, you can easily generate infinite number of collided strings by something like “ABCABC”, “ABCXYZ”, “XYZABC”, etc. DJBX33X is not vulnerable to “Equivalent substrings” attack but is vulnerable to “Meet-in-the-middle”. By using “Meet-in-the-middle”, an attacker can get collided strings with probability of around 1/2^16, which can easily be searched. By using these techniques, “alech” and “zeri” are able to DoS the following servers:

Server Name	Result
PHP	70-100kbit/s to keep one i7 core constantly busy Gigabit connection can keep about 10,000 i7 cores busy
ASP.NET	30kbit/s to keep one Core2 core constantly busy Gigabit connection can keep about 30,000 Core2 cores busy
Java Tomcat6	6 kbit/s can keep one i7 core constantly busy Gigabit connection can keep about 100,000 i7 cores busy
Python (32bit only)	20 kbit/s can keep one Core Duo core constantly busy Gigabit connection can keep about 50,000 Core Duo cores busy.
Ruby	850 bits/s can keep one i7 core busy Gigabit connection can keep about 1,000,000 i7 cores busy

Status:

Microsoft released a patch (MS11-100) on Dec 29th. The patch adds a new ASPX config parameter “aspnet:MaxHttpCollectionKeys”, default value is 1,000.
Tomcat released 7.0.23 and 6.0.35: new configuration parameter “maxParameterCount”, default value is 10,000.
PHP released 5.4.0 RC4: new “max_input_vars” directive to prevent attacks based on hash collisions.

As it is not always possible to upgrade to the latest application server, it is still possible to patch your application server by writing custom rule in a product like HP Fortify RTA.

References:

Original Paper http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf
n.runs-SA-2011.004 Advisory http://www.nruns.com/_downloads/advisory28122011.pdf

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.

Application Frameworks and Static Analysis (Part Zwei)

Fri, 9 Dec 2011 00:00:00 -0800

Last week you learned about some of the more advanced features in SCA and how they are used to support and identify vulnerabilities in application frameworks. We also discussed dataflow analysis. But dataflow analysis is not sufficient to adequately cover application frameworks. One has to look at the application framework with a discerning eye and identify vulnerabilities in the framework which are specific to the use of that framework. This week we will shift gears and start looking at framework specific vulnerabilities.

Framework Specific Vulnerabilities (Error Prone APIs)

Framework specific vulnerabilities relate to coding constructs or security holes which are created by well meaning developers (usually in the name of productivity enhancements) which allow a new and . Struts 2 has the following: over exposed request bound objects, inconsistent model on the value-stack, value-stack shadowing, file upload DOS, file disclosure, blended threats, default stack vulnerabilities, under inclusive exception handling, exposed *Aware interfaces, exposed methods (most privilege), framework specific race conditions, OGNL script injection, and file download vulnerabilities.

I obviously cannot go through all of the vulnerabilities identified above but let’s look at framework specific file disclosure.

Framework Specific File Disclosure

Framework specific file disclosure is a vulnerability where an attacker can download any file that is part of the application, remotely or execute files are the server remotely. The files that are downloadable are configuration files (web.xml, applicationContext.xml, default.properties, etc.), jar files (any jar files in the WEB-INF/lib directory), and class files (any class under the /WEB-INF/classes directory). It was originally discovered in a constructor argument to Spring MVC’s ModelAndView(…) object by Ryan Berg and Dinis Cruz (http://o2platform.files.wordpress.com/2011/07/ounce_springframework_vulnerabilities.pdf). Ryan and Dinis had discovered this vulnerability in the Spring MVC framework but this is a serious vulnerability which exists in many MVC frameworks. Here is what the vulnerability looks like across different frameworks:

//Struts 1.x given you are in an Action method …

String dest = request.getParameter(“url”);

return ActionForward(dest);

//Struts 2.x which is a bit more complicated because it includes the

//configuration file below

Public class ProcessOrderAction {

Private String dest;

//public getter and setters omitted

…

//Struts 2.x configuration file

…

<%-- in a Struts JSP page --%>

<s:include value=”${param.dest}” />

<%-- in a JEE JSP page --%>

<jsp:include page=”${param.dest}” />

<jsp:forward page=”${param.dest}” />

//Spring 3 annotated method

@RequestMapping (“/processOrder”)

public String processMyOrder(@RequestParam String dest, @RequestParam String id, @ModelAttribute Order order) {

…

return dest;

//In a servlet

String dest = request.getParameter(“dest”);

RequestDispatcher rd = request.getRequestDispatcher(dest);

rd.forward(req, res);

I could go on and on but you get my drift.

To exploit this vulnerability you can either pass in the full path to the file you want or utilize path parameters.

When the dest is directly being used you can pass in:

http://www.yourserver.com/webApp/logic?dest=/WEB-INF/web.xml

In other cases you may need to pass in

http://www.yourserver.com/webApp/logic?dest=forward:/WEB-INF/web.xml

and finally you may need to pass in

http://www.yourserver.com/webApp/logic?dest=../WEB-INF/web.xml;test=

this is due to the funny way Spring MVC resolves views.

If you return a string from a @RequestMapped method it will pass the string to an InternalResourceViewResolver. A typical view resolver is configured as follows:

</bean>

The way this works is that the string returned from a request mapped method is pre-pended with the prefix and post-pended with the suffix. So if “processOrder” is returned from:

//Spring 3 annotated method

@RequestMapping (“/processOrder”)

public String processMyOrder(@RequestParam String dest, @RequestParam String id, @ModelAttribute Order order) {

…

return “processOrder”;

…

Then the request is forwarded to “/WEB-INF/jsp/processOrder.jsp”.

To subvert the prefix and suffix the attacker can use path parameters. Path parameters are parameters passed in after the “;” (semicolon) in a URL.

So the attacker can return “../web.xml;test=x” which will forward the request to:

/WEB-INF/jsp/../web.xml;test=x.jsp

This request returns the web.xml file in the browser and test=x.jsp is treated as a path parameter.

If you see the following and think you are safe then you would be wrong depending on the app server you are running:

return new ActionForward(“/WEB-INF/jsp/someFile.jsp?param=” +

req.getParameter(“input”) );

Normally an attacker would not be able to exploit this as a file disclosure but if the application was running on certain versions of tomcat an attacker could still successfully carry out the file disclosure attack even if only appending a request parameter value.

According to CVE-2008-2370, “Apache Tomcat 4.1.0 through 4.1.37, 5.5.0 through 5.5.26, and 6.0.0 through 6.0.16, when a RequestDispatcher is used, performs path normalization before removing the query string from the URI, which allows remote attackers to conduct directory traversal attacks and read arbitrary files via a .. (dot dot) in a request parameter.”

So the attacker could pass in “/../../web.xml” and the web.xml would be displayed as the URL would look like the following:

/WEB-INF/jsp/someFile.jsp?param=/../../web.xml

Which gets canonicalized down to:

/WEB-INF/web.xml

But you may say, “What is the big deal if I reveal some configuration files especially if there is no confidential data in them.” There are two reasons why the file disclosure is especially bad: 1. The attacker can download your intellectual property including class files and jar files within your application. 2. This attack can be combined with a file upload vulnerability (as a server side blended attack) to allow an attacker to execute arbitrary system level commands.

The book, Struts 2 Design and Programming: A Tutorial by Budi Kurniawan provide a file upload example code similar to the following:

public class FileUploadAction extends ActionSupport {

private File attachment;

private String attachmentFileName;

private String attachmentContentType;

public String upload() throws Exception {

ServletContext sc = ServletActionContext.getServletContext();

String uploadDir = sc.getRealPath(“/WEB-INF”);

uploadedDir = uploadedDir + “/uploadedFiles”;

File savedFile = new File(uploadedDir, attachmentFileName);

Attachment.renameTo(savedFile);

}

I tried getting “..\” into the attachmentFileName without success because the “..” were getting filtered by the Apache Commons File Upload component. So if we assume that you could NOT do a path manipulation attack, why is this code important to the file disclosure vulnerability?

…

What if an attacker could upload a JSP file with the following body:

// From body of commandProxy.jsp

Runtime rt = Runtime.getRuntime();

rt.exec(request.getParameter(“osCommand”));

Then the attacker could use the file disclosure vulnerability in the following way.

http://www.yourserver.com/webApp/logic?dest=/WEB-INF/uploadedFiles/commandProxy.jsp?osCommand=rm%20–rf%20*

The attacker now has the ability to pown your server.

Conclusion

I have only scratched the surface as to researching and exploiting application frameworks. All of the vulnerabilities I described above can be found with the static analysis rules I described above. I hope I highlighted why you can count on Fortify to cover application frameworks and gave you insight into how we work. Some of the rule scripting techniques I described are currently only supported for internal use, however plans are in the works to expand the custom rules documentation to put the power of rules scripting into your hands. Once you see what you can do with custom rules and scripting, prepare yourself to be amazed.

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.

Misunderstandings on HttpOnly Cookie

Wed, 2 Nov 2011 07:47:59 -0700

HttpOnly Cookie is nothing new, it was first introduced by Microsoft back in 2002 when it released IE 6 SP1. Of course I don't think HttpOnly alone can solve all XSS problems but I believe it is a useful feature if used correctly. And while I don't think we can set every cookie with HttpOnly flag, at least we should set it on all session cookies whenever possible. However, statistics [1] show that only about 9% of websites use HttpOnly cookies. I don't know exactly why the usage rate is so low, but I think it may be related to the following misunderstandings:

1) HttpOnly is only for IE

No.

According to Google's Browser Security Handbook ^[2] and OWASP ^[3], almost 99% of all browsers (the only exception is Android) support HttpOnly cookies.

Test description	MSIE6	MSIE7	MSIE8	FF2	FF3	Safari	Opera	Chrome	Android
Is httponly flag supported?	YES	YES	YES	YES	YES	YES	YES	YES	NO

2) On .NET platform, it's disabled by default

Yes and No.

For custom application cookies, you have to manually enable it, but for session cookies, it is enabled by default.

Starting from .NET 2.0 (which was released in 2005, three years after HttpOnly was introduced), all session cookies come with the HttpOnly flag, and you can't even disable it. When decompiling that part of .NET program code, you will see:

System.Web.SessionState.SessionIDManager
private static HttpCookie CreateSessionCookie(string id)
{
    HttpCookie cookie = new HttpCookie(Config.CookieName, id);
    cookie.Path = "/";
    cookie.HttpOnly = true; // <-- burned in, not configurable
    return cookie;
}

The <httpCookies httpOnlyCookies="true" …> in web.config is only for custom application cookies, not for session cookies.

3) Most Java Application Servers don't support HttpOnly cookies

No.

But it is true that Java's support for the HttpOnly flag is very slow. There was no setHttpOnly() method in javax.servlet.http.Cookie until Java EE 6 (Servlet API 3.0) which was just released in December 2009. However, this doesn't mean application servers can't support HttpOnly without Java EE 6.

Type	Support HttpOnly Since	Comment
Tomcat	5.5.28^[4] or 6.0.20	Default "false" for 5.5.28 to 6.0. Default "true" for 7.0+
JBoss^#	6.0	Servlet 3.0, default "false", config via web.xml <cookie-config>
WebLogic	9.2 MP4^[5]	Servlet 2.4, default "true"
WebSphere^##	8.0^[6]	Servlet 3.0, default "true", can config via console as well

#: According to OWASP ^[3], JBoss 5.1 supports HttpOnly by using Context.xml (similar to Tomcat 5.5), but I can't make this work.
##: According to IBM ^[7], the custom property addHttpOnlyAttributeToCookies on WAS 6.1 and 7.0 does not affect every cookie that passes through the application server. The list of non-HTTPOnly cookies includes JSESSIONID cookies.

Summary

As you can see, many application servers already support HttpOnly cookies, some even set the HttpOnly flag on session cookies by default. The risk of setting HttpOnly flag on session cookies should be pretty low, and the steps for enabling it are not difficult. Therefore, if your web application is running on a “supported but default false” application server, such as Tomcat 6.0, you should enable it.

References:
[1] http://w3techs.com/technologies/details/ce-httponlycookies/all/all
[2] http://code.google.com/p/browsersec/wiki/Part2
[3] https://www.owasp.org/index.php/HTTPOnly
[4] http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
[5] http://download.oracle.com/docs/cd/E13222_01/wls/docs92/webapp/weblogic_xml.html#wp1071982
[6] http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/index.jsp?topic=/com.ibm.iea.was_v8/was/8.0/Security/WASv8_SecurityEnhancements/player.html
[7] http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg27004980

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.

Cyber Security and Kids

Mon, 26 Sep 2011 13:42:47 -0700

As a parent I worry every day about keeping my children safe. As schools and education increasingly becomes more dependent on the internet, cybersafety is a concern which has plagued many parents, including myself.

Each new school year - parents, schools and many volunteer organizations spend a lot of time and resources to review and remind the kids on how to be aware and safe from the various dangers that they may face. From bike safety to playground safety to bullying to drug and alcohol awareness. It struck me that there is not enough taught to kids about online safety and this has to change. The safety issue starts as early as elementary school, as more and more schools are getting connected and the internet begins to play a crucial role in our children's education.

With every new school assignment I find myself loosening the parental controls that I have set on their computer accounts. As I struggle to find the right balance between giving my kids access to what the internet has to offer and keeping them safe, I realize that I cannot isolate them from the dangers that lurk in cyberspace. It seems inevitable that they will at some point encounter a malicious link or website and the best I can do as their parent, is to educate them on cybersecurity and cybersafety.

A great set of resources, tools and age appropriate materials that I recently found to help me get started was on C-SAVE or Cyber Security Awareness Volunteer Education website. Part of the NCSA(National Cyber Security Alliance), it is designed to encourage and support professionals to volunteer their time to bring cybersecurity awareness to as many children as possible. I am hoping to share this at our school, in October, as part of the National CyberSecurity Awareness Month and would like to encourage as many of you as possible to do so as well.

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.

The Perils of Encodings

Thu, 15 Sep 2011 22:47:31 -0700

Encodings are something that we usually take for granted in our daily lives. All of our files use it when we save files to the file system. Our web applications use it determine how to receive and send data for each HTTP request. Our browsers use it to determine how bytes should be converted to characters when receiving the HTTP response. But most of us don’t understand the implications of using encodings incorrectly or not at all. The first case in point would be converting between Strings and byte arrays.

Converting Strings to Bytes and Vice Versa

If you look across the web for samples of how to code encryption you will see the following many times:

static string GenerateKey()

{

// Create an instance of Symetric Algorithm. Key and IV is generated automatically.

DESCryptoServiceProvider desCrypto

=(DESCryptoServiceProvider)DESCryptoServiceProvider.Create();

// Use the Automatically generated key for Encryption.

return ASCIIEncoding.ASCII.GetString(desCrypto.Key);

}

Similar code is all over the Web because the code came from Microsoft’s Security Patterns and Practices as well as MSDN’s articles on doing cryptography. If .NET developers are following Microsoft’s guidance then we are looking at a lot of potentially vulnerable (in hours not years) encrypted data. Here are the links to the MSDN articles:

http://support.microsoft.com/kb/307010

http://support.microsoft.com/kb/301070

Asides from the fact that DES is a broken algorithm can you spot the vuln? Hint it has to do with encodings.

Well if you guessed:

return ASCIIEncoding.ASCII.GetString(desCrypto.Key);

Ding…Ding…Ding. Give that person a cigar.

Running a randomly generated key through ASCIIEncoding.ASCII.GetString(…) will convert bytes outside range of 0-127 to char(63) which is the ?. The other bytes will get converted to characters within the 0-127 range. Making the mistake above would result in a key where half of the characters were question marks and the other half of the characters were limited to half of their byte key space. To put this into perspective, most encryption keys are 128 bits (16 bytes) however the DES example above uses 64 bit keys with a parity bit used in each key byte resulting in a 56 bit effective key size. After following the advice above, an AES 128 bit key turns into a 56 bit key (128/2 = 64 bits because half of the key is turned into question marks, then the remaining 64 bits or 8 bytes have their 8^th bit turned off which results in a 64 - 8 = 56 bit effective key size) and the DES key, from the example above, turns into a 28 bit effective key size (64/2 = 32 – 4 = 28 bits because the 4 bytes that were not turned into question marks have 0 as the 8^th order bit). Recent experiments have shown 56 bit keys to be breakable in hours. If you are a .NET developer and have relied on MSDN articles for guidance on how to do encryption I would strongly suggest that you revisit your encryption code.

If you are thinking of changing the errant code above to:

return UnicodeEncoding.UTF8.GetString(desCrypto.Key);

because you think that UTF8 (Unicode Transformation Format) should be able to represent all characters then you will be right and wrong with basically the same result. UTF8 can represent every character in existence and could be modified to support extra terrestrial character sets, but the encoding rules are going to trip you up if you try the code above as a replacement.

Remember that a crypto key has to be truly random. Whereas UTF8 encoded strings have to follow a strict bit encoding pattern to identify characters.

To summarize UTF8 semantics:

If the character is an ASCII character it will start with a 0 bit because every byte holds 8 bits and 0-127 can fit into 7 bits. So the bit sequence looks like:

01xxxxxx

When you represent an ASCII character in UTF8 there is a direct one-for-one mapping. However the problem arises when you need to represent characters outside of the 0-127 range. The general rule is that the number of ones before the first zero in the bit pattern will tell you the number of 8 bit byte sequences that will make up Unicode character. Remember that this is highly simplified as there are also rules associated with combining Unicode characters to make new characters but that is not relevant here. So if you have a valid sequence of UTF8 bytes they will look like the following:

1110xxxx 10xxxxxx 10xxxxxxx 10xxxxxx …

The x’s above represent the bits used to identify the code point for the Unicode character (given that every character in existence is assigned a code point value or set of code point values).

What happens if you get a byte sequence like the following (which could easily occur in a random key)

1110xxxxx 01xxxxxx 01110xxx 0001xxxx …

Well it kind of depends on the UTF8 parser and interpreter. Some interpreters will ignore/drop the invalid sequences altogether as bad (high-lighted in red) while others may ignore the starter byte (assuming that it was an error) and continue processing the byte sequences as characters that it understands (underlined and indented above). In either case the key is significantly weakened.

So ASCII and UTF8 are Messed Up What about ISO8859-1 it’s an 8-bit Code Page

Pretty good that you suggested that but there are problems with this as well. Initially you might think that these are ok because they are code pages which represent all 8 bits as characters. When you convert from key bytes to characters you should not suffer the loss that you would under UTF8 or ASCII. However, the problem is that there are a number of other ISO8859-x (cp1252-cp125x) code pages which utilize different characters for the high order bit patterns (128-255) with overlap between the code pages. So if you store the characters as ISO8859-1 on one system them retrieve the characters as cp125x, the byte mappings will get messed up and your encrypted data will be corrupted or not decrypt properly because the encryption key becomes corrupted/altered.

Summary of the Problem

Another way of explaining the problem is that there is a disconnect between what encryption keys are and how they are being treated. Encryption keys are being treated as text when they are just a random number of bits. Text has to follow bit pattern rules defined by the code page they are being rendered in to ensure that they display correctly. Encryption keys should not follow any rules and should be as random as possible to protect against brute forcing. The only way I can explain the code above is that the MSDN code writer was looking for a way to store the encryption key in a format other than bytes.

So What The Heck Are We Supposed to Do?

You might think of writing the raw bytes directly to a text file but avoid this because character sets are implicitly used when writing to or reading from files. If the encryption key is written out to a file on a machine using one character set and later moved to a machine using a different character set, key bytes could become lost or corrupted when read from the alternate character set file system.

If you are generating a key for use in a cryptographic operation, set the key on the crypter from the generated bytes directly. If you have to store the key, then you can Base64 encode the byte stream after encrypting it. When you need to use the key, Base64 decode the key, decrypt it, and set the key directly as a byte array on the crypter.

For references on how the ASCIIEncoding object encoder works:

http://msdn.microsoft.com/en-us/library/system.text.encoding.ascii.aspx#Y1209

"The ASCIIEncoding object that is returned by this property might not have the appropriate behavior for your application. It uses replacement fallback to replace each string that it cannot encode and each byte that it cannot decode with a question mark ("?") character. Instead, you can call the GetEncoding method to instantiate an ASCIIEncoding object whose fallback is either an EncoderFallbackException or a DecoderFallbackException, as the following example illustrates."

http://www.dijksterhuis.org/encoding-c-strings-as-byte-byte-arrays-and-back-again/

"Solution #1 – Convert Unicode to ASCII / String to an ASCII Byte[]

If you intend to send only the most basic of messages which can be satisfied with just A-Z, a-z & 0-9 and a few other characters you can convert the C# string using the ASCII encoder. You will however lose any characters that are not defined by ASCII. So while this is a good idea if your application is only used in North America, the rest of the world will probably not thank you for this design decision."

Special thanks to Brian Chess for reviewing this post for content and clarity.

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.

Terminator vs. Hacker?

Sun, 10 Jul 2011 19:07:24 -0700

Terminator and Hacker are somewhat, similar, they both look cool and more important, they both come from future.

When we build an application, we build it today, fix all the vulnerabilities we know as of today. However, hackers will attack it tomorrow, or next week, or next year, with techniques that we may not even heard of or aware of as of today.

I initially worked for Fortify as a Security Consultant in Asia. And in 4 years, I only saw a few customers who have streamlined processes to handle applications in “maintenance” mode. The easy part is to setup a process using latest version of Fortify SCA with latest rules to scan “maintenance” applications on regular basis even if there is no change in the program code. But the difficult part is to make sure there is always “someone” responsible for taking appropriate actions, or fixing the code if needed.

The same logic applies to real-time protection as well. For instance, Fortify released a special runtime rule in February for Fortify RTA to protect Java applications from a new type of DoS attack. But unless you updated your rules, Fortify RTA won’t be able to stop hackers from using this attack to “Terminate” you.

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.