IT’S ALL ABOUT PERSPECTIVE

Look at M. C. Escher’s painting Concave and Convexand you will quickly under- stand the meaning of perspective. On the other hand, maybe you prefer the saying, “A picture is worth a thousand words.” No matter your definition, everyone seems to have a different perspective about security, especially penetration testing.

Certainly, we all agree on what is being done during the test, but what of the impacts our decisions have on the test? What are the inherent and imposed limitations and how do we work within them to ensure value? What are your expectations of the test and your security program? Setting expectations and understanding the limitations of the test will help ensure proper planning.

OVERALL EXPECTATIONS

Companies that look to ethical hacking for security services have a broad spectrum of expectations. This can be a touchy subject with many topics to consider, ranging from political, technical, financial, and simple naiveté of security. Many companies expect that the penetration engagement will represent a real hack and the results can be directly applied to operations to mitigate any further intrusion. Unfortunately, this is not possible because of the various limitations placed on the testers, such as time and ethics, and the dynamics of technology as well as the mindset and capa- bilities of the tester compared to a hacker.

Another assumption by test recipients is that the results are comprehensive. Everyone understands that no system is entirely secure and is vulnerable to some form of attack. Considering this, many conclude that a highly paid whitehat hacker should find a hole and successfully exploit it. With the pressure to be successful, a tester may identify a single vulnerability and spend the entire engagement exploiting it to ensure the engagement was successful, from his perspective. However, this begs the question, “What was missed?” It must be not be readily assumed that all the vulnerabilities were identified, much less exploited.

Expectations for the test will set the bar for which the success of the test is to be measured and will become the foundation of imposed limitations. When perform- ing an ethical hack there must be restrictions to avoid seriously damaging equipment, imposing excessive downtime, destroying data, or causing personal anguish of tar- geted employees. Therefore, establishing limitations for the ethical hack is a standard

procedure, but are organizations informed when adopting restrictions on the test or simply embracing fictitious boundaries?

For example, a customer, having just implemented several forms of IDS and network controls, wanted an ethical hack. During the initial conversations, it was stated not to reveal the existence of IDS to the testers. This is where the expectations and value collide.

Notifying the testers that IDS is present would allow them the opportunity to test vulnerabilities surreptitiously using specific IDS evasion techniques, ultimately testing the ability of the IDS in concert with the existence of vulnerabilities. Of course, the byproduct is actually tuning the IDS systems to a controlled, highly sophisticated attack.

The fictitious boundary in this example is the assumption by the organization that real hackers will not know IDS exists and therefore neither should the testers. This is a perfect example of a narrow understanding of the inherent limitations placed on the tester, poor threat profiling, and the inability to use the test to one’s advantage rather than within a popular framework.

The prevalent philosophy behind ethical hacking is to attack a system. However, this perception ignores the confines of the test and the valuable role it can play in a security strategy. Simply stated, by forcing an experienced security professional to mimic an attacker greatly reduces the differentiating value of the test.

How Deep Is Deep Enough?

It is a common practice to define the networks and systems that are to be targeted, but it is rare to specify the depth of an attack.

There are two traditional approaches to dealing with the depth of an attack: 1. Specify a system, application, data, or authorization level to be obtained

before halting the specific exploit.

2. Do not state any limitation to the depth of the attack.

Many companies communicate that if a certain point is reached, such as obtain- ing root on a server, to stop the engagement or contact the management team as soon as possible. In nearly every case, the boundary is associated with a system, application, database, or some other attribute of the network that represents a point where the test represents a threat to the integrity of the organization.

In contrast, there are those who simply do not stipulate any depth limitations. No restriction on the depth of the attack represents a poor perspective of the potential value of the test and security practices, not to mention the potential damage that may result.

In both cases, there is no solid reasoning behind controlling the depth of an attack beyond the simple protection of systems. In contrast, the depth of the attack should be directly related to the overall security architecture and the relation to identified vulnerabilities. We see much of this when the target wishes to review the list of vulnerabilities prior to the exploitation phase to gather greater insight as to the potential risks associated with each.

Ask yourself: What is the logical impact of a vulnerability? Is it always necessary to obtain root or was the vulnerability essentially proven long before acquiring root- level privileges? When a vulnerability exists and is exploited are there opportunities to make logical conclusions on the obtainable depth into a system without actually prying the hole open any farther?

