Introduction To Network Security - Part 2 - 2. Penetration-Testing

Page 2 of 5: 2. Penetration-Testing

What is Penetration-Testing?

Penetration testing is basically when you hire (or perform yourself) security consultants to attack your network the way an attacker would do it, and report the results to you enumerating what holes were found, and how to fix them. It's basically breaking into your own network to see how others would do it.

While many admins like to run quick probes and port scans on their systems, this is not a penetration test -- a penetration tester will use a variety of specialised methods and tools from the underground to attempt to gain access to the network. Depending on what level of testing you have asked for, the tester may even go so far as to call up employees and try to social engineer their passwords out of them (social engineering involves fooling a mark into revealing information they should not reveal).

An example of social engineering could be an attacker pretending to be someone from the IT department and asking a user to reset his password. Penetration testing is probably the only honest way to figure out what security problems your network faces. It can be done by an administrator who is security aware, but it is usually better to pay an outside consultant who will do a more thorough job.

I find there's a lack of worthwhile information online about penetration testing -- nobody really goes about describing a good pen test, and what you should and shouldn't do. So I've hand picked a couple of good papers on the subject and then given you a list of my favourite tools, and the way I like to do things in a pen-test.

This is by no means the only way to do things, it's like subnetting -- everyone has their own method -- this is just a systematic approach that works very well as a set of guidelines. Depending on how much information you are given about the targets as well as what level of testing you're allowed to do, this method can be adapted.

Papers Covering Penetration Testing

I consider the following works essential reading for anyone who is interested in performing pen-tests, whether for yourself or if you're planning a career in security:

'Penetration Testing Methodology - For Fun And Profit' - Efrain Tores and LoNoise, you can google for this paper and find it.

