Off by On

Blog moved

Mon, 10 Dec 2012 13:33:37 -0800

Our blog moved to a new location. Check out http://www.hpenterprisesecurity.com/offbyone

150 ways to bypass ordinary WAF's but not ours, by design!

Wed, 8 Aug 2012 01:26:34 -0700

At BH US 2012, Ivan Ristic showed off a new tool called IronBee which contains 100+ possible ways to bypass WAFs. As he focused on getting past the open-source ModSecurity WAF, other ordinary open source and commercial WAF's fall obviously prey to these attacks too. By design WAFs try to protect on the wire, lacking all the context they need to achieve proper protection. Check out where the HP Fortify RTA solution is looking for malicious behavior and where ordinary WAFs are trying to protect.

In essence, for every piece of data in the request, a WAF has to decide if it let the data go through or not WITHOUT a clue where the data will be used. Common attack patterns are easy to spot, but when the data is encoded, encrypted, obfuscated and so on, a WAF will quickly miss something and that is exactly what Ivan is pointing out. It is so hard to know how to treat the data when it's not known how the data will be used in the application itself. By design, HP Fortify RTA does not have to go through the hassle of decrypting, decoding, normalizing and so on. RTA waits until the data is used in the application itself and will then interfere if the data is used in an inappropriate way. There is so much more context inside the application!

Understanding XSS (Cross-Site Scripting) Findings in SCA

Wed, 1 Aug 2012 12:00:00 -0700

In today’s post I am going to answer three questions that I am getting from a lot of users: 1. Why we report XSS issues when HTML encoding is applied to untrusted data, 2. Why SCA does not identify custom encoding methods, and 3. Why SCA does not understand the output context of untrusted data. I am NOT going to go into proper output encoding as it has been discussed in great detail at https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet and https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet.

It is easy to think you are immune to XSS because you are HTML output encoding your untrusted data but HTML encoding is just one of the encodings used to address XSS. XSS is a difficult problem to mitigate properly. You have to have proper input validation and contextual output encoding (i.e. HTML encoding, URL encoding, HTML Attribute encoding, CSS encoding, and Script encoding in their appropriate contexts).

Why Doesn’t HTML Encoding Mitigate XSS in All Contexts

You would think that HTML encoding in a URL context or JavaScript event handler would work fine to mitigate XSS because the parser in a JavaScript event handler or URL context would not understand HTML encoding and therefore the attack payload would fail. However, this is not the case because the browser decodes HTML-encoded content in an URL or JavaScript event handler at runtime.

All of the following are still executable even though the output is HTML encoded

HTML encoding in a URL context (the payload is “javascript:alert(123)”):

<a href=” javascript:alert(123)”>Click Me</a>

HTML encoding in a JavaScript event handler (the payload is “javascript:alert(123)”):

<a href=”#” onclick=” javascript:alert(123)”>Click Me</a>

If your application is outputting XHTML then the following will still pop even though all of the javascript code is HTML encoded (the file extension must be *.xhtml or the content type has to be set to "application/xhtml+xml"):

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<script type="text/javascript"> alert(11)</script>

</head>

<body>

<div>TODO write content</div>

</body>

</html>

So HTML encoding will not mitigate XSS in all contexts and cannot be trusted as a complete solution to XSS. First question down, let’s move to the second question.

Why SCA Doesn’t Identify Custom Encoding Methods

Identifying custom encoding methods is very difficult from a practical perspective. There are many ways to implement a custom encoding method and the selection of characters to encode varies based on the implementation and context in which the untrusted data is to be output. For example, some encoding implementations believe <, >, ‘, “, and & are sufficient to mitigate against XSS in an HTML context. Other implementations only encode < and >. While others encoders add other characters including \ and /. Furthermore, each encoding context has multiple ways of encoding. HTML can used decimal or hexadecimal values. JavaScript encoding can use hexadecimal, octal, backslash, or Unicode encodings. To find such constructs would require the implementation of a new source code analyzer and would significantly prolong scan times. So trying to determine custom encoding methods is a difficult task with limited returns.

If you have a custom encoding method that you trust to stop XSS and it is applied in the appropriate contexts, then you can write a pass through rule which adds the following taints: +VALIDATED_CROSS_SITE_SCRIPTING_REFLECTED, +VALIDATED_CROSS_SITE_SCRIPTING_PERSISTENT, +POORVALIDATION.

Here is a sample rule which addresses the HTML context:

…

<TaintFlags>+VALIDATED_CROSS_SITE_SCRIPTING_REFLECTED,+VALIDATED_CROSS_SITE_SCRIPTING_PERSISTENT,+POORVALIDATION</TaintFlags>

…

<Pattern>encodeForHTML</Pattern>

</FunctionName>

</FunctionIdentifier>

<OutArguments>return</OutArguments>

</DataflowPassthroughRule>

The VALIDATED_* taints remove the findings that move through the encoding function from the Reflected and Persisted XSS findings. The +POORVALIDATION will move all of the findings that were going through the custom encoding method to a new category called XSS: Poor Validation. The findings in XSS: Poor Validation are the dataflows which should be quickly skimmed to make sure that the correct encoding is being applied in the correct context. The purpose of this is to allow you to quickly segregate the XSS findings with no encoding from the XSS findings with some encoding. But this leads to another question, “Why can’t we identify the context that untrusted data is being output to more intelligently identify exploitable vulnerabilities?”

Why SCA Doesn’t Understand the Context in which Untrusted Data is Output

This is another question I often get and again the answer is that it is difficult to do without explicit control of where the data is being written to and the encoding which is applied to the output at that location.

Lets take a look at an example to better illustrate the difficulty of the problem:

…

function callFunc(input) {

document.write(input);

}

</script>

What context do you think untrusted_var is in? Well when you look at where the entrusted data is output you might guess that because untrusted data is output in a “style” attribute it is in a CSS context. Wrong.

How about the URL context because of the call to the CSS url() function. Wrong.

How about JavaScript context because of the “javascript:”? At first glance, you would be technically correct but does JavaScript encoding mitigate this XSS? JavaScript encoding does stop the attacker from escaping out of the quotes (injecting up) but when the data is passed to the callFunc() and output using document.write() the XSS pops. As you can see, trying to figure out the output context is a non-trivial task.

Conclusion

I hope you now understand why HTML encoding does not mitigate XSS in every context and why we move those findings to XSS: Poor Validation, why SCA does not automatically try to identify encoding methods, and why we don’t try to determine the output context. As technologies change and improvements in the underlying platform occur, we will revisit these issues to hopefully come up with improved solutions. Until then, keep the faith and keep plugging away.

Format Strings: Is Objective-C Objectively Safer?

Wed, 25 Jul 2012 12:00:00 -0700

With the explosion of mobile devices came mobile applications, and with the mobile applications came a plethora of new security and privacy concerns. If you've been following this blog or our products, you probably know that we just released our first Objective-C rulepacks, with a lot more support planned in the future. To kick things off, let's talk about one of the vulnerabilities that our Objective-C rulepacks can detect: format string flaws.

A common misconception is that Objective-C is a newer language compared to C and C++, and is therefore immune to many of the classic C vulnerabilities such as buffer overflows. In the C and C++ world, one cousin of the well-known buffer overflow exploit is format string attacks. Since Objective-C also supports format strings, does that mean that its applications are vulnerable as well? Let's first review how C/C++-style format string attacks work, then compare these to what Objective-C lets us do.

A string format function, such as printf(), takes in a format string and a variable list of arguments. Normally (with the exception of the %n specifier—more on that later), the format specifiers in the string is replaced with the values of the respective arguments. What happens if there are more specifiers than there are arguments? For example,

   printf("%d%d%d%d%d\n", val);

C and C++ will gladly continue to pop values off the stack until it fills in every value for every format specifier. What if an attacker is able to control the format string? At best, the program will crash or function incorrectly due to the damaged call stack. At worst, it can reveal sensitive information stored in local variables or passed as arguments to functions.

The story gets worse. C and C++ support the %n specifier, which writes a value—namely, the number of bytes written thus far—back to the corresponding variable. By controlling the number of bytes written and storing the value of %n, we can write any value back to the stack, including the address of any attacker-controlled malicious code. (To avoid having to write millions of characters just to form a 32-bit address, we can instead write %n four times, a single byte at a time.) If we can also manipulate the stack to fool the program into treating the value as the return pointer, then we can force the program to run our malicious code—not unlike a buffer overflow exploit.

So how much of this applies to Objective-C? The good news is that format string methods introduced by Objective-C do not allow the %n specifier, so there are no known ways to execute arbitrary code using format strings. The bad news is that Objective-C attempts to be backwards-compatible with C/C++ libraries, continuing to allow the old %n-style code execution exploits.

Nonetheless, even for the newer Objective-C-specific format string methods, using excess format specifiers to pop values off the stack still works:

   void myfunc(NSString *in) {
       NSLog(in);
       NSLog(@"Inside myfunc");
   }

   int main(int argc, char *argv[])
   {
       NSString *test = @"%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x\n%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x\n";
       myfunc(test);
       return NSApplicationMain(argc,  (const char **) argv);
   }

The output is as follows:

   (gdb)
   2012-02-13 22:12:12.525 objc[12983:a0f] 5fbff860.5fbff870.5fbff928.00000012.00000000.00000000.00002070.5fbff840
   000017e8.5fbff860.00000000.5fbff848.00002070.5fbff850.00001784.00000000
   (gdb) info args
   in = (NSString *) 0x100002070
   (gdb)

Note the address of the string test, 00002070, gets printed twice in the output, presumably because it is passed twice as an argument—once to myfunc, and again to NSLog. I should also note that in constructing the above test code, the program has also crashed several times with an EXC_BAD_ACCESS signal, further suggesting that the format string is corrupting the stack pointer.

I hope the above evidence is convincing enough to show that Objective-C does not perform any safety checks on format strings, letting them manipulate the call stack easily. The next reasonable question, how exactly can this be exploited? What might vulnerable code in an application look like? Consider the following code snippet:

    - (BOOL)application:(UIApplication *)application
            openURL:(NSURL *)url
            sourceApplication:(NSString *)sourceApplication
            annotation:(id)annotation {
        // Write to debugging log
        NSLog(@"++ Entered application");

        NSString *urlquery = [url query];
        NSLog(urlquery);
        ...
    }

This is one of the most common mistakes when using NSLog, which in turn can lead to a format string vulnerability. According to the official documentation, NSLog()'s first parameter is not a simple string, but in fact a format string. A rogue (or compromised) process might take advantage of this vulnerability by launching the app via its registered URL scheme and supply a URL with extraneous format specifiers. When the program reaches the line NSLog(urlquery), the NSLog() method now expects the values to fill in for these specifiers. It does this by gladly reaching backwards into the call stack, which corrupts the state of the stack. This causes the rest of the program to run incorrectly or eventually crash.

So in short, while Objective-C format strings manage to avoid some of the more heinous exploits that allow for arbitrary code execution, they are still vulnerable to stack manipulation. Attackers can still crash your program at best, and dump sensitive data at worst. Avoid using legacy C/C++ format string methods if possible; these are still vulnerable to the code execution exploits of old. In general, be careful when working with format strings; always make sure there are equal numbers of format specifiers and arguments. More importantly, do not let sources outside of your control, such as data and messages from other applications or web services, control any part of your format strings.

Presenting “Code Reviewing Web App Framework Based Applications” at Blackhat

Tue, 17 Jul 2012 08:58:43 -0700

For those of you going to BlackHat, I am running a 3-hour work shop on Code Reviewing Web App Framework Based Applications on July 25 from 2:15-5:15 in Florentine.

Frameworks have often been viewed with disdain in the security community. Often times you are just getting to know the in’s and out’s of the current web framework when developers decide to switch to another one with more development features. And just your luck, each successive framework is larger and more complicated than its predecessor; often times written in a totally different language. It is a bit over whelming as a security practitioner to have to pick up the new framework and language by yourself while having to find vulnerabilities. The 3 hour workshop that I am giving aims to give you an introduction to the most popular web frameworks in use by enterprises (Struts 1 and 2, Spring MVC, .NET MVC, Ruby on Rails, and to a lesser extent Groovy on Grails and Zend PJHP). In addition, we will go over an overall process of code reviewing applications built on web frameworks and help you identify common vulnerabilities associated with them.

Here is a high level preview of what is going to be covered:

1. Architectures of the web frameworks.

a. Architecture relates to the big picture of how different components within the framework work together with your application’s business logic to handle a request.

2. Dataflow paths through individual web frameworks.

a. In order to effectively prioritize findings a code reviewer needs to be able to trace sources of untrusted data to the sinks (points where vulnerabilities can occur).

3. Recognizing the language and framework constructs that can lead to vulnerabilities.

4. Discuss non-dataflow based vulnerabilities in framework-based applications.

a. Some examples of this are understanding where password management, authorization, and authentication logic usually reside.

5. Discuss inter-framework dependencies.

a. Often times web framework based applications are built on or actively utilize other frameworks. These other frameworks can introduce separate exploitable vulnerabilities when used within the web app framework.

6. Review combined and server-side blended threats.

a. It is great to find vulnerabilities but we need to take a step back and see how individual vulnerabilities can interact with each other to create new vulnerabilities.

If you don’t attend the workshop but have questions about Fortify, I will be volunteering at the OWASP Booth Wednesday morning.

Are Race Conditions the New Buffer Overflows?

Wed, 11 Jul 2012 10:09:23 -0700

Way back in 2005 we worked with Gary McGraw to develop the Seven Pernicious Kingdoms -- an open taxonomy of software security errors -- that has been adopted by HP Fortify solutions ever since. At that time, we predicted that the Time and State kingdom would become one of the most prevalent classes of errors in coming years. The errors covered by this kingdom are those that result from unexpected interactions between threads, processes, time, and data and include issues such as deadlocks and race conditions. As applications have become increasingly complex and distributed, components must often share state in order to communicate with one another, which has led to a growing number of problems.

It seems that we were not far from the truth. With the widespread adoption of Web 2.0 technologies and a lengthy list of web frameworks, asynchronous execution and keeping track of state have become key features of modern applications. The use of asynchronous communication seems to inevitably lead to race conditions.

Our hypothesis is also supported by the amount of research interest recently given to the topics related to time and state. If you look through the list of papers accepted to the most prestigious programming languages conference PLDI 2012, you will notice that there are a number of papers on such topics as concurrency, thread safety, and parallelization – all of which are directly related to time and state. One of the papers -- Race Detection for Web Applications -- looks especially interesting to us. The paper distinguishes between four different types of races:

Standard data races on JavaScript memory locations,
HTML races,
function races, and
event dispatch races.

The paper also defines the "happens-before" relation and a data access model, and describes a dynamic race detector tool built on top of WebKit. The authors used the tool on 100 real-world websites and found a number of real race conditions that result in runtime exceptions and crashes, so the results are quite promising.

While detecting time and state issues statically is definitely a challenge, doing so at runtime seems to have a lot more potential and opens up the field for more research opportunities with respect to both discovery and detection of time and state vulnerabilities. Let's see if the trend we predicted seven years ago will continue. I think it will.

PCI DSS 2.0 Support Handles Change from Best Practices to Requirement

Mon, 25 Jun 2012 07:00:00 -0700

The Payment Card Industry (PCI) Data Security Standard (DSS) 2.0 is now approaching the deadline of June 30^th, 2012 when two requirements, 6.2 and 6.5.6, will be switched from best practice to being required. This is an important consideration for companies who need to obtain and maintain PCI compliance. Requirement 6.2 requires a process to be in place for identifying and assigning a risk ranking to newly discovered vulnerabilities. Requirement 6.5.6 is intended, as part of a set of requirements, to ensure that the development of applications follow secure coding guidelines which consider newly identified “high” risk vulnerabilities in accordance with requirement 6.2.

The recently updated PCI support built into HP Fortify products handles these requirements and other recent changes in the PCI standard. According to requirement 6.2 a risk ranking system should be based upon industry best practices, with examples given for both vulnerabilities having a CVSS score of 4.0 (or above) and issued critical vendor patches. These two examples are for systems which are already in production; however, during the development lifecycle PCI DSS 6.5 comes into play with requirement 6.5.6 addressing requirement 6.2 (new high risk vulnerabilities). Risk ranking systems for security issues at the code level (risk = impact · likelihood), such as the one put forth in “Prioritizing Static Analysis Results” by Brian Chess and Jacob West, are needed to quantify suspected vulnerabilities during development and testing (impact is a measure of the negative impact resulting from a given vulnerability while likelihood is the probability that the impact will come to pass). Using the prioritization formula above all issues reported by HP Fortify products are assigned a Fortify Priority Order of one of the following: Critical, High, Medium, and Low.

For compliance, HP Fortify considers all issues with a Fortify Priority order of “Critical” or “High” to meet PCI DSS 2.0 requirement 6.5.6. Examples of older issues that would otherwise be ignored, without support for 6.5.6, include the following (see http://vulncat.fortify.com for a description):

Denial of Service (which was once handled by PCI DSS 1.1 requirement 6.5.9)
Privacy Violation: Social Security Violation
Unreleased Resource: Database
Null Dereference

Newer vulnerability classifications, such as those related to mobile security, which are not yet addressed by PCI are also addressed by our approach (e.g. Android Bad Practices, Privilege Management).

In our more recent editions of HP Fortify SSC we have included reporting tools for PCI DSS 2.0 compliance which support requirement 6.5.6 and the other software relevant portions of the standard. These reporting features categorize security related issues by their PCI DSS requirements and assist companies by identifying high risk security issues in the code which need to be addressed for PCI compliance.

Reference documentation: https://www.pcisecuritystandards.org/security_standards/documents.php

Software Security and ABAP ?

Mon, 11 Jun 2012 11:53:54 -0700

I have recently been spending some time researching and expanding our existing support for ABAP.

What is immediately evident is that even today most of the time and money spent in securing SAP systems revolves around authorization checks, single sign-on, SSL, segregation of duties and other security features. As important as these components are, it only tells half the story. Very little is being said and done about securing these systems at the application level.

Initially, this was not as big a concern, as most of the SAP systems were internal to the enterprise. But with other software systems, as they established an online presence, ABAP applications were found to be vulnerable to the same attacks that have plagued Java and other web applications for years.

In this blog post, we will look at how some ABAP vulnerabilities parallel common Java vulnerabilities.

Cross-Site Scripting

A simple example of a cross-site scripting attack in Java would look like:

<%String eid=request.getParameter("eid");%>

...

Employee ID : <%eid%>

An equivalent cross-site scripting attack in ABAP would be for the form:

eid = request->get_form_field('eid').

...

response->append_cdata('Employee ID:').

response->append_cdata('eid').

In both these cases unvalidated input, from the web or web related sources, that could contain malicious code is reflected back to the user and will be executed by the web browser as it displays the HTTP content.

The following two vulnerabilities similarly occur when tainted data from the web or web related sources finds its way to vulnerable ABAP APIs.

Command Injection

Just as java.lang.Runtime.getRuntime().exec(cmd) is vulnerable to tainted data resulting in command injection vulnerability so is the following ABAP command.

CALL 'SYSTEM' ID 'COMMAND' FIELD cmd.

The above is a system call to the ABAP kernel to execute an operating system command. Attack vectors containing tainted data that can find dataflow path to the cmd parameter can now compromise the SAP system.

Path Manipulation

An equivalent to Java's file system calls, such as java.io.File(), that are vulnerable to Path Manipulation attacks, in ABAP is:

OPEN DATASET <dsn> FOR OUTPUT.

Unvalidated input that makes it way to the <dsn> parameter allows an attacker access to modify or delete system files.

These simple examples show that SAP systems are not inherently any more secure then other web applications. And as SAP systems hosting business critical applications move online, SAP applications should be held to the same software security reviews and standards as other web applications.

Q2 Update from HP Software Security Research

Fri, 1 Jun 2012 16:43:50 -0700

It is with immense pleasure that we announce the first combined update from HP Software Security Research to support both HP WebInspect and HP Fortify solutions. The release includes new versions of the Fortify Secure Coding Rulepacks (Fortify SCA), Fortify Runtime Rulepack Kits (Fortify SecurityScope and RTA) and WebInspect SecureBase (WebInspect). Features include:

HP WebInspect SecureBase: SecureBase combines checks for thousands of vulnerabilities with policies that guide users in identifying critical security vulnerabilities in web applications under test. Features added this quarter include:

Session Fixation: Identify and understand session fixation vulnerabilities in web applications.
HSQL/Informix SQL Injection: Extend SQL Injection support to HSQL and Informix databases.
HTML5 (CORS): The first in a series of related updates identifies 4 new categories of vulnerabilities in applications using Cross-Origin Resource Sharing capabilities.

Fortify Secure Coding Rulepacks: As of this release, the Fortify Secure Coding Rulepacks detect 526 unique categories of vulnerabilities across 21 programming languages and over 710,000 individual APIs. New features include:

Apple Objective-C: Support targets iOS applications and covers 32 categories, including 10 unique to the platform.
Google Android: Enhanced support for content provider permissions, NFC API, and 7 new categories.
HTML5: Support adds 4 new categories and targets key features of HTML5 such as session and local storage, Web SQL database, and new HTML attributes.
Microsoft .NET MVC: Support extended to identify 12 relevant vulnerability categories.
SAP ABAP BSPs: Support includes modeling of database and other input sources, as well as 8 vulnerability categories.

Fortify Runtime Rulepack Kits: Enhancements to existing rules and monitors, detailed issue reports, enhanced accuracy, and easier configuration in the SecurityScope and RTA Runtime Rulepack Kits.

Finally, we're proud to have contributed to the widely publicized HP 2011 Top Cyber Security Risks Report, available at:

www.hpenterprisesecurity.com/collateral/report/2011FullYearCyberSecurityRisksReport.pdf

As always, we hope that you have found our research helpful and we welcome feedback. If you have any questions, please don’t hesitate to contact us.

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.

Man Plus Machine

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

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

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

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

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

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

NoSQL == no injections?

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

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

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

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

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

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

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

The intended query might look something like this:

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

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

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

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

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

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

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

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

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

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

An Important Tool in an Auditor's Toolbox

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

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

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

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

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

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

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

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

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

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

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

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

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

Common Unzip Pitfall

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

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

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

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

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

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

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

* These are zip programs already installed on my laptop

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

Context Sensitive Ranking

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

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

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

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

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

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

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

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

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

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

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

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

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

Java Denial of Service Vulnerability (Double Trouble)

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

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

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

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

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

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

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

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

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

Fortify at RSA Conference 2011

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

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

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

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

Handling Managed Beans

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

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

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


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

…
  
Your comment was:
  
#{Garbanzo.comment}

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

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


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

The com.foo.Garbanzo class looks like this:


class Garbanzo {
    
    private String comment;

    
    Garbanzo() {
        
        comment = “”;
    
    }

    
    String getComment() {
        
        return comment;
    
    }

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

    
    String getComment2() {
        
        return comment;
    
    }

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

}

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


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

…
  
Your comment was:
  
#{Garbanzo.comment2}

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

Free Security Audit For An Open Source Web App

Wed, 15 Dec 2010 08:05:32 -0800

Do you have an open source web application that you would like to have audited by Fortify? Let me know at jherr at hp dot com.

Securing Python From Path Manipulation

Tue, 7 Dec 2010 07:59:26 -0800

Path manipulation is where a hacker injects a fake path into an application to trick it into reading something different than it would normally. Take for example this simple application:

import csv
import sys

filename = sys.argv[1]
user = sys.argv[2]
password = sys.argv[3]

csvfile = '%(file)s.csv' % { 'file': filename }
print 'Checking %(file)s' % { 'file': csvfile }

userReader = csv.reader( open(csvfile, 'rb'), delimiter=',' )
found = 0
for row in userReader:
	if user == row[0] and password == row[1]:
		found = 1
		print 'Logged in'
if found == 0:
		print 'Not logged in'

This is a simple application that reads user accounts and does a login check. The first parameter is supposed to be 'users' or 'administrators'. The second and third parameters are the user name and password. Because the coder (me) is lazy I'm just going to use that first parameter to point to a particular password file. And because I believe that the file system permissions for the directory prevent tampering all is well.

Not so fast. Sure the happy path works just fine:

$ python bad.py users user1 password
Checking users.csv
Logged in

But so does the hacker path:

$ python bad.py ../mydata/users hacker password
Checking ../mydata/users.csv
Logged in

Because of the way I construct the path a hack can easily point the application at a completely different users file in another directory which they control and, viola, they have access. Whoops.

There are some simple fixes for this. One would be to selectively sanitize the input.

password = sys.argv[3]

filename = filename.replace( '.', '' )
filename = filename.replace( '/', '' )

csvfile = '%(file)s.csv' % { 'file': filename }
print 'Checking %(file)s' % { 'file': csvfile }

In this case I'm using a string replace to remove any dots or slashes. That will kill any directory referencing on most operating systems.

The problem with this approach is that there is still too much to check to be guaranteed that there will never be an issue. So another, better, option is to just check the value against known goods:

password = sys.argv[3]

if filename != 'users' and filename != 'administrators':
	print 'Bad user type'
	exit( 0 )

csvfile = '%(file)s.csv' % { 'file': filename }
print 'Checking %(file)s' % { 'file': csvfile }

This way we can give the user some informative response if their input is invalid, and we can check all of the possible input variations without worrying about patterns we hadn't yet come up with.

Securing Your Android Phone

Mon, 8 Nov 2010 11:39:52 -0800

Very informative article on securing Android phones from the front end and back end. Google is also working it's security issues internally. Nice to see companies taking such an active interest in security.

Facebook's One Time Password

Tue, 26 Oct 2010 10:36:32 -0700

I'm not passing judgement on Facebook's one-time password system. Not because I don't care about it, I just don't know enough about that technique. So what's the consensus on it? Going too far and potentially messing folks up even though it's more secure? Falling short of the mark and not providing adding any real security? Or did it hit the mark just right? Let me know at jherrington at fortify dot com.

Interesting news of late

Mon, 25 Oct 2010 09:34:16 -0700

Some interesting security news stories out in the past couple of weeks/days:

The NSA just did a document dump. Looks like a lot of this stuff goes way, way back.
NuCAPTCHA is going to try embedding the CAPTCHA text in a video. Certainly a novel approach.
There is some news out that security jobs will be more in demand than ever as two out of three companies report successful hacks.

I apologize for not blogging as much in the past few weeks. Things have been pretty busy around here with the pending new release. Additionally we are doing a lot of hiring, and also looking to do that Fortify Camp sometime next year. If you have any leads or ideas in any of those areas please contact me at jherrington at fortify dot com.

Reports in F360

Thu, 14 Oct 2010 08:15:39 -0700

We are internally involved in a project to address the default set of reports that we ship in F360. As part of that process we are looking for people who use the system who want to give us feedback on the current set of reports, what custom reports they have made, and what holes they see in the report set we currently have. If you are interested in being part of that process drop me a line at jherrington at fortify dot com.

Awareness of Awareness

Wed, 13 Oct 2010 08:51:18 -0700

October is National Cyber Security Awareness Month! I didn't know. Every month is Cybersecurity Awareness Month as far as I'm concerned. Do not relegate your application security concerns to this 31-day span. Attackers practice incessantly; we too must show constant vigilance.

Comments To Abyssal

Tue, 12 Oct 2010 10:25:09 -0700

At least for the time being it appears that comments to this blog are going into an abyss that I personally, along with the other bloggers, do not have the proper diving equipment or certification to explore. Please understand, we want your comments, they are the reason we do what we do. So while we are preparing for our dive certification exams please send your comments to jherrington at fortify dot com and I will see to them personally.

I apologize for any inconvenience this may have caused. We really, really want your feedback.

Why I'm Glad I Don't Work In The Military

Mon, 11 Oct 2010 15:19:14 -0700

Wired has an amazing chart of the 163 security regs that military folks have to get through before they can make IT changes. Wow.

Malware, You're the Disease

Fri, 8 Oct 2010 11:19:19 -0700

Scott Charney of Microsoft advocates a public health model for malware and botnets. I found Charney's paper worth the time to read. He offers some fine definitions of individual defence, collective defense, active defense, and offense as means to combat cyber crime, and compares these to their physical conuterparts.

That said, I'm not getting in line for a laptop health certificate. I do not find the public health model valid. It's an old saw in cyber threat modeling. I object to it as a false analogy. Measures like vaccination and quarantine are weighed carefully against civil liberties because in public health concerns, we deal with people and populations. Computers, ISPs, and the like do not have such advocates. My ISP can choke off my traffic, and no one would blink.

Furthermore Charney acknowledges that his proposal sacrifices privacy at the intent of security. Using his health model, he further blunders in his discussion on anti-smoking regulations as a comparative privacy loss for the public good. We must acknowledge that smoking in public is a willful act, unlike my computer's infection. Downloading software doesn't compare to lighting up.

It's time that security researchers shelve our copies of Outbreak and The Hot Zone. We need a model for the spread of software threats that applies to software threats.

Fortify Security Camp

Wed, 6 Oct 2010 09:57:27 -0700

This year HP put on an innovation camp in the Lake Tahoe area. We have been thinking about doing something similar for security in the middle of next year time frame. With a little help from HP. And maybe even in Lake Tahoe if we can swing it. ;-)

