7
Security Assessments

---

CERTIFICATION OBJECTIVES

7.01 Tool Types

Port Scanners

Vulnerability Scanners

Protocol Analyzer

Switch Port Analyzer

Network Enumerator

Password Cracker

Fuzzer

HTTP Interceptor

Attacking Tools/Frameworks

7.02 Methods

Vulnerability Assessment

Penetration Testing

Black Box

White Box

Gray Box

Fingerprinting

Code Rreview

Social Engineering

Two-Minute Drill

Q&A Self Test

---

Spend enough time in the security career field and at some point you will either conduct an assessment, create an RFP (Request for Proposal) for assessments, respond to an assessment RFP, or examine the results of an assessment. Assessments play a very big role in security—they can be one of the best tools you have to find issues and vulnerabilities before the “bad guys” do. On a more frequent basis, as a security professional you might be presented with a scenario and need to choose the appropriate approach or tool for the job. In this chapter, we’ll explore some common tools and methods for conducting assessments and other security tasks.

CERTIFICATION OBJECTIVE 7.01
Tool Types

Tools are a vital part of any security professional’s skillset. You may not be an “assessment professional” who spends most of his or her career examining networks looking for vulnerabilities, but you can use many of the same tools for internal assessment activities, tracking down infected systems, spotting inappropriate behavior, and so on. Knowing the right tool for the job can be critical to performing effectively.

Port Scanners

A port scanner is a tool designed to probe a system or systems for open ports. Its job is to probe for open (or listening) ports and report back to the user which ports are closed, which are filtered, and which are open. Port scanners are available for virtually every operating system and almost every popular mobile computing platform—from tablets to smartphones. Having a good port-scanning tool in your toolset and knowing how to use it can be very beneficial. The good news/bad news about port scanners is the “bad guys” use them for basically the same reasons the good guys use them. Port scanners can be used to do the following:

Search for “live” hosts on a network. Most port scanners give you the ability to perform a quick scan using ICMP, TCP, or UDP packets to search for active hosts on a given network or network segment. ICMP is still very popular for this task, but with the default blocking of ICMP in many modern operating systems, such as Windows 7, users are increasingly turning to TCP or UDP scans for these tasks.

Search for any open ports on the network. Port scanners are most often used to identify any open ports on a host, group of hosts, or network. By scanning a large number of ports over a large number of hosts, a port scanner can provide you (or an attacker) with a very good picture of what services are running on which hosts on your network. Scans be done for the “default” set of popular ports, a large range of ports, or every possible port (from 1 to 65535).

Search for specific ports. Only looking for web servers? Mail servers? Port scanners can also be configured to just look for specific services.

Identify services on ports. Some port scanners can help identify the services running on open ports based on information returned by the service or the port/service assigned (if standards have been followed). For example, a service running on port 80 is likely to be a web server.

Look for TCP/UDP services. Most port scanners can perform scans for both TCP and UDP services, although some tools do not allow you to scan for both protocols at the same time.

As a security professional, you’ll use port scanners in much the same way an attacker would. Probe the systems in your network for open services. When you find open services, you’ll need to determine if those services should be running at all, if they should be running on the system(s) you found them on, and if anything can be done to limit what connections are allowed to those services. For example, you may want to scan your network for any system accepting connections on TCP port 1433 (Microsoft SQL Server). If you find a system accepting connections on TCP port 1433 in your Sales group, chances are someone has installed something they shouldn’t have (or someone installed something for them).

So how does a port scanner actually work? Much will depend on the options you select when configuring your scan, but for the sake of this example, let’s assume we’re running a standard TCP connect scan against 192.168.1.20 for ports 1–10000. The scanner will attempt to create a TCP connection to each port in the range 1–10000 on 192.168.1.20. When the scanner sends out that SYN packet, it waits for the responding SYN/ACK. If a SYN/ACK is received, the scanner will attempt to complete the three-way handshake and mark the port as “open.” If the sent packet times out or a RST packet is received, the scanner will likely mark that port as “closed.” If an “administratively prohibited” message or something similar comes back, the scanner may mark that port as “filtered.” When the scan is complete, the scanner will present the results in a summary format—listing the ports that are open, closed, filtered, and so on. By examining the responses from each port, you can typically deduce a bit more information about the system(s) you are scanning, as detailed here:

Open Open ports accept connections. If you can connect to these with a port scanner, the ports are not being filtered at the network level. However, there are instances where you may find a port that is marked as “open” by a port scanner that will immediately drop your connections if you attempt to connect to it in some other manner. For example, port 22 for SSH may appear “open” to a port scanner but will immediately drop your SSH connections. In such a case, the service is likely being filtered by a host-based firewall or a firewall capability within the service itself.

Closed You will typically see this response when the scanned target returns an RST packet.

Filtered You will typically see this response when an ICMP unreachable error is returned. This usually indicates that port is being filtered by a firewall or other device.

Additional types Some port scanners will attempt to further classify responses, such as dropped, blocked, denied, timeout, and so on. These are fairly tool specific and you should refer to any documentation or help file that accompanies that port scanner for additional information.

In general, you will want to run your scanning efforts multiple times using different options to ensure you get a better picture. A SYN scan may return different results than a NULL scan or FIN scan. You’ll want to run both TCP and UDP scans as well. You may need to alter your scanning approach to use multiple techniques at different times of the day/night to ensure complete coverage. The bad guys are doing this against your network right now, so you might as well use the same tools they do to see what they see. Port scanners can also be very useful for testing firewall configurations because the results of the port scans can show you exactly which ports are open, which ones you allow through, which ports are carrying services, and so on.

