Ping is a utility that was written for the IP protocol in 1983. Ping was designed to send a packet to an IP address to determine if it is active. If so, the utility measures the round-trip time of the packet that was sent and received. Because a ping serves much the same purpose as the sonar ships use, it was named after the characteristic "ping" noise that is made when sonar identifies an object in water. The ping command is typically executed against a single IP address; a "ping sweep" is the act of running the utility across a range of IP addresses.

Ping sweeps, sometimes called "host discovery," are often the first step in a security assessment or attack because they can save time and effort by narrowing the number of IP addresses to assess/attack. Many other security testing tools are more intricate and exhaustive in the tests they run on each targeted IP address or system. To avoid wasting time trying to test or exploit an inactive IP address, ping sweeps are a valuable technique. The ping command is simple—it sends a packet to an IP address and waits a short time for a response. Scanning even an entire class C subnet, involving up to 254 hosts, can usually be done in less than 10 seconds depending on network speed.

Because the ping command was designed to communicate with a single IP address, it is necessary to use utilities specifically designed to ping sweep multiple IP addresses. Many freeware ping sweep utilities exist for nearly all major operating systems; here are some examples:

The utilities tend to offer easy-to-use, intuitive interfaces, such as the SuperScan interface shown in Figure 12-1.

Ping sweep capabilities are now included with many vulnerability scan and security assessment tools. Performing ping sweeps from within these utilities eliminates the need to re-enter active IP addresses into the vulnerability programs.

The exact output received from a ping sweep utility depends on the version of the utility used. However, at a minimum, the output will include the IP address and an indication as to whether the IP address is considered "live." Most of the above-mentioned utilities allow you to print the output, or you can save it and then use Microsoft Word or Microsoft Excel to remove all non-responsive IP addresses.

Figure 12-1. The SuperScan ping sweep utility.

Nmap, or Network Mapper, was developed in the late 1990s as a Linux port scanning tool to identify which IP ports, or services, were active on an IP address. Opinions are mixed as to whether the original intent of Nmap was to help systems administrators or hackers gain information about systems and networks. The result is that Nmap is one of the oldest and most widely used tools by security professionals and hackers alike. The tool identifies and assesses services and vulnerabilities on computer systems.

Nmap's core functionality consists of three features: ping sweeping, port scanning, and operating system (OS) detection. One of the most powerful and controversial features of Nmap, however, is its Nmap Scripting Engine. This scripting engine allows users to customize such things as how aggressively Nmap performs its scans and which IP port and services it probes. There are over 100 scripts included with the Nmap utility, and users familiar with the Lua programming language can create their own.

To use Nmap as a command-line utility, which is common for the UNIX and Linux versions, a user needs a strong fundamental knowledge of both Nmap's options as well as UNIX or Linux commands. For the more novice user, the Windows version of Nmap, known as Zenmap, has a graphical interface and is much easier to configure and execute. Although there are hundreds of scanning and probing options available in the utility, this section focuses on Nmap's abilities to discover and enumerate hosts. Additional Nmap capabilities will be discussed later in this chapter.

The "standard" Nmap scan performs non-intrusive activities—those unlikely to impact the server or appear to security systems as an attack, such as:

Although Nmap was originally written for Linux, the Zenmap Windows version of Nmap is easy to use and has some advantages. For those who do not use Nmap frequently enough to memorize all the command-line options, Zenmap allows users to click on desired scanning options. However, it also has a field that displays the command line that corresponds to the options that have been selected, as shown in Figure 12-2. The command-line feature makes Zenmap useful for learning Nmap.

Another important part of finding Web site vulnerabilities is identifying the operating system running on the hardware systems that support the Web server, application, and database components. This activity is known as "OS fingerprinting." Operating systems are designed differently and have unique vulnerabilities. Identifying the underlying operating system of a Web site can help determine which tools will be needed to further assess the server, the skills required for manual assessment techniques, and even the types of attacks that should be anticipated. As with ping sweeps and basic discovery, numerous tools provide OS fingerprinting. Many of those tools perform other security assessment functions in addition to OS fingerprinting, such as ping sweeping, port scanning, and vulnerability testing. Two of the most popular OS fingerprinting tools are Nmap and Nessus.

Figure 12-2. The Zenmap interface.

