IN THIS CHAPTER

Examining steps for successful vulnerability and penetration testing

Gleaning information about your organization from the Internet

Scanning your network

Looking for vulnerabilities

Before you dive headfirst into your security testing, it’s critical to have a methodology to work from. Vulnerability and penetration testing involves more than poking and prodding a system or network. Proven techniques can guide you along the hacking highway and ensure that you end up at the right destination. Using a methodology that supports your testing goals separates you from the amateurs. A methodology also helps ensure that you make the most of your time and effort.

Setting the Stage for Testing

In the past, a lot of security assessment techniques involved manual processes. Now certain vulnerability scanners automate various tasks, from testing to reporting to remediation validation (the process of determining whether a vulnerability was fixed). Some vulnerability scanners can even help you take corrective actions. These tools allow you to focus on performing the tests and less on the specific steps involved. Following a general methodology and understanding what’s going on behind the scenes will help you find the things that really matter.

Think logically — like a programmer, a radiologist, or a home inspector — to dissect and interact with all the system components to see how they work. You gather information, often in many small pieces, and assemble the pieces of the puzzle. You start at point A with several goals in mind, run your tests (repeating many steps along the way), and move closer until you discover security vulnerabilities at point B.

The process used for such testing is the same as the one that a malicious attacker would use. The primary differences lie in the goals and how you achieve them. Today’s attacks can come from any angle against any system — not just from the perimeter of your network and the Internet, as you may have been taught in the past. Test every possible entry point, including partner, vendor, and customer networks, as well as home users, wireless networks, and mobile devices. Any human being, computer system, or physical component that protects your computer systems — both inside and outside your buildings — is fair game for attack, and it needs to be tested eventually.

When you start rolling with your testing, you should keep a log of the tests you perform, the tools you use, the systems you test, and your results. This information can help you do the following:

• Track what worked in previous tests and why.
• Prove what you did.
• Correlate your testing with firewalls, intrusion prevention systems (IPSes), and other log files if trouble or questions arise.
• Document your findings.

In addition to general notes, taking screen captures of your results (using Snagit, Camtasia, or a similar tool) whenever possible is very helpful. These shots will come in handy later if you need to show proof of what occurred, and they’ll also be useful as you generate your final report. Also, depending on the tools you use, these screen captures may be your only evidence of vulnerabilities or exploits when the time comes to write your final report. Chapter 3 lists the general steps involved in creating and documenting a security testing plan.

Your main tasks are to find the vulnerabilities and to simulate the information gathering and system compromises carried out by someone with malicious intent — a partial attack on one computer, perhaps, or a comprehensive attack against the entire network. Generally, you look for weaknesses that malicious users and external attackers might exploit. Assess both external and internal systems (including processes and procedures that involve computers, networks, people, and physical infrastructures). Look for vulnerabilities. Check how all your systems interconnect and how private systems and information are (or aren’t) protected from untrusted elements.

These steps don’t include specific information on the methods that you use for social engineering and assessing physical security, but the techniques are the same. I cover social engineering and physical security in more detail in chapters 6 and 7, respectively.

If you’re performing a security assessment for a client, you may go the blind assessment route, which means that you start with just the company name and no other information. This blind assessment approach allows you to start from the ground up and gives you a better sense of the information and systems that malicious attackers can access publicly. Whether you choose to assess blindly (covertly) or overtly, keep in mind that the blind way of testing can take longer, and you may have an increased chance of missing some (or many) security vulnerabilities. Blind assessment isn’t not preferred testing method, but some people insist on it.

As a security professional, you may not have to worry about covering your tracks or evading IPSes or related security controls because everything you do is legitimate, but you may want to test systems stealthily. In this book, I discuss techniques that hackers use to conceal their actions and outline some countermeasures for concealment techniques.

Seeing What Others See

Getting an outside look can turn up a ton of information about your organization and systems that others can see, and you do so through a process often called footprinting. Here’s how to gather the information:

• Use a web browser to search for information about your organization. Search engines, such as Google and Bing, are great places to start.
• Run network scans, probe open ports, and seek out vulnerabilities to determine specific information about your systems. As an insider, you can use port scanners, network discovery tools, and vulnerability scanners (such as Nmap, SoftPerfect Network Scanner, and GFI LanGuard) to see what’s accessible and to whom.

