[Today we have our first guest blog entry from Elfriede Dustin. Elfriede is a co-author of "The Art of Software Security Testing" and has written a few books on software testing, most notably, "Automated Software Testing" published by Addison-Wesley in 1999. We have heard plenty from security experts on how to fix the software development process to produce more secure software. Elfriede brings a QA practitioners viewpoint. I'd like to hear more from the testing community on this topic. - Chris Wysopal]

The Software Trustworthiness Framework (STF©)
by Elfriede Dustin

Recently I presented the topic “Automated Software Testing” at a Department of Homeland Security workshop on Software Assurance. Most practitioners at the workshop equated Software Assurance with Software Security Testing and one might wonder what automated software testing has to do with software assurance?

In order to achieve software trustworthiness in the limited amount of time that’s generally allowed to produce software, a combination effort of automated software testing along with security testing is required: The Software Trustworthiness Framework (STF©) is needed.

Daily we are bombarded by news media alerts of new security breaches whether at the private, state, or government level, the latest example, UCLA having to alert 800,000 to data breach. [1]

Josh Bloch, chief Java architect at Google, said in a recent statement “Regardless of how talented and meticulous a developer is, bugs and security vulnerabilities will be found in any body of code – open source or commercial. Given this inevitably, it’s critical that all developers take the time and measures to find and fix these errors.”

Developers however are strapped cranking out new features while trying to meet the often unreasonable deadlines. First-to-market is key, beating the competition is the goal. Given this dilemma, where software developers alone cannot be responsible for software assurance, we need to look to other resources to help us win the software trustworthiness battle. Who is better suited to help a developer conduct security testing than the software testing groups already in place?

In the traditional software development lifecycle, software trustworthiness is often an afterthought, and security verification and testing efforts are delayed until after the software has been developed. Meeting deadlines is key, at all cost, including that of trustworthiness, yet vulnerabilities are an emergent property of software that appear throughout the design and implementation cycles.

Currently, much of the Security testing that is done after the software has been implemented, such as paying an external party to perform security testing and issue a report, can be considered just a Band-Aid solution. It is tempting for security testing teams to focus purely on the mechanics of testing the security of a software application and pay little attention to the surrounding tasks required of a secure software development lifecycle, such as automated software testing. This is where the STF© comes into play.

It is not possible to “test” software trustworthiness into software and it is widely known that the earlier a defect is uncovered, the cheaper it is to fix.

A full lifecycle approach to software development is the only way to achieve software trustworthiness. Therefore, combining security testing with test automation, and a before, during, and after approach to software development is required.

The most effective software trustworthiness programs start at the beginning of a project, long before any program code has been written. An effective security process is one that is used throughout the SDLC and one that employs automated testing technologies.

The Automated Testing Lifecycle Methodology (ATLM) described in the book “Automated Software Testing [2]” is a structured methodology, supports the successful implementation of automating testing, has been implemented by companies throughout the world, and is recommended by various tool vendors. The ATLM approach is consistent with rapid application development efforts including engaging the user early in the development cycle. Many universities and professional software testing organizations are adopting this methodology in their software testing courses, along with commercial companies heavily invested in automated testing.

The Secure Software Development Lifecycle (SSDL) described in Chapter 3 of the book “The Art of Software Security Testing” is a structured methodology that has emerged to support the successful implementation of secure and trustworthy software. In the SSDL security issues are evaluated and addressed early in the system’s lifecycle, during business analysis, throughout the requirements phase, and during the design and development of each software build. This early involvement allows the security team to provide a quality review of the security requirements specification, attack use cases, and software design. The team also will more completely understand business needs and requirements and the risks associated with them. Finally, the team can design and architect the most appropriate system environment using secure development methods, threat-modeling efforts, and so on to generate a more secure design. Much research has been performed in the area and resulting success of using a Secure Software Development Lifecycle (SSDL). The SSDL approach to software development is also recommended by some departments in DHS, Microsoft, and other major organizations.

Amalgamating the Automated Testing Lifecycle Methodology (ATLM) together with the Secure Software Development Lifecycle (SSDL) combines automated software testing with software security testing into the Software Trustworthiness Framework.

More on the STF©:

As outlined in Figure 1, the SSDL and ATLM represent a structured approach toward implementing trustworthy software – The Software Trustworthiness Framework. This framework mirrors the benefits of modern rapid application development efforts. Such efforts engage the stakeholders early on as well as throughout analysis, design, and development of each software build, which is done in an incremental fashion.

Figure 1 The Secure Software Development Lifecycle combined with the Automated Testing Lifecycle Methodology (ATLM) results in the Software Trustworthiness Framework (STF)

The inner layer of Figure 1 describes the ATLM and has six primary processes:

• 1. Decision to Automate Testing
• 2. Test Tool Acquisition
• 3. Automated testing Introduction Process
• 4. Test Planning, Design, and Development
• 5. Execution and Management of Tests
• 6. Test Program Review and Assessment

The outer layer of Figure 1 describes the SSDL and has six primary processes that are intertwined with the ATLM:

• A. Security guidelines, rules, and regulations – Oversight
• B. Security requirements: attack use cases
• C. Architectural and design reviews/threat modeling
• D. Secure coding guidelines
• E. Black/gray/white box testing
• F. Determining exploitability

The combined processes and tools make up the Software Trustworthiness Framework (STF©).

Implementing the Software Trustworthiness Framework (STF©) will allow for repeatable and consistent verification of new releases and software patches. It will evaluate the trustworthiness from an end-to-end system perspective, and will verify that the integration of components yield a trustable system.

Automating the testing efforts will allow for quick measurements of testing completeness and allow for testing consistency. Additionally, implementing the SSDL as described in “The Art of Software Security Testing” as part of the STF© will support efforts to make software secure and together with the ATLM it can assure that it is robust and behaves as expected in while interacting with multiple software applications, as required.

Use of the STF© will allow software testers to gain confidence that a fault in one piece of software does not introduce unknowns in a set of integrated software components. It will assure that the software trustworthiness is verifiable, given the often sparse level of software specification accessibility.

The Software Trustworthiness Framework provides a structured, multi-stage approach supporting the detailed and interrelated activities required to introduce and utilize automated tools along with security testing best practices with an iterative / spiral development approach. These activities include: test design development, development and execution of test cases, development and management of test data and the test environment, documenting, tracking and closing trouble reports found during testing.

I’ve always been a fan of Joel Spolsky’s Guerrilla Guide to Interviewing. Unfortunately, I’ve never been able to apply it in its purest form because in recent years, I’ve been hiring mostly application security consultants, not software engineers. However, the structure is still remarkably useful, with some modifications. So, without further ado, here’s an example of how one might apply Guerrilla Guide techniques when interviewing a candidate for an application penetration testing position.

Sample Question #1: What is the difference between a GET and a POST?

Note that I’m not violating the Guerrilla Guide’s “no trivia questions” rule by asking about some arcane feature of the HTTP protocol that only the RFC author would know. All I know is, anybody who can’t answer this question is a No Hire. If they can answer it, see how deep they go — there’s one very obvious answer, but it’s also a relatively open-ended question.

Sample Question #2: Explain how cookies work.

You’d expect to hear some discussion of the HTTP protocol here. If the person starts talking in API abstractions and can’t describe what’s happening one level down, we’re in trouble. Otherwise, you want to see how much detail they can provide beyond the basic answer.

Sample Question #3: Let’s say you wanted to brute force a POST request to http://example.com/foo, iterating the parameter ‘bar’ over a numeric range. How would you accomplish it?

This fulfills the “Easy Programming Question” objective of the Guerrilla Guide and is a good way of seeing how the candidate will approach a relatively straightforward task. Most skilled pen testers I’ve worked with would do this from the command line or write a quick script. You’re not looking for a particular scripting language, you just want to see that it’s familiar enough that you can quickly churn out the few lines of code. If the candidate struggles with it, or even worse, doesn’t understand what you’re asking for, that’s a bad sign.

Sample Question #4: Describe one of your most complex or unique attacks against a web application.

This is a good open-ended question and fulfills the Guerilla Guide’s “Recent Project” objective. Chances are, if the candidate has done more than a couple dozen pen tests, there was at least one time where they found and exploited something that required deep analysis and/or creative thinking. If they can’t come up with anything, you’re dealing with a novice. If they do, ask follow-on questions to make sure that they really understand the attack and can explain it in a coherent fashion. If they can explain the outcome of the attack but nothing else, there’s a good chance they either don’t communicate well or are trying to pass off someone else’s anecdote as their own. Finally, step back and ask yourself what was creative or complex about this particular finding. Remember, you asked for their best. If it’s something commonplace (e.g. “I used a SQL injection vuln to own the box with xp_cmdshell”), you’ve now established a baseline of this candidate’s abilities.

Wrapping It Up

Beyond these specific questions, you might also want to see how well the candidate can explain a common web application vulnerabilities, from root cause to exploitation methods to remediation. This is extremely important if you’re looking to hire a consultant, less important if it’s not a customer-facing role.

You can also ask their opinion on current application security topics or events. It’s more important that they actually have an opinion (and can back it up) than whether or not you agree with them. Ultimately, however, the fundamental tenet of the Guerrilla Guide still applies — “When you find the smart, gets-things-done candidate, you’ll know it. If you’re not thrilled with someone, move on.”

For all of you web app security people out there — what’s your favorite interview question?

It occurs to me that security, in general, has historically been measured as a function of a few inputs. Proactivity (locking up early), accuracy (locking things correctly), and completeness (locking all the doors). What’s missing from this equation is the fact that people often lock their valuables away and assume that they’re safe indefinitely that way. All codes, passwords, and locks degrade in value over time, and need to be replaced with better models. In any inherently insecure medium, such as the moving parts of software, security naturally erodes as requirements shift.

There’s a common misconception that security follows the rules of superposition. That something that has been secured (A), combined with something else that has been secured (B) will also be secure. The physical analogy with locks breaks down with more complex mediums, such as software, due to the intrinsic interdependencies between modules. A might call procedures in B that call back into procedures in A. The interfaces between modules may add arbitrary amounts of code complexity when pieced together.

So, what to do about this situation? Two remedies: Scan for software security issues frequently. Scan whole programs not just parts of programs. An analysis can’t simply scan module ‘A’ and expect module ‘B’ to play ball. This is made more difficult when you only have source code to module ‘A’, and not module ‘B’. This officially makes the problem harder to deal with than most people would like to admit.

On top of coverage, one must expect to scan more frequently as the threat landscape changes.

http://www.toool.nl/bumping.pdf

http://www.toool.nl/bumpkey-alert.wmv

Bump keys changed the game for physical security and the majority of locks built need to be replaced with different mechanisms to solve this problem. Thankfully, when the equivalent of the bumpkey comes to software (as remote vulnerabilities often do in operating systems), we can often upgrade it automatically when remedies are made available.

Agility, the ability to respond quickly to new threats when recognized, is of utmost importance. Old versions of software need to be scanned for new problems, as deprecation is purely the desire of the software producer, and not its eventual owners, who are generally satisfied with something that has ‘just worked’ for a long time.

Agility and automation are effectively the same thing in software security. The ability to automatically respond is required to manage vulnerability detection in legacy or deprecated versions of software, especially as the threat landscape changes. The digital immune system needs to be ‘always-on’, and deal with the occasional infection with speed and then come to recognize problems quicker the next time they surface.

Make application security a constant, automated process, not a turnkey, one-off effort.

In part I of this article I wrote about the history of vulnerability research and how researchers having legal access to the software and hardware they need to conduct their research is a pre-requisite. This is why there was such little research on software before 1996.

Not only is legal access important but being able to run the software in a lab environment is important. Pure black box testing is very inefficient for finding security bugs. You need to instrument the running program and be able to perform static analysis. This usually takes the form of using debuggers and shims which the program is running and using disassemblers to statically inspect the software. These techniques have been honed and improved over the years and there are even books[1] about them.

Technology marches on and a new way of running software is gaining significant ground over traditional software. Software as a Service (SaaS) is a model where you don’t install software on your own hardware. You use the software in a client server model over the web. Yahoo Mail for individuals and Salesforce.com for corporations are examples of this new model. An organization such as Yahoo runs the software and you just use it. It can be free or paid for with a subscription. The key difference here is you don’t run the software on your hardware.

This is a big change for vulnerability researchers who can’t use their white and gray box techniques, well legally anyway. Even using a strictly black box probably steps over the legal line in most cases. We are charting new territory here. Creating hundreds of sessions and inspecting session IDs is probably OK. Fuzzing all form fields is probably not OK.

There have been cases where people poking at web sites have gotten into legal trouble when they found something that looked like a security vulnerability.

From SecurityFocus http://www.securityfocus.com/news/11389

Last Thursday, the U.S. Attorney’s Office in the Central District of California leveled a single charge of computer intrusion against San Diego-based information-technology professional Eric McCarty, alleging that he used a Web exploit to illegally access an online application system for prospective students of the University of Southern California last June. The security issue–which could have allowed an attacker to manipulate a database of some 275,000 USC student and applicant records–was reported to SecurityFocus that same month. An article was published after the university was notified of the issue and fixed the vulnerable Web application.

The prosecution of the IT professional that found the flaw shows that security researchers have to be increasingly careful of the legal minefield they are entering when reporting vulnerabilities, said Lee Tien, senior staff attorney for the Electronic Frontier Foundation, a digital-rights advocacy group.

“I think the bottom line is that anybody that does disclosures of security vulnerabilities has to be very careful (so as to) not be accused of being a hacker,” Tien said. “The computer trespass laws are very, very tricky.”

And this from The Register, http://www.theregister.com/2005/10/11/tsunami_hacker_followup/

Cuthbert, a 28 year old from Whitechapel, London, was a security consultant at ABN Amro, a job he lost as a result of his arrest. He also lectured at Westminster and Royal Holloway universities – ironically he taught some members of the Computer Crime Unit.

On December 31, 2004, Cuthbert, using an Apple laptop and Safari browser, became concerned that a website collecting credit card details for donations to the Tsunami appeal could be a phishing site. After making a donation, and not seeing a final confirmation or thank-you page, Cuthbert put ../../../ into the address line. If the site had been unprotected this would have allowed him to move up three directories.

…

The police were able to track Cuthbert down because of the donation he made just before running the tests. He was arrested, brought in for questioning and subsequently charged with breaking the Computer Misuse Act.

These two cases should be a big enough warning that probing web sites for vulnerabilities has a good chance of landing, even those with good intentions, in jail.

It’s my belief that vulnerability researchers have not only educated the software community about how to find security vulnerabilities, but they have also been 3^rd party consumer watchdogs. They have giving consumers a fighting chance in understanding what software and which vendors. For both of these benefits, there is a need for vulnerability researchers to have access to the software that people use.

I fear that these benefits will disappear as more software moves into the Software as a Service realm. Some possible solutions are:

• SaaS providers could deploy their software on test servers where people would be free to attack it. If they are really bold they could give shell accounts.

• Congress could pass a “good Samaritan” law that would exempt researchers from the computer trespass laws if they are engaged in legitimate research.

• SaaS providers could engage trusted 3^rd parties to perform security testing and allow them to publish the results for consumers to see.

I am interested if others have ideas or how think the growth of SaaS will change the vulnerability research landscape.

There is no doubt that Web 2.0 is upon us. The software we use everyday is migrating from our desktops, laptops and company servers to the great data centers in the sky. The first application to move to the cloud was e-mail, then picture and file sharing services, and now traditional desktop applications such as calendaring, task lists, spreadsheets and word processing are all available via the web. Soon there will be little need for the average computer user to have any applications running on their desktop at all except for a web browser with media player plug-ins.

There are many benefits to the concept of software as a service: no hardware, no software to install and maintain, the ability to get at the application and your data from any internet connected computer with a browser. These benefits come from fact that the software is running on a computer owned and maintained by someone other than the user.

To understand what this new software paradigm means to the field of vulnerability research we need to take a look back at how the field has evolved over time. Public vulnerability research originated somewhat illegitimately in the late 80’s and early 90’s.

The type of networked systems for which vulnerability research was meaningful was expensive. They were in the hands of large corporations, government, and universities and prohibitively expensive for individuals. It was the rare computer geek that had a Sun or SGI workstation.

To research software vulnerabilities meant that you had to get permission from your employer or school or connect to computers you didn’t have legitimate access to or have permission to attack. Since getting permission to potentially crash a business computer was difficult, the only vulnerability researchers doing things legitimately were in an academic or research environment. This was rare. The majority of research was being done illegitimately on other people’s computers.

By the mid 90’s, hardware became more powerful and cheaper. This combined with the advent of Linux and FreeBSD, meant individuals could afford to run the software for which vulnerability research was meaningful. Name servers, mail servers, web servers, file transfer servers and operating system weaknesses were the staples of early vulnerability research. Now anyone could inexpensively install an OS and target software to research vulnerabilities legitimately in the comfort of their very own lab (or bedroom).

So around 1996 we start to see a lot more vulnerabilities being disclosed through organizations like CERT or on public mailing lists like Bugtraq. Of course they vulnerabilities were always there. The difference is people had the capability of looking for them without breaking the law. They had access to the hardware and software to look for vulnerabilities. Note the quick ramp up of vulnerabilities disclosed in this chart from the National Vulnerability Database.

Now zoom forward to 2006. Vulnerability research is alive and well but some categories of important software are off limits. How exactly is a vulnerability researcher supposed to inspect Google Spreadsheets for vulnerabilities they way he would inspect Microsoft Excel? Remember the software is running on Google’s hardware in Google’s data center. Can Yahoo mail be scrutinized to the same level that Microsoft Outlook can be? The answer is no and there are two reasons why.

1. Researchers are in legal jeopardy if they stage attacks against a computer owned by Google or Yahoo.
2. Researchers cannot use valuable reverse engineering or “grey box” techniques to find vulnerabilities.

In my next posting I will discuss what this means for the future.

[update: CSO magazine has published an article on this topic, "The Chilling Effect". Scott Berinato, the author interviewed me on the topic of the new vulnerability trend of XSS and SQL injection surpassing buffer overflows as the new kings of the vulnerability heap. I told him that it was true but that I had a bigger concern, that disclosure of these types of vulnerabilities was starting to get to be problematic for researchers. Scott ran with the idea and wrote a great article.]

[Update, 1/6/07: Google has implemented a workaround for this vulnerability on their servers, so the proof-of-concept links in this posting will no longer demonstrate the exploit]

Cross-site scripting (XSS) just got a lot scarier. At the 23rd CCC, Stefano Di Paola and Giorgio Fedon announced a new attack vector which basically puts any site hosting a PDF file at risk for XSS. The attacker doesn’t need to control the PDF, the mere existence of the PDF file on the server is enough. Here’s a basic example (if an alert box pops up, you’re vulnerable):

http://www.google.com/ads/techb2b_news.pdf#foo=javascript:alert(‘XSS’)

And of course the classic example of exploiting an XSS vulnerability involves leaking the contents of the victim’s cookie, either by sending it to the attacker by concatenating it to an HTTP request, or, more recently, by using Ajax to issue a series more complex requests. Here’s the same example displaying the cookie:

http://www.google.com/ads/techb2b_news.pdf#foo=javascript:alert(‘Your Google cookie:\n’ + document.cookie)

It goes without saying that a real attack would carry out its mischief without actually displaying pop-up dialogs to the victim.

This gets even more interesting if the targeted website has CSRF vulnerabilities. Remember the GMail Contact List CSRF vulnerability from a couple days ago? Now you wouldn’t even need to trick the victim into loading your malicious web page (or clicking an XSS link on some other site) in order to exercise the CSRF attack. Even the security-conscious users who use Firefox plugins such as NoScript to selectively enable Javascript most likely have scripting enabled on sites they visit regularly such as GMail, Yahoo, etc.

Thanks to Google, it’s easy to find sites hosting PDFs, or to locate PDFs on a specific domain — MSN, MySpace, Flickr, etc. — you get the idea.

Adobe has reported that this vulnerability only affects versions of Acrobat Reader prior to version 8, and only on the Windows platform. And they are in the process of preparing patches for earlier releases of Acrobat. Still, there are plenty of people out there who simply never upgrade.

A quick workaround on the client side is to configure your web browser to save PDF files rather than automatically opening them in the browser. Firefox allows you to do this through the Download pane of the Tools/Options dialog, no idea if you can do it with IE.

To protect your own site from being targeted, you could probably configure the web server to manipulate HTTP response headers. Forcing Content-Type: application/octet-stream or even Content-Disposition: attachment should force the user to save the file or launch the viewer outside of the web browser. However, there’s no guarantee that all browsers will behave the same way.

Now, how many other browser plugins have similar vulnerabilities? Somehow I doubt we will be waiting very long to find out.

Zero in a Bit is a blog about software security. We believe the root cause of most of the security problems today is insecure software. The internet is a global neighborhood where every digital miscreant is your next door neighbor. Far too often, software is the broken window allowing criminals access to the data and transactions organization need to protect.

Zero in a Bit is laser focused on software security. If we talk about vulnerabilities in the internet infrastructure we won’t be dissecting routing protocols, we will be analyzing integer overflows in routing software. When we speak of identity theft it won’t be about stolen backup tapes it will be about SQL injection or cross-site scripting in web applications that hold private data. There is often no process or additional layer that can be wrapped around insecure software to solve these security problems. We think you need to find the flaws in the software and fix them — hopefully before the software gets deployed.

Topics we will cover include:

• Software security testing and analysis
• Software security metrics
• The taxonomy of software vulnerabilities
• Disclosing vulnerabilities
• Zero day vulnerabilities
• Malicious software and backdoors