Professional Penetration Testing For Better Security

Author: David Brussin
Exclusive to the Web Site
Copyright David Brussin

Highlights:

Testing the security of network architecture
Verifying vendor claims about security products
Using "paradigm shift" to uncover unseen problems
Exploiting "allowed paths" to compromise security

When in Rome, conventional wisdom says we should do as the Romans do. When securing information systems, it is often helpful to do as the attackers do. Penetration testing, or approaching the security of systems and architectures from the point of view of an attacker, can be an extremely valuable technique in protecting sensitive systems and information. In an era of increasing Internet connectivity, testing the security of systems becomes critical to protecting sensitive information. This type of testing at its simplest consists of using contemporary hacking tools and techniques to confirm the effectiveness of a security configuration. This article will show how penetration testing as an approach is also able to make significant accomplishments in confirming the effectiveness of security designs.

Why penetration testing?

Penetration testing provides a number of benefits to the security effort, many of which could not be realized through other methods. Such testing, whether of internally developed or commercial solutions, helps to confirm the effectiveness of a design, and to verify vendors' claims about security features. Approaching the problem of security from the perspective of an attacker, who needs to find only one weakness to be successful, can often address many problems otherwise invisible to the defender (who has to defend many different points of attack). Also, the penetration tester has the freedom to act outside the paradigm, or context, of the system and its purpose. This paradigm shift can uncover problems that designers may never have considered. Finally, the penetration tester can work around perimeter defenses, such as firewalls, by exploiting 'allowed paths.' Allowed paths, or those services that a system provides, intentionally and by design, can often be manipulated to compromise security.

To use an analogy, the person responsible for protecting a computer system is like the defender of a castle. The defender must protect all points on the castle wall simultaneously, while the attacker has only to find a single weakness in order to take the castle. It can be quite valuable for the tester to put herself in the attacker's shoes, and attempt to find a single method of breaching the system's security. In performing this type of testing, the security professional must consider a number of factors, including the threats to the particular system or information involved. The best results will be obtained by closely approximating the types of threats the system will face. For example, a web server that contains no confidential data might face primarily 'vandalism' and denial of service attacks, whereas a sensitive banking system might be expected to deal with sophisticated criminal attacks. Also, the extent of a penetration test varies with the types of threat. A penetration test is not meant to be exhaustive, and is considered successful when vulnerabilities are discovered which could be used to compromise the target system with the amount of effort that a threat would be able to expend.

Small problems add up to big holes

As an illustration, we will look at the results of a penetration test on a fairly large telecommunications company. This organization had put into place a sophisticated Internet architecture. The architecture was configured in such a way that a combination of several problems could be used to compromise the internal network. These problems, which could be identified through other means, each presented minor weaknesses. The penetration testers, however, approached the problem with an attacker's 'serial' perspective, and were able to combine the smaller vulnerabilities to find a major problem.

In this case, the architecture did not have properly isolated internal and external DNS (Domain Name Service). This in and of itself is considered a weakness in an Internet architecture, but this wasn't enough to compromise the architecture. The architecture also had a weak HTML/CGI combination that permitted an attacker to send arbitrary e-mail from the web server. This problem, although more serious, was not on its own enough for a compromise. The combination of these two problems, however, permitted the penetration testers to target specific internal systems, identified through the DNS misconfiguration, for sendmail attacks using e-mail from the web server. At that point, this branch of testing could be stopped, considering the fact that a dedicated attacker would be able to systematically attack systems behind the firewall using these techniques.

Exploiting the paradigm shift

The contrast between defender and attacker is not the only factor that makes penetration testing beneficial. The fact that an attacker is not involved with the development, or even concerned with the intended purpose, of a system allows a 'paradigm shift' in the testing approach. This approach is best illustrated through an example. As corporations rush to fully represent themselves on the Internet, and to take advantage of electronic commerce opportunities, many organizations are realizing that they must take the critical step of connecting web applications to the live back-end systems and data that are the informational heart and soul of their businesses. Seeking to protect these critical internal systems, the more security aware companies guard electronic commerce web servers with firewall architectures, and require authentication before requests can be made of internal servers. In many cases, the paradigm shift between system designer and penetration tester can uncover serious, and otherwise elusive, security problems.

