We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

The Mike Rothman Security Report

Peter Schooff

Penetration Testing Like a True Hacker

Vote 0 Votes

***Editor's Note: If you like this topic, join ebizQ and Security Expert Mike Rothman for this month's Threatscape 2008 featuring Mike Rothman and A. N. Ananth.

Applications are the path of least resistance for the bad guys. With a myriad of client-side attacks and other JavaScript and PHP vulnerabilities, many web applications look more like Swiss cheese than the entry point to an organizations most sensitive data. The reality is that bad guys are attacking your environment every day. Just check your firewall and application logs if you don’t believe me.

Wouldn’t it be nice to know what the bad guys are going to find before they find it? No, I’m not going to tell you to buy a crystal ball, though that may not hurt. A concept I’ve been pushing called "security assurance" focuses on testing your environment, including your networks, systems, as well as applications. You use the same (or similar) tools as the bad guys do, and you try to break your stuff.

I believe every company of size needs to have a dedicated team focusing on trying to compromise business systems. Sure it’s an investment, but it also provides significant peace of mind -- and we all know that is priceless. To know what will happen when the bad guys exercise your defenses gives you a huge advantage in the ongoing battle with the dark forces that are trying to steal your customer's private data and your intellectual property.

But testing your application after it's been let loose on the world is not too helpful. So one of the first jobs you have to tackle is evangelizing the need to get the security team involved early and often in new application initiatives. I speak to lots of folks where the security team doesn't find out about new applications being deployed until servers and infrastructure is being installed to support it. Suffice it to say, that's just too late to have an impact.

Once you figure out which applications are happening and when they are going live, then you need to approach the development lead and work out a testing scheme that allows you to put the application through a security gauntlet before your customers (and the bad guys) do.

The main tool in your arsenal is going to be the application scanner. These tools mimic a number of attack vectors, like SQL Injection, buffer overflows, and cross-site scripting, in order to find the break points in your application(s). If you aren't doing proper input validation, the tool is going to find that. If you can bring down the application via a buffer overflow, you'll know.

Network and system-oriented scanners have been around for years and the technology is very mature. Historically, scanners focus on identifying the vulnerabilities in a non-intrusive way. Penetration testing products on the other hand (Metasploit, Core IMPACT, Canvas) use actual exploit code to see which systems can be exploited. Pen testing tools brake stuff by design, and I assure you -- that is a good thing.

But the line between vulnerability and exploit is not as clear in the application world. It turns out the only way to figure out if an application is vulnerable is to actually launch an attack. So there is definitely a blurring between application scanners and pen testing tools. Let's be clear -- to a customer, the difference is meaningless. You want to know if a bad guy can own your application. You aren't interested in semantics and vendor category definitions.

So what's an application scanner good for? At this point, they are pretty effective in determining the simple (and well-known) attacks, like SQL Injection and cross-site scripting (XSS). More complicated attacks, using holes in JavaScript and things like cross-site request forgery (CSRF), are more problematic to detect. The point is atool provides a good start to finding the obvious application holes that a bad guy could drive a truck through.

I do need to caution you that tools will only take you so far. Don't get too comfortable that a skilled attacker won't break your application via an advanced attack or logic error.

Which brings up the main point: You still need good, competent, skilled personnel to test your applications. They can uncover how your business logic might allow a hacker to exploit how your application handles sessions or recovers passwords. These tend to be the low hanging fruit for the bad guys.

Skilled application testers are worth their weight in gold. Seriously! By taking a very critical look at your application before it goes live, you will save yourself a ton of heartburn and maybe even protect your customer's data while you are at it. Is that worth a little hassle during the development cycle? I think it is, but I'm not the one telling the sales people that the application isn't ready because a hacker could make mincemeat out of it.

So, even with a commitment to testing using tools and skilled people, you still aren't done yet. You also need to be able to create a sufficient level of urgency to fix the issues you find and maybe even delay an application from deployment. But that's another topic for another day.

ebizQ is proud to bring you Security Incite's Mike Rothman, who podcasts and writes on application security and related topics.

Recently Commented On

Monthly Archives