So how do you defend against port scans? Well, it’s tough. Port scans are pretty much a part of the Internet traffic landscape now. Although you can block IP addresses that scan you, most organizations don’t because you run the risk of an attacker spoofing source addresses as decoys for other scanning activity. The best defense is to carefully control what traffic you let in and out of your network, using firewalls, network filters, and host filters. Then carefully monitor any traffic that you do allow in.

Unfortunately, there is far more information concerning port scanners, port-scanning techniques, defenses, and so on, than we have room for in this chapter. This is merely a small introduction to the topic, and we highly recommend you do additional research if the topic interests you.

The key to effective use of port scanners is to run them multiple times at different times and on different days. Your network looks different in the early hours of the morning than it does later in the afternoon. Run port scans on weekends, at night, during lunch, on holidays, and so on. Most scanners have a machine output option that makes it easy to import results into a database for easy comparison between scans.

Figure 7-1 shows a screen shot of Zenmap, a cross-platform version of the very popular Nmap port scanner available from insecure.org.

FIGURE 7-1 Zenmap—a port scanner based on nmap

Bottom line: When you need to map out your network or look for open services on one or more hosts, a port scanner is probably the most efficient tool for the job.

Vulnerability Scanners

A vulnerability scanner is a program designed to probe hosts for weaknesses, misconfigurations, old versions of software, and so on. There are essentially three main categories of vulnerability scanners: network, host, and application.

A network vulnerability scanner probes a host or hosts for issues across their network connections. Typically a network scanner will either contain or use a port scanner to perform an initial assessment of the network to determine which hosts are alive and which services are open on those hosts. Each system and service is then probed. Network scanners are very broad tools that can run potentially thousands of checks, depending on the OS and services being examined. This makes them a very good “broad sweep” for network visible vulnerabilities. Due to the number of checks they can perform, network scanners can generate a great deal of traffic and a large number of connections to the systems being examined, so care should be taken to minimize the impact on production systems and production networks. Network scanners are essentially the equivalent of a Swiss army knife for assessments. They do lots of tasks and are extremely useful to have around—they may not be as good as a tool dedicated to examining one specific type of service, but if you can only run a single tool to examine your network for vulnerabilities, you’ll want that tool to be a network vulnerability scanner. In Figure 7-2 we see a screenshot of Nessus from Tenable Network Security, a very popular network vulnerability scanner.

FIGURE 7-2 Nessus—a network vulnerability scanner

Bottom line: If you need to perform a broad sweep for vulnerabilities on one or more hosts across the network, a network vulnerability scanner is the right tool for the job.

Host vulnerability scanners are designed to run on a specific host and look for vulnerabilities and misconfigurations on that host. Host scanners tend to be more specialized because they’re looking for issues associated with a specific operating system or set of operating systems. A good example of a host scanner is the Microsoft Baseline Security Analyzer (MBSA), shown in Figure 7-3. MBSA is designed to examine the security state of a Windows host and offer guidance to address any vulnerabilities, misconfigurations, or missing patches. Although MBSA can be run against remote systems across the network, it is typically run on the host being examined and requires you to have access to that local host (at the Administrator level). The primary thing to remember about host scanners is that they are typically looking for vulnerabilities on the system they are running on.

FIGURE 7-3 Microsoft Baseline Security Analyzer

Bottom line: If you want to scan a specific host for vulnerabilities, weak password policies, or unchanged passwords, and you have direct access to the host, a host vulnerability scanner might be just the tool to use.

It’s worth noting that some tools (such as Nessus) really cross the line between network and host-based scanners. If you supply Nessus with host/login/domain credentials, it can perform many checks that would be considered “host based.”

Application vulnerability scanners are designed to look for vulnerabilities in applications or certain types of applications. Application scanners are some of the most specialized scanners—even though they contain hundreds or even thousands of checks, they only look for misconfigurations or vulnerabilities in a specific type of application. Arguably the most popular type of application scanners are designed to test for weaknesses and vulnerabilities in web-based applications. Web applications are designed to be visible, interact with users, and accept and process user input—all things that make them attractive targets for attackers. As such, a relatively large number of web application scanners is available, ranging from open source to subscription fee basis. To be an effective web application scanner, the tool must be able to perform thousands of checks for vulnerabilities, misconfigurations, default content, settings, issues, and so on, with a variety of web technologies from IIS to Apache to PHP to ASP and everything else in between. Application scanners are usually capable of performing advanced checks, such as SQL injection or JavaScript injection, that require interacting with the web application being examined and modifying requests and responses based on feedback from the application. Figure 7-4 shows a screenshot of Acunetix WVS (Web Vulnerability Scanner), an application scanner specifically for web technologies.

FIGURE 7-4 Acunetix WVS

Bottom line: If you want to examine a specific application or multiple instances of the same type of application (such as a website), an application scanner is the tool of choice.

Database vulnerability scanners are another type of specialty scanner—as the name suggests they are designed to look for vulnerabilities and misconfigurations with databases. Software version, user permissions, poor passwords, accounts with no passwords, table permissions, database permissions, and so on, can all be closely examined by a database scanner such as Scuba or AppDetective.

