Lesson from Apache flaw: Test everything

The Apache Software Foundation rolled out a patch last week to fix an Apache Server reverse-proxy vulnerability that allowed malicious hackers to access protected folders. Whether or not your organization runs Apache, the incident serves as a great reminder of the importance of performing vulnerability testing — not just on the code you write in-house but that of third-party offerings as well.

The Apache reverse proxy flaw, in short, enabled hackers to access off-limits folders by simply inputting a directory path with a missing forward slash. With the slash removed, the application is no longer locked down to a hard-coded root or an anchor folder.

[ Download Roger Grimes’s new “Data Loss Prevention Deep Dive” PDF expert guide today! | Follow the latest in open source developments and thinking with InfoWorld’s Technology: Open Source newsletter. | Stay up to date on the latest security developments with InfoWorld’s Security Central newsletter. | Get a dose of daily computer security news by following Roger Grimes on Twitter. ]

Longtime security watchers may find this particular exploit interesting in that it’s reminiscent of Web server hacking techniques we saw a lot — a decade ago. Back in those days, many attacks began with multiple slashes interspersed with periods, often indicating current or parent folders. Thus, an attack back in the year 2000 might look something like this: ../..//../../. The idea was to use slashes and dots to confuse the program into allowing access to folders the host did not intend.

Over the past 10 years, these types of simple attacks have faded into obscurity — or so we thought. The Apache vulnerability goes to show that old attack styles still have to be taken into consideration when designing modern-day software.

The vulnerability also demonstrates the importance of always testing your applications. Today’s Internet server hacks primarily concentrate on unpatched bugs and application errors. Developers already know they should write their code using SDL (security development lifecycle) techniques, but I’m not sure most realize they should also check the quality of the code they don’t write, such as Apache. You can’t assume that code you didn’t write is as secure as code that undergoes your own secure development and review.

Apache Web server software surely undergoes internal security reviews before release, and the “many eyes” theory of open source security review says it undergoes additional — although likely spotty– security checks after it is published. But no software is perfect. Case in point: Secunia’s vulnerability database shows Apache 2.2 has suffered 43 vulnerabilities over the past few years.

Hence, organizations that use software code that accesses or protects critical data or infrastructure should conduct their own tests. The Web is brimming with both free and commercial testing tools for just that task. One of my longtime free tools for checking website security is Nikto. It searches for thousands of vulnerabilities across a very large range of Web server software. It’s free and fairly easy to use, as long as you aren’t scared by Linux or Linux subsystem emulation. You can run its tests as a plug-in to Tenable’s Nessus vulnerability scanner, which runs on Windows. Along the way, you can scan for a bazillion other vulnerabilities.

Also, don’t forget to check your software with an application vulnerability fuzzer. Fuzzers specifically look for the type of vulnerability found in the recent Apache bug: They take a line of input requesting code and respond to it with hundreds, even thousands, of predefined malformed responses. The idea is to respond in many unexpected ways to see if it makes the application barf (a technical term).

Fuzzing is how most of today’s vulnerabilities are found. As with regular vulnerability testing tools, you can find free and commercial fuzzers. Among the freebies, there’s iDefense’s Filefuzz, which lets you malform many different Windows file formats. SPIKEfile does the same thing for Linux files. The HTML Manglizer fuzzes HTML parsers. Many fuzzers, such as Smudge, are written in scripting languages like Python.

I heavily recommend that all your applications undergo SDL processes and review. Part of that review should include vulnerability testing and fuzzing. In today’s world of expansive hacking, anything less is simply neglectful.

This story, “Lesson from Apache flaw: Test everything,” was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes’s Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.