This paradigm shift approach was particularly successful in exposing a flaw in the Internet architecture design of a health care company. Their design incorporated a web server, which would authenticate users and present various pages and forms, and a number of internal, back-end components. The web server, which existed within a firewall architecture, was to make requests of back-end database systems and present the results to the Internet user. From within a design paradigm, this model makes sense. The web server performs authentication and authorization based on its user database, and then requests information as required from the internal systems. The Internet user is prevented from directly querying the internal systems.

From within a penetration testing paradigm, however, certain issues become immediately apparent. First of all, the fact that the web server also contains authentication information is a serious design problem, considering the growing body of tools and techniques currently being used by hackers to attack various types of web servers. While the designer believes she has constructed a secure system, the penetration tester knows that the web servers are a young and volatile class of application, and that if a weakness does not exist today in that specific web server, it is likely one will soon be identified. Once the web server has been compromised, the tester can send arbitrary requests to the internal systems, and confidential data can be compromised. This penetration testing paradigm revealed the necessity of a truly firewalled Internet architecture, with a proxy stage between the web server and internal systems.

The allowed path issue

A penetration testing approach can also expose vulnerabilities in the allowed paths that a system or architecture offers. While a security administrator is busy monitoring firewalls for inappropriate traffic, an attack on an architecture's allowed paths can continue unnoticed, and often with a high level of compromise. When faced with an architecture for testing, a researcher will attempt to learn about the services offered by that architecture. In the case of Internet connected systems, this process usually begins with a TCP/IP port and address scan.

If this does not immediately provide any vulnerabilities for further exploit, attention will shift to the allowed paths. For example, when a tester discovers that she is prevented from making a telnet connection to hosts behind a firewall, she will quickly realize that there is probably no trivial way to make such a connection if there is no known vulnerability in the firewall itself. At this point, the tester will focus on the allowed paths behind the firewall, which might include TCP/IP port 80 (HTTP), port 21 (FTP), or port 25 (SMTP) on one or more addresses, to test the internal systems for weaknesses. If she then finds that some web server running behind the firewall has a CGI script that is known to be vulnerable to buffer overrun attacks, she will be able to utilize the legal, allowed path to that server in order to effect a compromise.

A recent penetration test conducted for a technology company, which depends on its web site to supply secure access to sensitive company, client, and project information, provides an excellent example of the benefits of this type of testing. In probes of a UNIX based web server, no system level vulnerabilities were immediately obvious. Since the target information was known to be available via the allowed HTTP path, the testing quickly focused on the web server's authentication and authorization systems. How did the web server know which user was allowed to see what data, and how could the server be sure of a user's identity?

As a result of these investigations, the testers were able to exploit several problems with the web server's content in order to compromise all of the sensitive target data, without ever achieving root access to the system. First, the testers took advantage of inconsistent HTTP access controls in order to gather information about legitimate user names. They then used this information to manipulate the behavior of the CGI scripts that actually retrieved documents for display, obtaining access to the sensitive data.

Conclusions

This example of problems with allowed paths reinforces the importance of independent penetration testing. The domains of responsibility associated with most Internet projects actually hamper IS professionals' ability to secure Internet applications. As illustrated above, a traditional focus on the components of the architecture resulted in a minimum of vulnerabilities, and presumably a high level of security. However, what would be traditionally considered the data contained on those components, in this case web content, actually contributed to the compromise of those systems. Since the IS security professional frequently has control over operating system, application, and network configuration, but not content, the security of the architecture must be confirmed through other means.

Some IS managers see penetration testing as an unconventional approach to security, but in fact the technique is analogous to the types of testing used in other areas. In software testing, individuals who were not involved with the coding of an application try to find conditions where a program will fail or behave unexpectedly. Similarly, penetration testers look for situations where the security of a system could be defeated or circumvented. This technique is critical for confirming the validity of security designs and implementations in the context of available hacker techniques and tools. Furthermore, penetration testing can provide several unique approaches to evaluating and testing designs, providing for more robust and elegant security solutions.

Updated Spring, 2002 by webloke © Stephen Cobb
Some article content reprinted by permission.
Article content copyright named author(s).