'An Approach To Systematic Network Auditing' - Mixter (http://mixter.void.ru)

'Penetration Testing - The Third Party Hacker' - Jessica Lowery. Boy is this ever a good paper ! (https://www.sans.org/rr/papers/index.php?id=264)

'Penetration Testing - Technical Overview' - Timothy P. Layton Sr. also from the www.sans.org (https://www.sans.org) reading room

Pen-test Setup

I don't like working from laptops unless its absolutely imperative, like when you have to do a test from the inside. For the external tests I use a Windows XP machine with Cygwin (www.cygwin.com) and VMware (www.vmware.com) most linux exploits compile fine under cygwin, if they don't then I shove them into vmware where I have virtual machines of Red Hat, Mandrake and Win2k boxes. In case that doesnt work, the system also dual boots Red Hat 9 and often I'll just work everything out from there.

I feel the advantage of using a microsoft platform often comes from the fact that 90% of your targets may be microsoft systems. However the flexibility under linux is incomparable, it is truely the OS of choice for any serious hacker.. and as a result, for any serious security professional. There is no best O/S for penetration testing -- it depends on what you need to test at a point in time. That's one of the main reasons for having so many different operating systems set up, because you're very likely to be switching between them for different tasks.

If I don't have the option of using my own machine, I like to choose any linux variant.
I keep my pen-tests strictly to the network level, there is no social engineering involved or any real physical access testing other than basic server room security and workstation lockdown (I don't go diving in dumpsters for passwords or scamming employees).

I try as far as possible to determine the Rules Of Engagement with an admin or some other technically adept person with the right authorisation, not a corporate type. This is very important because if you do something that ends up causing trouble on the network, its going to make you look very unprofessional. It's always better to have it done clearly in writing -- this is what you are allowed to do.

I would recommend this even if you're an admin conducting an in-house test. You can get fired just for scanning your own network if its against your corporate policy. If you're an outside tester, offer to allow one of their people to be present for your testing if they want. This is recommended as they will ultimately be fixing most of these problems and being in-house people they will be able to put the results of the test in perspective to the managers.

Tools

I start by visiting the target website, running a whois, DNS zone transfer (if possible) and other regular techniques which are used to gather as much network and generic information about the target. I also like to pick up names and email addresses of important people in the company -- the CEO, technical contacts etc. You can even run a search in the newsgroups for @victim.com to see all the public news postings they have made. This is useful as a lot of admins frequent bulletin boards for help. All this information goes into a textfile. Keeping notes is critically important, it's very easy to forget some minor detail that you should include in your end report.

Now for a part of the arsenal -- not in any order and far from the complete list.

Nmap - Mine (and everyone elses) workhorse port scanner with version scanning, multiple scan types, OS fingerprinting and firewall evasion tricks. When used smartly, Nmap can find any Internet facing host on a network.

Nessus - My favourite free vulnerability scanner, usually finds something on every host. Its not too stealthy though and will show up in logs (this is something I don't have to worry about too much).

Retina - A very good commercial vulnerability scanner, I stopped using this after I started with nessus but its very very quick and good. Plus its vulnerability database is very up-to-date.

Nikto - This is a webserver vulnerability scanner. I use my own hacked up version of this perl program which uses the libwhisker module. It has quite a few IDS evasion modes and is pretty fast. It is not that subtle though, which is why I modified it to be a bit more stealthy.

Cisco Scanner - This is a small little windows util I found that scans IP ranges for routers with the default password of 'cisco'. It has turned up some surprising results in the past and just goes to show how even small little tools can be very useful. I am planning to write a little script that will scan IP ranges looking for different types of equipment with default passwords.

Sophie Script - A little perl script coupled with user2sid and sid2user (two windows programs) which can find all the usernames on a windows machine.

Legion - This is a windows file share scanner by the erstwhile Rhino9 security group. It is fast as hell and allows you to map the drive right from in the software.

Pwdump2 - Dumps the content of the windows password sam file for loading into a password cracker.

L0phtcrack 3.0 - Cracks the passwords I get from the above or from its own internal SAM dump. It can also sniff the network for password hashes or obtain them via remote registry. I have not tried the latest version of the software, but it is very highly rated.

Netcat - This is a TCP/UDP connection backend tool, oh boy I am lost without this ! Half my scripts rely on it. There is also an encrypted version called cryptcat which might be useful if you are walking around an IDS. Netcat can do anything with a TCP or UDP connection and it serves as my replacement to telnet as well.

Hping2 - A custom packet creation utility, great for testing firewall rules among other things.

SuperScan - This is a windows based port scanner with a lot of nice options. Its fast, and has a lot of other neat little tools like NetBIOS enumeration and common tools such as whois, zone transfers etc.

Ettercap - When sniffing a switched network, a conventional network sniffer will not work. Ettercap poisons the ARP cache of the hosts you want to sniff so that they send packets to you and you can sniff them. It also allows you to inject data into connections and kill connections among other things.

Brutus - This is a fairly generic protocol brute forcing tool. It can bruteforce HTTP, FTP, Telnet and many other login authentication systems. This is a windows tool, however I prefer Hydra for linux.

Bunch of Common Exploits Effeciently Sorted

This is my collection of exploits in source and binary form. I sort them in subdirectories by operating system, then depending on how they attack - Remote / Local and then according to what they attack - BIND / SMTP / HTTP / FTP / SSH etc etc. The binary filenames are arbitrary but the source filenames instantly tell me the name of the exploit and the version of the software vulnerable.

This is essential when you're short on time and you need to 'pick one'. I don't include DoS or DDoS exploits, there is nobody I know who would authorise you to take down a production system. Don't do it -- and tell them you arent doing it.. and only if they plead with you should you do it.

Presenting Reports

This is the critical part -- it's about presenting what you found to people who probably don't understand a word of what your job is about other than you're costing them money. You have to show them that there are some security problems in your network, and this is how serious they might be.

A lot of people end the pen-test after the scanning stage. Unless someone specifically tells me to do this, I believe it is important you exploit the system to at least level 1. This is important because there is a very big difference in saying something is vulnerable and actually seeing that the vulnerability is executable. Not to mention when dealing with a corporate type, seeing 'I gained access to the server' usually gets more attention than 'the server is vulnerable to blah blah'.

After you're done, make a VERY detailed chronological report of everything you did, including which tools you used, what version they are, and anything else you did without using tools (eg. SQL injection). Give gory technical details in annexes -- make sure the main document has an executive summary and lots of pie charts that they can understand. Try and include figures and statistics for whatever you can.

To cater to the admins, provide a report for each host you tested and make sure that for every security hole you point out, you provide a link to a site with a patch or fix, . Try to provide a link to a site with detailed information about the hole preferably bugtraq or some well known source -- many admins are very interested in these things and appreciate it.