Whether you search generally or probe more technically, limit the amount of information you gather based on what’s reasonable for you. You might spend an hour, a day, or a week gathering this information. How much time you spend depends on the size of your organization and the complexity of the information systems you’re testing.

The amount of information you can gather about an organization’s business and information systems can be staggering and is often widely available on the Internet. Your job is to find out what’s out there. From social media to search engines to dedicated intelligence-gathering tools, quite a bit of information is available on network and information vulnerabilities if you look in the right places. This information potentially allows malicious attackers and employees to access sensitive information and target specific areas of the organization, including systems, departments, and key people. I cover information gathering in detail in Chapter 5.

Scanning Systems

Active information gathering produces more details about your network and helps you see your systems from an attacker’s perspective. You can do the following things:

• Use the information provided by WHOIS searches to test other closely related IP addresses and host names. When you map and gather information about a network, you see how its systems are laid out. This information includes determining IP addresses, host names (typically external but occasionally internal), running protocols, open ports, available shares, and running services and applications.
• Scan internal hosts when they’re within the scope of your testing. (They really ought to be.) These hosts may not be visible to outsiders (you hope they’re not), but you absolutely need to test them to see what rogue (or even curious or misguided) employees, other insiders, and even malware controlled by outside parties can access. A worst-case situation is that the intruder has set up shop on the inside. Just to be safe, examine your internal systems for weaknesses.

If you’re not completely comfortable scanning your systems, consider using a lab with test systems or a system running virtual machine software, such as the following:

• VMware Workstation Pro (https://www.vmware.com/products/workstation-pro.html)
• VirtualBox, an open-source virtual-machine alternative (https://www.virtualbox.org)

Determining What’s Running on Open Ports

As a security professional, you need to gather the things that count when scanning your systems. You can often identify the following information:

• Protocols in use, such as Domain Name System and NetBIOS.
• Services running on the hosts, such as email, web, and database systems.
• Available remote access services, such as Remote Desktop Protocol, Telnet, and Secure Shell.
• Virtual private network services such as SSL/TLS and IPsec.
• Permissions and authentication requirements for network shares.

You can look for the following sample open ports (which your network-scanning program reports as accessible or open):

• Ping (ICMP echo) replies, showing that ICMP traffic is allowed to and from the host.
• TCP port 21, showing that FTP could be running.
• TCP port 23, showing that Telnet could be running.
• TCP ports 25 or 465 (SMTP and SMPTS), 110 or 995 (POP3 and POP3S), or 143 or 993 (IMAP and IMAPS), showing that an email server could be running.
• TCP/UDP port 53, showing that a DNS server could be running.
• TCP ports 80, 443, and 8080, showing that a web server or web proxy could be running.
• TCP/UDP ports 135, 137, 138, 139 and, especially, 445, showing that a Windows host could be running.

Thousands of ports can be open — 65,534 each for both TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), to be exact. I cover many popular port numbers when describing security checks throughout this book. A continually updated listing of all well-known port numbers (ports 0–1023) and registered port numbers (ports 1024–49151), with their associated protocols and services, is located at www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt. You can also perform a port-number lookup at www.cotse.com/cgi-bin/port.cgi.

If a service doesn’t respond on a TCP or UDP port, that result doesn’t mean that the service isn’t running. You may have to dig further to find out.

If you detect a web server running on the system that you test, you might be able to check the software version by using one of the following methods:

• Type the site’s name followed by a page that you know doesn’t exist, such as www.your_domain.com/1234.html. Many web servers return an error page showing detailed version information.
• Use Netcraft’s What’s That Site Running? search utility (www.netcraft.com), which connects to your server from the Internet and displays the web-server version and operating system, as shown in Figure 4-1.

You can dig deeper for more specific information on your hosts by using these tools:

• NMapWin (https://sourceforge.net/projects/nmapwin) can determine the system OS version.
• An enumeration tool (such as SoftPerfect Network Scanner at https://www.softperfect.com/products/networkscanner) can extract users, groups, and file and share permissions directly from Windows.
• Many systems return useful banner information when you connect to a service or application running on a port. If you Telnet to an email server on port 25 by entering telnet mail.your_domain.com 25 at a command prompt, you may see something like this:

  220 mail.your_domain.com ESMTP all_the_version_info_
you_need_to_hack Ready

  Most email servers return detailed information, such as the version and the current service pack installed. After you have this information, you (and the bad guys) can determine the vulnerabilities of the system from some of the websites listed in the next section.

• An email to an invalid address may return with detailed email header information. A bounced message often discloses information that can be used against you, including internal IP addresses and software versions. On certain Windows systems, you can use this information to establish unauthenticated connections and sometimes even map drives. I cover these issues in Chapter 12.

Assessing Vulnerabilities

After finding potential security holes, the next step is confirming whether they’re indeed vulnerabilities in the context of your environment. Before you test, perform some manual searching. You can research websites and vulnerability databases, such as these:

• Common Vulnerabilities and Exposures (http://cve.mitre.org/cve)
• US-CERT Vulnerability Notes Database (www.kb.cert.org/vuls)
• NIST National Vulnerability Database (https://nvd.nist.gov)

These sites list known vulnerabilities — at least, the formally classified ones. As I explain in this book, many other vulnerabilities are more generic in nature and can’t easily be classified. If you can’t find a vulnerability documented on one of these sites, search the vendor’s site. You can also find a list of commonly exploited vulnerabilities at https://www.sans.org/critical-security-controls. This site contains the SANS Critical Security Controls consensus list, which is compiled and updated by the SANS organization.

If you don’t want to research your potential vulnerabilities and can jump right into testing, you have a couple of options:

• Manual assessment: You can assess the potential vulnerabilities by connecting to the ports that are exposing the service or application and poking around in these ports. You should manually assess certain systems (such as web applications). The vulnerability reports in the preceding databases often disclose how to do this, at least generally. If you have a lot of free time, performing these tests manually may work for you.
• Automated assessment: Manual assessments are great ways to learn, but people usually don’t have time to complete most manual steps. If you’re like me, you’ll scan for vulnerabilities automatically when you can and dig around manually as needed.

Many great vulnerability assessment scanners test for flaws on specific platforms (such as Windows and Linux) and types of networks (wired or wireless). They test for specific system vulnerabilities and may focus on standards such as the SANS Critical Security Controls and the Open Web Application Security Project (https://www.owasp.org). Some scanners map the business logic within a web application; others map a view of the network; others help software developers test for code flaws. The drawback to these tools is that they find only individual vulnerabilities; they don’t necessarily aggregate and correlate vulnerabilities across an entire network. This task is where your skills and the methodologies I share in this book come into play.

One of my favorite security tools is a vulnerability scanner called Nexpose by Rapid7 (https://www.rapid7.com/products/nexpose). It’s both a port scanner and vulnerability assessment tool, and it offers a great deal of help for vulnerability management. You can run one-time scans immediately or schedule scans to run on a periodic basis.

As with most good security tools, you pay for Nexpose. It isn’t the least expensive tool, but you definitely get what you pay for, especially when it comes to others taking you seriously (such as when PCI DSS compliance is required of your business). A free version, dubbed the Community Edition, is available for scanning smaller networks with fewer features. Additional vulnerability scanners that work well include QualysGuard (https://www.qualys.com) and GFI LanGuard (https://www.gfi.com/products-and-solutions/network-security-solutions).

Assessing vulnerabilities with a tool such as Nexpose requires follow-up expertise. You can’t rely on the scanner results alone. You must validate the vulnerabilities that the tool reports. Study the reports to base your recommendations on the context and criticality of the tested systems. You’ll find that higher-end vulnerability scanners provide proof and related information to help you in your validation efforts.

Penetrating the System

You can use identified security vulnerabilities to do the following:

• Gain further information about the host and its data.
• Obtain a remote command prompt.
• Start or stop certain services or applications.
• Access other systems.
• Disable logging or other security controls.
• Capture screen shots.
• Access sensitive files.
• Send an email as the administrator.
• Perform SQL injection.
• Launch a denial of service attack.
• Upload a file or create a backdoor user account proving the exploitation of a vulnerability.

Metasploit (https://www.metasploit.com) is great for exploiting many of the vulnerabilities you find and allows you to fully penetrate many types of systems. Ideally, you’ve already made your decision about whether to fully exploit the vulnerabilities you find. You may want to leave well enough alone by demonstrating the existence of the vulnerabilities, not exploiting them.

If you want to delve further into best practices for vulnerability and penetration testing methodologies, I recommend that you check out the Open Source Security Testing Methodology Manual (www.isecom.org/research/osstmm.html). The Penetration Testing Execution Standard (www.pentest-standard.org/index.php) and PCI DSS Penetration Testing Guidance (https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf) are good resources as well.