Network security, lesson 3: Penetration testing

This series intends to serve as a very brief introduction to information security with an emphasis on networking. Part three covers penetration testing techniques.

Penetration testing is basically when you hire security consultants (or yourself) to exploit 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 administrators 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 specialized 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 favorite tools and the way I like to perform 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.

Penetration testing resources

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:

Testing preparation

The advantage of using a Microsoft platform comes from the fact that 90% of your targets may be Microsoft systems. However, the flexibility under Linux is incomparable; it is truly the operating system (OS) of choice for any serious hacker, and as a result, for any serious security professional. There is no best OS 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. You're very likely to be switching between them for different tasks.

  
Administrator's notebook
Need a quick review? Here are the main points:
  • Penetration testing is basically breaking into your own (or your client's) network to see how others would do it.
  • Make sure you have permission, in writing, before scanning or testing a network.
  • There are multiple scanners and other tools that you can use to test your network.
  • Never simulate a Dos or DDoS exploit.
  • Write a detailed report showing how you gained access to the network to present to company executives. Include solutions to help administrators fix problems.

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 administrator or some other technically adept person with the right authorization, not someone at the corporate management level. This is very important because if you do something that ends up causing trouble on the network, it's going to make you look very unprofessional. It's always better to have it what you are allowed to do put clearly in writing.

I would recommend this even if you're an administrator conducting an in-house test. You can get fired just for scanning your own network if it's against your corporate policy. If you're an outside tester, offer to allow one of the company's IT people to be present for your testing. This is recommended because they will ultimately be fixing most of the problems you find. As in-house staff, they will be able to put the results of the test in perspective to the managers.

I don't like working from laptops unless it's 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 doesn't work, the system also dual boots Red Hat 9. Often I'll just work everything out from there.

Penetration tools

  • Nmap - 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 - Free vulnerability scanner, usually finds something on every host. It's not too stealthy, though, and will show up in logs.

  • Retina - A very good commercial vulnerability scanner, I stopped using this after I started working with Nessus but it's very quick and good. Plus its vulnerability database is very up-to-date.

  • Nikto - This is a Web server vulnerability scanner. I use my own hacked up version of this Perl program that 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 utility 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) that can find all the usernames on a Windows box.

  • Legion - This is a Windows file share scanner by the erstwhile Rhino9 security group. It is fast and allows you to map the drive right from 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, and I am lost without it! Half of my scripts rely on it. There is also an encrypted version called cryptcat that 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. It's 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.

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. 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 isn't anyone I know who would authorize you to take down a production system. Don't do it -- and tell them so.

I start by visiting the target Web site, 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 e-mail 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, because a lot of administrators frequent bulletin boards for help. All this information goes into a text file. Keeping notes is critically important -- it's very easy to forget some minor detail that you should include in your end report.

Presenting reports

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 between saying something is vulnerable and actually seeing that the vulnerability is executable. Also, when dealing with executives, saying, "I gained access to the server'" usually gets more attention than, "The server is vulnerable to blank."

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 (i.e. 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 administrators, provide a report for each host you tested and make sure you provide a link to a site with a patch or fix for every security hole that you point out. Try to provide a link to a site with detailed information about the hole, preferably bugtraq or some well-known source. Many administrators are very interested in these things and appreciate it.


Networking Click over to Firewall.cx for more articles like this one. You don't have to register or jump through any hoops. All you do is get the networking information you want. Copyright 2004 Firewall.cx.
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. You have to show them that there are some security problems in your network, and this is how serious they might be.
This was first published in February 2004

Dig deeper on Network Security Best Practices and Products

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close