If your organization does any application development, you may also wish to integrate the use of a source code scanner such as Fortify 360 SCA. A source code scanner actually looks through the source code of a program to identify potential vulnerabilities, such as input fields that are not filtered, improper or lack of bounds checking, possible buffer overflows, and so on. These tools are fairly specialized because you must have the actual source code of the application to test—a source code scanner does you no good on a finished, compiled product.

Protocol Analyzer

A protocol analyzer is simply a tool (either hardware of software) that can be used to capture and analyze traffic passing over a communications channel, such as a network. Although protocol analyzers exist for many types of communication channels, such as telecommunications traffic and system buses, the most common use of a protocol analyzer is for the capture and examination of network traffic. In the networking world, this is most commonly referred to as a packet analyzer or sniffer. Sniffers can be used to capture and analyze wired or wireless traffic and can be software based (most common) or a dedicated hardware/software platform. An effective sniffer must have the ability to place a network interface in promiscuous mode, which tells the interface to accept and process every packet it sees—not just packets destined for this specific system or sent to a broadcast, multicast, or unicast address. On a switched network, sniffers are typically plugged into SPAN or monitor ports that are configured to receive copies of packets passing through one or more interfaces on the same switch. Capabilities of packet analyzers vary greatly—some do nothing more than simple packet capture whereas others attempt to reconstruct entire TCP/IP sessions with decoded packets and color-coded traffic streams.

From a security perspective, protocol analyzers are very useful and effective tools. Want to see if any system on your network is transmitting traffic on a specific port? Want to see if any packets are being sent to an address at a rival company? Want to see which employees spend all day surfing eBay? Want to find the system that’s flooding the local network with broadcast traffic? A protocol analyzer can help you address all these issues and more—if you have the analyzer plugged into the right location of your network and can “see” the traffic you are concerned about. Most organizations will have multiple points in the network where traffic can be sniffed—in the core switch, between the user base and the server farm, between remote users and the core network, between the organization and any link to the Internet, and so on. Knowing how to ensure the sniffer can “see” the traffic you want to analyze, knowing where to place the analyzer, and knowing how to use the analyzer are all keys to getting the best results from a protocol analyzer.

Switch Port Analyzer

The term switch port analyzer (SPAN) is usually associated with Cisco switches—other vendors refer to the same capability as port mirroring or port monitoring. A SPAN is essentially the ability to copy network traffic passing through one or more ports on a switch or one or more VLANs on a switch and forward that copied traffic to a port designated for traffic capture and analysis (as shown in Figure 7-5). A SPAN port or mirror port creates the collection point for traffic that will be fed into a protocol analyzer or IDS/IPS. SPAN or mirror ports can usually be configured to monitor traffic passing into interfaces, out of interfaces, or passing in both directions. When configuring port mirroring, you need to be aware of the capabilities of the switch you are working with. Can it handle the volume of traffic? Can it successfully mirror all the traffic, or will it end up dropping packets to the SPAN if traffic volume gets too high?

FIGURE 7-5 A SPAN port collects traffic from other ports on a switch

Network Enumerator

A network enumerator is a tool that scans your network and collects information on the users, groups, shares, and services visible on your network. On insecure systems, this type of information can be pulled from anonymous queries to LDAP services, anonymous connections to Windows systems, Active Directory searches, scans to determine what service is actually running on a given port, and so on. This type of information is very useful to would-be attackers, and your job as a security professional is to prevent attackers from accessing this type of information. An easy way to start that process is to run network enumeration tools yourself to see what your network might look like to an untrusted outsider or trusted insider. Using network enumeration tools can show you how much information is available on your network and highlight which systems need to be secured, what services need to be disabled/restricted, and so on. Most general vulnerability scanners, such as Nessus, will perform network enumeration as part of their “default” scan settings, and port scanners, such as nmap, will attempt to identify the operating system and application running on examined systems.

Password Cracker

Want to test the strength of user passwords on a given system and have access to the password file or hashes? Then use a password cracker—a specialized tool designed to “guess” passwords. If you have a password file and know how it was created (what operating system it came from, how the passwords are stored, and so on), then you simply feed that password file into the appropriate password cracker, set the options, and let it run. Password crackers essentially “guess” passwords by taking a hash the cracker has created and comparing it against the hash in the password file to see if they match. Password crackers typically can operate in four common modes:

Dictionary file The cracker uses a dictionary file—a list of words that can range from the very broad (the entire Oxford dictionary) to the very specific (NFL teams). The password cracker takes each word in the file, computes a hash for that word, and then compares the calculated hash to the value stored in the password file.

Hybrid mode The cracker uses a dictionary file but then performs common substitutions on the words such as replacing the letter o with a zero. Some crackers also do permutations of dictionary words and letters or special characters to the end of each dictionary word (for example, password123).

Brute force You tell the cracker the max length of the password and the set of characters you’d like it to use, and the cracker tries every possible combination of characters (a, aa, aaa, aaaa, b, bb, bbb, and so on). Brute-force attacks can take a very long time to execute.

Rainbow tables Rainbow tables are pre-computed hashes. Essentially these are huge files with possible passwords and their corresponding hashes. Rainbow tables can potentially save an enormous amount of time because the password cracker is now simply attempting to match the hash of the password being cracked and a value it pulls from the rainbow table—the cracker doesn’t have to compute the hash anymore because it has already been done and is stored in the rainbow table.

