Security 101 - Security Testing Mentality
Author: Bill Ricardi
Reviewer: uTest
This is my attempt to explain how to go about finding security bugs. Although the more complex aspects of security testing cannot be picked up without a few years of experience, the mental state that you have to put yourself into is always the same. No matter what tools or software you choose to use once you start your security probing, you need to understand the steps that you'll take, and establish the goal of testing the security of this particular website or application. So I'll go through the mindset of approaching a new security project, which should help you research the security tools and education that fit your experience and personality.
NOTE: NEVER perform security testing unless the client and/or project leaders says that it is OK! Some security tests, especially automated tests, are processor-intensive, log-spamming, and could even take down the back end server!
1) On the outside looking in
The first stage of intrusion testing is to assume the role of a kid with his nose pressed against the glass window of a candy store. You are determining your motives. Why would you want to break into this site, if you were an intruder? Certainly, the motives of anarchy and revenge are always appropriate. But is there financial gain available? Is there sensitive information that might be used to embarrass or blackmail the company? Is there confidential client information that needs to remain private?
Your perceived motivations can be used to expand the range of standard attacks that you might mount against the test platform. Financial gain might mean a focus on the checkout stack. Sensitive internal information might mean mounting an attack on their internal email. Confidential client information means a focus on the client login scripts.
You need to understand motivation, so that you can explain why security is important to the client. Often times (and this is especially true with start-up companies), a company won't understand why anyone would want to target them with an attack. So you can explain the potential motivation of an attacker in the notes of your bug.
2) Getting a foothold
A 'foothold' scenario is when an invader is trying to set up shop in your territory. After you've determined what you can get out of a particular application or web site, you need to put that in the back of your mind. That is a goal, a final step. The first thing that you need to do is find something - anything - that will help get you 'inside.’ You need to dig for more information, more access, and more power. Like any good invader, it is time for you to establish a foothold.
On a web server, gaining your foothold might involve scanning for security risks in the form of old software or open ports. For other client-server software, you might search the web for potential valid logins (possibly discovered by publicly known email addresses, FTP accounts, etc.) that you can try to crack. Look at the notes in the source material (and view the source of web pages on the server) to see if there are hints of otherwise un-advertised insecurities. And of course, if you're allowed, a little social engineering (trickery aimed at getting others to give you information) can go a long way.
You don't care how you get 'in', as long as you get in. It doesn't matter if all you get is an E-mail account when you were looking for a way to crack their credit card authorization system. Once you have a foothold, you can develop your position into something more advantageous.
3) Pressing the advantage
No matter what kind of foothold you get, you should be able to leverage it into something important: Information. You're no longer on the outside looking in. You're inside the candy store, but you need to quietly get to the display case that has all of the good candy! So now is a time of discovery. What can you do with the access that you've earned? Read every help file. Use every informational command. Avoid interacting with human beings... talk to the robots. Anything that answers your requests automatically is your friend! Get all of the information you need to map out the software and services available to you. Then research the weaknesses of the particular versions of the program that you encounter.
Seek to be redundant. If you have one user account in hand, see if you can get another via the same discovery methods. If you have an FTP or Telnet login, see if you can also get its counterpart for all other active services. Lay your backup plans, just in case you get discovered. If you have access to create new accounts, make a handful with different access levels. If this company has the same security setup on different servers, seek to spread it out to other machines. If you find a weakness in one router, map out their network and see if the same weakness will give you access to other routers. Use your information. Expand. Look for the pot of gold.
4) Reporting the kill
At this point, you have come full circle. You can go back to the mindset that you had when you started the process, and see if you can achieve any of the goals that a motivated attacker might have. You should have all of the information that you need to either make your case, or discover an avenue of attack that you might not have thought of before you had all of the facts.
If your research yields something that you consider 'powerful' (be it root access, a strong denial of service, stealing the identity of someone in power, etc.), be careful. You MIGHT want to ask if the client wants a demonstration of your position of power, or just evidence of how you got there. Some clients will be savvy and experienced enough to understand what you've accomplished, and see the writing on the wall. They'll be glad that you haven't done any damage that they'll have to undo, whether or not you had permission! Other clients will want you to go ahead and execute at least some level of final attack, so that they can see what the end result would be. If that's the case, don't overdo it. If you can make your attack reversible, great. If you can turn it off at will, super.
But at this stage, consult with the project leader for your best course of action before doing anything rash.
Some clients test on production servers. In cases like this, NEVER take it down or take it out of action. If the clients ask you to, explain to them the consequences of their request via your project leader!
As you can see, you have to be really careful about your 'proof'. Good documentation, a lot of screen shots, and referencing the right security articles is usually a much better option than a destructive attack.
That's it! I hope that this gives you some insight into the mind of an intrusion and security tester. Remember, the tools that you use are entirely up to you, depending on how technical and experienced you are. You can research those on your own. But the mindset is critical, no matter how fancy your software is. Enjoy!