The camp would be a free-form get together of people involved in the field in security as well as people in the security research field. You can present stuff or not. Though presenting is preferable. The idea is to get some bright minds together in one place and then stir the innovation pot for a while to create some energy and excitement.

If your interested let me know at jherrington at fortify dot com. Hopefully I can get enough folks who are interested to make the event possible.

More on Stuxnet

Mon, 4 Oct 2010 10:48:51 -0700

Another cool article on the Stuxnet worm, how it was designed and how it spread beyond it's intended limits.

Reflections on the New Technological Era

Thu, 30 Sep 2010 14:53:11 -0700

Last week I had the privilege to attend a tour of the HP SmartHome. A model of a residential building in the middle of the parking lot at HP’s campus in Cupertino represents what some might view as the home of the future. But it is the reality today. It demonstrates HP’s vision of how technology is about to become something more than just an integral part of everyone’s everyday life.

The main idea behind the smart home is dependent on the cloud computing concept, where a consumer’s profile exists in the cloud with all of her data that includes preferences, family photo albums, favorite movie collections and so on. That way all the various devices that the consumer possesses can be easily synchronized through the cloud simply by way of authenticating the user to her profile. This scheme allows the profile to simply follow the consumer when she goes home from work or steps from the living room into the bedroom. And of course, all the devices are now going to be online. And not just computers and TVs, but also printers, alarm clocks, digital photo frames, as well as all the kitchen appliances.

As we were walking from one room to the next and joking about being able to remotely raise the temperature in the oven to be too high in order to cause fire in the house and therefore receive a payment from the home insurance company, I kept thinking about all the possible ways such system can be abused. I can see the same problems and questions arising again as those that did with e-voting and medical devices. How do we protect data stored in the cloud? How do we provide good authentication schemes for distinguishing between legitimate users and attackers? At which point should the system take control in its hands in order to avoid accidents?

Smart home is an example of many cool ideas people have about what we can do with modern technology, but in more and more cases, security and privacy are turning out to be the limiting factor. As we are entering this new technological era, we should keep in mind that software security is not limited to protecting websites or credit card numbers. It's about realizing the potential of information technology. And our job as security practitioners is to help with that and prevent catastrophes caused by technology, like the one that happened at Rutgers, from happening.

You Don't Have to Be A Genius to Work Here, But It Helps

Tue, 28 Sep 2010 14:31:17 -0700

The MacArthur Foundation announced its 2010 grant recipients. These fellowships are popularly known as Genius Awards, though no recipient would refer to herself as such. Such luminaries as author David Foster Wallace and mathematician Terence Tao have won this award.

This year the MacArthur Foundation recognized Dawn Song, Computer Security Specialist. As Computer Security Specialists ourselves, we at Fortify are thrilled to see one of our own lauded in this way. Congratulations Professor Dawn Song!

This is the first time the the MacArthur Fellowship's thirty-year history that a recipient's area of principal focus is computer security. This certainly testifies to the prolific Prof. Song and the quality of her work. It speaks highly also to the maturity and importance of this field. Let us ride the swell of Dr. Song's recent award to develop and share good security practices.

Internal security Threats

Tue, 28 Sep 2010 11:36:15 -0700

Fascinating article on internal security threats specifically around the theft of intellectual property. Well worth the read.

SRG Goes Mobile, Part Three -- iOS Security and Old Attacks Getting A Makeover

Tue, 28 Sep 2010 08:18:23 -0700

As an intern at Fortify this past summer, I researched analysis techniques for Objective-C and potential security vulnerabilities in iOS (iPhone, iPod Touch, iPad) applications. In this blog post I discuss recent attacks against the iOS platform and note some parallels to older attacks. In my next post, I'll discuss what a attack at the application layer of iOS might look like.

First, I'd like to discuss some articles I've been seeing in the news recently regarding mobile security. There have been a number of articles about "new mobile threats" and "mobile malware," but the attacks described are simply applications that have additional malicious functionality beyond the purpose they claim to the user. This is the exact same type of attack as 10 years ago when downloading a dancing smiley cursor would also give you pop-up ads. When you download a program, whether it be to your desktop or to your phone, there's a possibility that it may have malicious functionality. This type of problem is as old as computers.

Most public attacks aimed at iOS focus on attacking the platform itself or on stealing private data, with the former representing a vast majority. For a glimpse into attacks on the iOS platform, you can get an idea by reviewing the bugs fixed in iOS 4.0. Many of the bugs are from libraries used by iOS, with a large number being in Safari and Webkit. As for privacy, the main public attacks have been from malicious apps that actively steal personal data or legitimate apps that accidentally leave sensitive information in places where unintended agents may access it.

What interests me about these attack trends on iOS so far is that almost no (public) attack has been at the application layer - they've all been attacking the underlying OS or attacking the storage of sensitive data. It's like everyone has been attacking Apache or other programs running on a web server, but no one's been trying to hack the website itself. I think we can expect to see more attacks aimed at iOS applications themselves.

Written by Clint Gibler

SRG Goes Mobile, Part Two -- Fortify's Android Solution

Fri, 24 Sep 2010 11:02:49 -0700

The solutions that SRG has devised for Android's security flaws align with Android's security model. With Android, the developer bears the security onus. In the mobile arena this burden is particularly weighty.

Android allows a user to write data to "external storage". External storage includes removable storage media like an SD card and internal storage. Characterize external storage by what it allows, rather than by where it's located. These files are world-readable, they can be modified in USB mass storage mode, and we're explicitly informed "there's no security enforced upon files you save to external storage".

External storage users claim this is appropriate for large non-private data sets, like ringtones or wallpapers. Clearly it is inappropriate for the password used by your mobile banking application. Consider your organization's confidential information, which you received via corporate e-mail on your enterprise-supported Android phone. Such data should not reside in external storage. Fortify's solution alerts the software developer when the application could send your privileged information to this unprivileged place. When sensitive data never reaches unsecured storage, the threat of data theft as described earlier diminishes.

A malicious application on your mobile device will run roughshod over and across your device's software, as it would on your desktop machine. Android provides a mechanism to pen malicious applications, but fails to exercise it. Android demands that an application request permissions at install-time. The user can install or not based on these requested permissions. Certainly a wallpaper program should not request text messaging permission. These promiscuous applications exist. Fortify's solution advises the developer that dangerous permissions are requested, so that developers can create software with a least-permissive set.

It was our pleasure in SRG to create some tools for security-conscious developers of Android applications.

SRG Goes Mobile, Part One -- An Unsolvable Problem

Fri, 24 Sep 2010 10:59:38 -0700

For the first time, Fortify's Security Research Group investigated platforms and applications in the mobile space. In an upcoming post, SRG summer intern turned Ph.D. candidate Clint Gibler will detail his foray into iOS. Here we consider general security issues with mobile. We will go on to discuss how these vulnerabilities manifest in Google's Android operating system and applications.

The foremost security flaw with mobile is that you will lose your hardware. You may lose it to theft, you may hand your phone to a nefarious airport personnel for a few minutes as you walk through the metal detector. Moving away from the sinister side of the spectrum, you may inadvertently leave your phone in a bar. You may innocently recycle your phone when you upgrade to the newer model. Regardless of scenario, losing control of your multi-hundred dollar hardware hands over access to gigabytes of your valuable data: your contacts, your stored passwords, sensitive documents riding along as e-mail attachments.

We acknowledge this problem is endemic to mobile. Any data storage platform is a target for theft: a desktop machine, a laptop, thumb drive, or smartphone; even a manila folder. The risk of loss grows as the device size shrinks. Also, the target's value increases in proportion to its capacity. Thirdly, as a device performs more functions, there exist more types of information on it. A mobile phone contains a list of phone numbers, but a web-enabled mobile computing platform can contain this and bank account information and sensitive documents. Hence we believe that a mobile device like an Android-enabled phone lives in an attacker's sweet spot.

No software solution will prevent losing your phone. Fortify's Security Research Group addressed the resultant data loss by ensuring that sensitive data is not written to an unprotected location in Android. As your phone gains more of the functionality of you computer, you must protect it as such. For example, Android provides full support for SQLite databases that an application may use for structured storage. Mostly full, that is; SQLite mostly mitigates your fears of SQL injection, mostly. Analogous to your desktop, your mobile platform opens itself to attack through its software. These security issues - data loss and malware - exist for the Android platform.

In the next post, we will describe SRG's third quarter efforts to save Android from itself.

People Like Tech More Than Security

Fri, 24 Sep 2010 08:28:46 -0700

Turns out that your average Joe wants technology convenience more than he wants privacy. Make mine a double. If I can trade a little privacy for sensors in the roadways that allow my car to drive me to work hands free, count me in. Come to think of it, I can't think of a single technological advance that didn't involve some privacy concession.

Speaking of conceding privacy, I'll be in the big apple (NYC) on the 30th for two days if you want to get together and talk security, Fortify or software development. You can reach me at jherrington at fortify dot com.

Str0ng P@22w!rd?

Thu, 23 Sep 2010 14:42:10 -0700

On Sunday September 5, the New York Times printed an article about password strength. I have mixed feelings about this article. On the one hand, publication in a widely-circulated periodical brings application security issues to general audience. However the analysis in the NYT piece lacks the depth of a security publication. Security professionals are obliged to provide that depth. Consider the theses of the Times' piece, their destructive implications, and how we can guide the conversation to the benefit of users.

1. Complicated password policies are counter-productive. No one likes to create a new password of length eight to twelve characters, using a a combination of uppercase and lowercase letters, numbers and non-alphanumerics. Furthermore it is difficult to create a new one every ninety days, and to remember it. Multiply this onerous task by three or five or ten such accounts and one sways toward Donald Norman and Microsoft's security researchers quoted in the article.

By referring to Amazon, PayPal, and Fidelity's websites, the Times insinuates that since a simple password policy is good enough for these guys, it ought to be for everyone. But this obscures the fact that these corporations' simple password policies are just one element of multi-faceted information security infrastructure. If your information security policy is no more than your password policy, your system is in danger. Effective security policy is multi-layered; no single factor will adequately harden the target.

A strong password policy contributes hardness. A non-dictionary password, eight or more characters long defends against an off-line password guessing attack. Bruce Schneier wrote on this in 2007; his technical analysis remains sound.

Most of us do not set security policy in the organization; we merely abide. In 2009, Slate Magazine offered salient password creation guidance. Create your password out of a memorable pass-phrase. You might know that I'm a rabid Abba fan, but that won't help you or your password-cracking software deduce Dqy&so17
Dancing queen, young and sweet only seventeen...

2. Complicated password policies do not provide security. A second thesis of the NYT piece avers that password policies provide a false sense of security. False because a password will not protect against some more onerous threats. To evaluate this claim, one must consider the threat highlighted by the Times: a key-logger. Key-logging software on your machine will take your password, your bank account number, your mother's maiden name, and your best friend's e-mail address. Perhaps anti-virus software can detect this malicious program, though I've not found a security expert willing to risk her social security number on an anti-virus suite.

I acknowledge that this is a damning, damaging attack; as such it makes for good copy. A strong password would not stop a key-logger, nor would a dictionary password. Then again, multi-factor authentication, identity-based cryptography, and military-grade command and control would be ineffective. A key-logger is an infallible scribe recording each tap and click. Mentioning this omniscient, omnipresent demon obscures the discussion of passwords entirely. Security policy should prevent a key-logger from landing. A most conservative approach would restrict software downloads. But this circles back to Don Norman's criticism that security policy hampers usability to the point that users ignore the policy.

The NYT makes a valid statement in the title "A Strong Password Isn't the Strongest Security". A strong password is a necessary element of strong security. What are some additional elements?

Stuxnet - Going from virtual attacks to physical

Wed, 22 Sep 2010 09:42:49 -0700

Amazing article on Stuxnet, a piece of malware so complex that it's taken four months just to decipher it's purpose. Which turns out to be... attacking an Iranian nuclear power plant. So this piece of malware operating in the virtual world is intended to destroy a physical plant in the real world. Methinks we will be seeing more of this type of thing.

Rails Data Security

Wed, 22 Sep 2010 08:42:55 -0700

Last week I wrote about the SQL Injection potential in Rails. The conclusion there was to write ActiveRecord code the Rails way and everything will turn out alright. To continue on that theme I'm going to take a look at how use ActiveRecord the right way to impose limits on data visibility.

Take the schema below as an example:

Here we have two tables; users and groups. A user owns an asset and should only be able to see assets they own. Simple enough. The ActiveRecord code for the basics is shown below:

require 'rubygems'
require 'active_record'
 
ActiveRecord::Base.establish_connection(
	  :adapter  => 'mysql', :database => 'assets',
	  :username => 'root', :password => '',
	  :host     => 'localhost' )
ActiveRecord::Base.logger = Logger.new(STDOUT)

class User < ActiveRecord::Base
  has_many :assets
end

class Asset < ActiveRecord::Base
  belongs_to :user
end

So now I have a User and an Asset class that wraps the table. Just to make sure it's working I first get all of the users, and the user named 'Jack' with the good code below:

# Good
p User.find(:all)
print "\n"

# Good
p User.find_by_name('jack')
print "\n"

This works, so now I can demonstrate how to find the assets for just me in the next code block:

# Good
User.find_by_name('jack').assets.each { |gi| p gi }
print "\n"

ActiveRecord automatically does the user_id restriction for me on the groups table like so:

SELECT * FROM `users` WHERE (`users`.`name` = 'jack') LIMIT 1
SELECT * FROM `assets` WHERE (`assets`.user_id = 1)

So I didn't have to do any of the ID magic. I just tell ActiveRecord that a user has many assets and that assets belong to users and it does all the rest.

The same thing happens when I get the user associated with a particular asset like so:

# Good
p Asset.find(1).user
print "\n"

ActiveRecord then generates this code:

SELECT * FROM `assets` WHERE (`assets`.`id` = 1)
SELECT * FROM `users` WHERE (`users`.`id` = 1)

And once again, I don't have to do any of the ID magic work.

If you don't use has_many, has_one, belongs_to or any of that you will end up writing code like this:

# Bad
p Asset.find_all_by_user_id( 1 )
print "\n"

In this case I'm using a find on asset, but I'm specifying a value for user_id. You don't need to do that. Just get the user object then use it's assets member variable.

The same kind of issue is in this code:

# Bad
p Asset.find( :all, :conditions => [ 'user_id=?', 1 ] )
print "\n"

Again, we don't need to go that far with ActiveRecord. Let it do the work for us.

Here is another example where I use the user_id on an Asset record to do a find on the user.

# Bad
p User.find( Asset.find( 1 ).user_id )
print "\n"

The issue with all of the bad code is that I'm doing too much and not letting ActiveRecord do what it does best. And when I do all the work there is a potential that I might forget to put in the restrictions, which might end up giving one user access to the assets of another.

ActiveRecord has a very powerful model system. When it's used appropriately it will enforce data visibility restrictions for you.

Gartner Mobile Commerce Findings

Tue, 21 Sep 2010 09:52:25 -0700

Gartner has come out with some findings in the mobile commerce security space. Long story short; not unexpectedly, security tools has lagged behind mobile e-commerce development. Definitely some room for improvement. Though one has to wonder how long the distinction between mobile device and computer as there is increasingly little difference between the two.

Human nature and security

Mon, 20 Sep 2010 08:47:05 -0700

Excellent article on how human nature combined with bad code can result in big security issues.

Rails/ActiveRecord SQL Injection

Wed, 15 Sep 2010 09:58:02 -0700

If being cool were all it took to be immune from attacks then Rails would be the most secure system in the world. Sadly, it's not coolness that counts and Rails (and ActiveRecord) are just as susceptible as any system that allows direct submission of SQL.

Here we have a little code that connects to the database and does a reasonable ActiveRecord request to the database:

require 'rubygems'
require 'active_record'
 
ActiveRecord::Base.establish_connection(
	  :adapter  => 'mysql', :database => 'chat',
	  :username => '****', :password => '****',
	  :host     => 'localhost' )
ActiveRecord::Base.logger = Logger.new(STDOUT)

class ChatItem < ActiveRecord::Base
  set_table_name "chatitems"
end

# Good
ChatItem.find(:all).each { |ci| }
  # SQL - ChatItem Load (0.2ms)   SELECT * FROM `chatitems`

The code opens up a connection to the database, defines a wrapper class for the table, in this case 'chatitem', and requests all of the records.

So far so good, but we haven't actually taken any user input yet.

term = 'Megan'
# Good
ChatItem.find(:all,:conditions=>["user=?",term]).each { |ci| }
  # SQL - ChatItem Load (0.1ms)   SELECT * FROM `chatitems` WHERE (user='Megan')

This code now takes user input with the 'term' variable, which is hardcoded here but could easily have come from a request. The code is still good however because it uses a replacement operator with the '?' and allows ActiveRecord to do the right thing and escape the contents of the supplied variable.

Other equally good methods here are to use the find_by style or the where style. All of which is documented on the Rails site.

This code is a prime example of how it should be done. Now let's look at a bad example:

# Bad: open to attack
ChatItem.find(:all,:conditions=>"user='#{term}'").each { |ci| }
  # SQL - ChatItem Load (0.1ms)   SELECT * FROM `chatitems` WHERE (user='Megan')

In this case I use the Ruby string replacement operator to just hand a piece of SQL code to the ActiveRecord engine. This code is susceptible because I don't do any escaping. You can see from the result that it's ok in this case, but the 'term' variable could easily hold a SQL injection attack string.

Here it's even worse. The code just gives the whole SQL string.

# Bad: Too complex and open to attack 
ChatItem.find_by_sql("SELECT * FROM chatitems WHERE user='#{term}'").each { |ci| }
  # SQL - ChatItem Load (0.1ms)   SELECT * FROM chatitems WHERE user='Megan'

Just like the other this is also highly susceptible to attack. As is the final one that doesn't use the object model at all:

# Bad: Too complex, doesn't map to objects, and open to attack
ChatItem.connection.select_all("SELECT * FROM chatitems WHERE user='#{term}'").each { |ci| }
  # SQL - ChatItem Load (0.1ms)   SELECT * FROM chatitems WHERE user='Megan'

This code I wouldn't even categorize as ActiveRecord since it doesn't use any of the object model, it just uses ActiveRecord to execute SQL directly.

The lesson here is pretty simple and pleasant. ActiveRecord makes it easy and secure to access the database if you do things the Rails way. The more that you stray from that path the more things will get both difficult and insecure.

For security folks on Rails applications the message is: 'Use ActiveRecord the easy way'. The more SQL your developers are writing the worse off they are. The code will be slower, harder to read, and more open to attack.

You make get some carping about SQL inefficiencies but the SQL code that ActiveRecord creates is sent to the longs and you can contrast and compare to see if the code it writes is any less efficient than what your developers will write to replace it.

Q3 Rulepack Update

Fri, 10 Sep 2010 14:02:15 -0700

The Security Research Group released its Q3 update to the Fortify Secure Coding Rulepacks and the Fortify RTA Rulepack Kits last week and I wanted to take a chance to update you on the latest and greatest from SRG.

