Knockin' At Your Backdoor
A Guide to Penetration Testing
by Thomas Rude, CISSP
October 2000 - First Draft
Penetration testing. This phrase can conjur up many images and thoughts, some of which are better left to the creators of horror films. However, in today's digital data arena, where corporate empires are being built with people's personal information, penetration testing is a necessary function for every Security Department. Penetration testing needs to be thought of and discussed. The empires' data needs to be protected. No longer can we rely on firewall implementations as the answer to privacy. Misconfigurations, exploits, updates, patches, backdoors, disgruntled employees - all are driving reasons for the need for penetration testing.
There is no better way to find out where our weaknesses lie than by regularly performing penetration testing. I cannot think of a single greater test to prove the strength of our defense than by attempting to penetrate it. And I advocate to perform this testing regularly for obvious reasons: new exploits are released on a daily basis, patches and updates to software and firmware are released regularly as well, and by changing the mix of our ingredients (say, allow a new service through the firewall OR add a web front end to the back end database) we open the door to the possibility of a new breach.
There are different types of penetration tests. Or, perhaps, there are different scopes of penetration testing is the better way to phrase it. For example, we may test to see what can be compromised in the DMZ (de-militarized zone). Or, we may test to see if a network breach is possible (working in to the Intranet). Perhaps we test the PBX and the block of phone numbers. Or maybe we get very specific and test to see if we can not only penetrate the network, but compromise the database server as well. We can see that the scope of penetration testing is limited by only our concern for what is valuable to the company. What do we deem worthy of safe keeping? What must not be breached, no questions asked? What is disposable, in the sense that a breach of this system is acceptable?
Step 1: Defining the Scope
Long before the actual execution of the testing begins the scope of the test needs to be defined. Only by defining the scope can the critical areas be targeted, legalities addressed, and the execution team formed.
Who will be performing the test? The big debate here is in-house versus an outside party. And it really boils down to having checks in place. Remember in accounting where you have one group of persons handling accounts payable and another group handling the accounts receivable? And, ultimately, a (hopefully) neutral third party audits them both? Well, the same rationale applies to information security. Do you want your in-house people auditing their systems? Can you see the problems that arise? The implications that may be raised?
In all honesty, I cannot think of but a few circumstances where the penetration testing should be conducted by in-house staff. First, if there are monetary considerations (I.E., lack of fund$), then having in-house staff perform the testing is acceptable. At least someone is checking the security! Someone is better than no one - or, in worst case scenario, John Wannabe Hacker. Second, if the confidentiality of the data and/or the network architecture is so paramount that there is zero tolerance for any non-employee knowledge of it, then, again, in-house testing is mandatory. Perhaps this would apply in certain financial and governmental arenas?
By contracting with an outside party you are allowing for a complete and unbiased testing process (again, assuming that the outside party is neutral). There are many benefits to this beyond what we have already covered (checks and balances). By contracting with an outside party to perform penetration testing we can control, on a very granular level, the complete process. For example, we can give them as much or as little information about our security/network/architecture as we like. Obviously with in-house staff we do not have this valuable control. Personally, I believe this to be a decisive factor in penetration testing. Do we want to give them nothing and let them find everything on their own? Or, do we give them some information and through this give them a head start? As a side note, in keeping with security lingo, if a team is hired to perform a penetration test and given no information, this team is known as a RED TEAM.
The answer to this question is not as black and white as it may first appear. Yes, the idea behind the testing is to see what weaknesses are prevalent. But, do we want to take the stance of John Wannabe Hacker who knows nothing about our network and starts his attack from ground zero? Or, do we have to provide some information in order to protect ourselves? Perhaps our network environment is a 24/7/365 shop. Can we afford to have the penetration testing affect the availability? Or perhaps within our network we have a few key resources of which their existence must remain unknown. Do we give out some direction to the testing making sure to steer away from these resources? So, there are times when we have to give out information. Only your company can decide what is appropriate to your individual circumstances.
Ultimately, the penetration testing will be unique to each company. And maybe each company can have varying scopes of penetration testing: one for the PBX, another for the firewall, a third for the DMZ, etc. A major key to the success of this testing comes from the cooperation of the departments within the company. By working together the scope is defined and key issues are addressed.
Equally important during this scope definition stage are the legal implications which need to be addressed. For example, if we provide a service to customers (say we are a managed security services company) and the penetration testing affects the availability of this service (perhaps the testing party successfully penetrates the firewall but in the process brings it down), what are our responsibilities and what legal issues do we need to address? This is just one of many examples and scenarios which must be considered prior to the actual testing. Others may include; data integrity, network performance, detrimental publicity, etc.
As you can see, it is imperative that these issues must be raised and addressed prior to any testing. Through answering them the scope of the testing becomes very focused and defined. Further, there are then legalities which need to be worked out with the outside party. By having a tightly defined contract you will have recourse in the event that the testing party causes some adverse 'thing' (thing being defined as publicly leaked results, a crash of a server, etc.).
Playing devil's advocate, we, as the penetration testers, also need to cover ourselves legally. We must have a tightly defined contract from which to base our work. Are we to simply gather as much information as possible? Are we to only find holes? Are we to exploit those holes? In a nutshell, we need to cover our backsides with no doubt left.
(I would like to make a pitch to the legal experts reading this paper. My background and expertise is not the legal arena. For those of you who have this background, what is your experience with penetration testing? How have you handled the legal issues? I am sure we would benefit from your knowledge and appreciate any experience you can share)
As we plow through the team formation and legal issues we are faced with the third major area of the scope definition- what are our targets? Are wanting wanting a full-blown penetration testing of our entire 'empire' (empire being defined as network, telephony, and personnel)? Or are we wanting to target a specific area such as our firewall?
As you can see, the target of the penetration test can be any number of items. Network resources could include: firewalls, e-mail servers, database servers, standalone PCs, routers, etc. Telephony resources could include: PBXs, modems, etc. Personnel resources could include all in-house staff as well as delivery carriers. Do we perform a full-blown, intensive and invasive penetration test whereby we begin at ground zero, gather information and then attempt to exploit our findings? Or do we define a much narrower scope and target just the firewalls?
Defining the target system(s) is crucial in so many ways - legally, resourcefully, and financially. Perhaps a rotating schedule is best - whereby each month one of the three areas of the empire is targeted. This allows for testing of all key areas as well as a division of monies available.
The last point I would like to make in Step 1 is that an acceptable method of penetration testing is as follows: an outside party is contracted to perform a full-blown test. After the scope is defined, the test is performed. Upon completion, the methodology used and results obtained are shared. Further, a future date is set for another round of testing. In the interim period, we can perform our own testing according to the methodology given to us from the contracted party. This provides many benefits, some of which are the sharpening of in-house skillsets and the peace of mind that regular testing is being performed.
Step 2: The Reconnaissance Mission
This is where the fun begins! And it also happens to be what separates the men from the boys! No matter what the scope of the penetration test, information gathering is most critical. The outcome of the testing will be affected by the ability of the testers to effectively (and sometimes efficiently) gather information.
From a lack of experience, someone could perform a penetration test simply with any one of the numerous scanning tools available today (both commercial and freeware). Would this be a successful test? Perhaps. If the tool has been configured and applied correctly, it may find holes in the empire - if holes exist. Now, as we dig deeper, we must face this question: if we use a tool and no holes are found, are we to assume that our empire is safe?
I would like to suggest that the answer to the above question must be, in almost all cases, a resounding NO. This is not to take away from any tools that are available. There are many excellent products out there. However, I have yet to find one tool that does it all. And, from experience and knowledge, I have to believe that others, like myself, have found false positives at times with these tools, and even false negatives at other times.
When you consider the numerous pieces which make up an empire (software, hardware, access points, personnel) is it that difficult to see where any combination of these pieces can together create a hole? And a hole that has either; a) not been found previously, or b) a hole which has not been defined in this exact way from this combination? The potential number of variables from adding operating systems, web servers, mail servers, dns servers, database servers, etc., together is staggering.
From experience comes the knowledge that the reconnaissance mission will be the deciding factor in the depth of success of a penetration test. Why is it that one group of testers might find 2 holes, and another group find 13 holes? Especially when these two groups were given the same base line information and tools! Could it be because one group had more success at the information gathering stage and were therefore better able to design and deploy their penetration test?
When we speak of information gathering we are speaking of the process of gathering as much information on the empire as we can. Let us assume that we are a red team contracted to perform a penetration test of an empire. The only thing we know about the empire is their name -> Plaster Caster. Where do we begin to gather information? How can we penetrate their empire with no IP addresses or other targets given to us? This, my friends, is where the reconnaissance mission begins.
Self explanatory....read what we can about 'Plaster Caster' - press releases, newspaper articles, annual reports, SEC filings, and do not overlook their web site of course! Is it efficient to read absolutely everything we find? Of course not. Through experience we will learn to pick what we read more carefully. But to start, these are sources of vital company information! Things to look for: names of employees (especially key figures), product lines/releases, key dates (for example, the date a partnership was formed, or even better - the vice president's birthday), empire locations, mentions of hardware/software used, etc. The key to remember is that we start to build our target's profile here. I have included below a list of places to where I usually start information gathering. It is by no means an all inclusive list, just some starting points.
-->www.edgar-online.com = the source for SEC filings. Also has information on litigation, annual reports, and other financial information.
-->www.hoovers.com = an excellent source for business news, both historical and current. Perform a company name search.
-->www.tradespeak.com = an excellent source for white papers. Search by company or author. Now, if the author is the Network Admin and the paper is on "Routing" or something similar...hmm...
-->www.newsbytes.com = an excellent source for news pertaining to the information technology arena.
-->www.thomasregister.com = search for an American Manufacturer.
-->www.uspto.gov/patft/index.html = US Patent and Trademark Office web patent database.
-->www.firstgov.com = an excellent site for all government information.
-->www.govsearch.com = an excellent site for government resource information.
-->www.dotcom.com = an excellent source of information about the .COM world, operated by Network Solutions.
-->www.genealogy.com = once you have names, the place to go for a bit of family history. (looking for help on passwords?)
-->babelfish.altavista.digital.com/translate.dyn = the place to get that information translated from one language to another.
Digging a little deeper, we can now begin a more focused search. From the step above we have collected plenty of information. Now we want to narrow the scope a bit and target key areas of the company. These key areas may be networks, personnel, physical structures, strategic partners, etc. There are 'sub steps' within this process, and I will try to list them in an understandable context.
-->www.networksolutions.com/cgi-bin/whois/whois = Domain name lookup from Network Solutions. Find administrative, technical, and billing contacts. Can be almost nothing to the jackpot. For example, Plaster Caster may have their administrative and technical contacts listed (full name, address, phone/fax numbers, e-mail address) and now we have some excellent, focused, information to help shape our target's profile.
-->www.allwhois.com = as advertised, "the most complete whois service" you can find. Perform a domain search on Plaster Caster in any country. An incredible database!
NOTE: Performing the WHOIS lookup not only provides us with contact information, but it also lists the two Name Servers for the domain. These names and IP Addresses come in handy during the next step because many yield a very detailed network map for the domain, in our case 'PlasterCaster.com'
-->www.cdb.com/public/ = when you need to dig deeper, CDB Infotek may be the service answer. A multitude of services, centering around verification of assets and information for both people and businesses.
-->www.informus.com = Informus Corporation provides a plethora of services based on employment screening, but again, these services could be used to gather very specific information on assets and personnel for our target company.
NOTE: Depending on how in-depth we want to take the penetration test, we can gather personal information via background checks of key personnel (System and Network Administrators, Security Officers, Marketing Department, etc.).
Narrowing our focus, it is time to scan the networks. Through network mapping we attempt to draw a well-detailed architecture of our target. Web servers, dns servers, routers, gateways, and e-mail servers will become part of our map. We could perform an invasive ping sweep (sure to set off alarms and drop our IP Address) or a less alarm triggering stealth scan (longer in duration, but much more appropriate). Our goal should be to discover key IP Addresses, network masks, and specific operating systems and services (for example, a Linux box running Apache and telnet). Finally, let us not forget one of my favorite explorations - sweeping a block of phone numbers for unsecured modems!
Take care to not overlook strategic partners and alliances in addition to remote offices when scanning. There are times when the easiest way in is via another company in the food chain. Perhaps PlasterCaster's weakest link is via 'Company X' who provides their widgets.
-->nmap = the ultimate network exploration tool? Port scanning, ping scanning, OS fingerprinting, and more.
-->thc-scan = scans a block of numbers for carriers, tones, VMBs, Fax, etc.
We have read, searched, and scanned. It is now time to target what was discovered during the mapping process. We can use commercial or freeware products. In my opinion, it is best to use a combination. Seeing how the selection of tools is based upon the systems involved and personal experience, I have opted to not discuss them here. Perhaps that is a topic for another paper?
From scanning we were able to identify key resources. By targeting these key resources we attempt to get a thorough understanding of their configuration. In reality, the scanning and targeting processes seem like one process. And, in fact, they could be. However, we try to separate them by using scanning for laying out the network map and targeting to drill down within that map and enumerate the services and configurations.
If you have the permission, run them there exploits! However, do make sure that you have express written consent to run the exploits BEFORE attempting to do so! If not, you could be in for a rather nasty battle.
Back to Papers
copyright @2002 email@example.com