Password crackers have benefited more than any other assessment tool by the increase in readily available computing power. Multicore processers are now able to crack passwords in a fraction of the time it took three or four years ago. The advent of cloud computing has added a whole new level of speed to the practice of cracking passwords. Most cloud services allow you to rent massive amounts of computing power by the hour. Now any attacker can run massively parallel password-cracking operations at speeds that were previously only available to government entities.

As a security professional, you might use password crackers to test the strength of user passwords or test compliance with company policy. You will likely not want to run an exhaustive password-cracking effort where you attempt to crack every single password in a massive brute-force attack. A cracking effort that uses a dictionary attack or hybrid attack up to 14 characters will likely be sufficient to reveal any weak passwords that might comply with company policy, just enough to be allowed but still weak enough that they might be guessed by an attacker and should be changed. There are several good password crackers, such as John the Ripper, that can be used for password-auditing efforts (see Figure 7-6).

FIGURE 7-6 John the Ripper, a popular password cracking utility

Password cracking can be performed against pretty much anything that contains a stored password—such as a configuration file or database. A side note worth examining is the use of brute-force tools. In traditional password-cracking efforts, you have the encrypted or hashed passwords and are trying to determine what they are by calculating your own hashes and making comparisons to what’s stored in the file. In brute-force efforts, you’re also try to match the password, but it’s typically done through a login mechanism and without the computation of any hashes. Many brute-force tools, such as THC Hydra, can perform multithreaded, brute-force attacks against a variety of protocols, such as SSH, FTP, HTTP, HTTPS, SMB, and so on. Other tools such as Cain and Abel can capture password hashes as they are transmitted across the wire (or through the air) and then perform cracking efforts.

Fuzzer

Have you ever looked at a web page and thought, “Wonder what happens if I enter a bunch of random characters for my password?” If you’ve actually tried this, then you’ve “fuzzed.” A fuzzer is a testing tool used to find implementation bugs in software by submitting malformed or semi-malformed data to an application in an automated fashion. For example, if you have a web application with a login field, a fuzzer would send random (or semi-random) strings of data at the username and password field and examine the application’s reaction to that data. Did the application crash? Did it report an error back? What kind of error? Was it a buffer overflow? A denial-of-service condition?

From a security standpoint, fuzzers are typically used to examine web applications, custom applications, or any other system that accepts and processes user input. Fuzzers can be run at any time, but ideally fuzzers would be used during application development where the cost of detecting and correcting bugs is typically cheaper. A fuzzer can’t replace a good quality-control process, code walkthrough, debugging, and so on, but it can be a very powerful automated tool that augments these classic software assurance techniques. The primary issue with fuzzing is it tends to find only the more simple faults within software, although sometimes those bugs turn out to be serious, exploitable bugs. Fuzzers are available from both open source and commercial sources.

HTTP Interceptor

An HTTP interceptor is, quite simply, a tool that captures web traffic between the source (usually a browser) and the destination (usually a website). HTTP interceptors are usually called web proxy tools because they serve as an on-host proxy, capturing web traffic after it passes out of and before it passes into the browser. Most interceptors run on the local host using a local port (such as 8080) and require the user to configure their browser or connection settings to point to the interceptor as the proxy for HTTP/HTTPS traffic. Most interceptors will also handle certificate and SSL negotiations for any sessions passing through them.

Interceptors are great tools for examining web applications because they allow the examiner to do things the browser would not. Let’s say the client-side code for a website limits the length of a client-supplied username to 20 characters. The browser would help enforce that limit and would reject any username longer than 20 characters. When the user clicks Submit on their browser, the request passes to the interceptor first and now the user has a chance to modify the submitted data free from any restrictions the browser might try to enforce. Using the interceptor, the examiner could manually modify the submitted username and make it 200 characters in length—or even 2,000—before passing it off to the web server. If the developers haven’t done a good job of filtering user input on both the client and server side of their application, then an unexpected input of 2,000 characters in a 20-character field could cause a problem. Interceptors can also be used to modify URLs, change cookie values, modify data fields, and so on, with any web traffic passing through the proxy. Interceptors give you a tool to examine almost every aspect of how a web application processes traffic passing between the browser and web server. Figure 7-7 shows a screenshot of Burp Suite, a popular HTTP interceptor.

FIGURE 7-7 BurpSuite, a popular HTTP interceptor

Attacking Tools/Frameworks

Attack tools/frameworks typically go one step beyond a vulnerability scanner. Whereas a vulnerability scanner can tell you about a possible issue or where a definite issue exists, an attack tool will allow you to try and exploit that discovered vulnerability. For example, a vulnerability scanner might tell you that your remote system is vulnerable to a certain buffer overflow attack, but an attack tool/framework will actually launch an attack against the vulnerable target and attempt to exploit the buffer overflow (possibly giving you a remote shell on the vulnerable system). Attack tools and assessment frameworks typically have some type of limited vulnerability-scanning capability—usually to just verify vulnerabilities that the attack tool can exploit.

From a security standpoint, attack tools and frameworks are sometimes avoided—because they actually use buffer overflows and such to exploit vulnerabilities, they can have unintended consequences, such as crashing the service being examined or corrupting data. However, they can still be useful for taking the data in a vulnerability scan from a discussion about what an attacker might be able to do into a discussion about what an attacker definitely could do and would have access to. Sometimes showing the access that can be gained by exploiting a vulnerability is far more powerful than simply talking about it. Many different attack tools are available from both public and commercial sources, such as Metasploit (available in both open source and commercial versions) and Core Impact (commercial only).

