A little direction for those wanting to move into pentesting

I'm doing a security baseline class for a financial company all this week. For those thinking of moving into security, here's my 2 cents worth of advice.

1. Get you some Linux; Redhat, Suse, Fedora, it doesn't matter. If you really plan on making serious headway, you will need to be comfortable in front of a Linux command line. Things like compiling shell code on the fly or actually while you're in the middle of an exploit is a power you needn't do without. Also certain tools (Nmap comes to mind) are 100 times better and more flexible in a Linux environment.

2. Get some literature. For example, all of the books from the Stealing the Network series (co-authored by Fyodor (the creator of Nmap) is a good start. While all of these stories are fiction, the tools, techniques and exploits are very very real. Read these, make a list of the tools, exploits, etc you read about. Then start googling away, looking for information on these tools and exploits, and start practicing Learn and get comfortable with some of the popular IDS tools out there. Start with Snort, there's tons of info on the web explaining how to create filters, rules, etc. .

3. Start asking questions.

4. I know it's a bore, but go ahead and take the time to learn the 7 Layers of the OSI model and master them. Also, learn your ports and protocols and learn what they're for (TFTP is one of your best friends when it comes to pentesting). Snmp is your enemy when trying to secure your network.

These things will help you out in your near future (if your goal is to move to security). It will also help out your future instructors

Only one person in my class this week knew how to compile a simple program (ADMsnmp) from the linux console. Even though the prerequisites for the class clearly state "intermediate to advanced Linux experience...."

Good luck to you all. I'm sure Johan, /usr, kenny, and some of you others can add some more to this.

Find more posts tagged with

Comments

JDMurray

keatron wrote:

4. I know it's a bore, but go ahead and take the time to learn the 7 Layers of the OSI model and master them.

How does one master any given layer of the OSI model? What does that mean?

Webmaster

I think that means being able to recognize functions and operations of any network related technology as belonging to a particular layer. This can allow you to exclude both certain assets and attacking techniques, and implement safeguards on all layers. The modular approach offered by the OSI model works just as well for security as networking, as most of the vulnerabilities and threats are only present when the system is networked.

Still, I'd like to ask you the same question Keatron:
How does one master any given layer of the OSI model? What does that mean?
and add:
How do you apply the OSI model on the job?

I agree it can be a bore to learn the OSI model, the functions of the layers etc, but ones you got it down, learning networking technologies becomes a lot more interesting.

I'm sure Johan, /usr, kenny, and some of you others can add some more to this.

Well, I'm willing to give it a try under the supervision of you experienced pen-testers:

5. Subscribe to bug reports and security updates mailing lists for all the popular networking systems including the main MS products. For the obvious reason of knowing which holes to look for, but when you are starting out it's particularly interesting to get a good idea of what kind of holes are present (or digged/created... that could lead to an entire different discussion

). For those new to security, I bet they'll be suprised that the XXth bug in IE, for example, is really not 'that' easy to exploit.

6. Educated yourself on laws (and ethics if necessary) that related to your job. As with anything in IT, you should really know what you are doing, but when it comes to security, there's something as liability. Meaning that if you are payed 10k for pen-testing a coporate network, you make the corresponding recommendations based on what you've found, and some script-kiddie uses a free downloadable hacker tool to gain access to a domain admin or superuser account a week later, you got a problem. Apart from building up a bad rep and not getting the job again next year when they upgraded their systems, you may be held liable depending on the laws in your country/state. Of course you can deal with this in a contract before you take the job, which is only more reason to educated yourself on legal matters. The law is covered in many security related studies/certs, but additional or different laws may apply on your planet.

I think JD and I talked about this before when discussing securing wireless networks a fair time ago when wireless started to become more common and so open. War-driving thru a city would (and still will) show a large amount of wireless networks that aren't secured at all, or are secured but still very insecure (ie. WEP). It 'looks' so easy to start up a company and contact the owners of those vulnerable networks and make a lot of money securing wireless networks. With the current and future developments of wireless security technologies it becomes more feasible, but be careful when it comes to liability. Replacing WEP with WPA and claiming the network is secure can be a costly mistake.

