DATA SECURITY MANAGEMENT
P
ERFORMING
P
ENETRATION
T
ESTING
Stephen Fried
I N S I D E
Basic Attack Strategies; Planning the Test; Performing the Test; Reporting Results
BASIC ATTACK STRATEGIES
Every security professional who performs a penetration test will ap-proach the task somewhat differently, and the actual steps used by the tester will vary from engagement to engagement. However, there are sev-eral basic strategies that can be said to be common across most testing situations.
First, do not rely on a single method of attack. Different situations call for different attacks. If the tester is evaluating the physical security of a location, the tester may try one method of getting in the building; for ex-ample walking in the middle of a crowd during the morning inrush of people. If that does not work, try following the cleaning people into a side door. If that does not work, try something else. The same method holds true for electronic attacks. If one attack does not work (or the sys-tem is not susceptible to that attack), try another.
Choose the path of least resistance. Most real attackers will try the eas-iest route to valuable information, so the penetration tester should use this method as well. If the test is attempting to penetrate a company’s network, the company’s firewall might not be the best place to begin the attack (unless, of course, the firewall was the stated target of the test) be-cause that is where all the security attention will be focused. Try to attack lesser-guarded areas of a system.
Look for alternate entry points; for example, connections to a compa-ny’s business partners, analog dial-up services, modems connected to desktops, etc. Modern corporate
net-P A Y O F F I D E A
Penetration testing requires careful planning to avoid serious problems. The performance can be like a series of mines in a field. Learn from this article those proven techniques that can help during each step along the way. Be-cause the test is not completed until the final report is provided to management, this article covers what should be included in this report. 82-02-68
works have many more connection points than just the firewall, so use them to the fullest advantage.
Feel free to break the rules. Most security vulnerabilities are discov-ered because someone has expanded the limits of a system’s capabilities to the point where it breaks, thus revealing a weak spot in the system. Unfortunately, most users and administrators concentrate on making their systems conform to the stated policies of the organization. Processes work well when everyone follows the rules, but can have unpredictable results when those rules are broken or ignored. Therefore, when per-forming a test attack, use an extremely long password; enter a thousand-byte URL into a Web site; sign someone else’s name into a visitors log; try anything that represents abnormality or nonconformance to a system or process. Real attackers will not follow the rules of the subject system or organization — nor should the tester.
Do not rely exclusively on high-tech, automated attacks. While these tools may seem more “glamorous” (and certainly easier) to use they may not always reveal the most effective method of entering a system. There are a number of “low-tech” attacks that, while not as technically ad-vanced, may reveal important vulnerabilities and should not be over-looked. Social engineering is a prime example of this type of approach. The only tools required to begin a social engineering attack are the tester’s voice, a telephone, and the ability to talk to people. Yet despite the simplicity of the method (or, perhaps, because of it), social engineer-ing is incredibly effective as a method of obtainengineer-ing valuable information. “Dumpster diving” can also be an effective low-tech tool. Dumpster diving is a term used to describe the act of searching through the trash of the subject in an attempt to find valuable information. Typical informa-tion found in most Dumpsters includes old system printouts, password lists, employee personnel information, drafts of reports, and old fax transmissions. While not nearly as glamorous as running a port scan on a subject’s computer, it also does not require any of the technical skill that port scanning requires. Nor does it involve the personal interaction required of social engineering, making it an effective tool for testers who may not be highly skilled in interpersonal communications.
One of the primary aims of the penetration tester is to avoid detection. The basic tenet of penetration testing is that information can be obtained from a subject without his or her knowledge or consent. If a tester is caught in the act of testing, this means, by definition, that the subject’s defenses against that particular attack scenario are adequate. Likewise, the tester should avoid leaving “fingerprints” that can be used to detect or trace an attack. These fingerprints include evidence that the tester has been working in and around a system. The fingerprints can be physical (e.g., missing reports, large photocopying bills) or they can be virtual (e.g., system logs detailing access by the tester, or door access controls
logging entry and exit into a building). In either case, fingerprints can be detected and detection can lead to a failure of the test.
Do not damage or destroy anything on a system unless the destruction of information is defined as part of the test and approved (in writing) by management. The purpose of a penetration test is to uncover flaws and weaknesses in a system or process, — not to destroy information. The actual destruction of company information not only deprives the compa-ny of its (potentially valuable) intellectual property, but it may also be construed as unethical behavior and subject the tester to disciplinary or legal action. If the management of the organization wishes the tester to demonstrate actual destruction of information as part of the test, the tester should be sure to document the requirement and get written ap-proval of the management involved in the test. Of course, in the attempt to “not leave fingerprints,” the tester might wish to alter the system logs to cover the tester’s tracks. Whether or not this is acceptable is an issue that the tester should discuss with the subject’s management before the test begins.
Do not pass up opportunities for small incremental progress. Most penetration testing involves the application of many tools and techniques in order to be successful. Many of these techniques will not completely expose a weakness in an organization or point to a failure of an organi-zation’s security. However, each of these techniques may move the tester closer and closer to the final goal of the test. By looking for a single weakness or vulnerability that will completely expose the organization’s security, the tester may overlook many important, smaller weaknesses that, when combined, are just as important. Real-life attackers can have infinite patience; so should the tester.
Finally, be prepared to switch tactics. Not every test will work, and not every technique will be successful. Most penetration testers have a standard “toolkit” of techniques that work on most systems. However, different systems are susceptible to different attacks and may call for dif-ferent testing measures. The tester should be prepared to switch to an-other method if the current one is not working. If an electronic attack is not yielding the expected results, switch to a physical or operational at-tack. If attempts to circumvent a company’s network connectivity are not working, try accessing the network through the company’s dial-up connections. The attack that worked last time may not be successful this time, even if the subject is the same company. This may either be be-cause something has changed in the target’s environment or the target has (hopefully) learned itslesson from the last test. Finally, unplanned opportunities may present themselves during a test. Even an unsuccess-ful penetration attempt may expose the possibility that other types of at-tack may be more successful. By remaining flexible and willing to switch tactics, the tester is in a much better position to discover system weak-nesses.
PLANNING THE TEST
Before any penetration testing can take place, a clear testing plan must be prepared. The test plan will outline the goals and objectives of the test, detail the parameters of the testing process, and describe the ex-pectations of both the testing team and the management of the target organization.
The most important part of planning any penetration test is the involve-ment of the manageinvolve-ment of the target organization. Penetration testing without management approval, in addition to being unethical, can reason-ably be considered “espionage” and is illegal in most jurisdictions. The tester should fully document the testing engagement in detail and get the written approval from management before proceeding. If the testing team is part of the subject organization, it is important that the management of that organization knows about the team’s efforts and approves of them. If the testing team is outside the organizational structure and is performing the test “for hire” the permission of management to perform the test should be included as part of the contract between the testing organiza-tion and the target organizaorganiza-tion. In all cases, be sure that the management that approves the test has the authority to give such approval. Penetration testing involves attacks on the security infrastructure of an organization. This type of action should not be approved or undertaken by someone who does not clearly have the authority to do so.
By definition, penetration testing involves the use of simulated attacks on a system or organization with the intent of penetrating that system or organization. This type of activity will, by necessity, require that someone in the subject organization be aware of the testing. Make sure that those with a need to know about the test do, in fact, know of the activity. How-ever, keep the list of people aware of the test to an absolute minimum. If too many people know about the test, the activities and operations of the target may be altered (intentionally or unintentionally) and negate the results of the testing effort. This alteration of behavior to fit expectations is known as the Hawthorne effect (named after a famous study at West-ern Electric’s Hawthorne factory whose employees, upon discovering that their behavior was being studied, altered their behavior to fit the pat-terns they believed the testers wanted to see.)
Finally, during the course of the test, many of the activities the tester will perform are the very same ones that real-life attackers will use to penetrate systems. If the staff of the target organization discovers these activities, they may (rightly) mistake the test for a real attack and catch the “attacker” in the act. By making sure that appropriate management personnel are aware of the testing activities, the tester will be able to val-idate the legitimacy of the test.
An important ethical note to consider is that the act of penetration test-ing involves intentionally breaktest-ing the rules of the subject organization in order to determine its security weaknesses. This requires the tester to
use many of the same tools and methods that real-life attackers use. However, real hackers sometime break the law or engage in highly ques-tionable behavior in order to carry out their attacks. The security profes-sional performing the penetration test is expected to draw the line between bypassing a company’s security procedures and systems and ac-tually breaking the law. These distinctions should be discussed with management prior to the commencement of the test, and discussed again if any ethical or legal problems arise during the execution of the test.
Once management has agreed to allow a penetration test, the param-eters of the test must be established. The testing paramparam-eters will deter-mine the type of test to be performed, the goals of the tests, and the operating boundaries that will define how the test is run. The primary de-cision is to determine precisely what is being tested. This definition can range from broad (“test the ability to break into the company’s network”) to extremely specific (“determine the risk of loss of technical information about XYZ’s latest product”). In general, more specific testing definitions are preferred, as it becomes easier to determine the success or failure of the test. In the case of the second example, if the tester is able to produce a copy of the technical specifications, the test clearly succeeded. In the case of the first example, does the act of logging in to a networked sys-tem constitute success, or does the tester need to produce actual data taken from the network? Thus, the specific criteria for success or failure should be clearly defined.
The penetration test plan should have a defined time limit. The time length of the test should be related to the amount of time a real adversary can be expected to attempt to penetrate the system and also the reason-able lifetime of the information itself. If the data being attacked has an effective lifetime of two months, a penetration test can be said to succeed if it successfully obtains that data within a two-month window.
The test plan should also explain any limits placed on the test by ei-ther the testing team or management. If ei-there are ethical considerations that limit the amount of “damage” the team is willing to perform, or if there are areas of the system or operation that the tester is prohibited from accessing (perhaps for legal or contractual reasons), these must be clearly explained in the test plan. Again, the testers will attempt to act as real-life attackers and attackers do not follow any rules. If management wants the testers to follow certain rules, these must be clearly defined. The test plan should also set forth the procedures and effects of “getting caught” during the test. What defines “getting caught” and how that af-fects the test should also be described in the plan.
Once the basic parameters of the test have been defined, the test plan should focus on the “scenario” for the test. The scenario is the position the tester will assume within the company for the duration of the test. For example, if the test is attempting to determine the level of threat from company insiders (employees, contractors, temporary employees, etc.),
the tester may be given a temporary job within the company. If the test is designed to determine the level of external threat to the organization, the tester will assume the position of an “outsider.” The scenario will also define the overall goal of the test. Is the purpose of the test a simple pen-etration of the company’s computers or facilities? Is the subject worried about loss of intellectual property via physical or electronic attacks? Are they worried about vandalism to their Web site, fraud in their electronic commerce systems, or protection against denial-of-service attacks? All these factors help to determine the test scenario and are extremely im-portant in order for the tester to plan and execute an effective attack.
PERFORMING THE TEST
Once all the planning has been completed, the test scenarios have been established, and the tester has determined the testing methodology, it is time to perform the test. In many aspects, the execution of a penetration test plan can be compared to the execution of a military campaign. In such a campaign, there are three distinct phases: reconnaissance, attack, and (optionally) occupation.
During the reconnaissance phase (often called the “discovery” phase) the tester will generally survey the “scene” of the test. If the tester is plan-ning a physical penetration, the reconnaissance stage will consist of ex-amining the proposed location for any weaknesses or vulnerabilities. The tester should look for any noticeable patterns in the way the site oper-ates. Do people come and go at regular intervals? If there are guard ser-vices, how closely do they examine people entering and leaving the site? Do they make rounds of the premises after normal business hours, and are those rounds conducted at regular times? Are different areas of the site occupied at different times? Do people seem to all know one anoth-er, or do they seem to be strangers to each other. The goal of physical surveillance is to become as completely familiar with the target location as possible and to establish the repeatable patterns in the site’s behavior. Understanding those patterns and blending into them can be an impor-tant part of the test.
If an electronic test is being performed, the tester will use the recon-naissance phase to learn as much about the target environment as possi-ble. This will involve a number of mapping and surveillance techniques. However, because the tester cannot physically observe the target loca-tion, electronic probing of the environment must be used. The tester will start by developing an electronic “map” of the target system or network. How is the network laid out? What are the main access points, and what type of equipment runs the network? Are the various hosts identifiable, and what operating systems or platforms are they running? What other networks connect to this one? Is dial-in service available to get into the network, and is dial-out service available to get outside?
Reconnaissance does not always have to take the form of direct sur-veillance of the subject’s environment. It can also be gathered in other ways that are more indirect. For example, some good places to learn about the subject are:
• former or disgruntled employees • local computer shows
• local computer club meetings
• employee lists, organization structures • job application handouts and tours
• vendors who deliver food and beverages to the site
All this information will assist the tester in determining the best type of attack(s) to use based on the platforms and service available. For each environment (physical or electronic), platform, or service found during the reconnaissance phase, there will be known attacks or exploits that the tester can use. There may also be new attacks that have not yet made it into public forums. The tester must rely on the experience gained in previous tests and the knowledge of current events in the field of infor-mation security to keep abreast of possible avenues of attack.
The tester should determine (at least preliminarily) the basic methods of attack to use, the possible countermeasures that may be encountered, and the responses that may be used to those countermeasures.
The next step is the actual attack on the target environment. The at-tack will consist of exploiting the weaknesses found in the reconnais-sance phase to gain entry to the site or system and to bypass any controls or restrictions that may be in place. If the tester has done a thorough job during the reconnaissance phase, the attack phase becomes much easier. Timing during the attack phase can be critical. There may be times when the tester has the luxury of time to execute an attack, and this pro-vides the greatest flexibility to search, test, and adjust to the environment as it unfolds. However, in many cases, an abundance of time is not avail-able. This may be the case if the tester is attempting to enter a building in between guard rounds, attempting to gather information from files during the owner’s lunch hour, or has tripped a known alarm and is at-tempting to complete the attack before the system’s intrusion response interval (the amount of time between the recognition of a penetration and the initiation of the response or countermeasure) is reached. The tester should have a good idea of how long a particular attack should take to perform and have a reasonable expectation that it can be per-formed in the time available (barring any unexpected complications).
If, during an attack, the tester gains entry into a new computer or net-work, the tester may elect to move into the occupation phase of the at-tack. Occupation is the term used to indicate that the tester has established the target as a base of operations. This may be because the
tester wants to spend more time in the target gathering information or monitoring the state of the target, or the tester may want to use the target as a base for launching attacks against other targets. The occupation phase presents perhaps the greatest danger to the tester, because the tester will be exposed to detection for the duration of the time he or she is resident in the target environment. If the tester chooses to enter the oc-cupation phase, steps should be taken to make the tester’s presence un-detectable to the greatest extent possible.
It is important to note that a typical penetration test may repeat the re-connaissance/attack/occupation cycle many times before the completion of the test. As each new attack is prepared and launched, the tester must react to the attack results and decide whether to move on to the next step of the test plan, or abandon the current attack and begin the reconnais-sance for another type of attack. Through the repeated and methodical application of this cycle the tester will eventually complete the test.
Each of the two basic test types — physical and electronic— has dif-ferent tools and methodologies. Knowledge of the strengths and weak-nesses of each type will be of tremendous help during the execution of the penetration test. For example, physical penetrations generally do not require an in-depth knowledge of technical information. While they may require some specialized technical experience (bypassing alarm systems, for example), physical penetrations require skills in the area of operations security, building and site operations, human nature, and social interaction.
The “tools” used during a physical penetration vary with each tester, but generally fall into two general areas: abuse of protection systems and abuse of social interaction. Examples of abuse of protection systems in-clude walking past inattentive security guards, piggybacking (following someone through an access-controlled door), accessing a file room that is accidentally unlocked, falsifying an information request, or picking up and copying information left openly on desks. Protection systems are es-tablished to protect the target from typical and normal threats. Knowl-edge of the operational procedures of the target will enable the tester to develop possible test scenarios to test those operations in the face of both normal and abnormal threats.
Lack of security awareness on the part of the victim can play a large part in any successful physical penetration test. If people are unaware of the value of the information they possess, they are less likely to protect it properly. Lack of awareness of the policies and procedures for storing and handling sensitive information is abundant in many companies. The penetration tester can exploit this in order to gain access to information that should otherwise be unavailable.
Finally, social engineering is perhaps the ultimate tool for effective penetration testing. Social engineering exploits vulnerabilities in the physical and process controls, adds the element of “insider” assistance,
and combines it with the lack of awareness on the part of the subject that they have actually contributed to the penetration. When done properly, social engineering can provide a formidable attack strategy.
Electronic penetrations, on the other hand, generally require more in-depth technical knowledge than do physical penetrations. In the case of many real-life attackers, this knowledge can be their own or “borrowed” from somebody else. In recent years, the technical abilities of many new attackers seem to have decreased, while the high availability of penetra-tion and attack tools on the Internet, along with the sophisticapenetra-tion of those tools, has increased. Thus, it has become relatively simple for someone without a great deal of technical knowledge to “borrow” the knowledge of the tool’s developer and inflict considerable damage on a target. There are, however, still a large number of technically advanced attackers out there with the skill to launch a successful attack against a system.
The tools used in an electronic attack are generally those that provide automated analysis or attack features. For example, many freely available host and network security analysis tools provide the tester with an auto-mated method for discovering a system’s vulnerabilities. These are vul-nerabilities that the skilled tester may be able to find manually, but the use of automated tools provides much greater efficiency. Likewise, tools like port scanners (that tell the tester what ports are in use on a target host), network “sniffers” (that record traffic on a network for later analy-sis), and “war dialers” (that systematically dial phone numbers to discov-er accessible modems) provide the testdiscov-er with a wealth of knowledge about weaknesses in the target system and possible avenues the tester should take to exploit those weaknesses.
When conducting electronic tests there, are three basic areas to ex-ploit: the operating system, the system configuration, and the relation-ship the system has to other systems. Attacks against the operating system exploit bugs or holes in the platform that have not yet been patched by the administrator or the manufacturer of the platform. Attacks against the system configuration seek to exploit the natural tendency of overworked administrators not to keep up with the latest system releases and to overlook such routine tasks as checking system logs, eliminating unused accounts, or improper configuration of system elements. Finally, the tester can exploit the relationship a system has with respect other sys-tems to which it connects. Does it have a trust relationship with a target system? Can the tester establish administrative rights on the target ma-chine through another mama-chine? In many cases, a successful penetration test will result not from directly attacking the target machine, but from first successfully attacking systems that have some sort of “relationship” to the target machine.
REPORTING RESULTS
The final step in a penetration test is to report the findings of the test to management. The overall purpose and tone of the report should actu-ally be set at the beginning of the engagement with management’s state-ment of their expectation of the test process and outcome. In effect, what the tester is asked to look for will determine, in part, the report that is produced. If the tester is asked to examine a company’s overall physical security, the report will reflect a broad overview of the various security measures the company uses at its locations. If the tester is asked to eval-uate the controls surrounding a particular computer system, the report will most likely contain a detailed analysis of that machine.
The report produced as a result of a penetration test contains extreme-ly sensitive information about the vulnerabilities the subject has and the exact attacks that can be used to exploit those vulnerabilities. The pene-tration tester should take great care to ensure that the report is only dis-tributed to those within the management of the target who have a need-to-know. The report should be marked with the company’s highest sen-sitivity label. In the case of particularly sensitive or classified information, there may be several versions of the report, with each version containing only information about a particular functional area.
The final report should provide management with a replay of the test engagement in documented form. Everything that happened during the test should be documented. This provides management with a list of the vulnerabilities of the target and allows them to assess the methods used to protect against future attacks.
First, the initial goals of the test should be documented. This will assist anyone who was not part of the original decision-making process is be-coming familiar with the purpose and intent of the testing exercise. Next, the methodology used during the test should be described. This will in-clude information about the types of attacks used, the success or failure of those attacks, and the level of difficulty and resistance the tester expe-rienced during the test. While providing too much technical detail about the precise methods used may be overly revealing and (in some cases) dangerous, the general methods and procedures used by the testing team should be included in the report. This can be an important tool for man-agement to get a sense of how easy or difficult it was for the testing team to penetrate the system. If countermeasures are to be put in place, they will need to be measured for cost-effectiveness against the value of the target and the vulnerabilities found by the tester. If the test revealed that a successful attack would cost the attacker U.S. $10 million, the company might not feel the need for additional security in that area. However, if the methodology and procedures show that an attack can be launched from the Internet for the price of a home computer and an Internet con-nection, the company might want to put more resources into securing the target.
The final report should also list the information found during the test. This should include information about what was found, where it was found, how it was found, and the difficulty the tester had in finding it. This information is important to give management a sense of the depth and breadth of the security problems uncovered by the test. If the list of items found is only one or two items long, it might not trigger a large re-sponse (unless, of course, the test was only looking for those one or two items). However, if the list is several pages long, it might spur manage-ment into making dramatic improvemanage-ments in the company’s security pol-icies and procedures.
The report should give an overall summary of the security of the target in comparison with some known quantity for analysis. For example, the test might find that 10 percent of the passwords on the subject’s comput-ers were easily guessed. However, previous research or the tester’s own experience might show that the average computer on the Internet or oth-er clients contains 30 poth-ercent easily guessed passwords. Thus, the com-pany is actually doing better than the industry norm. However, if the report shows that 25 percent of the guards in the company’s buildings did not check for employee badges during the test, that would most like-ly be considered high and be cause for further action.
The report should also compare the initial goals of the test to the final result. Did the test satisfy the requirements set forth by management? Were the results expected or unexpected, and to what degree? Did the test reveal problems in the targeted area, or were problems found in oth-er unrelated areas? Was the cost or complexity of the tests in alignment with the original expectations of management?
Finally, the report should also contain recommendations for improve-ment of the subject’s security. The recommendations should be based on the findings of the penetration test and include not only the areas cov-ered by the test, but ancillary areas might help improve the security of the tested areas. For example, inconsistent system configuration might in-dicate a need for a more stringent change control process. A successful social engineering attempt that allowed the tester to obtain a password from the company’s help desk might lead to better user authentication re-quirements.
CONCLUSION
Although it seems to parallel the activities of real attackers, penetration testing, in fact, serves to alert the owners of computer and networks to the real dangers present in their systems. Other risk analysis activities, such as automated port scanning, war dialing, and audit log reviews, tend to point out the theoretical vulnerabilities that might exist in a system. The owner of a computer will look at the output from one of these activities and see a list of holes and weak spots in a system without getting a good sense of
the actual threat these holes represent. An effective penetration test, how-ever, will show that same system owner the actual damage that can occur if those holes are not addressed. It brings to the forefront the techniques that can be used to gain access to a system or site and makes clear the ar-eas that need further attention. By applying the proper penetration testing techniques (in addition to the standard risk analysis and mitigation strate-gies), the security professional can provide a complete security picture of the subject’s enterprise.
Stephen Fried is the senior manager for Global Risk Assessment and Secure Business Solutions at Lucent Tech-nologies, leading the team responsible for determining the security threats to Lucent's internal systems and ser-vices. Lucent's Corporate Computer and Network Security Organization. He is a Certified Information Systems Security Professional and has been a featured speaker on information security and technology at meetings and conferences worldwide.