One common issue associated with attack tools is the level of knowledge required to use them effectively. Anyone can download and run the tools, but you definitely need more than a rudimentary level of knowledge to be able to first identify a vulnerability and then select an appropriate exploit to test/validate that vulnerability. Selecting the wrong exploit or payload could result in crashing the service (or system) being examined, could corrupt data, or have a similarly undesirable impact. Some attack tools (including Core Impact and Metasploit) make this process much easier because they pair vulnerability tests with appropriate exploits and payloads that can usually be executed with minimal damage.

Attack tools/frameworks are also available now in live CD format and in pre-built distributions. For example, BackTrack Linux is a bootable live CD that contains a large variety of packaged assessment, scanning, and exploit tools. The live CD format allows you to boot from the CD into a functional assessment environment using almost any available platform.

CERTIFICATION OBJECTIVE 7.02
Methods

The point of a security assessment is to ensure the proper safeguards and security controls are in place. Assessments ensure systems are patched, applications are not vulnerable, and networks are locked down. Many different approaches and methods fall under that very broad umbrella of “security assessments”—some methods are best at addressing broad concerns and some are very specific in nature. In this section, we’ll examine some of the various assessment methods you can use (or hire other to use) to help secure your network and applications.

Vulnerability Assessment

A vulnerability assessment is designed to answer the following questions: Do we have issues? How many? How bad are they? A well-performed vulnerability assessment should identify and evaluate the vulnerabilities in the system, network, application, or process being examined. Although many people think “network” or “application” when the term vulnerability assessment is mentioned, in reality vulnerability assessments can and are performed on anything from public water supplies, to transportation systems, to production processes.

A vulnerability analysis typically consists of the following steps:

Defining and classifying the network, system(s), or processes What will be examined, what value does it have, and what capabilities does it have?

Valuation How important is this system as compared to that system? How important is something to the organization? And so on.

Threat identification What are the potential threats, how bad are they, how serious would it be if someone were able to exploit those vulnerabilities?

Mitigation strategies How does one reduce the risk from the discovered vulnerabilities and how can the network/system/process be better protected?

A vulnerability assessment is good for evaluating the security posture of your network, critical systems, and so on. Being able to identify the threats and quantify their impact can help determine what mitigation/protection strategies to pursue. Vulnerability assessments can help determine where to spend security budgets, where to devote manpower, and can even be used to help obtain additional resources. Often the first step in securing your network or systems is finding out how badly it is broken.

Penetration Testing

A penetration test (or pentest) simulates an attack from a malicious outsider—probing your network and systems for a way in (often any way in). Pentests are often the most aggressive form of security testing and can take on many forms, depending on what is considered “in” or “out” of scope. For example, some pentests simply seek to find a way into the network—any way in. This can range from an attack across network links to having a tester physically break into the building to social engineering and anything in between. Other pentests are limited—only attacks across network links are allowed, with no physical attacks.

Regardless of the scope and allowed methods, the goal of a penetration test is the same—to determine if an attacker can bypass your security and access your systems. Unlike a vulnerability assessment, which typically just catalogs vulnerabilities, a penetration test will attempt to exploit vulnerabilities to see how much access that vulnerability allows. Penetration tests are very useful in that they

Can show relationships between a series of “low-risk” items that can be sequentially exploited to gain access (making them a “high-risk” item in the aggregate).

Can be used to test the training of employees, the effectiveness of your security measures, and the ability of your staff to detect and respond to potential attackers.

Can often identify and test vulnerabilities that are difficult or even impossible to detect with traditional scanning tools.

Black Box

Black-box testing is a software-testing technique that basically consists of finding implementation bugs using malformed/semi-malformed data injection in an automated fashion. Black-box techniques test the functionality of the software, usually from an external or user perspective. Testers using black-box techniques typically have no knowledge of the internal workings of the software they are testing. They treat the entire software package as a “black box”—they put input in and look at the output. They have no visibility into how the data is processed inside the application, only the output that comes back to them. Tests cases for black-box testing are typically constructed around intended functionality (what the software is supposed to do) and focus on providing both valid and invalid inputs.

Black-box software testing techniques are very useful for examining any web-based application. Web-based applications are typically subjected to a barrage of valid/invalid/malformed/malicious input from the moment they are exposed to public traffic. By performing black-box testing before an application is released, developers can hopefully find and correct errors in the development or testing stages.

Black-box testing can also be applied to networks or systems. Pentests and vulnerability assessments are often performed from a purely external perspective, where the testers have no inside knowledge of the network or systems they are examining.

White Box

White-box testing is almost the polar opposite of black-box testing. Sometimes called clear-box testing, white-box techniques test the internal structures and processing within an application for bugs, vulnerabilities, and so on. A white-box tester will have detailed knowledge of the application they are examining—they’ll develop test cases designed to exercise each path, decision tree, input field, and processing routine of the application.

White-box testing is often used to test paths within an application (if X, then go do this; if Y, then go do that), data flows, decision trees, and so on. Sometimes the term white-box testing is applied to network assessments where the tester will have detailed knowledge of the network, including but not limited to IP addresses, network routes, valid user credentials, and so on. In those cases, the tester is typically referred to as a “white hat.”

Gray Box