Nmap returns the OS fingerprint as part of a "regular scan" profile selected in Zenmap, or it can be specifically requested by executing the following command:

nmap -O ip address

The result will be a line in the output that resembles the following:

OS details: Linux 2.6.19 - 2.6.31

Like Nmap, Nessus began as a free, open-source application. Because it was created in the late 1990s, around the same time that network security was gaining in importance, it quickly became one of the most popular vulnerability scanning tools for security professionals.

Although there are a few feature overlaps between Nessus and Nmap, they are largely considered complementary tools. Where Nmap's strengths lie in its ability to probe and identify systems and their services, Nessus is equally proficient at testing those systems and services for vulnerabilities. Nessus is now a commercial product for use in corporate environments, but it still is offered free to home users scanning personally owned systems.

Nessus is primarily comprised of two components: a scanning engine and thousands of "plug-ins" that associate vulnerabilities with items such as services, operating systems, applications, and so on. To scan a system, a user first creates a policy, which means choosing a set of options and plug-ins to use during the scan.

Figure 12-3. Summary page from a Nessus vulnerability scan.

After creating a policy, the user initiates the scan by entering information about the host system to be scanned and then choosing the policy against which to assess that host or hosts. Figure 12-3 shows the summary screen of a normal Nessus vulnerability scan.

Nessus also has the ability to perform both authenticated and unauthenticated scans; unauthenticated is the default. The difference between the two methods of scanning can be very important depending on how accurate the results need to be. Unauthenticated scanning means Nessus does not have permission to log onto the target system while scanning it. Nessus determines which vulnerabilities to report largely by first identifying the applications present or IP ports open and then searching the plug-ins to see which vulnerabilities are associated with those applications/ports. In some cases, this leaves room for error because Nessus cannot confirm the exact configuration of the application or port and whether it already addresses its vulnerabilities. By configuring Nessus with the appropriate logon credentials, it can attempt to validate some of its findings by running additional tests that are only possible while being logged on.

Because the server operating system is like the foundation of a house, supporting all the other components, it is important to identify and assess the OS version and its running services accurately. At minimum, an assessment of the Web server OS should involve:

An unauthenticated scan is usually acceptable for OS assessment, but if privileged credentials are available, it is recommended that both an unauthenticated and an authenticated scan be performed.

A typical enumeration and assessment of the Web server OS might be as follows:

Arguably, the most valuable information gained from a Web server OS scan is whether the operating system is missing any critical security patches or running any insecure services. Patches are typically easy to address by applying patches that are missing and recommended by the scan program. Insecure services can be more difficult to remedy if they are truly insecure by design but are needed for business purposes. An example is Telnet services that allow users to remotely connect or logon to the Web server. Often, this is reserved for administrators who need Telnet services to manage the Web server's operating system. However, Telnet is insecure in that it does not require authentication and transmits data in plaintext. This includes transmitting logon IDs and passwords in plaintext even when Telnet is configured with authentication enabled. Some common remediations include limiting Telnet capabilities to certain workstations or implementing a more secure equivalent, Secure Shell (SSH).

Additional items to look for when scanning the Web server OS include:

Assessing Web server applications can be a complex task because applications are unique and offer a variety of services. A Web server application can be anything from a grouping of scripts to a fully custom-coded program. In many cases, assessing Web server applications consists of scanning the application for known vulnerabilities as well as performing more specific testing of the code itself.

Vulnerability scanning and security assessment of Web server applications are much like assessments of the Web server OS and front end. Depending on the type of Web application on the server, tools like Nessus or Metasploit may be useful in finding and testing vulnerabilities in the application. However, for traditional custom-coded applications, it is recommended that the code be reviewed by a commercial source code assessment tool such as WebInspect or IBM Rational Appscan. These source code tools examine various programming languages and find poorly designed or insecure coding techniques that could present risks, such as:

Much like the assessment of the Web server OS, it is recommended that, both an authenticated and unauthenticated test of the Web server application be performed. This will identify potential risks that might be exploited by either an outside attacker or an authorized user. The following steps are typical of a basic Web application security assessment:

Assessing Web site front-end software, the program that serves HTTP pages to users, is very similar to assessing OS software. Like an OS, Web site software typically consists of a core program combined with add-on services to support specific capabilities. In many cases, the vulnerability scan of the Web server OS will identify Web site front-end software and its vulnerabilities as part of its overall enumeration. However, depending on the scan tools used, there are typically some Web site-specific options that can help the scan application perform a more thorough assessment of Web site front-end vulnerabilities.

Because the Web site front-end software often integrates or supports the Web server application, many of the tools used to assess the application also can be used to assess the front end. Often, the Web site application consists of Web pages or forms that are designed in Java or PHP. Web site front-end software is often the platform for more popular but sometimes more exploitable technologies such as Flash, Shockwave, and others. These technologies are often targeted by exploits because they are used so heavily in Web sites and applications.

Some common activities performed when assessing Web site front-end software are:

Web site forms allow Web site users to input data either into the Web site front end or the Web site application. Although data input forms and fields are useful, they present a significant security risk to a Web site if not implemented properly. When a user enters data into a Web site field or form, there are usually scripts and programs that process that data. Depending on how well the Web site front end or applications have been configured, or are designed, they may have problems if a user enters bad or improperly formatted text.

There are a few ways that input can be incorrectly entered, causing Web site problems. The most common involves entering a very large number of characters into a field that might expect only a few. For example, an attacker tries to enter 100 characters into a phone number field. A properly configured, or well-written, Web site application would either require the correct number of characters before processing the data or check for incorrect data and not process it.

Another form of improperly formatted data involves entering special commands into fields. This is often known as code injection or cross-site scripting (XSS). Cross-site scripting has long been one of the most widely exploited vulnerabilities. It is popular because it takes advantage of two common features of Web sites: JavaScript and data input fields/forms. The term stems from the nature of the technique: An attacker accesses a Web site and provides data in the site's fields that cause issues with how JavaScript interprets the data and/or executes it. This produces results ranging from wrong characters or data being displayed to compromising the security of Web browser sessions that interact with the Web site.

Most vulnerability scanners, commercial or free, can perform at least a basic scan for cross-site scripting and code injection vulnerabilities. Because there are so many types of cross-site scripting and code injection vulnerabilities, it is recommended that multiple scan programs be run against a Web site.

One of the most common uses for Web sites is e-commerce. Web sites that store, transmit, or process credit card numbers must comply with security standards that have been set by the payment brands—Visa, MasterCard, American Express, Discover, and JCB. These standards are known as the Payment Card Industry Data Security Standards (PCI DSS). Although this chapter won't cover PCI DSS in detail, it is worth noting the sections within PCI DSS that apply to Web site security testing. Failure to comply with PCI DSS can lead to a Web site's losing the right to process credit card transactions as well as to fines for the Web site's owner by the payment brands.

PCI DSS consists of twelve major security requirement sections, each with numerous specific controls. The 12 major requirement sections are:

For Web sites that handle credit cards, all 12 requirements will apply. The requirements most related to this section are:

The attack plan for Web front-end systems often centers on the application's user interface and how a Web site visitor, legitimate or not, could gain unauthorized access to data through the Web server or application. If system availability is an important issue or if the Web server is part of a larger group of systems, then the tester might also incorporate attacks such as denial of service (DoS) and/or deeper reconnaissance attacks. To keep the planned attack efficient and focused, it is important to establish the exact strategies that will be attempted as well as possible outcomes. A basic planned attack on a Web site front end might include:

Earlier scans with vulnerability programs should have produced information on the OS version, type of Web software running, patch levels, and perhaps even configuration settings. Those pieces of information provide insight into possible security gaps.

Another technique to identify Web front-end security gaps is to review the HTML source code for hidden fields. A Web developer might want to calculate or store data on a Web page that the application needs but users shouldn't see. For example, an online sales order form might use hidden fields that contain price and quantity information about products being purchased. Upon checkout, the Web site might use those hidden fields to calculate the final order total and number of items purchased. If the Web site and application are not properly secured, an attacker could discover the hidden fields, manipulate the values, and place a fraudulent order with lower prices.

Privilege escalation involves exploiting a vulnerability or flaw in a system to gain access to resources not otherwise available to the attacker or tester. Privilege escalation applies not only to gaining a higher role in the system, known as "vertical privilege escalation," but also to gaining access to files or data that normally are restricted to peer users. The latter scenario, known as "horizontal privilege escalation," may be much easier for an attacker to accomplish than vertical privilege escalation yet provide a comparable benefit.

