Methodology | Penetration/Vulnerability Test

The team should thoroughly investigate target systems and networks in a structured manner, documenting their findings as they proceed. The goal is to attempt to identify all thesignificant vulnerabilities on the network—including their location and implications—and provide recommendations for securing the affected systems. Testing results in a comprehensive, operational review or “snapshot” of the state of the network. Testing should include an analysis of the external network from the perspective of an outside hacker, and/or a review of the internal network from the perspective of a disgruntled employee or contractor.

Discovery

The discovery process takes advantage of publicly available information that relates to your organization. Internet search engines, Whois databases, network registrars, DNS servers, and company Web sites are all sources of information. This phase can yield data that your organization might wish to protect. Table 1 lists a number of recommended tools used during the discovery phase. All of these are either native UNIX tools or are freeware, with the exception of WSPingPro.

Table 1: Common Security Testing Tools 

Discovery	Scanning	Vulnerability Assessment
Whois	Hping	tcpdump
SamSpade	Nmap	Voipong
WSPingPro	LDAPMiner	Wepcrack
SuperScan	scanrand	Getlf
dig	NetStumbler	Nessus
nslookup	Kismet	Retina
ping	Nikto	Brute
traceroute	PSTools	WinFingerprint
TCPTraceroute	WSPingPro	Lophtcrack5
	SQLPing 2	ISS Internet Scanner
	ToneLoc	SnagIT
	Dsniff	@stake Proxy
	SuperScan	Ethereal
		Ettercap
		Amap
		John the Ripper
		Netcat

Scanning

Scanning or fingerprinting utilizes a variety of automated, non-intrusive scans. Nmap is a recommended tool for this step. Foundstone’s SuperScan is another useful tool at this stage. Results of these scans should be constantly monitored in order to minimize bandwidth issues and to ensure that the scanning process does not result in loss of network connectivity for any networked devices. If any device fails under this type of scanning, that is a finding in itself.

It may be useful to emulate specific IP phones when testing VoIP gateways. For testing H.323 gateways or gatekeepers, the OpenH323 project offers OpenPhone, which has a GUI for Windows clients and command-line options for Linux distributions.

For testing SIP proxies, registrars, and gateways, many sites (such as sipXphone and YATE) have open-source SIP clients that are quite configurable. SJ Labs’ SJphone softphone (www.softjoys.com) is also useful for testing in a VoIP environment, and is free for 30 days. SIPsak and SIPbomber are also useful SIP proxy testing tools. Callflow (http://callflow.sourceforge.net/) can be very useful for examining and understanding the alterations in calling message sequences that can result when performing SIP testing.

As an indication of the maturity of this field, SiVuS (www.vopsecurity.org) has been released. SiVuS is the first publicly available vulnerability scanner for VoIP networks that use the SIP protocol.

Vulnerability Assessment

Vulnerability assessment, one of the most important phases of penetration testing, occurs when your team maps the profile of the environment to publicly known or, in some cases, unknown vulnerabilities. Tools such as Nessus, Retina, and ISS Internet Scanner are all good choices at this stage. An excellent listing of the top 75 security tools can be found at www.insecure.org/tools.html.

When you are vulnerability testing VoIP networks, it is not necessary to test every IP phone. Because of the oftentimes, sheer number of IP phones, vulnerability testing has the potential to generate enough network traffic that voice quality is negatively affected. Testing one particular IP phone per vendor is often adequate since configurations should be functionally identical.

In most VoIP environments, it is possible to identify IP phones by their SNMP signature. Calling the IP phone directly—thus, bypassing any gateways or gatekeepers—can sometimes yield interesting information.

Exploitation

The exploitation phase begins once the target system’s vulnerabilities are mapped. The testers will attempt to gain privileged access to a target system by exploiting the identified vulnerabilities. This may take the form of running an exploit tool such as scalp.c or iis5hack.c, or launching a password guessing attack using THC-Hydra, a network authentication cracker. (An excellent resource of known/default accounts and associated passwords is located at www.phenoelit.de/dpl/dpl.html.)

Reporting

Throughout the testing, the team should maintain a detailed journal of activities to account for effects and results of the testing procedures. This record will serve to distinguish the test team’s activities from any other anomalies that occur during the course of the penetration test. Some techniques for capturing these data include the use of echo and logging. When appropriate, the use of screen captures may be an option.

• Detailed results of the testing performed
• What the results indicate
• Recommendations on types of corrective actions

One internal measure that can be used to quantify a particular vulnerability is a “Threat Index.” This index is based upon two independent metrics: perceived risk (Table 2) and an estimated frequency (Table 3). The subsequent two-part identifier is formed by combining these two results, and is placed in the 3X3 matrix. The Threat Index (TI) has several purposes: First, it is used to rapidly prioritize a discovered vulnerability. Severe or high TIs (see Table 4) require immediate attention, and may also require more in-depth analysis by testers. Second, the TI can be used to rapidly code particular vulnerabilities. For example, if a newly discovered vulnerability is ranked with a TI of H1, all members of the team immediately understand that this is a severe problem that requires immediate action, while a TI of L3 indicates an insignificant issue.

Table 2: Risk Categories 

High Risk (H)	Loss of critical proprietary information, system disruption, or severe environmental damage
Medium Risk (M)	Loss of proprietary information, severe occupational illness, or major system or environmental damage
Low Risk (L)	Minor system or environmental damage

Table 3: Modified Department of Defense Frequency Categories 

Frequent (1)	Likely repeated occurrences
Occasional (2)	Possibility of repeated occurrences
Improbable (3)	Practically impossible

Table 4: Threat Index 

	High Risk (H) Med	ium Ri sk (M) Low	Ris k (L)
Frequent (1)	H1	M1	L1
Occasional (2)	H2	M2	L2
Improbable (3)	H3	M3	L3

Your organization can apply these criteria in any way you see fit. The point is to determine as objectively as possible a method to prioritize threats against your infrastructure. You may even use different rankings based upon different portions of the network infrastructure—for example, when testing data services, threats to data integrity may be important, compared to voice services, where threats that negatively impact availability may be critical.

In Table 4, any vulnerability with a threat index of H1, H2, M1, M2, and L1 requires immediate attention.