So what happens when you mix a bit of black-box testing and a bit of white-box testing? You get gray-box testing. In a gray-box test, the testers will typically have some knowledge of the software, network, or systems they are testing. Gray-box testing can be very efficient and effective because testers can often quickly eliminate entire testing paths, test cases, and toolsets because they have some inside knowledge and can rule out things that simply won’t work and are not worth trying.

Fingerprinting

Fingerprinting is often the first step in any network attack or assessment. When fingerprinting, the attacker or tester is attempting to gather information and enumerate their target(s). Typically this is done at multiple levels, and many of the more popular fingerprinting tools combine multiple information-gathering techniques to produce a more accurate “fingerprint.” Consider nmap, which is a port-scanning tool that works for TCP and UDP services, can test for ICMP acceptance, can identify services running on discovered ports, and can even produce an educated guess as to the application and operating system being examined. Quickly producing an accurate fingerprint is very important to potential attackers—if an attacker is looking for vulnerable Linux systems, they don’t want to waste time attempting to exploit Windows or Solaris systems. If an attacker is looking for web servers running IIS 6 or later, then Apache-based web servers are not interesting at the moment.

From a security officer perspective, fingerprinting tools can be a great way to “see” what’s on your network. Scanning your own network will help you identify systems running unnecessary services, systems that do not appear on current inventories (and should not be connected to the network), and so on. Figure 7-8 illustrates HTTPrint, an older fingerprinting tool used to identify web servers.

FIGURE 7-8 HTTPrint, an old web server fingerprinting tool

Code Review

Code review is essentially proofreading of source code. Code reviews are intended to find programming errors and poor coding practices that can lead to vulnerabilities such as buffer overflows, memory leaks, unhandled exceptions, and so on. Code reviews can be done in various ways, ranging from the informal (one programmer looks over the shoulder of a fellow developer) to the extremely formal (such as a team walkthrough of an entire code base). Code reviews can be performed manually, but tools exist that provide automated code review capabilities. These automated review tools can be used to scan large codebases and identify potential issues or areas where issues may exist. Developers can then focus in on those areas without having to scan the entire codebase manually. Automated scanning followed by manual review is a widely accepted common practice that provides good coverage for far less “cost” than a manual review of the entire codebase.

The key benefit to code reviews is to find and address bugs and vulnerabilities as soon as possible—preferably before the software even enters formal testing. The earlier in the development process a bug can be caught and addressed, the cheaper is it to fix. Consider Microsoft Word—if a bug is caught in development, it is far, far cheaper to correct it there than it is to correct the bug in a released product. Addressing the bug in development may involve a few developers and a few lines of code with comments. Addressing that same bug in a released product involves code revisions, configuration management, regression testing, patch development, patch note development, and so on. As you can see, the sheer amount of effort required to address bugs post-production encourages many organizations to perform code reviews early and often during the development cycle.

Social Engineering

Social engineering is a very broad term that describes any activity that attacks the human rather than the technology. An attacker using social engineering techniques relies on their ability to convince people to circumvent or ignore existing security protocols, reveal sensitive data, grant access where none should be given, and so on. For example, someone attempting to access a particular organization’s infrastructure may call the organization’s help desk and impersonate an actual user in an attempt to get the user’s password reset to something the attacker will know.

Social engineering does not always have to involve direct contact or direct interaction. Social engineering can be performed via e-mail—ever gotten an e-mail informing you that your bank account or e-mail account has been compromised and you must log in right away and verify all your credentials? Phishing is social engineering via e-mail. The goal of phishing is to trick the user into either giving away information they shouldn’t (such as login credentials and bank account numbers), to click links, or to run software they shouldn’t. You may also have seen “scareware” ads that pop up informing you your system is infected and that you need to install and run a specific software package that will “clean up and protect” your system.

Social engineering is a technique that is typically negotiated for use in a vulnerability or penetration test. Many pentest engineers make heavy use of social engineering techniques because bypassing the human component of a security system is far easier than bypassing the technology. Imagine how many of your users would give their login and password to someone from the “help desk” or “IT” when asked. It only takes a single person to make a bad decision and allow an attacker to bypass tens of thousands of dollars in security technology.

CERTIFICATION SUMMARY

In this chapter, we discussed tools that can be used to examine your network, the traffic passing through your network, the systems, and the services provided by the systems. We discussed using port scanners to identify systems and the services they support. We talked about network-based and host-based vulnerability scanners. We detailed the uses of protocol analyzers for examining network traffic and the function of a switch port analyzer for capturing traffic passing through switches. We talked about using network enumerators to probe systems for discoverable information and using password crackers to test password strength. We discussed the use of fuzzers for testing application inputs, the use of HTTP interceptors for manipulating web traffic between the browser and the server, and the use of attack tools/frameworks for exploiting discovered vulnerabilities.

The second objective in this chapter covered the methods used to examine and secure a network. We talked about the use of vulnerability assessments to probe for and identify issues and then testing the extent of those discovered issues in penetration tests. We discussed black-box, gray-box, and white-box testing based on the level of visibility given to the tester or testing methods. Finally, we talked about the use of fingerprinting, code reviews, and social engineering (attacking the user, not the technology).

TWO-MINUTE DRILL

Tool Types

A port scanner is a tool designed to probe a system or systems for open ports.

Port scanners are available for virtually every operating system and almost every popular mobile computing platform—from tablets to smartphones.