When planning for the test, what constitutes a success should be defined. This is important for several reasons, most notably, time. Time is what costs money, typically, not a tool or some product. The time it takes to penetrate a network is directly associated with the cost of the test. Given that time is an element not applied to a hacker and only to a tester, the length of time it takes to actually exploit a vulnerability may be an obtuse investment. Most occasions exploiting the vulnera- bility are core to gaining the most value from the test. However, there are situations where the evolution of the attack meets a point where you are only stacking up evidence to prove a point that was made hours, if not days, prior. The point of the test is to determine the true risk of vulnerabilities to the company if they were exploited. Once that’s met, then going beyond that point can be considered super- fluous.

To illustrate this point, consider a traditional network with a firewall, IDS, a DMZ with Web servers, and some middleware connecting them to a database of account information. A tester begins by scanning the firewall and peering into the Web server. He identifies a vulnerability in the Web server that can be exploited through the firewall. He spends a few hours researching and discovers a method that could be used to disable the IDS with a paralyzing collection of packets. This proves to be successful and eventually exploits the vulnerability in the Web server. Now, with complete control of the Web server he uses the poorly configured middleware to inject data into the database. During this process he sees the database is running on a vulnerable version of UNIX. With a strong foundation established in the Web server he exploits the vulnerable UNIX system and with a rootkit obtains root on the system within minutes. As root he essentially owns the system and begins to move around the network in search of other opportunities. He spends several days finding many other UNIX hosts that have the same vulnerability and takes them over with much the same technique. At this point he uses the information collected to move to other networks throughout the company. By the end of the engagement, he has found no less than 15 vulnerable UNIX hosts throughout the network.

At what point was the risk associated with the vulnerability proven? As you can see, this is a very argumentative point. Supporters of the depth of the attack would argue that the process exposed weaknesses in many systems well beyond the initial point of entry. Other could argue that once the first UNIX system was exploited the vulnerability was proven. All the same, many would support that this was a very successful test. However, in the scope of true value, once the UNIX system was exploited, the tester should have noted it and looked for other unrelated opportunities. In fact, the tester’s finding that all the UNIX systems had the same vulnerability would have been the first signal to the tester to look for other avenues of attack. Several critical vulnerabilities were identified: the IDS, Web server, and middleware to name only a few and all these were proven in a very short timeframe. As a hacker, this example is a great opportunity to wreak havoc on a company, but as a tester,

the goal should be to expose a multitude of threats and use his understanding to project the likelihood of deeper attacks. If the tester were to continue launching attacks into the company from a fortified position, his customer, upon closer inspec- tion, would realize the limited inclusiveness of the test and possibly question the overall value.

ONE-HOLE WONDER

To draw upon the previous discussion, there are occurrences of a single vulnerability being used as a gateway into the targeted network. A hole is found on a Web server in the DMZ and exploited to gain administrative control. Due to the lax security controls of the targeted company, the admin account’s password is the same across several critical systems. The tester spends the entire engagement pulling sensitive information from every system for which she has administrative access. The results are collected and presented, having a profound impact on her customer.

But, under closer scrutiny the value of the test is nearly nonexistent. The test has proven the existence of a single vulnerability—a highly critical one—but one never- theless. The test also proved internal security access methods are lacking a great deal. However, is a penetration test necessary to identify these shortcomings? A brief assess- ment investigating password management and access controls would have exposed the problem much faster, with less risk to operations, and probably at less expense.

All too often companies that know little about security seek penetration testing as the silver bullet to expose their strengths or weaknesses. When a test is performed using a single point of entry, the results are usually astounding and shocking. This is due to the fact that most companies have fortified borders and no regard for internal controls. Therefore, once in, the game is over. So by using the same argument, the test should be used to identify as many points of potential entry and stop, knowing the network could not withstand the attack.

So how is a company to know how to address these issues when a test is being performed? It comes down to balancing the test with the results being gathered and determining the scope of what you’re trying to accomplish. If you want to know how far an attacker can get into your network without concern for the vulnerability, then a single hole will do just fine. This is the best approach for an organization that feels its perimeter and internal security controls are sufficient, but does not go as far as being concerned with internal threats. In contrast, if the perimeter is the foundation of your security, the exploitation of a single vulnerability will be useless.