One scenario used to test for horizontally escalated privilege levels involves visiting Web server pages where documents, files, or other pieces of information are requested, perhaps a secure area where user-specific documents are stored. A sign of potential vulnerability can be a URL that looks like:

http://www.acme.com/showmydocuments.asp?DocID=13

A valid test would be simply to change the "13" in the URL to other numbers and see if documents are accessible that normally shouldn't be—perhaps documents belonging to other users. This test actually uses two pen testing techniques—URL manipulation and directory traversal.

Another, perhaps more popular, form of attempted privilege escalation is buffer overflow attempts. By sending improperly formed information to the Web site or application, it is sometimes possible to overflow the computer's memory and cause the application to crash. Most buffer overflow attacks result in the Web application and system simply shutting down or rebooting. However, with improperly secured Web systems, it is sometimes possible that the server will close the Web application but keep the applications logon session, and rights, active. This has led to occasions where the Web system, upon closing the application, returned to a command prompt that had full administrative rights still active. This meant that if attackers could crash the application simply by flooding the computer's memory, their level of privilege could be escalated once they were at the console prompt.

Developing an attack plan for a back-end system or database is very similar to developing one for a Web front-end system. Many attack methods can be performed through the same Web application or forms.

The most likely difference in planning an attack on a database is that additional discovery tools need to be used to identify the database type. Most scanning tools identify database types based on open ports or services running on the system. However, if the database type cannot be determined by scan tools, then another method that sometimes works is field manipulation and forcing error messages. Inputting a wrong value in a field the database processes may cause an error. The resulting error message displayed on the screen may give information about the database.

Once the database type is identified, the general plan of attack on a database might attempt to:

Probing database applications for gaps and holes is a common feature of the penetration testing software on the market. Metasploit, a freeware tool, is adept at exploit testing, as its name implies. Metasploit has modules, or preconfigured test scripts, for numerous database types and their vulnerabilities, but it isn't as user-friendly as some other tools mentioned in this chapter. Even the Windows version runs as a command-line utility.

Many of the Web application scanners also have scripts and tests for back-end databases. Acunetix is one of those programs and will attempt to connect to the database as well as run Structured Query Language (SQL) commands.

Attempting to escalate privileges for back-end databases is very similar to the strategy used for Web server applications. Once again, Metasploit is a good utility for attempting various strategies for escalating privileges. One item to be cautious about, however, is that many of the scripts and techniques used to gain escalated privilege level involve strategies to crash either the application or the database itself. If the database is crashed, then accessing data may be considerably more difficult, even if privileged access is gained.

Most scanning and pen test utilities now have built-in SQL injection testing capabilities. However, SQL injection is a fairly simple activity that an attacker can attempt manually by manipulating URLs in a browser.

SQL injection is the act of inserting various SQL commands into a URL, or sometimes into a form field, so that the command will be run against the back-end database. The steps below contain a basic SQL injection attempt:

An executive summary is typically designed to do what its name says—provide executives, or other levels of management, the ability to understand the assessment's major points. Usually the first section or chapter of an assessment report, an executive summary should be relatively short and focus on the findings of most interest. This typically includes "critical" or "high" vulnerabilities and security gaps as well as any that might affect the system's compliance status—such as being PCI compliant/certified.

A good executive summary will include information that is specific and clear so it can be quickly consumed and understood. It should also include points management needs to know to make business decisions about risk, budgeting, resource planning, and so on. It is perfectly acceptable for an executive summary to include detailed information, or even advanced topics and terms, as long as it reads quickly and gets its points across clearly. Many executive summaries are no longer than a single page and contain graphs and charts to consolidate information and help focus the reader's attention.

Some points an executive summary should cover include:

Remember to keep the executive summary fairly high level. Avoid mentioning potentially sensitive information such as IP addresses, version numbers, and names of programs used that could be used by another party to compromise systems and applications. This keeps the executive summary clean of technical details and usable as a standalone document to show customers or other outside parties that an assessment was performed.

The summary of findings section should go a step farther than the executive summary and outline most or all the findings rather than just the most critical findings that are included in the executive summary. Many scan tools can generate summary graphs or tables straight from the collected data. The summary of findings is a good place to use graphs to show analysis or trends, such as:

The summary of findings can also include text descriptions or observations about the percentages/quantities that are shown. For instance, if the vulnerability scans were performed only in a non-authenticated manner and did not log onto the systems being assessed, the assessor might want to mention that fact. The assessor might also want to explain briefly how that might generate false positives, or "suspected but not necessarily confirmed," vulnerabilities that could make the results look worse than they really are.

The vulnerability assessment section of the report is typically one of the easiest to generate, but it also contains the largest amount of data. Many vulnerability scanning tools are adept at generating detailed reports. The better tools can even export that data in various formats so that it can be easily imported and manipulated into a manual assessment report or presentation. Depending on the purpose for the vulnerability scan and report, it may be required to use the report provided by the scan tool, so that the findings cannot be manipulated or deleted. When selecting a vulnerability scan application, be sure to take into consideration its ability to report or export data in a convenient format.

The type, or complexity, of vulnerability scan usually determines the amount of data or findings that will be generated. It's not unusual for a single system or IP address to generate 50 to 100 findings. Considering that most vulnerability scan tools devote up to a half-page description for each vulnerability found, this can create a long report. Each write-up for a vulnerability finding typically includes the following information:

If the native report from the vulnerability scanning utility proves to be too long, try exporting the data into a format that allows for the fields to be manipulated, such as Excel. This will work, however, only in situations that don't require a certified, or non-modifiable, report. In the case of PCI, where it is required that authorized third parties perform the scans, the reports must be generated and delivered in PDF format so that the results cannot be altered.

The security assessment, or penetration test, section of the report is likely to be the least structured due to the subjective nature of security assessment testing and tools. Depending on the approach used, there are a few ways that security assessment information can be reported.

One effective way of organizing security assessment information is to group the findings by system or component and then sub-group the findings within each system by the type of attack performed or the functionality that was being tested. The following is an outline of a method for reporting security or penetration test results:

The recommendations section, also referred to as the remediation section, of the report is arguably the most important section. Because vulnerability remediation will likely have been mentioned as part of the data from vulnerability scan tools, this section is primarily a summary of fixes. There may be a large number of findings to fix and complexity involved from one fix to another. Therefore, you should consider categorizing the recommendations by short term and long term.

Although there are very few bad tools for performing security assessments and vulnerability scans, some are certainly better than others. Rarely will one tool find every vulnerability or security hole. Don't be afraid to evaluate different tools and use multiple tools, even for the same function, when performing security assessments. That certainly results in more effort and data to review, but the end goal isn't necessarily speed and convenience when testing application security. In most cases, attackers use a wide variety of tools—often the same tool run from different operating systems. Not only does that give the attackers a better chance of compromising a system or application, but it also helps them learn the various operating systems and application languages. A thorough assessor will follow the same practice. Some additional items to remember when selecting tools:

As mentioned earlier in this chapter, there often are differences in the results of non-authenticated scans and tests versus authenticated ones. It can be difficult or even impossible to get the credentials needed to perform authenticated tests—so many times authenticated testing is simply passed over. However, authenticated scans need to be performed in order to accurately evaluate an application's true security risks. If authenticated testing of production systems is simply too controversial or risky, then perform authenticated scans on a test system—which can help justify getting a test system in place if one isn't already present.

Attackers are as familiar with security testing tools as security professionals are—probably more so. Although the standard tools and techniques are still necessary, be on the lookout for new techniques. Using Google advanced search techniques is one way of performing non-standard testing. Be on the lookout for new crawlers and other utilities or services that are designed to help advertise or improve search results for Web content. Many of these engines will find ways, albeit usually well-intentioned, to get to data within the Web server or Web application quicker than some attackers or security tools can.

There are plenty of Web sites available that monitor attack trends, offer unique testing tools, and even support forums that attract assessors and attackers alike. It's not enough to simply run tools or perform a few manual techniques and consider an application tested. The tools and techniques are a start—but knowing things like the technology behind the attacks, how attacks are evolving, which industries the attacks are happening in, and so on will prove invaluable in truly securing an application or Web site. Perform a Web search for the server's name occasionally to see if any attackers or online tools are targeting the system or application.