A vulnerability scanner is a program designed to probe hosts for weaknesses, misconfigurations, old versions of software, and so on.

Network-based scanners look for vulnerabilities across network connections.

Host-based scanners look for vulnerabilities on the host being examined.

A protocol analyzer is simply a tool (either hardware of software) that can be used to capture and analyze traffic passing over a communications channel, such as a network.

An effective sniffer must have the ability to place a network interface in promiscuous mode, thus telling the interface to accept and process every packet it sees—not just packets destined for this specific system or sent to a broadcast, multicast, or unicast address.

The term switch port analyzer (SPAN) is usually associated with Cisco switches—other vendors refer to the same capability as port mirroring or port monitoring.

A SPAN is essentially the ability to copy network traffic passing through one or more ports on a switch or one or more VLANs on a switch and to forward that copied traffic to a port designated for traffic capture and analysis.

A network enumerator is a tool that scans your network and collects information on the users, groups, shares, and services visible on your network.

Using network enumeration tools can show you how much information is available on your network and can highlight which systems need to be secured, what services need to be disabled/restricted, and so on.

A password cracker essentially “guesses” passwords by taking a hash the cracker has created and comparing it against the hash in the password file to see if they match.

Password crackers can usually operate in four modes: dictionary, hybrid, brute force and rainbow tables.

A fuzzer is a testing tool used to find implementation bugs in software by submitting malformed or semi-malformed data to an application in an automated fashion.

From a security standpoint, fuzzers are typically used to examine web applications, custom applications, or any other system that accepts and processes user input.

An HTTP interceptor is, quite simply, a tool that captures web traffic between the source (usually a browser) and the destination (usually a website).

HTTP interceptors are very useful for testing web applications because they allow you to modify and manipulate web requests as they pass between the client and server.

Attack tools/frameworks are collections of tools that allow the user to scan for and exploit vulnerabilities.

Attack tools are often used in penetration tests (pentests).

Methods

A vulnerability assessment is designed to answer the following questions: Do we have issues? How many? How bad are they?

A well-performed vulnerability assessment should identify and evaluate the vulnerabilities in the system, network, application, or process being examined.

A penetration test (or pentest) simulates an attack from a malicious outsider, probing your network and systems for a way in (often any way in).

Unlike a vulnerability assessment, which typically just catalogs vulnerabilities, a penetration test will attempt to exploit vulnerabilities to see how much access that vulnerability allows.

Black-box testing is a software testing technique that consists of finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.

Testers using black-box techniques typically have no knowledge of the internal workings of the software they are testing.

A white-box tester will have detailed knowledge of the application they are examining—they’ll develop test cases designed to exercise each path, decision tree, input field, and processing routine of the application.

In a gray-box test, the tester will typically have some knowledge of the software, network, or systems they are testing.

Fingerprinting is the process of identifying a target and gathering information about that target, such as scanning for open services and then identifying what specific version of an application is providing that service.

Code reviews are intended to find programming errors and poor coding practices that can lead to vulnerabilities such as buffer overflows, memory leaks, unhandled exceptions, and so on.

Code reviews can be done in various ways, ranging from the informal (one programmer looks over the shoulder of a fellow developer) to the extremely formal (such as a team walkthrough of an entire code base).

Social engineering is a very broad term that describes any activity that attacks the human user rather than the technology.

An attacker using social engineering techniques relies on their ability to convince people to circumvent or ignore existing security protocols, reveal sensitive data, grant access where none should be given, and so on.

SELF TEST

The following questions will help you measure your understanding of the material presented in this chapter. Read all the choices carefully because there might be more than one correct answer. Choose all correct answers for each question.

1. A port scanner looks for:

A. Only closed ports

B. Only open ports

C. Only filtered ports

D. All of the above

2. Which protocols do port scanners typically scan for?

A. ICMP and SNMP

B. TCP and SNMP

C. UDP and TCP

D. UDP and RIP

3. What is the highest port number most port scanners will accept?

A. 1337

B. 65534

C. 65535

D. 65536

4. Which of the following is a network vulnerability scanner?

A. Nmap

B. Nessus

C. Tripwire

D. Iptables

5. Two of the main types of vulnerability scanners are:

A. Host-based and port scanners

B. Network-based and password crackers

C. Switch port analyzers and host-based

D. Network-based and host-based

6. Protocol analyzers:

A. Are only software based

B. Are only hardware based

C. Place network interfaces in promiscuous mode

D. Only work on switched networks

7. A protocol analyzer might be used to:

A. Examine network traffic for duplicate IP addresses

B. Find the source of an ARP spoofing attack in your network

C. Look for unauthorized computers connected to your network

D. All of the above

8. A switch port analyzer allows you to:

A. Copy traffic from one or more ports in a switch

B. Limit connections by MAC address

C. Block malware from spreading inside your network

D. Separate network traffic into VLANs

9. A network enumerator scans your network and collects:

A. Visible shares

B. User accounts

C. Visible services

D. All of the above

10. Password crackers work by:

A. Separating passwords from user IDs

B. Only checking for default passwords

C. Creating hash values and comparing them to password hashes

D. Calculating MD5 checksums of passwords

11. Password crackers benefit the most from:

A. Available memory

B. Long dictionary files

C. Solid state drives

D. A fast multicore processor

12. Fuzzers test web applications by:

A. Sending random strings of text at input fields

B. Forking multiple requests to test load-balancing capabilities