As of this release, the Fortify Secure Coding Rulepacks detect 459 unique categories of vulnerabilities across 18 programming languages and over 680,000 individual APIs. Please see the attached PDF document for the full release details, but in summary, our latest updates include the following exciting features:

Fortify Secure Coding Rulepacks
Google Android – Rules support for programs that run on the Google Android platform, which identify insecure data storage and categorize applications by their security permissions.
HTML 5 – Support for this revision of the HTML specification targets features aimed at rich web applications, including vulnerabilities related to offline applications, inter- and intra-session data storage, and client-side SQL statements.
Microsoft .NET 4.0 – Expanded coverage for the latest version of the .NET framework includes data visualization tools, updated encoding methods, and routing mechanisms as well as strengthened core support for tuples, memory mapped files, file system enumeration, and string manipulation methods.
Amazon Cloud – Targeted support for the Amazon Web Services (AWS) Java API, including: S3, SimpleDB, and EC2.
Facelets – Coverage of common vulnerabilities exposed in Facelets, which is an open source XHTML template framework designed as an alternative to JSP in applications that use Java Server Faces (JSF).
JAX-WS 2.0 – Support for web applications that leverage annotations from the Java API for XML Web Services.
DISA STIG Version 3 – Vulnerabilities generated by the Fortify Secure Coding Rulepacks now include references to like issues found in the latest version of the DISA STIG (Version 3 Release 1).

Fortify RTA Rulepack Kits for Java and .NET
Tuning Capabilities – This update includes enhanced rules for SQL Injection and Cross-Site Scripting that allow users to easily and accurately tune the rules to produce the highest fidelity results.

Premium Content
Cloud Security Process Template – As a complement to the project template released last quarter, this update includes a process template that highlights ways to reduce risk during the SDLC when migrating a program from an internal data center to a cloud provider. Compliance and Standards Report – Expanding on the reporting capabilities of Fortify 360 Server, this release includes an updated compliance report for DISA STIG Version 3 Release 1.

Your Static Analysis 'Buddy'

Thu, 9 Sep 2010 10:57:43 -0700

Build Security In has a interesting (if dry) paper on using static analysis. Yannick notes that static analysis can be a good buddy (in a pair programming sense) for use in complex projects. At least, that's what the conclusion says, since I honestly couldn't get through the full paper.

Oh, and the paper is in PDF format, so watch out! How ironic would it be if the PDF had a payload the exploited the latest vulnerability?

Picking The Right PHP Database Abstraction API

Wed, 8 Sep 2010 08:03:33 -0700

In previous posts I've talked a lot about how direct access to a particular database API (usually MySQL) is a bad thing. It locks you into a particular database, and it encourages some bad practices like using string concatenation to build SQL statements. In this blog I'll talk about the different types of database abstraction APIs that are available to PHP developers.

To get started I want to bring back the advantages of using a database abstraction layer:

Database Portability - The MySQL functions are bound to MySQL only. Using an abstract database interface allows you to connect to any supported database using the same code.
Replacement Operators - You place ? characters in your query string wherever you need parameters, then you pass in an array of parameters and they automatically fill those slots. That makes the query code a lot easier to read and maintain.
SQL Injection Security - If you use replacement operators the database abstraction layer will automatically do the parameter escaping for you, thus saving you the hassle of doing it yourself and keeping you safe from SQL injection.
Prepared Statements - You can prepare a SQL statement for execution, then use that statement multiple times in an efficient batch mode. That allows the database driver to cache the compiled SQL statement which gives you a real performance boost.

If you look at these you can see that there are two primary issues that we are addressing, the first is database portability, the second is a combination of security against invalid input (i.e. SQL injection) and using the database properly and efficiently (i.e. prepared statements). There are three levels of database abstraction layers and they each have a different way of addressing, or not addressing these issues.

Pure Database Portability

The dbx library provides just the core level of database abstraction. The idea is fairly simple; having multiple database libraries meant using different functions for each library, this new library gives you a single syntax for connecting to any database. It does not provide for prepared statements or replacement operators.

Portability With Prepared Statements

The next level up from dbx are libraries like PDO and MDB2. These libraries no only provide portability, they also provide for replacement operators and prepared statements which make them SQL injection safe and database efficient if they are used properly.

Object-Relational Mapping

The third level is an Object-Relational Mapping (ORM) layer. An example of this is Doctrine. ORM layers provide a mapping between PHP objects and the database tables where their data is stored. When configured properly all the developer has to do is concentrate on the business logic in the PHP classes and the persistence of the data into the database will be handled by the ORM layer.

I hope this blog post gives you an idea of the different options you have when moving away from direct access of the database. My personal preference is to go for a library like PDO or MDB2 because it provides portability with a relatively easy migration path.

Watch Out Twitter Fans

Tue, 7 Sep 2010 13:40:32 -0700

There is a new easy to exploit vulnerability in Twitter that's making the news. Not a first for Twitter, but it's certainly worth keeping an eye on how attacks are being perpetrated on this popular service.

Symantec is Getting Jiggy With It!

Fri, 3 Sep 2010 11:25:04 -0700

Snoop Dogg has teamed up with Symantec to host a rap video contest hackiswack. People basically try and rap about the dangers of cybercrime and the best rapper wins concert tickets to Snoop's show.

Symantec is trying to raise awareness of cybercrime and espouse the dangers of being a "cyber thug". Snoop Dogg isn't exactly known for leading a squeaky clean lifestyle. His music doesn't exactly promote a crime-free lifestyle either. I particularly like the song, "Gin N Juice". I just find the irony of Symantec's decision to pick Snoop Dogg incredibly amusing.

To maximize your enjoyment of the rap contest, Symantec recommends that you "have fun, fo shizzle!" They're hip! They're cool! Symantec's attempt at being cool reminds me of Microsoft's Launch Party recommendations. Both are so wrong, they're right!

Microsoft's Fresh New DLL Hell

Wed, 1 Sep 2010 09:34:07 -0700

Way back when the issue with DLLs was in versioning. Now Microsoft has a fresh new security issue with DLLs. Which just from a developers take looks pretty bad. CNet estimates that dozens of apps could be effected, including obscure applications like Word, PowerPoint, Firefox, Chrome and Photoshop. For it's part Microsoft is still being a little cagey about which apps are vulnerable.

To my eyes, it doesn't look like the primary issue here is with the applications themselves. This seems to be a vulnerability built right into the operating system.

Securing PHP and MySQL From SQL Injection - Part 2

Wed, 1 Sep 2010 09:25:45 -0700

In the first article in this series I talked about how to protect PHP applications that used the MySQL API directly from SQL injection attacks. In this blog post I’ll show you how to migrate your MySQL API code to a database abstraction library like PDO. This move will give you both portability as well as some performance boost as you move to prepared statements.

Let’s start with some simple database access code using the MySQL API directly.

<?php
$sql = "SELECT * FROM user WHERE ";
$sql .= "user_id='"+$_GET['user']+"' ";
$sql .= "AND password='"+$_GET['password']+"'";
$resp = mysql_query( $sql );
?>

Ugh, ok, so the first thing to do here is to move it over to using the PDO library:

<?php
$stmt = $dbh->prepare("SELECT * FROM user WHERE user_id=? AND password=?");
$stmt->bindParam(1, $_GET['user']);
$stmt->bindParam(2, $_GET['password']);
$stmt->execute();
?>

See how much cleaner that is already? And this has given us not only database portability, but also SQL injection protection and database efficiency through prepared statements all in one shot.

Now we can do even a little better by using named parameters:

<?php
$stmt = $dbh->prepare("SELECT * FROM user WHERE user_id=:user AND password=:password");
$stmt->bindParam('user', $_GET['user']);
$stmt->bindParam('password', $_GET['password']);
$stmt->execute();
?>

This way it doesn’t matter what order the parameters go in the query, they always go into the right spots in the query when they are executed.

So not bad, huh? The PDO library makes database access easier to read and maintain, more efficient, less susceptible to SQL injection attacks and portable between database vendors. How cool is that!

Richard Clarke on Cyberwar

Tue, 31 Aug 2010 14:09:01 -0700

ITWorld has just published a short Q&A with Richard Clarke focusing on Cyberwarfare and how companies can prepare.

MQ-8 In Restricted Airspace

Fri, 27 Aug 2010 07:55:14 -0700

This isn't strictly about security, though I suppose it could result from a security breach. The military lost an MQ-8 drone and then found it in restricted airspace over Washington D.C.. Ah well, say hello to our new robot overlords. Happy Friday everybody!

How A Flash Drive Compromised Military Security

Wed, 25 Aug 2010 11:24:45 -0700

The Washigton Post has an excellent article today on how a USB drive was used to compromise military security. The article is light on technical details but it does act as a good reminder on the importance of physical security, as well as having secure operating systems.

Securing PHP and MySQL From SQL Injection - Part 1

Wed, 25 Aug 2010 08:00:26 -0700

PHP and MySQL are a natural pair. From the very beginning of PHP the language has had direct bindings to the MySQL API and a lot of applications still use those functions (i.e. mysql_connect, mysql_query, etc.) today. PHP has improved a lot and there are certainly better alternatives to using those direct API functions which I'll explore in subsequent articles. But if you have one of these legacy applications that uses the direct APIs you can do a lot to secure it from SQL injection without doing a massive port to one of the newer, better, PHP database APIs.

So, what's the problem with using this direct method? The issue comes in how we construct SQL queries. Here is a classic example:

<?php
$sql = "SELECT * FROM user WHERE ";
$sql .= "user_id='"+$_GET['user']+"' ";
$sql .= "AND password='"+$_GET['password']+"'";
$resp = mysql_query( $sql );
?>

Now leaving aside for the moment that the password field is unencrypted cleartext the primary issue here is that the query is vulnerable to SQL injection. The hacker could easily send a password string that terminated the single quote and added an OR condition that was always satisfied. That would give them instant access to the system because the query would always return the user record regardless of whether the correct password was provided.

The easiest way to secure your application from this type of attack is to use the mysql_real_escape_string method. This method escapes the string that's used in the SQL and thus protects against input that has malicious SQL embedded in it. Shown below is the same code fragment but with the mysql_real_escape_string method used.

<?php
$sql = "SELECT * FROM user WHERE ";
$sql .= "user_id='"+mysql_real_escape_string($_GET['user'])+"' ";
$sql .= "AND password='"+mysql_real_escape_string($_GET['password'])+"'";
$resp = mysql_query( $sql );
?>

Now some of the applications I've seen have had custom versions of mysql_real_escape_string that escaped out quotes. I really don't see the point of doing that. The mysql_real_escape_string does the job the right way. It's secure, it's maintained, and you should use it.

Having said all this, using the MySQL API directly is not really the best option. If you have the time you should use one of the newer database APIs for the following reasons:

Database Portability - The MySQL functions are bound to MySQL only. Using an abstract database interface allows you to connect to any supported database using the same code.
Replacement Operators - You place ? characters in your query string wherever you need parameters, then you pass in an array of parameters and they automatically fill those slots. That makes the query code a lot easier to read and maintain.
SQL Injection Security - If you use replacement operators the database abstraction layer will automatically do the parameter escaping for you, thus saving you the hassle of doing it yourself and keeping you safe from SQL injection.
Prepared Statements - You can prepare a SQL statement for execution, then use that statement multiple times in an efficient batch mode. That allows the database driver to cache the compiled SQL statement which gives you a real performance boost.

This blog post shows you how to secure the MySQL/PHP application you have today. In the follow-on blog post next week I'll show you how to convert this code to use one of PHPs database abstraction layers to get all of the advantages I enumerated above.

Python Security Site

Tue, 24 Aug 2010 09:35:23 -0700

The guys at Python Security are doing an awesome job not only categorizing types of security attacks, but also specific vulnerabilities in Python packages. If you are involved in security and work in Python I hope you will help out their site and contribute your expertise on the Wiki.

Big ColdFusion Vulnerability

Mon, 23 Aug 2010 15:26:10 -0700

Anyone running a ColdFusion server will want to know about this vulnerability. It allows an attacker to get access to any file on the server without authentication. There is a patch for versions 8 and 9 of the CF server.

Securing PHP From XSS Attacks

Thu, 19 Aug 2010 15:08:26 -0700

In the coming months we will be putting more information onto the security blog in a relevant form for front-line engineers. We're happy to take any suggestions you have for what topics we should cover. In this entry we look at how to secure PHP applications from cross-site scripting.

A very common source of PHP security issues in cross site scripting (XSS) attacks based on using unfiltered user input in PHP driven HTML pages. Here is an example of a simple web form:

<html><body>
	<form action="showme.php" method="POST"> 
	<textarea name="mytext"></textarea>
	<input type="submit">
	</form>
</body></html>

Here is the associated showme.php page with the XSS security issue:

<html><body>
<?php echo( $_POST['mytext'] ) ?>
</body></html>

This code allows an attacker to put anything he wants on the page, new tags, and of course, Javascript of his own design.

A simple way to secure the code is to use the PHP strip_tags function:

<html><body>
<?php echo( strip_tags( $_POST['mytext'] ) ) ?>
</body></html>

This will strip any HTML out of posted variable, thus negating any possibility of injected tags or attributes. You can loosen up this filtering by adding a second parameter to strip_tags with a list of allowed tags. However there are issues with the second parameter to strip_tags that you should be aware of.

It is important to understand how to validate input within a context. In this case I've simplified it by outputting HTML. But if you are putting the text into CSS or Javascript, you will need to understand what potential there is for adding malicious scripts in those contexts, and it won't be as easy as simply removing tags. Perhaps more on that in a followup blog.

We have more information on XSS attacks in PHP on our Vulncat site.

Police Force Privatization And Internet Security

Fri, 13 Aug 2010 11:16:23 -0700

Hi, I'm Jack Herrington. I'm a senior software developer at Fortify. I'll be blogging here to give a developers perspective on security, as well as to bring some light to product features, and maybe throw in a relevant article or two.

To start this off I bring you a piece from Marketplace. They had an interesting story yesterday on the privatization of police forces. The software security relevant element is here:

That's right. In other words, up to now, we talked about the lower-level security that private security guards enter into. Now, we have more sophisticated crime, like identity theft, like Internet crime. The police doesn't deal with it anymore at all. So, private security forces got into it, but it's further. A lot of those investigations require high caliber professionals -- accountants, IT people, lawyers, etc. -- that the police have difficulty recruiting, because of limited budget. And it can never pay the high salary that the private sector does.

Nothing too surprising, but it is interesting to see the acknowledged potential for private IT security and the lack of resources in the public sector to handle IT issues. And of course it's nice to hear about high salaries in the security space.

Dr. Dobbs BSIMM2 Spotting

Tue, 10 Aug 2010 15:31:05 -0700

It looks like Dr. Dobbs has picked up on Fortify and Cigital's BSIMM work. Check out the article here.

Safety vs. Privacy in the Mobile Parenting Technology

Thu, 5 Aug 2010 16:12:23 -0700

Even though I don’t have to worry about this now, in less than 12 years my son will become a teenager. At that point I will join the parenting crowd in trying to find ways to ensure my child’s safety without compromising his privacy. Considering that the world around us is turning more and more mobile, and it’s becoming impossible to find a phone that just makes phone calls, the idea of a mobile phone application that assists in parenting a teenager sounds less and less fictional.

To be honest, I would not be talking about this now if I did not come across an interesting paper on the subject. The authors conducted interviews with several teens and their parents and, based on their responses, provide guidelines for designing secure and private mobile phone safety technologies. The questions discussed include the kinds of data to collect, as well as when and whom to notify.

One of the interesting and possibly unexpected things that came out of the interviews is the kind of data the parents want and the teens are willing to share. For example, both teenagers and their parents agreed that mood is too private to share with anyone, unlike exact address of location, transportation type, destination, and the names of companions. In addition, the kids are more willing to share various types of information if they are notified when the other party accesses information about them. Both teens and their parents are reluctant to share any information with the government, however their views disagree on whether teenager’s friends should have access to the data – parents feel a lot more reluctant about it than their kids do.

Based on the observations drawn from the analysis of the interviews, the authors of the paper then proceed to make several technical recommendations for the design of future parent-teen mobile safety technologies. For example, they suggest separate encryption pathways for different types of data, as well as multi-party decryption for the data that need to be accessed when, for example, multiple parties must work together during a teen’s disappearance.

It pleases me to see that this type of research is being conducted proactively rather than after-the-fact. There is hope that the developers of these new types of mobile applications will take suggestions from security researchers into consideration when designing new technologies. As for the code of these applications, there are always solutions like those provided by Fortify to assist in making sure that the implementation adheres to the design.

Some Highlights of Defcon 18

Wed, 4 Aug 2010 09:45:30 -0700

Hey everyone, my name is Clint Gibler and I'm an intern at Fortify for the summer. I had the opportunity to attend Defcon 18 and thought I'd mention a few neat presentations I saw. There were many good presentations I'm not going to cover, but you can review them yourself here.

Perspectives on Cyber Security and Cyber Warfare and Of Bytes and Bullets

There were several panels about cyber warfare and cyber crime. The following people participated in the talks listed above:

Max Kelly, former CSO of Facebook
Jeffrey Carr, author of "Inside Cyber Warfare: Mapping the Cyber Underworld"
Robert Knake, author of "Cyber War: The Next Threat to National Security and What to Do About It"
Joseph Menn, author of "Fatal System Error: The Hunt for the New Crime Lords Who Are Bringing Down the Internet"
Robert Vamosi, author of "When Gadgets Betray Us: What We Don't Understand About the Everyday Gadgets We Use and How That Puts Us At Risk"

Some comments made:

It's unlikely that there will be an attack that takes a large portion of the internet offline, because the internet is a valuable asset that attackers don't want to lose. Attacks will probably focus on causing localized network problems.
The military tends to defend computers like they are buildings - (fire)walls, access control, restricting information flow.
The Russian government sponsors some Russian mafia hackers.

Uses their technical abilities for attacking other nations, political rivals, etc.
Gives government deniability for actions taken.
"Russian mafia doesn't do anything not blessed by the Kremlin." -one of the speakers

Over 100 nations are starting cyber warrior programs.
Recently declassified U.S. military cyber doctrine indicates desire for offensive superiority.

Historically, when nations sought offensive superiority there tended to be more wars.
One panelist recommends further research into cyber deterrence.

"The Chinese Cyber Army - An Archaeological Study from 2001 to 2010" talk was cancelled at the last minute for mysterious reasons.

Kim Jong-Il and Me: How to Build a Cyber Army to Defeat the U.S. by Charlie Miller

Charlie Miller is a well-known computer security researcher, known among other things for exploiting Apple products. In this talk Charlie described what his process would be if he was kidnapped by a foreign government and forced to develop a cyber army. The talk was insightful and high level enough that someone with average security knowledge could grasp nearly all of it. This was one of my favorite talks, I recommend watching it online later if you missed it. Some takeaways:

Charlie's proposed army requires a budget of ~$49 million a year (less than the U.S. currently spends on cyber security) and is composed of ~600 people.
The army would be composed of the following roles: bug finders, exploit developers, bot obtainers, bot maintainers, penetration testers, remote personnel, developers, technical consultants, and system administrators.
Bots and human agents would be geographically distributed.

A country can't protect itself by filtering packets from the outside when there are already both bots and agents inside.

He would develop several different bot software instances so that an AV signature or vulnerability of one type would not impact the others.
After 2 years from inception, Charlie expects his army would have some foothold into almost every desired network - financial institutions, power grid, government agencies, etc. He also projected that his botnet would be composed of around 500 million computers by this point.
Final message: Not much defense is possible against attackers with enough dedication, patience and skill.

Mastering the Nmap Scripting Engine by Fyodor and David Fifield

Nmap is a free and open source utility for network exploration or security auditing. I'll let them describe NSE: "Nmap's high-speed networking engine can now spider web sites for SQL injection vulnerabilities, brute-force crack and query MSRPC services, find open proxies, and more."

They had a number of Windows-specific rules they needed to test. However, they didn't have any Windows VM's so...
Fyodor scanned Microsoft's 1 million IP range and found ~75k hosts.

