Off by On

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.