7. Get your MCSA:Security or MCSE:Security, preferably for 2 different Windows versions. I'm not saying this is a requirement for every infoc sec pro, Linux is 'the' hacker's main OS (hence pen-testers' OS), but Microsoft products are the most widely used. Your job as a pen-tester is not promoting your favorite Linux-distro, in most cases your clients don't want to hear they should replace their Windows + Exchange 2003 server with a Linux+sendmail server, but how they can improve the security of their current system.

8. Keatron already mentioned compiling shell code, I'd like to suggest a step further: learn how to program and how to interpret code in basically all the popular languages, especially scripting languages (cgi, php, asp, python, javascript, vbscript)

9. Apart from networking in general, the OSI model, focus on TCP/IP. Many of the popular network attacks are possible due to the inherently insecure nature of TCP/IP. Getting your CCNA will help a lot, and at the same time you will learn the basics of the most popular devices (Cisco) on the Internet and most corporate networks.

10. Read all the 'new features' guides for popular systems/software (operating systems, browsers, email servers/clients, firewall and intrusion detection and prevention systems. Security is a hot issue, has been for some time now, and many of the improvements in products relate to security. Knowing the history of networking, security, and the popular products will give you a much better understanding of new features and technologies and why they exists (and when you should recommend them).

11. Choose an area to specialize in. There is so much to choose from, and you can't know it all. Try to pick a popular area and expand from there. Much of the knowledge that you learn in one area (e.g. secure storage) will apply in others as well (e.g. secure messaging). Knowing the concepts as covered in the Security+ and CISSP certs is valuable, but things in real world often don't exactly match the concepts. For example, reading about encryption and knowing the different algorithms, key sizes, overall strenght etc. is important info, but knowing which products and technologies are available to implement the different types of encryption is as least as important.

keatron

Thanks for clarifying Johan. To clarify more; When I'm troubleshooting connectivity issues, I usually think in layers (unless it's an obvious problem). This has been my practice (as I was taught this way years ago) since I've been seriously involved in IT at all (11 years). Same goes for security, I think of this in a layered manner. The OSI model is key to building a solid foundation in networking and networking protocols in general. While it doesn't come close to covering everything you need to know about networks from a conceptual perspective, it gives you a good base to build from.

By mastering, I meant don't just read some exam prep list and remember that for example, instead of just memorizing that TCP is a Transport (layer 4) protocol. Break down something like an entire process and study what happens at each layer. This will be huge in understanding how to prevent some exploits.

A common mistake is designing a security model that does not include any layer 6 or 7 protection or packet inspection. In other words, how deep down in those packets can this particular solution inspect packets coming through this choke point in my infrastructure? For example I've heard many "security experts" say things like "all you have to do is deny all inbound traffic on all ports except port 80 on your firewalls and filtering devices".

As if port 80 couldn't possibly be exploited. While this is definantly a good step, it is not the end. Other questions should come to mind, like what types of traffic is allowed on port 80? Which leads to, how will my security devices know what kind of traffic is actually coming through? This is where you can look at what level your security/IDS devices can inspect up to/down to when inspecting packets. Just because my traffic looks like ICMP traffic, does it neccesarily mean that's all it is?

JDMurray

keatron wrote:

By mastering, I meant don't just read some exam prep list and remember that for example, instead of just memorizing that TCP is a Transport (layer 4) protocol. Break down something like an entire process and study what happens at each layer. This will be huge in understanding how to prevent some exploits.

The people who really live the OSI layers are soft/firmware people who write the code that actually live at all these layers (all but layer 1, that is).
If you are a hardware-only person the best you could probably do to fully understand the workings within the OSI layers is to read the TCP/IP book series by Doug Comer http://www.cs.purdue.edu/homes/dec/netbooks.html.

keatron wrote:

A common mistake is designing a security model that does not include any layer 6 or 7 protection or packet inspection.

Packets are stripped away by layer 3. At layers 6 and 7 there's only data. What these layers need is better data validation. This is a prime reason that buffer overflow attacks are successful. Bad data handled badly can blow your stack (or heap). Most of the time it just throws an error and does nothing harmful.

keatron

Packets are stripped away by layer 3. At layers 6 and 7 there's only data. What these layers need is better data validation. This is a prime reason that buffer overflow attacks are successful. Bad data handled badly can blow your stack (or heap). Most of the time it just throws an error and does nothing harmful.

Buffer overflows alone usually don't do harm, it's the code that's included in the extra data that executes unwanted commands that's the problem. We're talking about security, so I'm not referencing accidental buffer overflows that occur from programming errors (I guess they are all a result of poor programming however

).

I mis-worded the layer 6 and 7 part. I basically meant using solutions that can drill down all the way into the packets and "see" or "inspect" layer 6 and 7 information which is as you said, data.

The people who really live the OSI layers are soft/firmware people who write the code that actually live at all these layers (all but layer 1, that is)

Yep, and as already mentioned these same soft/firmware people are the ones who write code exploitable by buffer overflows time and time again.

JDMurray

Most buffer (heap) overflows are harmful because they cause memory protection violations. It doesn't matter what data you write to the buffer. The concept of writing code to a buffer and then executing it is a stack overflow. Those are nasty, but they are rare and difficult to discover.

I think all security people need to learn how to write software. The language doesn't matter; what's important is to get a feel for what is actually the target of most security threats: software. And poor software coding and testing practices is what has created most of the vulnerabilities.

keatron

I agree with that 100%