The scan took about 26 hours. (That's over 10 IPs scanned per second for those counting)

Fyodor showed some funny host configurations found and was able to enumerate the user accounts on certain machines. (with comic results)
Lastly David wrote a script live that found a webserver running on his computer at home that was behind a NAT.

The script was only 30 lines or so (of Lua), demonstrating the power and customizability of the NSE.

Black Ops of Fundamental Defense: Web Edition by Dan Kaminsky

Dan Kaminsky is well known for having found the critical DNS vulnerability in 2008. This year Dan talked about the benefits of and some recent work in DNSSEC.

Dan spent most of the talk speaking about applications of DNSSEC and integrating it into current systems in a way that minimizes migration pains.
He demonstrated the ability to do cross-domain authentication using the infrastructure provided by DNSSEC:

eg. ssh dan@recursion admin@client.example.com

Very rough paraphrase: "You often hear at places like Defcon and other security venues that users are stupid and are the weak link in the security chain. I disagree. They asked us for secure products and we have failed them. We gave them new ways to communicate, like email, but we have failed at preventing spam and phishing attacks. We gave them complicated solutions like PKI..."

He gave an excellent layman's description of public key cryptography:

"It's easy to recognize someone else's face, and it's hard to squish your face to look like someone else's."

Blaming the user is a cop-out of having to design easy to use, secure systems.

"When you receive an email from the bank, someday soon, you will know it came from the bank."

Exploits Demo'd

Every year at Defcon there's at least one presentation about how a widely used product, API, operating system or something else electronic was hacked in some way. Here are two notable ones from this year:

Jackpotting Automated Teller Machines Redux by Barnaby Jack
Practical Cellphone Spying by Chris Paget

All of the presenter slides, videos of the talks and sometimes released tools will be available online from the Defcon website in a few weeks. Until then, you can read the talk descriptions here.

The First Step towards Hybrid Analysis

Fri, 11 Jun 2010 14:19:36 -0700

In the past couple of months we've had several blog posts on hybrid analysis, including Jacob West’s preview of his RSA talk with Jeremiah Grossman on Correlating Static and Dynamic Security Results and Fredrick Lee's pointer to HP's writeup on the benefits of hybrid analysis. While the first one introduced the idea of correlating static and dynamic analysis results and the second emphasized that such correlation leads to a more complete analysis of the application, better prioritized results, as well as reduction of time and cost of fixing vulnerabilities, this current post is a follow-up that goes into a bit more detail with regards to implementing the first step necessary to do such correlation.

The fact of the matter is these two types of analyses work on two different types of input: while static analysis looks at source code, dynamic analysis looks at web traffic. Thus, in order to do correlation between the two there has to exist or be generated a common link that connects two types of findings. While implementing a correlation mechanism by looking at web traffic seems hard, doing it on the static analysis side is a lot more promising. Static analyzer can infer URLs for the findings by analyzing various configuration files. The generated URLs can be included as auxiliary data in as many static findings as possible. This can later serve two purposes, namely assist in matching dynamic and static findings and also provide inputs to dynamic analyzers. The first will lead to better prioritized results and reduction of time and cost to fix vulnerabilities, while the second -- to a more complete analysis of the application.

As of Q2 2010 rulepack update release, Fortify SCA generates URLs for four different Java frameworks: standard J2EE servlets, JSF, and Struts 1 and 2. Generating these URLs turned out to be trickier than it seemed at first due to heavy usage of wild cards and reliance on default context root, which makes it difficult to identify statically scanned application's web root. In general, in order to generate the URLs, SCA (with assistance from rules) looks at the following configuration files (as well as all others that have different names, but the same structure): web.xml, faces-config.xml, struts-config.xml, and struts.xml. We analyze URL patterns as well as direct and indirect URL mappings when possible. We also look at forms and navigation rules to collect information about the page flow of the application. Then we match these up with regular SCA findings based on the source code location of sources and sinks of the findings.

To give a better idea of what I am talking about, here is a concrete example. Fortify SCA finds the following privacy violation vulnerability in PerformRegistration.java class, which is part of an application written with Struts 2 Java framework:


...

Profile profile = new Profile(username, password, firstName, lastName, email, ssn);

System.out.println("added profile for " + profile.getUsername() + " (" + profile.getSsno() + ")");

...

In the code above, an SSN (private information) gets printed to the screen and therefore exposed to the outside world. From struts.xml configuration file we learn that PerformRegistration class is a struts action in a /login namespace:


...

<package name="login" namespace="/login" extends="struts-default,tiles-default">
        
    <action name="PerformRegistration" class="com.fortify.samples.riches.PerformRegistration">

    ...
	
    </action>

</package>

...

From web.xml configuration file we learn that struts actions have a .action extension:


...
    
<filter>
        
    <filter-name>struts2</filter-name>
        
    <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
    
</filter>

    
<filter-mapping>
        
    <filter-name>struts2</filter-name>
        
    <url-pattern>*.action</url-pattern>
    
</filter-mapping>

...

Using these two pieces of information we construct the URL for the PerformRegistration action by concatenating the action’s namespace, name, and extension. Now we know that /login/PerformRegistration.action URL triggers the privacy violation vulnerability described above, and include the URL in the dataflow path for the finding.

While this is just the first step (a.k.a. Hybrid 1.0), we plan on expanding URL generation for static findings to other frameworks and building a much more sophisticated technology on top of it later this year. Once static and dynamic findings are matched up, they can be automatically re-prioritized by taking both analyses into account. Plus, the evidence generated by both types of analyses can be aggregated in one place for each correlated issue, thus demonstrating an exploit of a statically identified finding on the one hand, and a source location for fixing a dynamically identified finding on the other. And this is exactly what Hybrid 2.0 will offer.

The True Cost of a Hack

Thu, 20 May 2010 17:02:37 -0700

Albert Gonzalez, the hacker who stole over 170 million credit card records from top retailers and credit card processors was sentenced to 20 years in prison a few months ago. Preparing for a presentation recently, I was reminded of just how huge the impact this hacker, working with what appears to have been a small group of accomplices, had on the US economy. As part of the court proceedings the US Department of Justice applied multiple calculations with legal precedent for estimating the losses the hacker’s exploits caused. These estimates range from $400-$780 million USD. Heartland, one of the worst affected targets, claims losses of over $130 million USD already due to legal fees, settlements, and fines.

These calculations got me thinking? How should we measure the cost of a breach like this? Most mechanisms focus on the amount of money the hacker gets out of the stolen accounts, could feasibly get out of the accounts, or in other ways try to measure direct monetary loss to the victim or gain to the hacker. But what about the tens of thousands of identities that could be stolen because of information gathered in the attacks? These soft costs seem to be the true risk of insecure software and they are much, much greater than any financial loss. Until we place some legally-relevant value on them we won't truly be able to measure the impact and justify investments to counter risk.

BSIMM2

Wed, 12 May 2010 15:16:01 -0700

BSIMM2 has landed! We have excellent data on the inner workings of 30 major software security initiatives. Download the full pdf report here, or get the quick summary here. The 20 participants that have graciously allowed us to use their names are:

Adobe
Aon
Bank of America
Capital One
EMC

Google
Intel
Intuit
Microsoft
Nokia

QUALCOMM
Sallie Mae
Standard Life
SWIFT
Symantec

Telecom Italia
DTCC
Thomson Reuters
Vmware
Wells Fargo

Expansion of Domain Names to Include Non-latin Characters

Fri, 7 May 2010 11:50:19 -0700

Recently, Internet Corporation for Assigned Names and Numbers (ICANN) approved the addition of non-Latin domain names to the Internet’s master directory of domain names. As a result, Arabic users will soon be able to access websites with URL’s written entirely in Arabic characters. Companies will be able to reach out to new audiences.

In the short term, there will be more opportunity for attackers to conduct phishing attacks against sites registered within these new domains. The domains are relatively new with a lot of unregistered space. As a result, attackers should be able to register plenty of unclaimed space for subsequent phishing attacks. With an expanded web audience and domains, the volume of phishing attacks should continue to rise.

In the long term, the security community will need to focus on finding better solutions to detecting phishing sites using methods beyond blacklisting. Blacklisting will be an increasingly unmaintainable solution to prevent users from visiting an ever-increasing and diverse set of phishing sites. Many different solutions have been proposed. Check out this article that provides a good overview of various solutions.

Here is the original article that inspired this blog post.

Static Analysis: A Science or An Art?

Wed, 14 Apr 2010 09:59:37 -0700

Last Monday marked the beginning of my seventh year at Fortify. During the last six years, I’ve been participating in several efforts to perform scientific experiments in the area of static analysis. Some focus on comparing different static analysis tools. Others have a goal of establishing guidelines for the code that should be analyzable by static analysis. While others want to define the notion of compliance as it is applied to the tools – that is, define a set of requirements that the tools need to meet in terms of the kinds of vulnerabilities they detect and results they generate. I think static analysis is still a little bit of an art, so while the knowledge we gain from such efforts is potentially amazingly useful, the challenges we face must be addressed before the outcomes of similar endeavors become beneficial. Some of the challenges I personally ran into are discussed below.

- Different tools generate different results. Time and time again, we witness differences in the output generated by static (ant not just static) analysis tools. Even though the tools claim to be looking for the same kinds of problems, techniques they use differ enough to generate results with very little overlap. In fact, even if they do overlap, it is very difficult to correlate them because they differ in format and metadata that is associated with each finding.

- Evaluating generated results is not enough. When comparing static analysis tools, evaluating generated results is definitely important, but considering other aspects of the product’s usage is critical. The tool might be producing excellent findings with low false positive rates, but be completely unusable because it does not integrate well into build systems, does a poor job of managing and tracking results, or cannot be customized to fit specific user needs.

- Definition of false positive is highly subjective. To some, false positive means reporting something that is not true under any circumstances, while to others a result that is not interesting in the current context is also a false positive. Which brings me to the last and probably most interesting challenge:

- Tools perform differently in different contexts. The same tool can perform very poorly in one situation and amazingly well under different circumstances. It all depends on the kinds of constructs and libraries used in the code, the size of the codebase, build system used for building the code, application profile (whether it is internal or externally facing), whether the user wants to treat the database as a source of untrusted data, and a lot of other factors that we sometimes don’t even think about in advance. Obviously, it is impossible to build one tool that understands different contexts equally well out-of-the-box. That’s why it’s so important to build a product that is extremely flexible -- can be easily customized, configured, and extended in various ways that make the most sense. It is not easy!

Perhaps, in the future things will change -- different techniques the tools use to perform analysis and interfaces for interacting with the tools will converge, but I think we’re not there yet. That’s why, before we attempt to compare tools in a scientific fashion and try to define binary compliance guidelines for the products by requiring them to generate a set of specific results on a set of specific benchmarks, we need to acknowledge and address the challenges current state of the art (pun intended) presents.

Top 3 Reasons You Need Hybrid Analysis.

Fri, 2 Apr 2010 17:06:56 -0700

HP has a nice write-up posted about the benefits of the HP/Fortify Hybrid Analysis 2.0. Check it out!

Schneier on Software Security Assurance

Wed, 31 Mar 2010 13:27:23 -0700

In a recent post titled Should the Government Stop Outsourcing Code Development?, Bruce Schneier dismisses the connection between where code is written and, instead, rightly focuses attention on how code is written. Specifically, he describes assurance as being "less about developing new security techniques than about using the ones we already have."

At Fortify, we couldn't agree more. Our Software Security Assurance (SSA) program is all about helping organizations bring together their people, process, and technology to deliver software that has security built-in from the ground up. As Schneier points out, security can't just be a requirement, it needs to be a priority! Give the blog post a read and see if it doesn't leave you agreeing that security has more to do with how your software is built than where it is built.

Q1 release from Fortify SRG

Mon, 22 Mar 2010 12:18:34 -0700

If you're a Fortify customer you already know we released updates in three main areas at the end of February (we always release the last business day of the second month of the quarter). If you haven't seen these updates, I decided to post a summary of what we've been up to here. As of this release, the Fortify Secure Coding Rulepacks detect 439 unique categories of vulnerabilities across 18 languages and over 650,000 individual APIs. In brief, our latest releases include:

Fortify Secure Coding Rulepacks

Oracle Application Framework – Support for Oracle Application Framework (OA Framework), the Oracle Applications development and deployment platform for HTML-based business applications.

CakePHP – Support for the CakePHP rapid development framework, which includes the model-view-controller framework and simplifies database interaction.

SANS/CWE, OWASP, FISMA Standards Support – Vulnerabilities generated by this rulepack now include a reference to like issues found in the 2009 SANS/CWE Top 25, OWASP 2010 Top 10, and FISMA (specifically FIPS-200).

4 New Categories – New categories include Race Condition: Format Flaw, Process Control: Invoker Servlet, and CakePHP Misconfiguration vulnerabilities.

50+ Enhancements – Over 50 internally and externally requested minor enhancements.

Fortify RTA Rulepack Kit

Spring Security 2 – Provides support for identifying brute force logins and report Spring Security authorization failures and privilege changes at runtime.

Premium Content

Microsoft SDL – Process templates for Fortify 360 Governance users implementing the four security maturity models in the Microsoft Security Development Lifecycle (MS SDL): Basic, Standardized, Advanced, and Dynamic.

CVSS – Project templates for auditors using Fortify SCA and Audit Workbench to annotate vulnerabilities using the Common Vulnerability Scoring System (CVSS).

BSIMM2

Mon, 1 Mar 2010 19:04:11 -0800

Planning a software security initiative can benefit from understanding and analyzing real-world software security initiatives. That is exactly the purpose of the BSIMM project which gathers data from leading software security initiatives. The number of initiatives studied thus far reached 30 which means that applying statistical analysis on the data makes sense. But before going that route, can’t there be anything simpler derived from the data that gives a useful insight in to it? Well, I think that ranking the activities by what was observed the most is simple and very useful. The top 15 activities can be found in the latest informIT column on the BSIMM and is definitely worth a read!

Hitler and Cloud Computing Security

Wed, 24 Feb 2010 20:58:57 -0800

Props to Marcus Ranum and Gunnar Peterson for a brilliant rendition of this YouTube standard.

Fortify Joins Microsoft's SDL Pro Network

Fri, 5 Feb 2010 12:51:42 -0800

Recently, Microsoft welcomed seven additional companies to join their Microsoft SDL Pro Network. We’re excited to announce that Fortify has joined the SDL Pro Network as a Tools provider.

So, what exactly does this mean to Fortify users? Well, it means that Fortify along with the Fortify 360 product suite can be used to help an organization manage and comply with Microsoft’s prescribed SDL.

Specifically, the seven portions of the MS SDL are addressed by Fortify in the following ways:

*: The roll-out and deployment of the MS SDL can be managed through the Fortify 360 Governance module. Fortify user’s simply need to use the Fortify created MS SDL process template that best models their organizations security maturity level (Fortify provides support for Advanced level down to Basic level maturity), load the process template into Fortify 360, and follow the prescribed requirements and activities.

Training: Fortify Training provides comprehensive secure development practices which address all phases of the Security Development Lifecycle.

Requirements: Fortify 360 Governance module prescribes the proper MS SDL Requirements steps. The Governance module also stores and artifacts produced from the Requirements phase.

Design: The Governance module also directs users of what MS SDL design activities are required for the organizations security maturity level. The resulting design artifacts are stored in the 360 server for review.

Implementation: Fortify SCA performs static analysis for an organization’s code base. Fortify 360 consumes the static analysis results and warn of banned function violations.

Verification: Fortify 360 is capable of consuming and reporting upon dynamic testing results from multiple vendors. The Governance module stores relevant threat model/attack surface analysis.

Release: The Governance module along with the accompanying MS SDL process template, enforce a proper release strategy.

Response: Once again, the Governance module serves as a repository for response artifacts.

In essence, Fortify 360 provides a comprehensive solution for rolling out the MS SDL throughout an organization.

Good Boy, Have a Star!

Thu, 4 Feb 2010 16:13:03 -0800

It's that time of year again--RSA is just around the corner. When the conference folks put up the speaker list this year I was pleased to see a little red star next to my name, which I learned means I'm a "Top Rated Speaker" from past years. Yay, me :P

This year I'll be speaking with Jeremiah Grossman from WhiteHat Security on Correlating Static and Dynamic Security Results. This is a topic we've both been interested in for years (along with half the security community, it seems), but this is the first time we both feel like we have some significant contributions to share. In particular, we're excited to talk about real-world examples of correlation we've seen in the context of Fortify on Demand.

If you just can't wait until March, Jeremiah and I recorded a podcast with RSAConference.com Editor-in-Chief Jeanne Friedman where we preview the session.

Some secure memory sticks may not be all that secure...

Thu, 14 Jan 2010 16:03:18 -0800

Sometimes, I like to use my USB memory stick to hold data because it's incredibly convenient and it has a large enough data storage capacity for most things. Naturally, security becomes a concern when I'm storing sensitive data on the stick. I don't want the bad guy to take the stick I may lose and examine the sensitive data. Typically, secure memory sticks use data security controls like encryption to protect the data. The algorithm requires a password to decrypt the contents. A user that is authorized to view the data will know this password and be able to successfully decrypt the data and examine the stick's contents.

Some manufacturers of secure USB memory sticks have forgotten to encrypt the contents using the user-supplied password. Instead, they use a hardcoded password to decrypt the contents. They use the user-supplied password as an authorization check. Upon successful authorization, the stick uses its hardcoded password to decrypt the contents.

If you know the hardcoded password and you can bypass the authorization check, you can decrypt the contents without knowing the user's password.

The folks at the security firm SySS have done just that... check it out here.

The Curse of the Single Quote

Tue, 22 Dec 2009 11:45:38 -0800

Speaking from personal experience, having Tsipenyuk as a last name can be inconvenient due to pronunciation and spelling errors, but the last name O'Neil can cost you an identity. I came to realize this when I got married and, being convinced by many around me, exchanged my complicated scary-looking Ukrainian last name for this simple and straightforward Irish one. Turns out, my problems were just beginning.

I will skip over describing the pain and frustration of filling out millions of request forms asking to change the last name on millions of the accounts from one to another, and making millions of photocopies of the marriage certificate to send along with the forms as a proof. I won't start a discussion on why changing your last name on a credit card account is significantly less painful than doing the same for an airline frequent miles account. I will proceed straight to the really good stuff.

The Social Security office simply dropped the single quote from my last name even though my request form clearly contained one. When I inquired about it, the response was that their system automatically does this and treats O'Neil and ONeil the same.
TD Ameritrade and Wells Fargo sites (as well as many others) don't allow single quotes in their passwords.
The zenTrack project management and bug tracking software escapes single quotes, but does so incorrectly, leaving backslashes for display.

The list goes on--these are just a few examples of what I keep running into. I am sure some of you see what I'm getting at. Clearly, all of the mentioned inconveniences are caused by the fact that single quote is a special character that needs to be correctly handled by software behind all these institutions. Some institutions choose to deal with the problem by simply not allowing special characters, others attempt to escape them. Still others--remain vulnerable. It boggles my mind that this one character causes so much pain and makes it necessary for me to remember what version of my last name I should use at which point. Why is there still no standard way of dealing with this problem? Why is everyone still doing their own thing?

It shouldn't be a surprise to you that my advice to the software developers writing code for these institutions is to create standards that allow them to be consistent and correct in their handling of names as "special" as O'Neil. I still hope that one day the standard everyone adheres to will exist, and then I will be an O'Neil at all times. Until then we'll keep running into problems similar to this one.

Obama names Howard Schmidt Chief of Cybersecurity

Mon, 21 Dec 2009 23:25:41 -0800

Last spring Howard Schmidt and I took our advice on software security to Washington DC. We spoke to just about anyone who'd listen about ways the federal government could build security into the code they build, buy, and commission. Here's an article on what we had to say. Point #1: Appoint a Leader.

Apparently there were more people listening than we realized. President Obama has named Howard the new Chief of Cybersecurity. Congratulations Howard!

Fortify on Demand

Wed, 9 Dec 2009 11:26:09 -0800

Today we are officially launching Fortify on Demand. You can upload your compiled code, and we'll generate a vulnerability analysis report. Give us the source code too, and we'll include information about the offending lines of code. Give us a URL where the code is running, and we'll create an integrated static/dynamic analysis report, with the dynamic results courtesy of our friends at WhiteHat Security. (Press release here.)

I got started on static analysis in order to help programmers write better code, but I've learned there's a lot to be said for simply creating a code assessment. Non-programmers deserve answer questions like "Did I get what I paid for?" But non-programmers aren't usually in a position to make static analysis fly. And even if they are, the norm is a static analysis report that says things one way and a dynamic analysis report that says them another. Our early adopters (thanks guys!) are big on the ease-of-use factor. Multiple assessment techniques coming together in one report without any fussing around with code. What could be better?

If you want a closer look at what we've built, sign up for the webinar Jacob West and Jeremiah Grossman are giving on Jan 14. Register here.

Q4 Update to the Fortify Secure Coding Rulepacks

Mon, 7 Dec 2009 15:56:50 -0800

You might have noticed some new rulepacks showed up on your virtual doorstep just before the Thanksgiving holiday in the US. If you haven't gotten into the nitty gritty details yet, as of this release, the Fortify Secure Coding Rulepacks detect 436 unique categories of vulnerabilities across 18 languages and over 600,000 individual APIs. In brief, our latest release includes support for:

- Python (new language)

- Microsoft SharePoint

- Adobe Blaze DS (Server-Side Flex API)

- Spring Annotations

- Apache Commons FileUpload API

As always, we're very excited about the release and encourage Fortify users to play around with the new features as soon as possible.

Irrational: Why the Snake Oil Flows

Mon, 30 Nov 2009 15:13:35 -0800

It’s only the end of November, but I’m ready to hand out the Snake Oil Security Product of the Year Award to ATSC (UK) Ltd. for their product, the ADE 651. It’s a portable device for detecting all manner of important things (including bombs, drugs, and truffles). It works on the same principle as a divining rod or a Ouija board—that is, it doesn’t work. That hasn't stopped the Iraqi army from spending tens of millions of dollars on hundreds of ADE 651s.

A successful con of this magnitude requires a victim who desperately wants something and who's willing to depart from rational thought in order to believe they can have it. Software security assurance is ripe for snake oil salesmen because measuring security is hard and major loss events are relatively rare. But what are software security practitioners so desperate for that they'll buy even though the product doesn't work? I'll outline two ideas below. Any resemblance to actual commercial offerings is purely coincidental.

The Silver Bullet
This vulnerability detector uses a patented counter-interpolation analysis to apply a vulnerability database derived from the scariest hax0rs around. There are never any false positives. False negatives? We don't even know what that means. Good for analyzing source code, binaries, web sites, services on the network, networks you have only heard about, and iPhone apps. Merely analyzing your software|hardware|network once guarantees a seal of approval from OWASP/SANS/PCI/FISMA/NRA.

The Responsibility Shifter
Buying this product allows you to sit back and relax. Your job as a security professional will now be taken care of by all of the non-security people in your organization. You drop the software off on their desks, they immediately understand how important security has become in the past few years, and they stop doing their jobs in favor of doing yours instead. If anything goes wrong, the software will explain to management that getting security right requires a team effort, and you really can't be held accountable.

Have more product ideas? Post them here or send me email, and I'll do a roundup in a few weeks.

BSIMM Europe

Wed, 11 Nov 2009 09:06:16 -0800

BSIMM made it across the Atlantic! Over the last few months, I've traveled with Gary McGraw, Brian Chess, Florence Mottay, and Dave Harper through Europe to companies like Nokia, SWIFT, Standard Life, Telecom Italia, and Thomson Reuters to expand the original BSIMM study with data from Europe. While we were expecting that European companies are tackling software security completely different, we were surprised to find out that the studied European companies are doing software security not terribly different from the original nine US companies in the BSIMM study. European companies tend to focus more on Compliance and Policy, Penetration Testing, and Software Environment while Training and Security Testing and assurance activities (like Code Review) seem to be behind. Our full analysis is here

Cross-Origin Resource Sharing

Mon, 9 Nov 2009 13:08:36 -0800

A few days ago Facebook and MySpace fixed some bugs in their crossdomain.xml files that could have allowed malicious apps to steal user data or do other nefarious things. The crossdomain.xml file allows a site to specify which third party sites are allowed to make cross-domain Flex based AJAX request to that site. This basically disables the same origin policy for allowed sites. Chris Shiflett has a nice write up about the dangers that come along with allowing cross domain AJAX and Flash.

I wanted to take this opportunity to remind our readers of the lesser known Cross-Origin Resource Sharing (CORS) standard that allows similar behavior. Most new browsers support this standard, so the associated cross-site manipulation vulnerabilities are not limited to Flash. It is a little harder to detect if a site is vulnerable since you can't just request crossdomain.xml. Instead you need to find a resource that uses certain access control headers (See Ajaxian and Mozilla for examples). Now I'm pretty sure only a few sites have adopted this standard, but once the adoption picks up, it's only a matter of time before we see a bunch of advisories about CORS.

PCI DSS in Russia

Fri, 30 Oct 2009 12:08:52 -0700

A lot has been said about the Payment Card Industry Data Security Standard (PCI DSS) established in 2004. Actually, let me correct myself: a lot has been said about what is going on with regards to PCI DSS here in the US. But have you ever wondered what is going on with the standard in other parts of the world? Well, I have. In fact, I do travel to Russia once in a while, and I do use my credit cards there since rate of currency exchange is best when you use a credit card. Plus credit cards are convenient since you don't have to carry cash around and worry about thieves. But perhaps instead of worrying about physical thieves, I should really worry about virtual ones?

To answer my questions, I did some "yandexing" (google equivalent) and found some interesting information. The good news is that PCI DSS assessment is now a requirement, even though before September 2006 it was not. Unfortunately, according to this article written by Anton Karpov, a Qualified Security Assessor (QSA) working for Digital Security, PCI compliance is still optional. You will be fined if you don't get an assessment, but nothing will happen if you don't pass it. This state of affairs leads to many companies getting an assessment just so that they don't get charged any fines, and going on with their lives no matter what the outcome of the assessment is. Moreover, I found several articles and blog posts (for example, this one) cautioning the companies to be careful when choosing their auditors because some of them incorrectly interpret the standard and others give a passing mark even when the requirements of the standard are not met. The amusing thing is that the blog post seems to be written by Anton Karpov's boss, but when I looked the auditor up via QSA employee lookup, it turned out that Anton's QSA certificate has expired. I hope he gets it renewed before doing any more audits.

PCI DSS is not the only accepted standard. ISO 27001 and ISO 17799 and their Russian equivalents ГОСТ 17799 and ГОСТ 27001, as well as СТО БР ИББС-1.0 are also accepted. However, even assessments of compliance with either of these are not mandatory -- they are only recommended. So, looks like PCI DSS is still a little bit ahead of the others. Sadly, all of the above seems to imply that it's gonna take Russia a little while before it catches up with the US in terms of Software Security Assurance (SSA). But who knows, perhaps I'm wrong.

Windows versus Linux Security

Mon, 26 Oct 2009 11:57:45 -0700

When asked to comment on an article comparing Windows and Linux security I wrote up a few bullet points showing the pros and cons on each side. My commentary ended up posted as a guest blog on the LastWatchdog blog. You can check it out here.

Read Logicomix

Sat, 24 Oct 2009 06:07:31 -0700

Want to know how we got into this fine mess? Why we're not getting out anytime soon? Read Logicomix, a graphic novel about Bertrand Russell, the failed search for a foundation of mathematics, and the pre-dawn of the computer age. It's an easy read and a lot more fun than Maus. Buy copies for the people who love you too, so they can better understand that, on an absolute scale, you're really not that strange.

Do The Right Thing

Thu, 22 Oct 2009 12:28:26 -0700

A colleague noted that my posts tend to be “angry old man rants” of the “get off my lawn” (for the record, it is a nice lawn) ilk. I’m not sure if this was a slight against my age, but I do occasionally see the brighter side of our software development world and I’d like to highlight something that recently made me smile.

After several years of users pleading with (and the security wonks groaning at) the Rails development group to escape HTML by default, they’ve finally listened and the latest “Edge” version of Rails will escape output by default and developers will have to explicitly mark a string as “safe” to output unencoded HTML. Why is this such a big deal? Because as the BSIMM project has pointed out, secure-by-default frameworks are a much better approach towards long-term application security than bolt-on security.

John Steven at Cigital posted a few months back expounding upon the value of a secure-by-default framework. I’d like to draw attention to two of the bullet points that I feel are most important to get adoption from a development group:

Maintains transparency, as best as possible – Those securing the framework can place implementation ‘under the hood’ allowing developers to call functions as normal;

Moves security ‘lower in the stack’

My previous complaint with Rails (and apparently others had the same frustration) was that the Rails developers had the foresight to include the option for html escaping, but developers had to explicitly invoke it (‘<%= h’ to escape versus ‘<%=’). This made it *very* easy for developers to miss. This behavior was in direct conflict to the “Convention vs Configuration” mantra that Rails has adopted with regard to API design and usage.

That’s enough history for now though. Rails, welcome to the club with the other frameworks that are already doing the right thing:

Grails -- The Grails gang has been incorporating security into their design since the beginning. The following is the default Grails behavior:
- All standard database access via GORM domain objects is automatically SQL escaped to prevent SQL injection attacks
- The default scaffolding templates HTML escape all data fields when displayed
- Grails link creating tags (g:link, g:form, g:createLink g:createLinkTo and others) all use appropriate escaping mechanisms to prevent code injection
- Grails provides codecs to allow you to trivially escape data when rendered as HTML, JavaScript and URLs to prevent injection attacks here.
They have a web page that gives developers a highlight of common web vulnerabilities and how they can address these issues with Grails.
Django -- As of Django 1.0, HTML escaping is on by default in the Django templates via the autoescape behavior. Unless the developer explicitly turns off escaping or the variable has had the “safe” filter applied, variables are HTML escaped before rendering the output.

If you know of any frameworks that also “Do The Right Thing”, let us know in the comments!

Unwanted Guests

Tue, 13 Oct 2009 16:04:26 -0700

Users who have upgraded to Apple's recently released 10.6 update to OS X, codenamed Snow Leopard, have reported a seemingly rare bug that results in their entire user account, including settings and data, being lost inadvertently. The bug apparently rears its head when a user logs in, either intentionally or unintentionally, to the 'guest' account on their machine. When the user logs out and logs back into their regular user account they receive the nasty surprise that it has been fully reset to the default state for a new account and their data has been lost.

If this bug turns out to be as easy to trigger as it sounds, then the security implications are pretty serious since they effectively translate a short window of physical access to a machine into the ability to do irreparable damage in fairly subtle way. Although reports of the bug appear to have surfaced within days of Snow Leopard's release, Apple has only just now acknowledged the problem.

Until Apple addresses this problem properly, a good first-step defense is to disable the 'guest' account.

CNET has posted tips for avoiding the bug and recovering data if you've fallen prey to it already.

Read Logicomix

Sat, 10 Oct 2009 22:27:56 -0700

Maybe you should look at the source code

Mon, 21 Sep 2009 11:03:57 -0700

When eBay acquired Skype in 2006 for $3 billion, they didn't even blink at the source code and were satisfied with a binary that was "protected" (read obfuscated). As revealed now, Skype seems to contain a backdoor that remotely shuts down Skype by disabling encryption. This stunning revelation seems to indicate that it might be a good idea to at least have a look at the source code before you put money on the table for a piece software.

refs:
Twilight in the Valley of the Nerds
TmcNet

Using SCA/AWB as a guiding tool

Fri, 18 Sep 2009 10:28:26 -0700

We all know that static analysis tools produce their fair share of false positives. One example where static analysis tends to suffer is when an application uses custom cleansing logic to prevent cross-site scripting (XSS). In this scenario, SCA leaves it up to the auditor to determine whether a particular method performs adequate validation to negate a particular vulnerability.

In this situation, it can be tempting to discount all XSS issues where data passes through validation logic without looking at individual issues on a case-by-case basis. However, outputting data sanitized for cross-site scripting can still lead to potential security problems. For example, the code below output a cleansed string into an anchor tag's href attribute, which leads to open redirect vulnerabilities.

<meta http-equiv="refresh" content="1;url=<%=request.getAttribute("CLEANSED_STRING")%> "/>

or

<a href="<%=request.getAttribute("CLEANSED_STRING")%>">Click Me</a>
Here’s an example where outputting a sanitized string into the src attribute of a script tag is just as bad as cross-site scripting since it can allow attackers to source in arbitrary Javascript.

<script src="<%=request.getAttribute("CLEANSED_STRING")%>"></script>
So, a good tip when auditing Fortify SCA results is to avoid taking all of the results literally. If SCA reports cross-site scripting, also try looking for open redirects and dangerous file includes. Similarly, you can look for access control problems when auditing SQL injection or LDAP injection issues. By looking at issues more broadly, you might find vulnerabilities in places you've previous overlooked.

Java Web Frameworks Hodgepodge

Thu, 3 Sep 2009 18:43:09 -0700

Another rulepack release is behind us. On August 31st the latest version of the Fortify Secure Coding Rulepacks (English language, version 2009.3.0.0006) became available from update.fortify.com and the Fortify Customer Portal. The new release contains quite a few improvements, including: support for ColdFusion 7 and 8, enhanced PL/SQL support, as well as improvements to our handling of a number of Java web frameworks – Axis 1 and 2, GWT, JSF, and Struts 2. It’s this final subject, web frameworks, that I want to talk about in this post.

The thing that bothers me the most about web frameworks is that their numbers grow faster than anyone’s full understanding of their advantages, disadvantages, security holes, or simply capabilities. How many Java web frameworks can you think of? What about templating engines, which are becoming more and more popular and provide integration with various existing web frameworks? What about Ajax component libraries? Did you get JSF, Spring, Struts 1 and 2, WebWork, Apache Beehive, WebObjects, JBoss Seam, Facelets, FreeMarker, Velocity, RichFaces, and IceFaces?

The list goes on and on. And even though the end-goal is always the same – a web application that consists of model, view, and controller layers – each of the frameworks has its own way of achieving this goal and each claims to be an improvement over existing ones. While older frameworks, such as Struts 1, require action classes to extend an abstract base class, newer frameworks, such as Struts 2, allow any POJO to be used as an action. While JSF, Struts 2 and WebWork use configuration files to define beans and actions, JBoss Seam and Apache Beehive use annotations. While Facelets uses XHTML files to define templates, FreeMarker uses proprietary FTL files and Apache Velocity uses its own proprietary VM files. The list of differences goes on even longer than the list of frameworks.

What a headache it is for the developers to keep all these differences straight, especially when upgrading from an older framework to a newer one or migrating from one to another! Switching between different structures of various configuration files, learning to apply annotations where none used to be necessary, and implementing views with the new proprietary templating language seem like very error-prone processes. No wonder frameworks misuse is so common! And a security auditor at a company where programmers can choose any and all frameworks will have to know the ins and outs of a huge technology landscape. So, what can reduce frameworks misuse, and, for that matter, software bugs and flaws? I believe the answer is straightforward – standardization of web frameworks. The fewer differences there are among the frameworks, the easier it will be for the developers to adopt a new framework. The more frameworks are built according to an accepted standard, the easier it will be to establish a set of common guidelines and best practices around their usage. And once such guidelines are in place, they can be enforced. But until then we need ways to capture and apply knowledge about a large number of frameworks, and this is an area where static analysis becomes particularly useful.

A knife with my name on it at the airport

Sat, 29 Aug 2009 21:26:11 -0700

The TSA says you can't take knives through airport security. But why would you want to if you can just buy a knife once you're through? I'm usually perfectly happy leaving the TSA humor to Bruce Schneier, but this is too good to pass up: personalized pocket knives for sale past security at SFO. Credit for this find (and photo) to my friend Jeff Piper.

Breaking the Record of Shame

Wed, 19 Aug 2009 01:33:33 -0700

The world recently learned that Albert Gonzalez, a former Secret Service informant, was allegedly involved in breaking the record for the greatest number of credit card numbers stolen in a single operation. According to prosecutors, he did so by stealing 130 million credit and debit card accounts as part of a breach that targeted the card payment processor Heartland Payment Systems and two chain stores: 7-Eleven and Hannaford Brothers. Remarkably, Gonzalez also held the previous record, which he set by allegedly steeling 45 million card numbers in a breach that targeted T.J. Maxx, Barnes & Noble, Sports Authority and OfficeMax.

For readers who like to track the play-by-play and not just the statistics, it is now being reported that the hacker behind the Heartland breach broke into the system using a SQL injection attack. Once on the network, he installed some malware that contained a backdoor, which had been tested against 20 popular anti-virus programs to make sure it went undetected. Once again, this incident demonstrates that when you're code doesn't have security built into it, attackers will find a way to exploit this shortcoming to their great advantage.

DEFCON 2009

Fri, 14 Aug 2009 16:15:33 -0700

As usual, security researchers at Fortify kept up with the latest in hacking by attending the DEFCON conference in Las Vegas. In a lot of ways this year's 17th annual DEFCON felt like a confirmation of our work at Fortify: Topics included advanced SQL injection attacks and other seemingly exotic vulnerabilities, which the Security Research Group has already built support for into one or more of our products. So what was exciting?

In my opinion, the inventive misuses of Firefox plug-ins and the novel Wi-Fishing technique were two of the most interesting talk. On average, users today install Firefox plug-ins as if they were recommended by Mozilla and certified to be secure. Guess what? The plug-ins that were abused had been recommended by Mozilla, but apparently not proven to be secure.

The handful of misuses all exploit design flaws in the add-ons and ranged from password discovery to automatically dialing numbers from the Skype. For example, under normal conditions the Skype plug-in recognizes a phone number in a page and shows you a button to dial the number. But what if you could eliminate the user interaction (autodialing) and trick a victim in visiting a malicious page that automatically dials hundreds of charge-for-use phone numbers?

The Wi-Fishing technique is again a simple but clever misuse of the design. Even if you’re a thousand miles away from home, your wifi client may be continuously scanning for network names it has connected to in the past and attempting to connect to them again. The proof-of-concept tool attempts to phish these wifi clients that are searching for common networks that they have connected to in the past, such as “wireless” or “linksys”. Once the configuration settings of the network that the device is using to connect are known, a ‘clone’ of the network can be set up. Connecting to the clone makes the clone a man in the middle which is a perfect set up to sniff passwords, redirect to malicious websites, or phish other personal information from users.

Both of these exploits come down to a question of trust. Wireless networks have always been dangerous to connect to, but as we come to depend on Internet connectivity more and more, our propensity for connecting to potentially untrusted networks is increasing. Be careful! With respect to malicious software from trusted third-parties, my personal conclusion is that more and more attackers will take advantage of newly popular trusted but unverified sources of software, such as Firefox plugins and Apple App Store applications. Here at Fortify we're keeping an especially keen eye on this threat because we think software analysis may play a roll in preventing some types of malicious software from making it into a third-party distribution sites.

Stranger in a Standards Land

Wed, 5 Aug 2009 12:38:37 -0700

It's been three weeks since I joined the CCHIT Advanced Security working group and so far it has been a very educational experience. I’ve been impressed by the amount of knowledge and drive my new colleagues bring to the process, as well as the sheer volume of government regulations, standards and guidelines that we have to contend with. As I spend more time thinking about this initiative, two new points have become apparent:

Certification is Expensive

Developing more secure software is expensive, but that expense actively improves the software. The certification process can also be expensive. Currently, CCHIT tests products by auditing a demonstration of the product following a set of test scripts and reviewing documentation provided by the vendor. When I first looked at this, it did not seem like much, at least in terms of security. However, I’m beginning to realize that the level of organization the process requires and the amount of time qualified professionals must invest to observe demonstrations and review paperwork is immense.

I still believe we need a more rigorous testing process, but I think we also need to consider how to do this in a way that is both economically feasible and actively improves the products. This is easier said than done, but it’s an important thought to keep in mind.

Failure would be Really, Really Bad

This wasn’t an entirely new thought for me – health data has always seemed more valuable than financial data because of its permanence. If someone gets your credit card number, you can cancel your credit card and get a new one. Of course, it isn’t quite that simple, but knowing that your data has been compromised can allow you to prevent future misuse. With health data, the information is about you, not assigned to you.

The part I had not considered is that a failure to handle security and privacy properly could prevent electronic health records from being quickly and widely adopted. While the Obama administration and others believe that electronic records can improve efficiency and accuracy in medicine, many believe they are expensive boondoggles. In short, supporters of electronic health records need to push for stronger security regulations. Without these regulations, we are likely to see a series of public breaches like the ones we've seen in the financial industry, which could prove to be a huge setback for the digitization of health records for decades to come.

It's all about the apps

Mon, 20 Jul 2009 17:07:04 -0700

This month Aviv Raff is running a month of (third-party) Twitter bugs. The majority of these bugs are XSS or XSRF and allow attackers to send tweets on behalf of a victim. These third-party web sites are effectively offering open relays that provide spammers and malware authors with new distribution channels and as Aviv notes, these vulnerabilities can be used to create twitter worms too.

Of course, this class of problem isn't limited to Twitter. For example, Facebook also has an open API that allows third-party developers to write their own applications that run on the Facebook platform. When the Facebook API first came out, I took a quick look at it and remember noticing that they did a decent job of preventing HTML and JavaScript injection (at least they were thinking about security). Instead of allowing developers to insert arbitrary HTML, Facebook forces them to use FBML. However, that can lead to FBML Injection. Facebook even has its own query language FQL (similar to SQL), which opens the door to FQL injection.

In the end, even if your favorite social networking websites were secure and never fell prey to another vulnerability (yeah, right), we still need to contend with all of the third-party apps that use their APIs. API providers should include documentation about security in their developer guides. Twitter recently added a Security Best Practices page in their developer section, but I'd like to see security documentation in-line (explicitly included with code examples) rather than a footnote or reference section.

Grossman On Fixing WAF Protected Vulnerable Code

Thu, 9 Jul 2009 23:59:21 -0700

Jeremiah's done an excellent write up on the value of fixing vulnerable code that's even when the vulnerability has been mitigated with a WAF solution. Unfortunately, there's no retweet feature for blog posts, so I'll just add a direct link to Grossman's post.

Is 128 Bits Better than 256?

Mon, 6 Jul 2009 12:18:02 -0700

Several months ago, the Fortify Security Research Group (SRG) published Crypto Manifesto -- a technical note that contains the guidelines for the usage of various cryptographic algorithms in a variety of popular programming languages. The blog entry that accompanied this publication is here. One of the guidelines we gave in the paper (and that we enforce in Fortify Secure Coding Rulepacks) states that keys for symmetric encryption algorithms (such as AES) should be no less than 128 bits in length, naturally implying that keys of 192 and 256 bits are better or at least are as good as those of 128 bits. It turns out, though, that this might not actually be the case.

A recent paper describes new cryptanalytic attacks on AES that are better than brute force. The attacks work only on AES-192 and AES-256, and the idea used for these attacks does not apply to AES-128, making it theoretically stronger than the other two variants of the block cipher, at least against these attacks. Interestingly enough, the attacks are based on the idea of local collisions -- the notion derived from the cryptanalysis of hash algorithms. This means that these attacks will have implications on AES-based hash functions. The publication of the paper raised many interesting questions about security of AES, and a lot of them are addressed by the authors in their FAQ.

How does this affect the guidance we've been giving? We do not think it does. Even though the new attacks are better than brute force, they are still a long way from being practical. As far as we are concerned, symmetric keys of 128, 192, and 256 (no less than 128) bits might not be safe forever, but they're still safe today.

Online Resources for Emerging Threats

Fri, 3 Jul 2009 19:23:23 -0700

One of the challenges of an infosec practitioner is remaining knowledgeable about the emerging threats coming down the pipeline. The following are some of the online resources I leverage to seek out emerging threats and as well as manage the information:

Google Alerts - This tool is a no brainer. As with any other Google alert, simply supply your search terms and sit back as Google does its magic. A few of search terms I have plugged in are "hacked security computer", and "security data breach databreach" "sql injection xss" with a configuration to email me the results once a day. Overall, this simple email alert is a very effective way to be updated on recent breaches.
XSSed Alerts - XSSed.org is a site were users report cross-site scripting vulnerabilities as they are found. The site also allows one to monitor domains for newly discovered vulnerabilities. The submitted proofs-of-concept are valuable for determining how various XSS attacks are crafted.
Twitter - As much as I bash Twitter for their lax security, I have gotten a lot of mileage out of the very active info security community that "tweet". Combined with the very liberal usage of hashtagged topics (#security, #vulnerability, #xss being amongst my favorites), Twitter provides a quick means for seeing what security topics, events, and incidents are "hot" at any given moment.
RSS feeds - Another no brainer for the list. There's no need to elaborate on the benefits of RSS. Instead, I'll list some of my daily security reads. These are in no particular order of importance:

Electronic Health Records: Deja vu all over again.

Wed, 17 Jun 2009 17:35:08 -0700

The American Recovery and Reinvestment Act (ARRA) has set aside $2 billion to improve Health Information Technology (a nice summary of this part of the bill is available here), particularly to encourage the use of Electronic Health Records (EHR). There are many reasons this makes sense – why should I have to fill out the same health history forms every time I walk into a doctor’s office or hospital? It’s important to remember, however, that any computer systems designed to help solve these problems will necessarily maintain and communicate incredibly sensitive and valuable health data. Of course, anytime the government starts talking about spending a couple billion dollars on something, a whole lot of people get involved. One of the biggest conversations has been on how to decide what is a "qualified" EHR.

The definitive answer to that question won’t come until the Office of Health and Human Services releases standards at the end of this year. However, existing certification standards give some idea of how the health industry currently handles security. The Certification Commission on Healthcare Information Technology (CCHIT), which is working on certification that complies with the ARRA, has around 50 security criteria for access control, auditing, authentication and other specific security features. However, the criteria and test scripts that are used to demonstrate compliance fail to describe any way to test or audit the software that implements these features to make sure it does so securely.

One of the ubiquitous challenges in software security is to get the focus away from the features and on to the details of how the software is built. When you say the word “security”, many people think of encryption and authentication features. What encryption algorithm are you using? How big are your keys? Security features are important, but if the software is not developed securely, features alone won’t protect you.

We were here five years ago, only we were talking about financial data, not health data. In 2004, the Payment Card Industry established the Data Security Standard (PCI DSS). It wasn’t until it was revised in 2006 that any mention of auditing or testing the code was included in the standard. Starting in 2008, the PCI DSS requires source code analysis, web application scanning or an application firewall.

I hope that those in charge of the new standards will look at the process the PCI DSS went through and recognize the value of code analysis and application scanning from the beginning. To that end, I will be joining the CCHIT Advanced Security working group starting in July and plan to both call attention to lessons learned in the past and promote the official adoption of industry best practices around the development of secure software. I will also be heading up a continued effort within Fortify to help organizations keep our health records secure.

Basket Full of Eggs?

Wed, 17 Jun 2009 11:52:28 -0700

With services like Twitter gutting the English language leaving only 140-character shells of real communication, the ability to minimally shorten URLs for sharing has become hugely popular. However, a recent hack against Cligs has shown that URL-shortening services can be a central point of security failure.

URL-shortening services began with href="http://www.tinyurl.com">TinyURL in 2002, whose creator wanted to link to cumbersome newsgroup URLs more easily. Although early exploits against predictable hash values led to some amusing redirects, such as ‘dick’ taking users to www.whitehouse.gov, they were mostly harmless. The greatest security concern to-date has been that shortened URLs introduce an extra level of abstraction between the user and the content they wish to view. We in the security community are fond of instructing users to only visit trusted domains with a reputation for being free of malware and other nasties, but this becomes nearly impossible in the face of multitudes of nearly indistinguishable shortened URLs.

Last weekend, hackers exploited a vulnerability in Cligs, a competitor of TinyURL, to redirect millions of users to a seemingly benign, but certainly unintended, site. Although the motivation for the attack is unclear (some suggest the unusual destination may have been a mistake on the part of an attacker who wanted to redirect users to a malicious site), the implications are dire. Had the site been a launch pad for malware or a phishing attack, the more than 2 million users who were sent there against their will would have little recourse.

From a business perspective this is an interesting example of security becoming a major competitive differentiator. For companies that provide a comparatively generic service like URL shortening, distinguishing oneself from competitors can be challenging. This attack suggests that companies who strive to grow market share without focusing on security run the risk of security becoming the competitive differentiator that drives users to other, more secure, services.

Rulepack update: soundtrack and bonus material

Mon, 1 Jun 2009 13:19:06 -0700

We released our latest Secure Coding Rulepack on Friday. This rulepack adds 22 new vulnerability categories, support for Spring MVC, Apache Wicket and 2 popular .NET packages (SubSonic and Castle Active Record). Along with the rulepack, we've also released a utility for generating source code analysis rules from Microsoft SAL annotations. You can download the rulepack here. The SAL utility is here.

But wait ... there's more! This rulepack is the first of it's kind to come with a soundtrack. Here's what the engineers were listening to while they did the work:
    Andrea Dorea Bucci Bag
    Rise Against Re-Education (Through Labor)
    The Clipse Swagga Like Us Remix
    Vivaldi Four Seasons
    Cloud Cult Happy Hippopotamus
    CPU Computer Error

The codename for this release was bostoncreme, and certain elements within our office have an interest in miniature food, so we're celebrating the release with Boston cream pie cupcakes. Martha makes it easy for you to join us.

HPP and Fortify

Wed, 20 May 2009 20:13:37 -0700

At OWASP AppSec Poland 2008, Stefano Di Paola and Luca Carettoni presented their work titled "HTTP Parameter Pollution" (HPP) . In essence, they inject multiple parameters with the same name in the HTTP request (in the query string, in the cookies and in the body of the request) and find that different pieces of software make different choices about which parameter value to use. They were able to exploit this condition in a number of applications, sometimes circumventing security mechanisms, and sometimes defeating security products.

As the presentation shows, WAF vendors have some patching to do as their protection mechanism is broken. WAFs do not take program context into consideration which makes them vulnerable to this type of attack. Actually, it is unclear to me how they can fully patch a WAF to capture any instance of this attack. Without knowing which instance of a parameter the program is going to use, how can you know what to protect?

As for Fortify, our Real Time Analysis (RTA) operates in the application itself, it does take context into consideration. In other words, we see parameter values the same way the rest of the program sees them. RTA doesn't kick in until the decoding of the request is done, and like in this case until a value is assigned to a variable in the program, so this just isn't a problem we have.

Busting the Fortify Myth

Sun, 17 May 2009 17:11:18 -0700

Weird stuff happens when people make software. Sometimes that's because of complexity and unintended consequences, but sometimes it's because the people making the software are just weird. This video is about extending Fortify 360 Server to automatically assign vulnerabilities to the right developer. You might not think that would require any exploding toilets or a car dressed up like a space shuttle, but that's why you need to watch the video.

Busting the Fortify Myth from Brian Chess on Vimeo.

XSS for Fun (and profit?)

Wed, 13 May 2009 12:00:00 -0700

I recently read an article in 2600 magazine about how to make quick money by exploiting XSS vulnerabilities in a retail website. In short, XSS vulnerabilities can enable an attack to alter the price of an item displayed on a reputable website. At first glance this appears harmless since the attacker can't actually purchase the item at the modified price. However, by printing out the page showing the modified price and requesting a price match at a competing store, the attacker can leverage this technique to acquire goods at radically discounted prices.

Beyond the fact that retailers are losing money because their competitors have lousy websites, this technique is interesting because it leads to fraud that is incredibly hard to detect. First of all, the print contains a seemingly legitimate URL from a competitors’ website. Second, even if the employee who grants the price match is suspicious, the attacker can trick him into confirming the fraudulent price by asking him to visit the specially crafted URL that replicates the cross-site scripting attack. The really nasty thing about this is that the software vulnerability (XSS) is costing another company, a competitor in fact, money so there's very little motivation for the vulnerable website to fix this particular problem.

Iron Chef Interviews Part 2: Sean Fay

Sat, 2 May 2009 13:18:51 -0700

Here is the second half of the Iron Chef interviews from Black Hat 2008. This interview is with Sean Fay, Fortify’s chief architect. I should point out that we interviewed Charlie and Sean separately, so they answered without being able to hear the other person’s answers first. The fact that they both talk about cycling and hamburger helper just adds to the mystery of the cosmos.

Charlie hates Apple. What do you hate?

I guess if Charlie hates Apple, I have to go with Microsoft. It’s nothing personal really. It’s just that I find it frustrating that no matter what my job title is, I seem to spend a fixed percentage of my time rebooting Windows machines.

You did Iron Chef last year too. Any advice for Charlie?

An hour goes a lot quicker than you might think. If you’ve invented some kind of machine to slow time down, now would be a good time to deploy it.

Can people build their own static analysis tools? Should they? Any advice for a tool builder who’s just getting started?

There are lots of cases out there in the software world where some custom static analysis can be really useful. But building a static analysis tool is a lot of work! As with most things, it’s better to build on top of someone else’s work to achieve your objectives. Both commercial and open source static analysis tools tend to be designed to support customization and extension.

Why aren’t there better open source static analysis tools?

Building a static analysis tool is a lot of work! There actually are some great open source static analysis tools out there - like FindBugs – but they tend to be domain and language specific.

Even a great static analysis tool by itself isn’t that useful. A tool needs a set of rules that describe the behavior of libraries and define the problems that the tool should look for. It’s a lot of stuff to pull together, and right now there’s no good standard for describing checks or characterizing libraries.

What’s wrong with fuzzing?

Fuzzing is a great technique for finding vulnerabilities, but it has two fatal flaws:

The first is that it’s skin-deep. The deeper and more involved the bug, the harder it is to uncover with fuzzing. The person fuzzing the app doesn’t have much of an advantage over an attacker. That means you have to hope that the attacker just isn’t going to try harder than you did.

The second is that it requires someone with very specialized skills and understanding. This makes it a hard technique to scale in an environment where lots of software is being produced.

People say static analysis produces too many false positives. Are they right?

No, it’s just that static analysis tools are complicated to use. Most people forget to turn on the switch to disable false positives before they run their tool.

Seriously though, false positives are a fact of life with static analysis, but a good toolset gives you easy ways to manage them and quickly sort out what is relevant and from what isn’t.

Charlie wrote a book about fuzzing. If static analysis is so cool, why haven’t you written a book about it?

I tried writing a book but I couldn’t get the first chapter to compile.

The static analysis concept has been around for a long time, but it seems like it’s gained popularity lately. Why?

I think that’s a combination of a lot of different factors. The tools are getting friendlier and more powerful. At the same time, a growing awareness about security is making their value more apparent.

When you meet women, how do you explain your job?

Well, before that Adam Sandler movie came out I used to explain that I was secretly a Mossad agent and this was just my cover. That hasn’t been working out so well for me lately.

What’s the biggest mistake people make when they use static analysis?

Lack of preparation. Static analysis is a means to an end. If that end is making your application secure, you need to spend time thinking about the architecture of your application and the assumptions that are being made about trusted and untrusted data.

A security-oriented static analysis tool will tell you a lot about where untrusted data is used within your application. But it’s very difficult to interpret that data unless you’ve already made some decisions about where validation is supposed to happen and where untrusted data is allowed to go.

What do you expect the fuzzing results will be like?

Hard to predict since I don’t know what the application is that we’ll be looking at. These guys are good at what they do, so I’ll bet that at the end they’re going to have something pretty interesting to show us. But with the limited time, we probably won’t see a very broad analysis of the application.

Why do you think you’re going to win?

I’ve been learning about competition from watching “Le Tour”. In preparation for Iron Chef, I’ve been doping with EPO for weeks. My red blood cell count is off the charts.

What's your favorite vulnerability or security incident from the last year?

That has to be Mark Dowd’s flash exploit.

What other disciplines do you take inspiration from?

Besides professional cycling? I guess online poker.

Where did you grow up?

I grew up in a small town called Ipswich in Massachusetts. It’s famous for clams and old houses.

If this were the original Iron Chef, what would you cook?

Well, I’ve been vegetarian for 7 years, but tofu just isn’t a crowd pleaser. I’m pretty sure I can still make a mean hamburger.

Iron Chef Interviews Part 1: Charlie Miller

Sat, 2 May 2009 09:52:45 -0700

I’m cleaning up my machine, and I came across the interviews we did for the Iron Chef competition at Black Hat in August 2008. They’re too much fun for me to keep to myself. Our lead Chefs were Charlie Miller from ISE and Sean Fay from Fortify. Charlie fuzzed his way to victory, but Sean gave him a run for his money with static analysis. Here’s what Charlie had to say before the game. I’ll post Sean’s interview in a few days.

Charlie Miller is a principle analyst at Independent Security Evaluators, but he’s better known as the first guy to hack the iPhone, and he’s made a habit of walking away with a Mac in the annual CanSecWest Pwn2Own contest. We just think he’s an Apple hater. Charlie, why you gotta hate?

I’m not a hater. I just like pointing out how the “cool” company isn’t perfect. That and I like to irritate all the fanboys. Oh wait, I guess I am a hater.

How did you prepare for the competition today?

Actually, I did A LOT of preparation. More than I thought I’d need to do when I signed up. I was told the target program would speak Bonjour, HTTP, and DAAP. So I made sure I had some fuzzers that would work on those protocols.

For some fuzzers this meant getting packet captures or client programs (for mutation) or learning the protocol and writing a simple specification for generation-based fuzzers. Unfortunately for me, there aren’t a lot of DAAP or Bonjour fuzzers sitting around.

It’s easy to get started with fuzzing, but should people build their own fuzzing tools? What are the advantages/disadvantages of doing it yourself? Any advice for people just getting started?

The advantage of doing it yourself is the ability to customize it. However, just like most development, it’s usually best to use something that’s been around for a while and been tested rather than rolling your own version.

I’m using 3 fuzzers against 3 different protocols and didn’t write any of the fuzzers (although I made some small modifications to some of them.) It turns out that debugging a fuzzer is super difficult!

There are a lot of open source fuzzing tools out there. Should people consider commercial tools too? If you pay money, what do you get that doesn’t come for free with open source?

Yes, commercial fuzzers are an option. If you want the most thorough fuzzing, you need to build in a lot of protocol knowledge into the fuzzer. This takes a considerable amount of time and effort.

When you buy a fuzzer, you are buying the fact someone did all the research for the protocol and built the test cases for you. If you are fuzzing a proprietary format, you probably won’t be able to find a commercial fuzzer for it. It all depends on whether you have more time than money. For me, I have more time.

What’s wrong with static analysis?

Static analysis tools are often plagued by false positives. Instead of looking for bugs, users of static analysis tools end up spending all their time trying to find the one bug out of the 10,000 alerts generated by a tool. I also think static analysis fails to find extremely complex bugs.

Fuzzing is negative testing, so you can never be sure you’ve found all the bugs. How should people balance fuzzing with other techniques?

Fuzzing should be used as only one part of a complete and balanced diet of bug finding techniques. It can find bugs and point static/manual analysis to untested portions of code. However, it isn’t the end-all-be-all. For example, I probably wouldn’t waste my time fuzzing a program written in Java.

You’ve got a PhD in math. If fuzzing is so cool, why didn’t you study it in school?

Yea, I totally wasted those 5 years. When I got my PhD, I could barely program, much less understand fuzzing. However, I knew everything about nonlinear partial differential equations! (Sadly, that last statement is a gross exaggeration) Also, keep in mind; I’m an old dude, so fuzzing wasn’t exactly hip in 2000 when I graduated (much less 1995 when I started grad school). The OULU guys hadn’t blown the world away yet.

Barton Miller coined the term “fuzzing” in 1990. Why didn’t it become a popular technique sooner?

That’s a great question! I’d say that it was a combination of a couple of things:

First, it wasn’t exactly hard to find bugs in something like Microsoft RPC 10 years ago. You didn’t NEED fuzzers.

Another is that Miller was an academic so the guys who actually look for bugs weren’t aware of the work. It wasn’t until OULU broke the Internet with their ASN.1 fuzzer that everyone took notice.

After you fuzz a program, do you still respect it in the morning?

It matters how easy it gave it up to me. Apache is a total prude! I currently have a restraining order against QuickTime.

What do you expect the static analysis results will be like?

Lots of alerts about coding style. Lots of “lame” bugs that don’t get you a shell. Lots of “bugtraq”-esque bugs that say “if they configure it this way and run it as root and write their configuration file in UTF-8, there is a bug”. Maybe there will be a good bug thrown in by accident.

Why do you think you’re going to win?

Because my buddy from work picked the target program. No, wait, that’s why Sean is going to win. I’m going to win because I’ve got mad skillz…and I hand picked a couple of the judges.

What’s the biggest mistake people make when they fuzz?

Probably that they don’t check what they are doing. The biggest problem with fuzzing is if you do it wrong, you don’t find any bugs, which means either there weren’t any bugs or there were bugs and you missed them. Often, it’s hard to tell which.

The other common mistake is not fuzzing long enough. For me at least, I’m very impatient and want to turn off the fuzzer after a couple of hours when I should let it run for a week.

What's your favorite vulnerability or security incident from the last year?

I kinda liked the cross-site scripting attack that redirected Obama’s site to Clinton’s, even though in general I think XSS is lame.

What other disciplines do you take inspiration from?

They don’t have anything to do with computer hacking, but I like to race my bike (like Lance Armstrong except way slower) and I like watching hockey. I’m also possibly the oldest man to play dance dance revolution and I kicked ass at it.

Where did you grow up?

I’m a product of St. Louis County public schools.

If this were the original Iron Chef, what would you cook?

I cook a mean Hamburger Helper. Probably whatever the special ingredient was, I’d just throw it in with a box of the helper. Depending on what it was, I might choose Lasagne, or Three Cheese flavor, or maybe Cheeseburger Macaroni. I’d never use Beef Noodle which is horrible!

Why Passwords Sent Over Email Suck

Fri, 1 May 2009 09:02:11 -0700

I’m tired of beating up on Twitter. And at this point, it really seems like they don’t even care about security. Passwords sent clear text over email? Administrative passwords sent to an EXTERNAL email address? Allowing administrative logins from an external network? Really, Twitter? Really?

http://www.informationweek.com/news/internet/social_network/showArticle.jhtml?articleID=217201066&subSection=News

I was a bit puzzled by the lack of response from Twitter's Chief Security Office, then I realized that twitter probably doesn't have a CSO (at least I couldn't find information one) and they don't seem to have a chief privacy officer. Now, I realize that Twitter is a small startup (approximately 30 people), but that's not really an excuse to take security lightly.

I'll end my angry old man ranting with a link to a small glimmer of hope for Twitter: http://twitter.jobscore.com/jobs/twitter/softwareengineersecurity/bWXUUalpOr3OZwaaWP50_m

Cyber Attack on the Bay Area

Thu, 23 Apr 2009 14:49:54 -0700

I was on vacation when I read that multiple fiber lines had been cut around the Bay Area; thankfully the Internet connection in my apartment in Paris was unaffected. However, upon my return I was amazed to hear just how scary the events that occurred should be to all of us. One of the best accounts begins with the following paragraphs (read the rest here):

"Just after midnight on Thursday, April 9, unidentified attackers climbed down four manholes serving the Northern California city of Morgan Hill and cut eight fiber cables in what appears to have been an organized attack on the electronic infrastructure of an American city. Its implications, though startling, have gone almost un-reported.

That attack demonstrated a severe fault in American infrastructure: its centralization. The city of Morgan Hill and parts of three counties lost 911 service, cellular mobile telephone communications, land-line telephone, DSL internet and private networks, central station fire and burglar alarms, ATMs, credit card terminals, and monitoring of critical utilities. In addition, resources that should not have failed, like the local hospital's internal computer network, proved to be dependent on external resources, leaving the hospital with a "paper system" for the day.

Commerce was disrupted in a 100-mile swath around the community, from San Jose to Gilroy and Monterey. Cash was king for the day as ATMs and credit card systems were down, and many found they didn't have sufficient cash on hand. Services employees dependent on communication were sent home. The many businesses providing just-in-time operations to agriculture could not communicate."

Software Security Industry Growth

Mon, 20 Apr 2009 15:00:20 -0700

Gary McGraw put out an article last week detailing the revenue generated by the software security industry for 2008. It’s nice to see our industry growing at a steady clip, but as Gunnar Peterson pointed out after Gary published 2007’s numbers, the software security market is dwarfed by the network security market. Gunnar’s numbers are a bit fuzzy, however, I think it’s safe to say we spend billions on network security (firewall, VPN, IDS, services, etc.), but only a fraction of that amount is spent on software security. The thing that worries me is that spending is a reflection on awareness, so even though increased spending in the software security sector indicates expanded awareness about software security I don’t think awareness is growing nearly fast enough. These days everyone knows about firewalls, but frequently people in IT know very little about software security. What do you guys think will help growing awareness? What would you like to see consultants and vendors like Fortify do to drive software security awareness?

Enforcing Enterprise Policy with Fortify 360 v2.0

Tue, 14 Apr 2009 13:45:22 -0700

During a recent off-site, a few of us in SRG whipped up this brief video demonstrating how a fictitious company might use Fortify 360 v2.0 to enforce an enterprise-wide policy forbidding cross-site scripting vulnerabilities. This is just a taste of what Fortify 360 is capable of and shows how the product can be employed to enforce very specific policies.

More on Annotations...

Tue, 24 Mar 2009 11:55:08 -0700

In addition to their other capabilities, Fortify Java Annotations can be used to identify new vulnerabilities in code. For example, the following code writes sensitive user information to a log file, but Fortify SCA cannot report a warning out-of-the-box because it has no knowledge of the sensitivity of the data in question.

String query = "Select credentialA, keyB, elementC from userTable where userid = ?"; PreparedStatement pstmt = connection.prepareStatement(query); pstmt.setInt(1, userid); ResultSet results = pstmt.executeQuery();  // extract data from the ResultSet while (results.next()) {   String credentialA = results.getString(1);   int keyB =  results.getInt(2);   Blob elementC = results.getBlob(3); 	   String stringBlobRepresenation = new String(elementC.getBytes(1, (int) elementC.length()));   logger.info("Retrieved info for user " + userid + ": " + stringBlobRepresenation); }

This code snippet queries the application’s database using Java Prepared statements to retrieve information about the user userid. The userTable table contains a sensitive column elementC that must never be handled in an insecure way. As part of the debugging effort, a developer has insecurely logged elementC to disk, thus compromising the sensitive information it contains.

By adding the @FortifyPrivate annotation to the code above, a developer can tell Fortify that elementC is sensitive and allow Fortify SCA to identify dangerous uses of this variable.

String query = "Select credentialA, keyB, elementC from userTable where userid = ?"; PreparedStatement pstmt = connection.prepareStatement(query); pstmt.setInt(1, userid); ResultSet results = pstmt.executeQuery();  // extract data from the ResultSet while (results.next()) {   String credentialA = results.getString(1);   int keyB =  results.getInt(2);   @FortifyPrivate Blob elementC = results.getBlob(3); 	   String stringBlobRepresenation = new String(elementC.getBytes(1, (int) elementC.length()));   logger.info("Retrieved info for user " + userid + ": " + stringBlobRepresenation); }

Fortify SCA now reports the privacy violation that occurs when elementC is logged.

As we mentioned in a previous post, Fortify 360 2.0 and the Q1-2009 update to the Fortify Secure Coding Rulepacks now recognize the following Fortify Java Annotations:

Dataflow: Source, Sink, Passthrough, and Validation
Field and Variable: Password, NotPassword, Private, NotPrivate, NonNegative, NonZero
Other: Dangerous Class, Method, Field, and Variable and CheckReturnValue

A detailed sample that demonstrates the full capabilities of Fortify Java Annotations is available with supported versions of Fortify 360 and through the Premium Content section of the Customer Portal.

Look Who's Reading

Sat, 21 Mar 2009 13:02:41 -0700

Who's reading this blog? The author(s) of Conficker, apparently. Here's the story.

Conficker's creators have a Ron Rivest fetish. Conflicker uses RC4, RSA, and MD-6 (details here) all of which are the work of Professor Ron Rivest. Last month we blogged about bugs in SHA-3 reference implementations (MD-6 included). This month Conficker C incorporated the MD-6 fix that Ron's group submitted to NIST.

Anyway, hello Conficker crew. F*** you very much for your attention.

A Few Words about Crypto

Thu, 12 Mar 2009 15:28:36 -0700

Recently, there has been a lot of talk and speculation regarding various cryptographic algorithms that are still widely used. Some security experts suggest banning a number of them; while others argue that some of these algorithms are still secure enough to be used for the time being. No wonder developers remain confused about the choice of which crypto to use in their code.

In order to clarify things, the Fortify Security Research Group (SRG) performed a thorough investigation of the subject. As a result, we came up with a set of guidelines that will be published later this week in the form of a Crypto Manifesto and is available immediately to Fortify customers through the Premium Content area of the Customer Portal. These guidelines cover four of the most critical topics: hash functions, encryption and encoding functions, encryption keys, and pseudo-random number generators (PRNGs). All of the guidelines will be enforced through the most recent version of the Fortify Secure Coding Rulepacks, which were released on February 27th, 2009.

The table below summarizes our guidelines on the usage of crypto in security sensitive contexts:

	Avoid	Use
Cryptographic Hashes	MD2, MD4, MD5, SHA-1	RIPEMD-160, SHA-224, SHA-256, SHA-384, SHA-512
Encryption and Encoding	RC2, RC4, DES	3DES, AES
Symmetric Keys (AES)	< 128 bits	>= 128 bits
Public Keys (RSA)	< 1024 bits	>= 2048 bits with OAEP padding
Pseudo-Random Number Generators (PRNGs)	Statistical PRNGs	Cryptographic PRNGs

When it comes to computing hashes on security sensitive data such as passwords, certificates, or any other kinds of digital security credentials where collision and pre-image resistance are important, MD2, MD4, MD5, and SHA-1 are no longer recommended. Collisions have been found in MD2 as early as 1997, while attacks on MD4, MD5, and SHA-1 were demonstrated in 2005. Furthermore, a much more recent research project showed at the end of December 2008 that it is possible to mount a man-in-the-middle attack on Secure Sockets Layer (SSL) via creating rogue certificates issued by rogue Certification Authorities (CAs), only with the help of a homegrown array of machines. Combine this work with Dan Kaminsky's Domain Name System (DNS) problems, and you got yourselves virtually undetectable phishing attacks on the internet.

Similarly to hashing algorithms, a number of encryption algorithms have recently been broken: RC2, RC4, and DES. Worse yet, base64 encoding is mistakenly thought of by many as an encryption scheme. It is important to point out that base64 encoding is useful when there is a need to transmit binary data over a communication channel that is designed to transmit character data. However considering that its character space is only of size 64, the scheme does not provide the same security guarantees as strong cryptographic encryption algorithms, and therefore should not be used for protecting secrets.

In addition to choosing the right encryption algorithm to protect sensitive data, it is important to generate appropriate keys to use with these schemes. Considering that hardware has been getting faster and faster in recent years, choosing appropriate encryption key lengths is becoming increasingly important as the rate at which attackers can make guesses grows. The National Institute of Standards and Technology (NIST) suggests using symmetric keys (particularly, AES keys) of no less than 128 bits in length and RSA keys of no less than 1024 bits, moving towards using 2048-bit keys by 2013. In the case of RSA keys, it is also important to choose the right padding scheme, which can prevent a number of attacks that potentially work against RSA without padding. Public-Key Cryptography Standard (PKCS) #1 v.2.1 recommends the use of Optimal Asymmetric Encryption Padding (OAEP) for new applications.

As for the pseudo-random number generators, when unpredictability is critical, which is the case in security-sensitive contexts, it is important to use strong cryptographic rather than statistical PRNGs. Unlike cryptographic PRNGs, statistical PRNGs produce highly predictable output, which makes it trivial for an attacker to guess the values they generate. However, statistical PRNGs are acceptable when predictability is not a concern - for example, for generating a random order in which images are displayed in a slideshow.

Fortify Java Annotations

Thu, 12 Mar 2009 12:06:20 -0700

Fortify Java Annotations allow developers to give Fortify SCA hints about how their code works, which can prevent both false positives or false negatives. Like custom rules, annotations work by augmenting Fortify's model of the program with additional information and allow for more accurate analysis.

Consider the following code, which loads a password prompt for a login screen, logs it, and returns the loaded string to its caller.

private String loadPasswordLabel() {   String passwordLabel = props.getProperty("passwordLabel");    logger.info("Password label loaded: " + passwordLabel); // false positive!   return passwordLabel; }

A rule built into the Fortify Secure Coding Rulepacks causes Fortify SCA to guess that the contents of the variable passwordLabel are sensitive because its name contains the string 'password', which causes Fortify SCA to report a false positive privacy violation issue when the variable is written to the log.

The code below demonstrates how Fortify Java Annotations can be used to eliminate this false positive:

private String loadPasswordLabel() {   @FortifyNotPassword String passwordLabel = props.getProperty("passwordLabel");    logger.info("Password label loaded: " + passwordLabel); // no issue reported   return passwordLabel; }

The @FortifyNotPassword annotation informs Fortify SCA that the variable to which it is applied does not contain a password.

As of Fortify 360 2.0 and the Q1-2009 update to the Fortify Secure Coding Rulepacks, Fortify SCA recognizes the following Fortify Java Annotations:

Dataflow: Source, Sink, Passthrough, and Validation
Field and Variable: Password, NotPassword, Private, NotPrivate, NonNegative, NonZero
Other: Dangerous Class, Method, Field, and Variable and CheckReturnValue

The Security Fig Tree

Fri, 6 Mar 2009 16:37:48 -0800

Gunnar Peterson just posted an insightful response to a comment on a webcast that he and I (mostly he) did on SOA a while back. Most importantly, Gunnar reiterates the point that there's a big divide between most of the set folks with software knowledge and the set with security knowledge. Technology is great, and we're learning more and more ways to leverage it to productive ends, but arming the people responsible for building secure software with the right know-how is critical.

BSIMM

Wed, 4 Mar 2009 17:09:36 -0800

I've spent the last few months running around with Gary McGraw and Sammy Migues talking to organizations that represent the leading edge of software security. We talked to top software vendors, financial services companies, and technology companies. It's been fascinating for many reasons, not the least of which is how similar the leader's approaches are considering how different their businesses are. The result of these interviews is a new study we announced today called the Building Security In Maturity Model (BSIMM). BSIMM has it's own Web site. Take a look.

The meat of BSIMM is a set of real-world software security activities, all of which we observed in one or more of the organizations we studied. We've organized the activities so that you can determine where you stand with your software security initiative and how you can best evolve an initiative over time. Until now, the great majority of the published work in our field has been either small-scale (shown to works for one program or one programming team), or unproven (a bunch of good ideas that might or might not work outside the group that created them.) To my knowledge, this is the first real study of the software security practices across a range of successful organizations.

So far we've seen a warm reaction from the press and analysts. See this piece in the Wall Street Journal. But the best reactions have been from the participants. People have been really excited to see the results and learn about how they compare to their peers. We hope BSIMM will improve ties among the community of people who lead asoftware security initiative in their organization. We plan to continue adding new organizations to the model, so if you're interested, please drop me a line.

SHA-3 Analysis Details

Fri, 27 Feb 2009 17:25:48 -0800

For those who would like to know more about our SHA-3 analysis:
NIST SHA-3 Competition Security Audit Results

SHA-3 Round 1: Buffer Overflows

Fri, 20 Feb 2009 17:41:40 -0800

NIST is currently holding a competition to choose a design for the SHA-3 algorithm (Bruce Schneier has a good description of secure hashing algorithms and why this is important). The reference implementations of a few of the contestants have bugs in them that could cause crashes, performance problems, or security problems if they are used in their current state. Based on our bug reports, some of those bugs have already been fixed. Here's the full story:

The main idea behind the competition is to have the cryptographic community weed out the less secure algorithms and choose from the remainder. A couple of us at Fortify (thanks to Doug Held for his help) decided to do our part. We're not hard-core cryptographers, so we decided to take a look at the reference implementations.

This competition is to pick an algorithm, but all of the submissions had to include a C implementation, to demonstrate how it works and test the speed, which will be a factor in the final choice. We used Fortify SCA to audit the 42 projects accepted into Round 1. We were impressed with the overall quality of the code, but we did find significant issues in a few projects, including buffer overflows in two of the projects. We have emailed the submission teams with our findings and one team has already corrected their implementation.

Confirmed issues:

Implementation	Buffer Overflow	Out-of-bounds Read	Memory Leak	Null Dereference
Blender	1	0	0	0
Crunch	0	0	0	4
FSB	0	0	3	11
MD6	3	2	0	0
Vortex	0	0	1	15

One of the projects with buffer issues was MD6, the implementation provided Professor Ron Rivest and his team. All of the problems came back to the hashval field of the md6_state struct:

     unsigned char hashval[ (md6_c/2)*(md6_w/8) ];

The buffer size is determined by two constants:

     #define w md6_w     /* # bits in a word                   (64) */      #define c md6_c     /* # words in compression output      (16) */

At several points, this buffer is read or written to using a different bound:

     if (z==1) /* save final chaining value in st->hashval */           { memcpy( st->hashval, C, md6_c*(w/8) );             return MD6_SUCCESS;           }

Further analysis showed that ANSI standard layout rules would make incorrect behavior unlikely, but other compilers may have allowed it to be exploited. The MD6 team has doubled the size of the vulnerable buffer, which eliminated the risk. In this case, Fortify SCA found an issue that would have been difficult to catch otherwise.

The other buffer overflow was found in the Blender implementation, from Dr. Colin Bradbury. This issue was a classic typo:

     DataLength sourceDataLength2[3];	// high order parts of data length      ...      if (ss.sourceDataLength < (bcount | databitlen)) // overflow           if (++ss.sourceDataLength2[0] == 0) // increment higher order count                if (++ss.sourceDataLength2[1] == 0) // and the next higher order                     ++ss.sourceDataLength2[3]; // and the next one, etc.

The developer simply mistyped, using 3 instead of 2 for the array access. This issue was probably not caught because it would not be exposed without a very large input. The other issues we found were memory leaks and null dereferences from memory allocation.

This just emphasizes what we already knew about C, even the most careful, security conscious developer messes up memory management. Some of you are saying, so what? These are reference implementations and this is only Round 1. There are a few problems with that thought.

Reference implementations don't disappear, they serve as a starting point for future implementations or are used directly. A bug in the RSA reference implementation was responsible for vulnerabilities in OpenSSL and two separate SSH implementations. They can also be used to design hardware implementations, using buffer sizes to decide how much silicon should be used.

The other consideration is speed, which will be a factor in the choice of algorithm. The fix for the MD6 buffer issues was to double the size of a buffer, which could degrade the performance. On the other hand, memory leaks could slow an implementation. A correct implementation is an accurate implementation.

We will put out a more detailed report on all the results soon.

Gartner Magic Quadrant for Static Analysis

Wed, 11 Feb 2009 19:57:33 -0800

Today Gartner released its first ever Magic Quadrant on Static Application Security Testing (SAST). Here it is. I fought for them to call it Built-in Application Developer-Assisted Security Systems (BADASS), but professionalism appears to have won the day.

From an industry standpoint, this is a big deal. Gartner's recognition means software security has hit the mainstream. Gartner creates an MQ when an industry segment reaches $100M in total revenue. Then Gartner, as an independent organization, invites vendors to participate. No vendor pays for the MQ and Gartner doesn't charge for it. They evaluated ten vendors. Fortify took the top spot.

Its worth looking at the Gartner methodology to understand what that means. The report is primarily based on what Gartner hears from its clients. (Being an analyst is a good gig if you can get it.) Gartner talked to hundreds of people, not just the companies being evaluated. And customer input is the most influential factor. We had to answer lots of questions about our product and strategy, and I'm sure our sweet and soothing words didn't hurt, but this is not an essay test. Bottom line: it's what the market told Gartner. My favorite part: although static analysis was the focus of the MQ, the runtime components in Fortify 360 were the first thing they called out as Fortify's key differentiator. Satisfaction.

If you're already down with the Gartner crew, you should talk to the authors: Joseph Feiman or Neil MacDonald.

Hacker fall-out from Israeli-Palestinian conflict

Wed, 4 Feb 2009 21:09:58 -0800

This is retired Major Bruce Jenkins of the USAF commenting on cyber attacks originating from the Middle East.

Companies with even the remotest connections to the Middle East should be on guard against a malware or similar cyber-attack as a result of the ongoing conflict between Israel and the Palestinians.

Our observations suggest that a large number of Web sites have been defaced by a variety of hacker groups from Iran, Lebanon, Morocco and Turkey, and the trend is accelerating.

In the past, attacks were focused on the Department of Defense and other government organizations. But as the government, led by the US Air Force, have built up their cyber defenses, hackers need to move to less suspecting targets. Basically this means that any company with an Internet connection and which has perceived or rumoured connections with the two countries involved in this conflict - or has links with allegedly partisan firms who are also connected - could find their Web site and/or Internet- connected systems under active attack.

As a result, many tens of thousands of companies on the Web could find their hacker attack profile raised significantly, often for no good reason other than rumour and innuendo.

These sorts of attacks are random and reflect a hacker herd mentality. As a result, companies of all sizes should take extra precautions to protect their IT resources.

These precautions include ensuring your IT security, operating system and software patches are up to date, and monitoring the firm's network traffic for any unusual activity.

Given the fact that many Western leaders are urging all sides in the current Middle-Eastern conflict to stage a cease-fire and open diplomatic negotiations, most countries are now in the hacker firing line.

Given the fact that the Internet is so pervasive, I think we could see some very driven hacking and cracking attacks on all manner of targets. Companies of all types need to take precautions, especially as the Internet wakes up after the holiday period. Go here for an article on this subject.

No noticeable consequences for Monster.com breach -- This stuff drives me crazy!!!!!

Wed, 4 Feb 2009 20:17:48 -0800

So, apparently there have been little if any repercussions for the recent Monster.com breach. Society at large is starting to suffer from "security breach" a fatigue and customers are being told to believe breaches don't matter if SSNs aren't exposed. What will it take to finally get these companies to be accountable for AVOIDABLE losses?

This quote in particular sums it up: "And yet Monster might suffer little fallout - because the overall state of computer security is so bad anyway."

That kind of sentiment wouldn't be acceptable in any other industry. Oy!

http://www.google.com/hostednews/ap/article/ALeqM5g_bw5CTl4CQJz0y50UE_ebQRfJ8QD964UTIG0

Why they do it: RBS Leak Net $9Mill

Tue, 3 Feb 2009 18:46:41 -0800

So the fallout from the RBS breach last Nov. got the coordinator(s) $9 million bucks in just one day. The RBS breach is/was one of the cases PCI detractors like to point towards for failures of the standards and how we currently enforce those standards. In the absence of real consequences, attacks like these are likely to become more common place since the payout is so big.

http://blog.wired.com/27bstroke6/2009/02/atm.html

Google's Security Glitch

Sun, 1 Feb 2009 20:34:41 -0800

How do you take down The Google? They have lots of data centers, gobs of bandwidth, unrivaled peering, and a scary amount of compute power. A DDOS from your pimply nephew's botnet won't get the job done. The one force in the universe able to tackle The Google head on? Google Security! Their list of malicious web sites is so powerful that a single fat finger on a Saturday morning can essentially shut down Google search for the better part of an hour. (If you haven't read the story already, go here.)

This turns out to be an all-too-common failure mode for security mechanisms. If the security is powerful enough to do a good job of protecting you, it's probably powerful enough to do some real damage too. People make mistakes, and so sometimes the whole web gets marked as a purveyor of malware, and sometimes your anti-virus deletes applications like Excel.

And those are only the accidents. The more exciting cases are the ones where attackers turn the security system back on the people it's supposed to protect. My favorite from 2008 was the Maryland high school kids who figured out that they could fake up a license plate with a laser printer, drive by a speed camera, and give a speeding ticket to anyone they chose.

People have long known that locking accounts based on authentication failures can have the same sort of effect: if I don't like you, I can lock you out of your account until customer support opens on Monday morning. If I don't like customer support, I can lock out a few thousand users and sit back and enjoy the chaos.

The moral to the story: security features are just like all of the other features. If you haven't thought through what happens when they go wrong, you're probably in for a surprise. Security features sometimes get a free pass because somebody in the security group dreamed them up, and that's a recipe for trouble.

Confickering the Internet

Tue, 27 Jan 2009 16:27:25 -0800

Quite a bit of buzz has formed around a remotely exploitable buffer overflow in the RPC Server service of all modern versions of Microsoft Windows (2000, 2003, XP, Vista, 2008 and pre-beta 7). This vulnerability is the root cause a widespread worm, known as Conficker or Downadup, exploits to spread across Windows machines. This code has been a target time and time again for attackers seeking out remotely exploitable vulnerabilities in Microsoft systems.

As usual, the discussion in the community has been centered on the IT security response, often emphasizing identifying the worm on the network and cleaning infected machines. The justification for this emphasis is that now that Microsoft has found and fixed the bug, the biggest challenge is preventing unpatched machines from remaining or becoming infected. Clearly, this reactive approach is inadequate to protect users, roughly 10 million of whom are already infected with Conficker.

To draw a public health analogy, if Microsoft was better able to vaccinate its software against vulnerabilities like these from the outset, the patch/response cycle would become obsolete. Obviously, we cannot preemptively avoid every vulnerability; bugs in software are a fact of life. However, a strong software security assurance program that integrates security into software at every step in its development lifecycle can dramatically reduce the risk of serious vulnerabilities making their way into production software. Judicious application of the right security processes and technologies are the vaccine that will make worm outbreaks, like polio, a thing of the past. We've made a lot of progress over the last few years, but it's time for the security community and press to shift the balance to spend more time talking about prevention than about treatment.

Inside Job?

Wed, 21 Jan 2009 13:53:17 -0800

Heartland Payment Systems said Tuesday that hackers had compromised its computer systems and gained access to customer information related to the roughly 100 million transactions the company processes each month. Although the number of customer records that was compromised hasn't been disclosed yet, this breach is likely to give TJX, who exposed more than 45 million customer credit card numbers to hackers beginning in 2005, a run for its money as the largest breach of credit card data to-date.

The breach, the early signs of which Visa and Mastercard may have identified back in late 2008, was perpetrated using what investigators describe as highly sophiscated malware that specifically targeted Heartland. Since the means by which cyber criminals mounted this attack remain to be seen, it will be interesting to find out if the person or persons responsible were insiders, specifically out to get Heartland, or whether they were working as part of a larger effort.

Although there's no evidence yet this was an inside job, insider threats always pose a serious risk. Never has this risk been more acute than under the current economic conditions. When large groups of employees are fearful about layoffs and other hardships, employers often need to take stock of how they might be exposed if an employee with an axe to grind decided to leave something behind when they leave the company.

A few months ago, the Fortify Security Research Group (SRG) developed a custom rulepack specifically designed to help code auditors look for insider threats in Java web applications. The rulepack is available through Fortify Exchange, which is part of the Premium Content area of the Fortify Customer Portal. Currently, we're testing the rulepack with a group of interested customers to fine tune its detection capabilities and target a broader range of potential attack vectors.

Unexpected XSS Attack Vectors

Wed, 21 Jan 2009 12:52:17 -0800

In FreeBSD and UNIX, characters such as < and > are allowed in file names. As these characters are the main ingredients for a straight forward cross-site scripting (XSS) attack, it is not surprising that filenames can be used to exploit XSS vulnerabilities. An internal audit recently uncovered a vulnerability in the online photo album application Gallery, which allowed to use a specially crafted filename to exploit a XSS vulnerability. For example, uploading a picture with the name <script>alert('hi')</script>somefile.gif could exploit this vulnerability.

But the danger goes even further. Files can be archived in multiple ways, including ZIP, RAR, and other formats and some languages, such as PHP, provide functionality to display the contents of these archives. Therefore, even if it is impossible to upload a file with a malicious name directly, it may still be possible to upload an archive containing files, which in turn may serve as attack vectors. For example, the following zip file will lead to an XSS vulnerability when processed by the code below:

file.zip: (1) <script>alert('hi')</script>somefile.txt (2) ...

example.php: <?php $zip = new ZipArchive; $name = $_GET['name']; echo "The used zip file is " ; echo $name; $res = $zip->open($name); if ($res == TRUE) {      echo "Name index 0 is ";      echo $zip->getNameIndex(0);      $zip->close(); } else {     echo 'failed, code:' . $res; } ?>

This exploit is not restricted to Unix-based operating systems either, it suffices to create a valid zip archive containing these filenames. Malicious archives like the one above can be created on a Unix system and later be used to exploit a vulnerability on a different platform. Furthermore, malicious archives can also be created on non-Unix platforms by editing the internal filenames stored in the archive before it is distributed to potential victims.

The moral of the story is don't trust input. Even if a particular source of input has external constraints placed on it, such as the characters supported by a given file system, they might be altered or negated entirely.

Voting, Three Months Later

Thu, 15 Jan 2009 17:08:53 -0800

When we published a report on voting back in October, our conclusion included the line:

Just as important, we must not forget about election systems until October 2012.

So, what has happened since then?

Well, November wasn't a huge disaster, which is good. It'll be awhile before people start putting out reports that can really tell us how things went but we have a result that no one can really dispute (at least in the presidential election - I'm just going to ignore Minnesota for now).

But since November, we've seen some interesting stuff. Everyone's favorite whipping boy, the-company-formerly-known-as-Diebold (Premier Election Solutions), has been in the news. The state of Maryland is suing the company for the $8.5 million they spent fixing security problems with the $65 million of touch-screen machines they bought in 2001. Meanwhile, controversy is brewing in California over tabulation software Diebold knew would randomly delete ballots.

I'm going to be an optimist for a moment and explain how these articles actually point to some positive steps:

Maryland admits there are problems and has worked toward fixing them based on independent expert advice. One disturbing thing we found when we looked into the electronic voting security was that election officials tend to trust the voting manufacturers over security experts. I'm fully aware that this change of heart in Maryland is the result of a lot of bad publicity and lawsuits directed toward the state, but it's progress.
Maryland is making Diebold pay for it's mistakes. This is the only way we will see these companies produce better products - by making it expensive and impractical to do otherwise.

In California:

They figured out the ballots were missing because Humboldt County has implemented a public auditing program. All of the ballots included in the tally are scanned and posted online to allow anyone to do their own count. During this process, they discovered they had more scanned ballots then the system reported. This sounds like a pretty good rebuttal to those who keep insisting there is no need for a physical verification mechanism. It also sounds like a great program, I'd love to see this done more widely.

Of course, these articles also point to underlying screw-ups, but I'm going to focus on the possibility that these steps will lead to more steps and we'll be in a different place in October 2012.

Voting, Three Months Later

Thu, 15 Jan 2009 16:12:03 -0800

When we published a report on voting back in October, our conclusion included the line:

"Just as important, we must not forget about election systems until October 2012."

So, what has happened since November? Everyoneâs favorite whipping boy, the-company-formerly-known-as-Diebold (Premier Election Solutions), has been in the news. The State of Maryland is suing the company for $8.5 million spent fixing security problems with touch-screen machines they purchased in 2001 leading up to the 2008 election. Meanwhile, controversy is brewing in California over tabulation software that not only is known to randomly delete ballots, does not log such actions. However, Iâm going to be an optimist for a moment and explain how these articles actually point to some positive steps: - Maryland admits there are problems and has worked toward fixing them based on independent expert advice. One of the overwhelming problems we found when we looked into the electronic voting security is the disturbing tendency for election officials to trust the voting manufacturers over security experts. Iâm fully aware that this change of heart in Maryland is the result of bad publicity and lawsuits directed toward the state, but itâs progress. - Maryland is applying economic pressure. This is the only way we will see these companies produce better products, making it expensive and impractical to do otherwise. In California: - This problem was found because Humboldt County in California has implemented a public auditing program. All of the ballots included in the tally are scanned and posted online to allow anyone to do their own count. During this process, it was discovered the official count different from the number of scanned ballots. This sounds like a pretty good rebuttal to those who keep insisting there is no need for a physical verification mechanism. It also sounds like a great program, Iâd love to see this done more widely. Of course, these articles also point to underlying screw-ups, but Iâm going to focus on the possibility that these steps will lead to more steps and weâll be in a different place in October 2012.

CWE/SANS Top 25 Most Dangerous Programming Errors

Mon, 12 Jan 2009 18:27:34 -0800

Over the last few months I have worked with a group of software security experts to develop the CWE/SANS Top 25 Most Dangerous Programming Errors. Working on this project has got me thinking about a key point that we make in Secure Programming with Static Analysis: Most of the people who build software are focused on things other than security (writing code, running test cases, deploying applications, and so on). These people are making security-critical decisions on a daily basis, but they can't afford to become security experts--they've got other things to worry about.

Security is a complicated field and we can't expect everyone to become experts. Software developers and architects, quality assurance testers, and operations engineers all have a wide range of responsibilities. As an industry, our best chance to develop secure software is to get non-experts making meaningful contributions.

We must enable non-experts to get security right. This means arming them with the right processes (building security into the software development lifecycle from the ground up), skills (teaching people to ask "What could go wrong?", not arcane security specifics), and tools (deploying static analysis in development, runtime analysis in QA testing, and active defenses in deployment).

The winds of change are blowing in the right direction. Top universities across the country are beginning to offer courses that either address or focus entirely on software security. Fortify currently works with over 50 universities by helping them incorporate software security into their course offerings and by granting them unrestricted academic licenses for classroom and research purposes. This offer is open to any college or university who wishes to participate.

Despite a sunny outlook, most people building software today have received no formal training on software security. Projects like the OWASP Top 10 and the CWE/SANS Top 25 focus attention on the problems that are causing the most pain, serve as fodder for training programs, and generally increase awareness among non-experts. Let's hope that projects like these continue to carry the banner for software security into the 21st century.

Reality Check

Mon, 12 Jan 2009 16:40:54 -0800

Masochist McGraw has gone and signed himself up for a second podcast: Reality Check. I was an early victim of his original Silver Bullet series: listen here. Reality Check is all about practitioners, and the first interview is with Steve Lipner. Steve runs the SDL group at Microsoft. A strong way to get started.

The Vista Blame Game

Fri, 9 Jan 2009 10:20:15 -0800

CNet talking to Steve Balmer:

CNET News: Obviously, Microsoft didn't necessarily get everything it might have hoped for in terms of the critical response for Vista. What are you guys planning to do differently with Windows 7?

Ballmer: Well, I think we made some choices in Vista to improve security at the kind of expense, if you will, of compatibility. ...

I get nervous when I hear someone say "Our product flopped because we put in too much security" especially when there's no way to know what kind of train wreck it would have been if they hadn't gotten serious about security. We often hold up the Gates memo as the Platonic ideal for executive buy-in, but "when we face a choice between adding features and resolving security issues, we need to choose security" is what got us Vista. Let's hope people understand that, had they chosen features, there wouldn't have been an XPSP2 either, and that would have been an even bigger world of hurt as people fled to other operating systems, or simply decided that computers weren't a reliable way to do business.

Twitter Continues to Be Caught With Their Pants Down

Wed, 7 Jan 2009 01:17:33 -0800

Ok, so Twitter may not be suffering as much as this poor guy, but Twitter should be equally embarrassed. Within the last 30 days, Twitter has had several high profile security incidents: an unintentional direct message leaks, an ongoing phishing attack, and now a hack of at least 33 high-profile accounts. Unfortunately neither Twitter or the reported perpetrators are giving specifics about how the hack was pulled off (I'll gripe about that at some later date), so we can't discuss ways to mitigate and prevent such attacks. However, we can expound on what we do know and why this compromise was potentially catastrophic for Twitter.

So, what happened?

By reading Twitter's own post, we can conclude that some of Twitter's admin functionality were compromised. The admin tool allowed the support team to edit an account's email address. This seems innocuous enough, right? In this age of multiple work, school, and personal email addresses, it's not surprising for a user to forget the address used during registration. Twitter's support tool was created just to handle such a scenario. Unfortunately for the Twitter team, though, they forgot to not only ensure that the admin tool was only accessible by their support staff but that the admin tools were designed with security in mind. Sadly, many companies don't realize that the administrative portions of their applications are prime targets for malicious users. In Twitter's case, the admin tool allowed a malicious user to change the targeted account's email address to an attacker controlled email address. The attacker could then use Twitter's "Forgot Password" link to have a new password emailed to the attacker controlled email address. Using a system's password reset functionality to compromise an account sounds pretty familiar to the Sarah Palin "hack" (and I use the term "hack" lightly) not too long ago.

So, why is this such a big deal?

Fundamentally, Twitter is a communication transport and as such, users not only expect data integrity ("Did what I write actually get communicated?", "Did I receive what was actually written?") but also data authenticity ("Did I receive this message from the real author?"). [Apologies to all the cryptographers out there for the over simplification] While Twitter is limited in their ability to verify the account owner's real-life identity, Twitter *is* responsible for the authenticity of the accounts on their system. Their current solution is the traditional username/password that we're all familiar with. However, if Twitter's administrative tools were compromised (as their own posting alludes to), Twitter failed to provide that authenticity since malicious users were able to change account passwords. While the attack was occurring, Twitter was unable to guaranty the authenticity of the messages being sent out to the millions of followers of the celebrities that were targeted. During those few hours, Twitter essentially ceased to be.

That is why getting security right is so important.

Driven by the adoption of several tech luminaries and jettisoned by the mainstream adoption of a group of high profile celebrities that even your mother would recognize, Twitter has had a meteoric rise within the social-networking field. Being a start-up, can Twitter really afford to be constantly putting out security fires? How do these incidents impact their ability to attract more users? Better yet, what will these incidents do to their user retention? Twitter's "microblogging" service isn't too different from Facebook's status messages. Most of the targeted accounts also have Facebook accounts, a switch of platform would be very low effort for them. Could Twitter go the way of their competitors because security vulnerabilities cause users to lose faith?

postmortem, scriptkiddies, twitter

Tomcat Does Not Love You

Sun, 4 Jan 2009 22:20:15 -0800

Java String objects are immutable, so you can't guarantee sensitive data is removed from memory if you put that sensitive data in a String object. Once data is in a String, it's up to the VM to deallocate the object and then put it back into play as something else, and that might happen sooner, later, or not at all.

That's why paranoid Java programmers don't put secrets (passwords, crypto keys) into String objects. Instead, they treat them as arrays of bytes or characters so they can manually zero out the juicy stuff. At first blush, it appears that Tomcat supports this level of paranoia in the org.apache.catalina.Realm interface:

    public Principal authenticate(String username, byte[] credentials)

But the RealmBase class, the base class that everyone actually uses, just yanks the rug right out from under your feet:
org/apache/catalina/realm/RealmBase.java:

  342       public Principal authenticate(String username, byte[] credentials) {   343      344           return (authenticate(username, credentials.toString()));   345      346       }

Yup, that's right, it converts your credentials (read: password) from a byte array into a String. It would be unthinking for Tomcat to provide no way to authenticate without using a String, but providing an interface and then intentionally subverting it seems like calculated cruelty.

Kingdom of the Future

Tue, 23 Dec 2008 23:48:33 -0800

Microsoft has an excellent security culture. Case in point: Michael Howard posted an in-depth explanation of the latest Internet Explorer bug including the key piece of code involved. Read it. Most organizations go to extraordinary lengths to bury a failure as quickly as possible, but Microsoft seems to understand that they have to really understand their failures if they hope to avoid repeating them.

But the big news here is the bug itself. It was use-after-free caused by a thread safety problem. C++ failed twice in one fell swoop: first, the programmer was forced to do direct memory management, and surprise surprise, eventually an object gets freed while there's still a pointer to it. Second, the use-after-free allowed an attacker to execute arbitrary code. That's a pretty high price to pay for a mistake in code that wasn't supposed to have anything to do with pulling in outside instructions, but that's the way it goes in C++.

But even with a better programming language, thread safety is a tough problem. If you're writing in Java or C# or Ruby a thread safety problem probably won't cause you to end up with a vulnerability that allows arbitrary code execution, but you might inadvertently allow one user to see another user's data, and that's plenty bad. Back in 2005, Katrina Tsipenyuk, Gary McGraw, and I wrote a paper titled Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors. We lumped this kind of race condition together with errors caused by distributed computation and called them problems related to "time and state". In the presentations I gave on the paper, I always referred to Time and State as the kingdom of the future, because we're only headed for more CPU cores, more threads, and more interconnected systems, and that means more opportunities for getting out of sync.

Penetration Testing is Dead, Long Live Penetration Testing

Mon, 15 Dec 2008 15:39:04 -0800

Last week, in a CSO magazine article titled Penetration Testing: Dead in 2009, I said that penetration testing is undergoing a transformation - it's going to die and be reborn as part of a more tightly integrated approach to security. This week Ivan Arce responded in defense of penetration testing in a CSO article titled Twelve Reasons Pen Testing Won't Die. Ivan is a class act, which is why his article isn't titled "12 Reasons Brian Chess is a Ninny." But Ivan doesn't address the core of my original argument, so I'm going to further explain myself here. Let me start by saying this: if you misread the original article to mean "on Jan 1, 2009 all penetration testers are going to go out Jonestown-style", then you need to keep reading.

It's December. For me that usually means my travel schedule winds down, I spend more time doing family stuff, and I start thinking about what I'm going to do next year. This year the travel hasn't let up, and as for the future, all I can think about are the things Gary McGraw, Sammy Migues and I have learned interviewing executives at some the world's top software security programs. We're in the process of building a maturity model out of the data we collected, but some of the stuff we learned is too good to wait. We wrote up a Letterman-style Top 10 Surprises article this month. Check it out.

For me the biggest surprise was about penetration testing. Penetration testing is one of the first things many organizations do when it comes to software security. I believe it to be universally true that if you're not paying attention to security, you have security problems, but it seems most people like to pay a penetration tester prove it to them. Now here's the surprise: as organizations get better at software security, their emphasis on penetration testing diminishes. In most cases it doesn't disappear, but it does get wrapped into a much larger and much more comprehensive approach to improving security. The best initiatives balance the yin and the yang of attack and defense.

We passed an inflection point last year. People are now spending more money on getting code right than they are on proving it's wrong. (More on that here.) This isn't the end of the road for penetration testing, but it does change things. Rather than being a standalone "product", it's going to be more like a product feature. Penetration testing is going to cease being an end unto itself and reemerge as part of a more comprehensive security solution. This kind of thing happens all the time in high-tech. The first PC spell checkers were standalone programs, but the market for stand-alone spell checkers died when they became a standard part of any word processor. These days spell checkers are everywhere (even in my IDE), but there is no market for a standalone spell checker. Proof positive: there aren't even any Web 2.0 or iPhone spell checker startups!

Alright, so why 2009? The time is right because back in 2007, IBM bought a company named WatchFire and HP bought a company named SPI Dynamics. The acquired companies both made web application penetration testing products. IBM and HP spent serious money for these companies'not crazy dotcom prices, but even at HP and IBM you have to have to tell a good story before you get to spend north of seventy million dollars. The good story was that the acquired technology would work together with other products and services to fuel a broad entrée into a rapidly growing software security market. It takes a little while to digest any acquisition, but by now it's been long enough. 2009 will be the year this strategy comes together, and when we look back, it will be the year when most of the world began thinking about penetration testing as part of a larger offering. There will always be boutique security consulting companies with funny names and exotic services, but the industry will grow by integrating security yin and yang. If you'd like a sneak preview of what the future holds, check out the work White Hat Security has done to integrate their vulnerability measurement service with Web application firewalls. This is attack and defense working together in a creative new way.

More than ever before, people understand the software security challenge, and penetration testing deserves credit for helping spread the word. But knowing a security problem exists is not the same as knowing how to fix it. In other words, penetration testing is good for finding the problem and bad for finding the solution. Just like the venerable spell checker, it's going to die and come back in a less distinct but more pervasive form.

Start State

Thu, 30 Oct 2008 15:14:11 -0700

It's easy to visualize a world where you can actually trust the software you use. In fact, a lot of people try to pretend they live in that world right now! While the end state is easy to imagine, a lot of organizations have a lot more trouble figuring out how to exit the start state. In other words, what do you do first? How will you know if you're making progress? How do you know when you've arrived?

We're going to try to answer some of those questions by creating a maturity model for software security. Based on a first draft created largely by Pravir Chandra, we've set up a software security framework. Check it out here.

Now the data are starting to roll in. Gary McGraw, Sammy Migues, and I just finished our first round of maturity model interviews. We're talking to the people in charge of some of the most successful initiatives in the world and mapping what they've accomplished into the framework. We've got a huge amount of work in front of us, but the results are already fascinating.

Space Race

Fri, 12 Sep 2008 23:02:24 -0700

McGraw has published his roundup for the software security space in 2007. Lots of juicy numbers. Here it is.

Mark 2007 on your calendar--it was a turning point. It was the first year there was a bigger market for products that help you get code right than there was for products that help you demonstrate a problem exists.

The Empty Debate over Open Source Security

Thu, 31 Jul 2008 16:46:25 -0700

Last week, Fortify published a study on adoption of security best-practices within the Open Source community. Given mounting risk posed by extensive use of Open Source technologies within business and government IT, we were gratified to see the passionate discussions that followed. Unfortunately, much of that debate was simply a rehash of tired old themes that we must move beyond to make substantive progress in assuring security of Open Source software. These debates reveal the underlying problem: a lack of understanding and collaboration between developers and security experts – today each are talking past each other when it comes to security.

Three all-too-familiar debates have resurfaced:

The naïve notion that a software package’s "Open Source" or "Commercial" basis will somehow have an impact on whether it is secure or not.

This week the old "Open Source (or Commercial) software is more secure" feud rose again. The fact is, any development team that accepts security as an engineering objective can deliver it just as they can functional, quality, or performance objectives. Security is a choice not a birthright. It does not come 'for free' because of the way you license your product. However, if security objectives are not clear and secure development methodologies are not in place, it’s a pretty safe bet that security problems will result. Does the Open Source or Commercial software world have an exclusive on building things right? Of course not. Over the last decade, Fortify, has worked with hundreds of development organizations establishing, and in many cases, defining, engineering processes that assure application security. Originally limited to the elite world of global banking and military, we now see a broad range of organizations joining these ranks. Ironically, this is an area where the IT development community is ahead of both the Commercial and Open Source, leaving neither bragging rights on which is most secure.
The erroneous idea that eliminating security flaws is a distraction and somehow less (or more) important than tackling functional, quality or performance issues.

We have heard the argument that vulnerabilities are just another bug in the code. Emblematic of this viewpoint was Linus Torvald’s recent rant. The fact is, Quality and Security are not the same; both important, but not the same. Poor quality is obvious to the user who genuinely wants your software to work. Security is an invisible property to all but an expert who is intent on harming your system. QA is a positive testing exercise (ensuring software does what its supposed to do) focusing on the "mainline" placing less emphasis on "corner cases". Security Assurance is often a negative testing exercise (ensuring software does not do what it is not supposed to do) where the corner cases are certain to be explored by an attacker. Quality Assurance depends heavily on alpha, beta, and GA users to report problems. Outside of a small group of security researchers, there are few cases of hackers filing bugs on vulnerabilities. I could go on for several pages, but I think the point is clear: quality and security (and performance, and features for that matter) are important and should be represented equally in a sound engineering practice.
The reflexive accusations that any security comments on Open Source software is an affront to the entire Open Source movement and similar to "yelling fire in a crowded theatre".

There are definitely case of bad behavior with security "researchers", with no intention of fixing problems, pointing out specific vulnerabilities for a taste of short lived fame -- what Marcus Ranum calls, "vulnerability pimping." Developers naturally react negatively to this kind of grandstanding. Unfortunately we have also reached a state where even the most rational productive discussions around security and Open Source result in a loud cry of foul. The best of these discussions sound like a mother nagging a teenager to clean their room. That must change and become a collaborative inquiry into how we can do better. This starts with development organizations taking responsibility for security and security experts productively helping them achieve their goals.

As the sponsors of Java Open Review, Fortify supports the ongoing security assessment and remediation of over 100 open source projects –without publicly disclosing a single issue. We do this because we have a vested interest in ensuring that 3rd party components used by us and our customers are secure. We use many of these components ourselves in systems with extreme security requirements. Our customers build financial systems that entire economies depend upon, military software with life and death consequences hanging on data integrity, and all build systems that are critical to their organization.

At Fortify, we know the solution is developers and security experts working together to build software right from the start. We are already working with several projects in the report and look forward to proving that security experts and software development teams can work together effectively.

Secure code for the iPhone

Fri, 14 Mar 2008 14:49:33 -0700

Seems like we security people don’t get to celebrate a victory nearly as often as we get to learn from defeat, so please take a moment to enjoy some good news. I’ll try to prolong the moment by saying this: I spend a lot of time telling programmers that they are no longer in a position where they can pretend that security isn’t part of their jobs, but my message is contravened by most of the training material programmers see. Whether it’s documentation a new framework, library, or platform, the standard play is to pretend that security doesn’t exist. No mention of what you need to do in order to make your code secure. No mention that security is anything other than a user name and a password. I’m happy to say that Apple is bucking this trend.

Apple opened up the iPhone for third party applications last week. That means they’re providing programmers a software development kit and instructions on how to write code for the iPhone. On the home page for iPhone development, they have a list of common coding questions such as “How do I debug my application?” and “How can my application detect motion?” At the bottom of the list is “How do I write secure code?” The answer links to a secure coding guide that discusses topics like validating input and avoiding buffer overflow as well a discussion of the security services the iPhone’s OS provides. Nice.

(In order to browse the links above, you have to register as an iPhone developer. It’s free. Go here.)

Bye-Bye Disk Encryption

Thu, 21 Feb 2008 22:00:44 -0800

Ed Felton and the gang at Princeton have struck again! This time they've figured out how to defeat the disk encryption schemes built into Vista, MacOS X, and others. The attack works because the values held in RAM don't disappear instantly when a computer is switched off. They decay slowly over a period of seconds, and that can be extended to minutes with a little bit of coaxing. That's long enough to boot up a second OS and read out the contents of memory. After that, it's just a matter of extracting the crypto keys, and the game is over. Awesome work. Read about Cold Boot attacks on Encryption Keys.

If there's a lesson to be re-discovered here, I think it's the amazing way we end up building security systems on what seem to be solid ground (as in "computers forget stuff when you turn them off"), and only when it's too late do we find out that our premise was strong enough for trying to explain computers to someone like your old uncle Hugo, but not strong enough to adequately secure your data.

It appears to me that this attack is still too sophisticated for the average thief who steals laptops in coffee shops, but it's plenty easy for the forensics guy down at the police station.

The New (De)face of Cybercrime

Tue, 19 Feb 2008 11:16:15 -0800

Some inspired soul has reworked the New Face of Cybercrime trailer. Watch this. My favorite bit: the cat and the baby.

Secure Programming Makes the Rounds

Sat, 16 Feb 2008 18:45:57 -0800

It's been a while since Brian or I posted anything about Secure Programming with Static Analysis, and Gary McGraw's mention of the book in his recent article on Dark Reading seems like as good an excuse as any. Gary concludes his post, The Truth Behind Code Analysis, with the following:

"If you’re interested in static analysis for security (and you should be), buy and read Secure Programming with Static Analysis by Brian Chess and Jacob West."

The book was also recently reviewed in a recent blog post by the folks over at the Denim Group.

And the following are just a few of the other relevant mentions it has received:

I've also been (pleasantly) surprised by how much interest we've gotten in the warez scene. I won't post those links, however.

WTFs/Minute

Wed, 6 Feb 2008 10:33:30 -0800

We don't get that many cartoons about code review, so when a new one crops up, it's cause for celebration. If you don't think it's hilarious, you need to do more code review. Many thanks to Mark Curphy.

SATE

Mon, 4 Feb 2008 23:36:54 -0800

NIST has announced what they call a Static Analysis Tools Exposition (SATE). Participating static analysis tools will be used to analyze a small set of programs selected by NIST. Eventually all of the results will be made public. I like the idea a lot, and I'm going to make sure Fortify takes part in both the C and Java tracks.

Running a bunch of programs against the same test cases might seem like a straightforward exercise, but it's not. Finding an even-handed way to examine complicated tools is tough, and the fact that NIST is emphasizing the detection of security vulnerabilities makes it that much tougher. (Tell me again, what exactly constitutes a "vulnerability" in source code?) Just browse through the steps in the SATE protocol to get a feel for the complexity involved.

To make the exercise even more difficult, everyone who makes a tool can't help but worry that they'll come out looking bad. After all, this sounds a little bit like the setup for a product review. We've seen those before. (Here's a link to the one Network Computing did in the middle of 2007: link.) Product reviews generally have winners and losers. NIST says they'll work hard to avoid these kinds of labels, but it's not going to be easy. All of this makes test case selection a touchy subject, and comparative presentation of the results is an absolute minefield.

The problems are many, but there's also a lot to be gained. Here are the three reasons I'm looking past all of the complexity and anxiety and participating in SATE:

People who want to run their own tool comparisons will benefit. You might like the way SATE works or you might not, but you'll be able to see what they did and where it took them.
Tool builders will benefit. Static analysis for security is a hot topic in both industry and academia. The results will give us a little bit of insight into which problems we've conquered and which ones require more work.
The security community will benefit. Being able to compare output from different tools will give us a better idea about how the tools classify code, and my guess is that we'll learn that our nomenclature still needs improvement. Better nomenclature makes it easier to talk to the 99% of humanity that doesn't think about software security every day.

They Set the Wii Free

Tue, 29 Jan 2008 23:49:17 -0800

It appears that a buffer overflow vulnerability in The Legend of Zelda for the Wii, and that’s all hackers need in order to run their own code on the machine. Here’s the scoop.

Pretty soon this will mean game pirating for the Wii without the need to get out your soldering iron. That’s important if you want to get people to steal games in the same casual manner they steal music. Piracy is a big deal for all modern gaming platforms because most of the money comes from software (games) not from hardware.

Apple has run into similar trouble recently. It seems that more than a million iPhones have been unlocked, and I think it’s safe to assume that it’s mostly happening using the simplest mechanism out there, a web site that exploits a buffer overflow in the iPhone. That means Apple is missing out on their cut of the phone subscription going to AT&T, and that has to hurt. The moral to this story is this: if your business relies on the security of your software, you’ve got two choices:

Design a system that will be secure even when people discover a few bugs.
Make sure you don’t have even a single bug.

Neither of those options is easy, but creating a robust design not nearly as hard as creating a flawless implementation.

Analyzing the Analyzers: Looking at Source Code for Breathalyzers

Mon, 28 Jan 2008 11:25:33 -0800

For as long as there have been breathalyzer machines, DUI suspects have been looking for creative ways to beat them (see newspaper clipping below.) The latest trend is to go after the source code. Here are three recent cases:

August 2007: Minnesota Supreme Court rules that source code must be revealed.
December 2007: Source code analysis in New Jersey class-action breathalyzer case.
January 2008: Kentucky appeals court rules that source code must be revealed.

My favorite anecdote so far comes from the New Jersey analysis. One of the teams used Fortify to analyze the code, and lo-and-behold, they found a buffer overflow vulnerability! This raises the possibility that if you mix just the right cocktail at just the right time, you could craft an exploit. (Dream on.)

The real lesson here is that our legal system is waking up to the importance of code. If the code isn’t trustworthy, the outcome isn’t trustworthy either. (Electronic voting machine vendors, you might want to read that last line again.) If the code provides evidence that the programmers weren't being careful, that's going to be bad news for the vendor.

The Checklist

Fri, 25 Jan 2008 06:54:42 -0800

“What do you do when expertise is not enough?”

Atul Gawande

Hundreds of little decisions per day. Screw up any one of them, and disaster could ensue. Smart and highly trained professionals who know what to do, but who aren’t always focused on the details. A transition from a cowboy mentality to an emphasis on a boring but safe and repeatable process.

Sound like the hymn of software security? It does indeed, but it’s also the way Atul Gawande describes modern intensive care units in his article The Checklist. Intensive care units appear to suffer from many of the same problems the software community faces. Too much complexity creates too many opportunities for error. Little mistakes lead to complications, and those complications can, quite literally, kill.

As with software, there is no easy or complete answer to the problems doctors face in the ICU, but the surprising finding this article points out is that a simple tool, the checklist, is enormously effective. Arm nurses with a five step checklist for avoiding an infection when inserting a line, and secondary infection rates plummet.

Do programmers in your organization have the equivalent for common security-sensitive operations? Maybe those cross-site scripting errors keep popping up because there’s no template to guide programmers as they create new code. If you’re still casting around for one or two more new year’s resolutions, resolve to give programmers good examples they can follow. In the book, we try to give a positive, correct, and secure code listing for every broken, bad, or vulnerable piece of code we discuss.

Getting Started

Mon, 14 Jan 2008 12:52:33 -0800

Software security can be hard to talk about, sometimes because people who make software are an incredibly diverse bunch. I’m not talking about globalization, I’m referring to the fact that the term “software” covers a lot of ground. Building operating systems, web sites, cell phones, and airplanes all require major software chops, and they all require an understanding of security, but they are very different undertakings.

If you’re talking to someone about the new software security initiative you just got off the ground, the result can be wild confusion before you figure out that the other person’s take on what a “software security initiative” means is completely different than your own. I like McGraw’s latest DarkReading column because it gives a nice overview of the different ways people get started.

Has Online Banking become Safer than Offline Banking?

Mon, 29 Oct 2007 07:21:37 -0700

Last summer, I gave a talk about online banking: http://www.aipsi.org/eventi/download/agenda_issa_rome_2007.pdf (PDF)

After the talk, a CSO from a major bank came up to me and said,

"Great presentation, but you missed one key thing: banking online is safer than banking offline."

Seems counter intuitive. Doesnt it?

Banking online can be scary because:

Hackers have global reach, If you're doing offline banking in California, you only need to be worried about bad guys in California, for instance the customers and employees present in your local branch. If you're banking online, anyone in the world could attack you and your assets.
Automation - in the physical world attackers are limited by their ability to manipulate physical items like making an extra copy of your account number. In the online world attackers are essentially unlimited in the resources they can bring to bear.
Online security is opaque to the end user. People who aren't particularly tech savvy have a tough time differentiating between good online security practices and bad online security practices. Security in the physical world is much more intuitive for most people- keep your checkbook in a safe place or don't let someone peek when you are entering your PIN.

How can someone argue that online banking is safer?

The first issue: what is the root cause of financial fraud? According to the 2007 Javelin online banking security report (PDF), more than three-quarters of fraud actually comes from offline factors. As the chart below highlights, physical means of exposing personal information are the most common. Online methods, such as spyware or phishing, accounted for significantly fewer breaches. The leading factors are under the consumers control: lost or stolen wallets, credit cards, checkbooks or friends and family.

The second issue: self-detection. If consumers can detect someone sucking money out of their account, then the fraud amount is usually the smaller. As the fraud survey noted, almost half of fraud discovery continues to be done by consumers which as a group average quicker times to discovery and lower fraud amounts. If consumers can spot incorrect activity faster there' less fraud. The Javelin report also highlights that if a consumer uses electronic monitoring, the average time to detect a problem is 22 days whereas it's only 12 days longer if you receive a monthly statement via snail mail.

The third issue: fraud size. According to Credit Union.coop, the median online fraud is $195. For offline fraud, according to Javelin, the average consumer fraud cost is $422, nearly double the online average.

What the numbers don't tell you

A short history of online banking might be useful. The first bank in the world to offer online banking was Wells Fargo in 1995 and it sparked a mad rush to get onto the Internet by both competitors such as Bank of America and upstarts like e-Trade. In the early days, security took a back seat to release dates. The flurry of negative headlines from this period illustrated the consequences of putting security on the backburner. While the banks were down, they weren't out. As Andy Grove said, "A fundamental rule in technology says that whatever can be done will be done." So what did they do?

The banks realized something basic: if the banking infrastructure or software applications are compromised, then every account would be compromised. Or, "It's the application, stupid."

The strategy of locking down the applications paid off as evidenced, ironically, by the rise of phishing. Since direct hacks against banking systems became very difficult, cyber criminals resorted to phishing consumers with dubious emails. While phishing schemes are a growing, major problem today, they pale in comparison to the potential impact of the breach of core systems. And here's the paradox that most people miss: phishing forces the hacker to follow the slow, painful process of compromising accounts one at a time.

Could online banking be like flying? Statistically, it's safer but it's just psychologically scarier.

To learn more about how online banking became more secure, read Fortify's whitepaper.

Off by On

Blog moved

150 ways to bypass ordinary WAF's but not ours, by design!

Understanding XSS (Cross-Site Scripting) Findings in SCA

Why Doesn’t HTML Encoding Mitigate XSS in All Contexts

HTML encoding in a URL context (the payload is “javascript:alert(123)”):

HTML encoding in a JavaScript event handler (the payload is “javascript:alert(123)”):

If your application is outputting XHTML then the following will still pop even though all of the javascript code is HTML encoded (the file extension must be *.xhtml or the content type has to be set to "application/xhtml+xml"):

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<script type="text/javascript"> &#x61;&#x6c;&#x65;&#x72;&#x74;&#x28;&#x31;&#x31;&#x29;</script>

</head>

<body>

<div>TODO write content</div>

</body>

</html>

So HTML encoding will not mitigate XSS in all contexts and cannot be trusted as a complete solution to XSS. First question down, let’s move to the second question.

Why SCA Doesn’t Identify Custom Encoding Methods

Why SCA Doesn’t Understand the Context in which Untrusted Data is Output

Conclusion

Format Strings: Is Objective-C Objectively Safer?

Presenting “Code Reviewing Web App Framework Based Applications” at Blackhat

Are Race Conditions the New Buffer Overflows?

PCI DSS 2.0 Support Handles Change from Best Practices to Requirement

Software Security and ABAP ?

Q2 Update from HP Software Security Research

HTML5

RTA Customization: The power of being inside the application

The Emerging WebSocket Protocol

Mass Assignment - It's Not Just For Rails Anymore

Model Objects

Auto-binding of Request Parameters to Objects

Identifying the Problem

Where Developers Assumptions Go Wrong

Addressing the Problem

Blackhat Europe 2012 roundup

RSA : End to End Security

RSA Roundup: SSL, and How to Annoy Your Attackers

Secure in 2010? Broken in 2011!

Vulnerabilities Enabling Mobile Exploits

RSA Cryptographers’ Panels

Q1 2012 Update

Browser Based Reflected XSS Protections

Mobile Operating Systems and their Role in Security

Valentine's Hacker

Handling Session Statically

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

Web Server DoS by Hash Collision

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

Code Execution

Attack strings in URLs

Escaping and blacklisting characters are insufficient

Let’s Talk About Overprivilege

Application Frameworks and Static Analysis (Part Zwei)

Framework Specific Vulnerabilities (Error Prone APIs)

Framework Specific File Disclosure

Conclusion

Watch Us on YouTube

Application Frameworks and Static Analysis (Part Ein)

Architectural Flows and Components

Dataflow Analysis

Conclusion

Q4 2011 Rulepack Update

From an Undisclosed Location in Washington State

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

Common Pitfalls in Custom Rules -- constantValue and null

Misunderstandings on HttpOnly Cookie

Brakeman

Reflections on Mobile Trends

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

BSIMM 3

Cyber Security and Kids

FoD 3.0!

The Perils of Encodings

Converting Strings to Bytes and Vice Versa

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

Summary of the Problem

So What The Heck Are We Supposed to Do?

For references on how the ASCIIEncoding object encoder works:

<script type="text/javascript"> alert(11)</script>