C. Testing the strength of SSL ciphers in use

D. Validating user-supplied input

13. An HTTP interceptor will allow you to modify:

A. Web requests on the server

B. Data passing from the browser to the web server only

C. Data passing from the web server to the browser only

D. Data passing between the browser and the web server in either direction

14. Which of the following is a popular attack framework?

A. Acunetix

B. Metasploit

C. Nmap

D. John the Ripper

15. Which of the following is not a typical step in a vulnerability assessment?

A. Valuation of examined systems

B. Threat identification

C. Exploiting vulnerabilities to penetrate systems

D. Developing mitigation strategies

16. A penetration test usually simulates an attack from:

A. A malicious outsider

B. Malware and worms

C. A rival organization

D. ICMP floods

17. A tester using black-box testing techniques:

A. Has detailed knowledge of function calls inside the software being tested

B. Has some knowledge of function calls inside the software being tested

C. Has no knowledge of function calls inside the software being tested

18. Fingerprinting is often:

A. One of the first steps in an assessment

B. Rarely used by professional penetration testers

C. Used in conjunction with dictionary files

D. Only performed on Linux-based systems

19. Code reviews are intended to:

A. Find programming errors and poor coding practices

B. Validate placement of punctuation

C. Catch bugs after software is released

D. Count lines of code

20. Social engineering is a technique that:

A. Targets Facebook and Twitter accounts

B. Bypasses firewalls by tunneling traffic

C. Attacks the human element and not technology

LAB QUESTION

The network management group of your organization is putting together a justification for an upgraded sniffing capability (new switches, new platform, and so on). They are asking you to provide some input to help justify the upgrade “from a security viewpoint.” Provide them with some bullet points to help explain how the sniffing capability could be used to enhance the security of your organization.

SELF TEST ANSWERS

1. D. Port scanners can be used to look for open ports, closed ports, and filtered ports.

A, B, and C on their own would not be correct.

2. C. Port scanners typically scan for TCP and UDP protocols.

A, B, and D are incorrect because port scanners do not typically look for SNMP and RIP protocols.

3. C. 65535 is the maximum port number.

A, B, and D are all incorrect.

4. B. Nessus is the only networking vulnerability scanner in that list.

A, C, and D are all incorrect. Nmap is a port scanner, Tripwire is a file integrity checker, and iptables is a firewall.

5. D. Two of the main types of vulnerability scanners are network-based and host-based.

A, B, and C are incorrect because port scanners, password crackers, and switch port analyzers are not vulnerability scanners.

6. C. Protocol analyzers place network interfaces in promiscuous mode, which allows them to capture any packet the interface sees.

A, B, and D are all incorrect. Protocol analyzers can be software or hardware based and can work on flat networks or networks based on hubs.

7. D. A protocol analyzer could be used for any of these purposes.

A, B, and C are all incorrect on their own.

8. A. A switch port analyzer allows you to copy traffic from one or more ports in a switch.

B, C, and D are all incorrect.

9. D. A network enumerator scans a network and collects visible shares, group names, user names, visible services, and so on.

A, B, and C are all incorrect on their own.

10. C. Password crackers work by creating hash values and comparing them to password hashes.

A, B, and D are all incorrect.

11. D. A fast multicore processor allows a password cracker to create hashes faster and perform more comparisons in less time.

A, B, and C all have a minimal impact on password-cracking performance when compared to a fast multicore processor.

12. A. Fuzzers test web applications by sending random strings of text at input fields and observing the results.

B, C, and D are all incorrect.

13. D. An HTTP interceptor allows you to modify data passing between the browser and the web server in both directions.

A, B, and C are all incorrect because they are incomplete with respect to the functionality of an HTTP interceptor, which is better described by (D).

14. B. Metasploit is a popular attack framework.

A, C, and D are all incorrect. Acunetix is a web vulnerability scanner, nmap is a port scanner, and John the Ripper is a password cracker.

15. C. Vulnerability assessments typically do not exploit discovered vulnerabilities.

A, B, and D are all steps typically performed in a vulnerability assessment.

16. A. A penetration test usually simulates an attack from a malicious outsider.

B, C, and D are all attacks, but they are not usually simulated by a penetration test.

17. C. Black-box testing techniques use no knowledge of the internal workings of the system or application being examined.

A and B are incorrect. A describes white-box testing and B describes gray-box testing.

18. A. Fingerprinting is often one of the first steps in an assessment.

B, C, and D are all incorrect. (B) Fingerprinting is regularly used in pentesting and (C) uses signatures, not dictionary files, and (D) is used on Windows systems as well as Linux.

19. A. Code reviews are intended to find programming errors and poor coding practices.

B, C, and D are all incorrect. (B) code reviews are functional tests, not syntax based, and (C) code reviews occur before code is released to catch errors before production, and (D) automation is used to count lines of code.

20. C. Social engineering attacks and attempts to compromise the human element.

A and B are both incorrect in that although social engineering can be used as part of these attack vectors, the answer concerning compromising the human element is more accurate and hence the better answer.

LAB ANSWER

A sniffer gives your organization visibility into the network traffic passing into and out of your organization. A sniffer can help you monitor for and identify a list of potential issues, such as infections, the presence of malware or botnets, the use of unauthorized protocols, unusual patterns in traffic, unusual sources of traffic, and unauthorized systems. Sniffers can be used to develop and evaluate firewall rules and access control lists.