I N T E L L I G E N C E G A T H E R I N G
Intelligence gathering follows the pre-engagement
activities as the second step in a penetration test. Your
goals during intelligence gathering should be to gain
accurate information about your targets without revealing
your presence or your intentions, to learn how the
organization operates, and to determine the best route
of entry. If you don’t do a thorough job of intelligence gathering, you may
miss vulnerable systems or viable attack vectors. It takes time and patience to
sort through web pages, perform Google hacking, and map systems thoroughly
in an attempt to understand the infrastructure of a particular target.
Intelligence gathering requires careful planning, research, and, most importantly,
the ability to think like an attacker. At this step, you will attempt to collect
as much information about the target environment as possible. This can
be an expansive amount of information, and even the most trivial data gathered
during this stage can prove useful later on, so pay attention.
Before you begin intelligence gathering, consider how you will record
everything you do and the results you achieve. You must remember and record
16 Chapter 3
as many details of your penetration test as possible. Most security professionals
quickly learn that detailed notes can mean the difference between a successful
and a failed penetration test. Just as a scientist needs to achieve reproducible
results, other experienced penetration testers should be able to reproduce
your work using your documentation alone.
Intelligence gathering is arguably the most important aspect of a penetration
test, because it provides the foundation for all work that follows. When
recording your work, be methodical, accurate, and precise. And, as stated
earlier, be sure that before you fire off your exploits, you have learned all
that you can about your target.
The excitement for most people comes in exploiting systems and getting
to root, but you need to learn to walk before you can run.
WARNING If you follow the procedures in this chapter, you can actually damage your system and
your target’s system, so be sure to set up your test environment now. (For help, see
Appendix A.) Many of the examples in these chapters can be destructive and make a
target system unusable. The activities discussed in this chapter could be considered
illegal if they are undertaken by someone with bad intentions, so follow the rules and
don’t be stupid.
Passive Information Gathering
By using passive and indirect information gathering, you can discover information
about targets without touching their systems. For example, you can use
these techniques to identify network boundaries, identify the network maintainers,
and even learn what operating system and web server software is in
use on the target network.
Open source intelligence (OSINT) is a form of intelligence collection that
uses open or readily available information to find, select, and acquire information
about a target. Several tools make passive information gathering
almost painless, including complex tools such as Yeti and the humble whois.
In this section, we’ll explore the process of passive information gathering
and the tools that you might use for this step.
Imagine, for example, an attack against http://www.secmaniac.net/. Our
goal is to determine, as a part of a penetration test, what systems the company
owns and what systems we can attack. Some systems may not be owned
by the company and could be considered out of scope and unavailable for
attack.
whois Lookups
Let’s begin by using Back|Track’s whois lookup to find the names of
secmaniac.net’s domain servers.
msf > whois secmaniac.net
[*] exec: whois secmaniac.net
. . . SNIP . . .
Intelligence Gathering 17
Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
Domain Name: SECMANIAC.NET
Created on: 03-Feb-10
Expires on: 03-Feb-12
Last Updated on: 03-Feb-10
Domain servers in listed order:
NS57.DOMAINCONTROL.COM
NS58.DOMAINCONTROL.COM
We learn at that the Domain Name System (DNS) servers are hosted
by DOMAINCONTROL.COM, so this is a good example of systems that would
not be included in a penetration test because we would have no authority to
attack them. In most large organizations, the DNS servers are housed within
the company and are viable attack vectors. Zone transfers and similar DNS
attacks can often be used to learn more about a network from both the inside
and outside. In this scenario, because DOMAINCONTROL.COM is not owned
by secmaniac.net, we should not attack these systems and will instead move on
to a different attack vector.
Netcraft
Netcraft (http://searchdns.netcraft.com/) is a web-based tool that we can use to find
the IP address of a server hosting a particular website, as shown in Figure 3-1.
Figure 3-1: Use Netcraft to find the IP address of the server hosting a particular website.
Having identified secmaniac.net’s IP address as 75.118.185.142, we do
another whois lookup on that IP address:
msf > whois 75.118.185.142
[*] exec: whois 75.118.185.142
WideOpenWest Finance LLC WIDEOPENWEST (NET-75-118-0-0-1)
75.118.0.0 - 75.118.255.255
WIDEOPENWEST OHIO WOW-CL11-1-184-118-75 (NET-75-118-184-0-1)
75.118.184.0 - 75.118.191.255
We see from the whois lookup and a quick search that this IP
(WIDEOPENWEST) appears to be a legitimate service provider. While
the actual subnet range isn’t specifically registered to secmaniac.net or
secmaniac.com, we can tell that this site appears to be hosted inside the
author’s home, because the IP block appears to be part of a residential
range.
18 Chapter 3
NSLookup
To get additional server information, we’ll use Back|Track to leverage nslookup, a
tool built into most operating systems, to find information about secmaniac.net.
root@bt:~# nslookup
set type=mx
> secmaniac.net
Server: 172.16.32.2
Address: 172.16.32.2#53
Non-authoritative answer:
secmaniac.net mail exchanger = 10 mailstore1.secureserver.net.
secmaniac.net mail exchanger = 0 smtp.secureserver.net.
We see in this listing that the mail servers are pointing to mailstore1
.secureserver.net and smtp.secureserver.net. Some quick research on these mail
servers tells us that this website is hosted by a third party, which would not
be within the scope of our penetration test.
At this point, we have gathered some valuable information that we might
be able to use against the target later on. Ultimately, however, we have to
resort to active information gathering techniques to determine the actual
target IP, which is 75.118.185.142.
NOTE Passive information gathering is an art that is not easily mastered in just a few pages
of discussion. See the Penetration Testing Execution Standard (PTES; http://
www.pentest-standard.org/) for a list of potential ways to perform additional passive
intelligence gathering.
Active Information Gathering
In active information gathering, we interact directly with a system to learn
more about it. We might, for example, conduct port scans for open ports on
the target or conduct scans to determine what services are running. Each system
or running service that we discover gives us another opportunity for exploitation.
But beware: If you get careless while active information gathering, you
might be nabbed by an IDS or intrusion prevention system (IPS)—not a
good outcome for the covert penetration tester.
Port Scanning with Nmap
Having identified the target IP range with passive information gathering as
well as the secmaniac.net target IP address, we can begin to scan for open ports
on the target by port scanning, a process whereby we meticulously connect to
ports on the remote host to identify those that are active. (Obviously, in a
larger enterprise, we would have multiple IP ranges and things to attack
instead of only one IP.)
Nmap is, by far, the most popular port scanning tool. It integrates with
Metasploit quite elegantly, storing scan output in a database backend for
Intelligence Gathering 19
later use. Nmap lets you scan hosts to identify the services running on each,
any of which might offer a way in.
For this example, let’s leave secmaniac.net behind and turn to the virtual
machine described in Appendix A, with IP address 172.16.32.131. Before we
get started, take a quick look at the basic nmap syntax by entering nmap from
the command line on your Back|Track machine.
You’ll see immediately that nmap has a quite a few options, but you’ll use
just a few of them for the most part.
One of our preferred nmap options is -sS. This runs a stealth TCP scan
that determines whether a specific TCP-based port is open. Another preferred
option is -Pn, which tells nmap not to use ping to determine whether a system
is running; instead, it considers all hosts “alive.” If you’re performing Internetbased
penetration tests, you should use this flag, because most networks
don’t allow Internet Control Message Protocol (ICMP), which is the protocol
that ping uses. If you’re performing this scan internally, you can probably
ignore this flag.
Now let’s run a quick nmap scan against our Windows XP machine using
both the -sS and -Pn flags.
root@bt:~# nmap -sS -Pn 172.16.32.131
Nmap scan report for 172.16.32.131
Host is up (0.00057s latency).
Not shown: 990 closed ports
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
1025/tcp open NFS-or-IIS
1433/tcp open ms-sql-s
3389/tcp open ms-term-serv
Nmap done: 1 IP address (1 host up) scanned in 14.34 seconds
As you can see, nmap reports a list of open ports, along with a description
of the associated service for each.
For more detail, try using the -A flag. This option will attempt advanced
service enumeration and banner grabbing, which may give you even more
details about the target system. For example, here’s what we’d see if we were
to call nmap with the -sS and -A flags, using our same target system:
root@bt:~# nmap -Pn -sS -A 172.16.32.131
Nmap scan report for 172.16.32.131
Host is up (0.0035s latency).
Not shown: 993 closed ports
PORT STATE SERVICE VERSION
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds
20 Chapter 3
777/tcp open unknown
1039/tcp open unknown
1138/tcp open msrpc Microsoft Windows RPC
1433/tcp open ms-sql-s Microsoft SQL Server 2005 9.00.1399; RTM
. . . SNIP . . .
Device type: general purpose
Running: Microsoft Windows XP|2003
OS details: Microsoft Windows XP Professional SP2 or Windows Server 2003
Network Distance: 1 hop
Service Info: OS: Windows
Host script results:
|_nbstat: NetBIOS name: V-MAC-XP, NetBIOS user: <unknown>, NetBIOS MAC:
00:0c:29:c9:38:4c (VMware)
|_smbv2-enabled: Server doesn't support SMBv2 protocol
| smb-os-discovery:
| OS: Windows XP (Windows 2000 LAN Manager)
| Name: WORKGROUP\V-MAC-XP
Working with Databases in Metasploit
When you’re running a complex penetration test with a lot of targets, keeping
track of everything can be a challenge. Luckily, Metasploit has you covered
with expansive support for multiple database systems.
To ensure that database support is available for your system, you should
first decide which database system you want to run. Metasploit supports
MySQL and PostgreSQL; because PostgreSQL is the default, we’ll stick with
it in this discussion.
First, we start the database subsystem using the built-in Back|Track init.d
scripts.
root@bt~# /etc/init.d/postgresql-8.3 start
After PostgreSQL has started, we tell the Framework to connect to the
database instance. This connection requires a username, password, name of
the host on which the database is running, and the database name we want to
use. Back|Track’s default PostgreSQL username is postgres with the password
toor, but we’ll use msfbook as the database name. Let’s make the connection.
msf > db_connect postgres:toor@127.0.0.1/msfbook
If this were the first time we connected to the database name, we would
see a lot of text output as Metasploit sets up all the necessary tables. Otherwise,
the command will return to the msfconsole prompt.
Metasploit provides a number of commands that we can use to interact
with the database, as you’ll see throughout this book. (For a complete list,
enter help.) For now, we’ll use db_status to make sure that we’re connected
correctly.
Intelligence Gathering 21
msf > db_status
[*] postgresql connected to msfbook
Everything seems to be set up just fine.
Importing Nmap Results into Metasploit
When you are working with other team members, with various individuals
scanning at different times and from different locations, it helps to know
how to run nmap on its own and then import its results into the Framework.
Next, we’ll examine how to import a basic nmap-generated XML export file
(generated with nmap’s -oX option) into the Framework.
First, we scan the Windows virtual machine using the -oX option to generate
a Subnet1.xml file:
nmap -Pn -sS -A -oX Subnet1 192.168.1.0/24
After generating the XML file, we use the db_import command to import
it into our database. We can then verify that the import worked by using the
db_hosts command, which lists the systems entries that have been created, as
shown here:
msf > db_connect postgres:toor@127.0.0.1/msf3
msf > db_import Subnet1.xml
msf > db_hosts -c address
Hosts
=====
address
-------
192.168.1.1
192.168.1.10
192.168.1.101
192.168.1.102
192.168.1.109
192.168.1.116
192.168.1.142
192.168.1.152
192.168.1.154
192.168.1.171
192.168.1.155
192.168.1.174
192.168.1.180
192.168.1.181
192.168.1.2
192.168.1.99
msf >
22 Chapter 3
This tells us that we’ve successfully imported the output of our nmap
scans into Metasploit, as evidenced by the IP addresses populated when we
run the db_hosts commands.
Advanced Nmap Scanning: TCP Idle Scan
A more advanced nmap scan method, TCP idle scan, allows us to scan a target
stealthily by spoofing the IP address of another host on the network. For this
type of scan to work, we first need to locate an idle host on the network that
uses incremental IP IDs (which are used to track packet order). When we
discover an idle system that uses incremental IP IDs, the IP IDs become predictable,
and we can then predict the next ID. However, when spoofing the
address of an idle host while scanning a target’s responses from open ports,
we can see a break in the predictability of the IP ID sequence, which indicates
that we have discovered an open port. (To learn more about this module
and IP ID sequences, visit http://www.metasploit.com/modules/auxiliary/
scanner/ip/ipidseq/.)
Use the Framework’s scanner/ip/ipidseq module to scan for a host that fits
the TCP idle scan requirements, as shown next:
msf > use auxiliary/scanner/ip/ipidseq
msf auxiliary(ipidseq) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
GWHOST no The gateway IP address
INTERFACE no The name of the interface
LHOST no The local IP address
RHOSTS yes The target address range or CIDR identifier
RPORT 80 yes The target port
SNAPLEN 65535 yes The number of bytes to capture
THREADS 1 yes The number of concurrent threads
TIMEOUT 500 yes The reply read timeout in milliseconds
This listing displays the required options for the ipidseq scan. One notable
one, RHOSTS at , can take IP ranges (such as 192.168.1.20–192.168.1.30);
Classless Inter-Domain Routing (CIDR) ranges (such as 192.168.1.0/24);
multiple ranges separated by commas (such as 192.168.1.0/24, 192.168.3.0/24);
and a text file with one host per line (such as file:/tmp/hostlist.txt). All these
options give us quite a bit of flexibility in specifying our targets.
The THREADS value at sets the number of concurrent threads to use
while scanning. By default, all scanner modules have their THREADS value initially
set to 1. We can raise this value to speed up our scans or lower it to reduce
network traffic. In general, you should not set the THREADS value greater 16
when running Metasploit on Windows, and not greater than 128 on UNIXlike
operating systems.
Intelligence Gathering 23
Now let’s set our values and run the module. We’ll set the value for RHOSTS
to 192.168.1.0/24, set THREADS to 50, and then run the scan.
msf auxiliary(ipidseq) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(ipidseq) > set THREADS 50
THREADS => 50
msf auxiliary(ipidseq) > run
[*] 192.168.1.1's IPID sequence class: All zeros
[*] 192.168.1.10's IPID sequence class: Incremental!
[*] Scanned 030 of 256 hosts (011% complete)
[*] 192.168.1.116's IPID sequence class: All zeros
[*] 192.168.1.109's IPID sequence class: Incremental!
[*] Scanned 128 of 256 hosts (050% complete)
[*] 192.168.1.154's IPID sequence class: Incremental!
[*] 192.168.1.155's IPID sequence class: Incremental!
[*] Scanned 155 of 256 hosts (060% complete)
[*] 192.168.1.180's IPID sequence class: All zeros
[*] 192.168.1.181's IPID sequence class: Incremental!
[*] 192.168.1.185's IPID sequence class: All zeros
[*] 192.168.1.184's IPID sequence class: Randomized
[*] Scanned 232 of 256 hosts (090% complete)
[*] Scanned 256 of 256 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(ipidseq) >
Judging by the results of our scan, we see a number of potential idle hosts
that we can use to perform idle scanning. We’ll try scanning a host using the
system at 192.168.1.109 shown at by using the -sI command line flag to
specify the idle host:
msf auxiliary(ipidseq) > nmap -PN -sI 192.168.1.109 192.168.1.155
[*] exec: nmap -PN -sI 192.168.1.109 192.168.1.155
Idle scan using zombie 192.168.1.109 (192.168.1.109:80); Class: Incremental
Interesting ports on 192.168.1.155:
Not shown: 996 closed|filtered ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
MAC Address: 00:0C:29:E4:59:7C (VMware)
Nmap done: 1 IP address (1 host up) scanned in 7.12 seconds
msf auxiliary(ipidseq) >
By using the idle host, we were able to discover a number of open ports
on our target system without sending a single packet to the system.
24 Chapter 3
Running Nmap from MSFconsole
Now that we’ve performed advanced enumeration on our target, let’s connect
nmap with Metasploit. To do this, we first connect to the msfbook database:
msf > db_connect postgres:toor@127.0.0.1/msf3
Now we should be able to enter the db_nmap command from within
msfconsole to run nmap and have its results automatically stored in our new
database.
NOTE We’ll be attacking only one system in this instance, but you can specify IPs by CIDR
notation and even ranges (for example, 192.168.1.1/24 or 192.168.1.1–254).
msf > db_nmap -sS -A 172.16.32.131
Warning: Traceroute does not support idle or connect scan, disabling...
Nmap scan report for 172.16.32.131
Host is up (0.00056s latency).
Not shown: 990 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
25/tcp open smtp Microsoft ESMTP 6.0.2600.2180
80/tcp open http Microsoft IIS webserver 5.1
|_html-title:
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
443/tcp open https?
445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds
1025/tcp open msrpc Microsoft Windows RPC
1433/tcp open ms-sql-s Microsoft SQL Server 2005 9.00.1399; RTM
3389/tcp open microsoft-rdp Microsoft Terminal Service
MAC Address: 00:0C:29:EA:26:7C (VMware)
Device type: general purpose
Running: Microsoft Windows XP|2003
OS details: Microsoft Windows XP Professional SP2 or Windows Server 2003
Network Distance: 1 hop
Service Info: Host: ihazsecurity; OS: Windows
Host script results:
|_nbstat: NetBIOS name: IHAZSECURITY, NetBIOS user: <unknown>, NetBIOS MAC: 00:0c:29:ea:26:7c
| smb-os-discovery:
| OS: Windows XP (Windows 2000 LAN Manager)
| Name: WORKGROUP\IHAZSECURITY
|_smbv2-enabled: Server doesn't support SMBv2 protocol
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/.
Nmap done: 1 IP address (1 host up) scanned in 33.51 seconds
Notice a series of open ports , software versions , and even a prediction
about the target’s operating system .
Intelligence Gathering 25
To check that the results from the scan are stored in the database, we
run db_services:
msf > db_services
Services
========
host port proto name state info
---- ---- ----- ---- ----- ----
172.16.32.131 135 tcp msrpc open Microsoft Windows RPC
172.16.32.131 139 tcp netbios-ssn open
172.16.32.131 445 tcp microsoft-ds open Microsoft Windows XP microsoft-ds
172.16.32.131 777 tcp unknown open
172.16.32.131 1433 tcp ms-sql-s open Microsoft SQL Server 2005 9.00.1399; RTM
We’re beginning to develop a picture of our target and exposed ports for
use as potential attack vectors.
Port Scanning with Metasploit
In addition to its ability to use third-party scanners, Metasploit has several
port scanners built into its auxiliary modules that directly integrate with most
aspects of the Framework. In later chapters, we’ll use these port scanners to
leverage compromised systems to access and attack; his process, often called
pivoting, allows us to use internally connected systems to route traffic to a network
that would otherwise be inaccessible.
For example, suppose you compromise a system behind a firewall that is
using Network Address Translation (NAT). The system behind the NAT-based
firewall uses private IP addresses, which you cannot contact directly from the
Internet. If you use Metasploit to compromise a system behind a NAT, you
might be able to use that compromised internal system to pass traffic (pivot)
to internally hosted and private IP-based systems to penetrate the network
farther behind the firewall.
To see the list of port scanning tools that the Framework offers, enter the
following:
msf > search portscan
Let’s conduct a simple scan of a single host using Metasploit’s SYN Port
Scanner. In the following listing, we start the scan with use scanner/portscan/
syn, set RHOSTS to 192.168.1.155, set THREADS to 50, and then run the scan.
msf > use scanner/portscan/syn
msf auxiliary(syn) > set RHOSTS 192.168.1.155
RHOSTS => 192.168.1.155
msf auxiliary(syn) > set THREADS 50
THREADS => 50
26 Chapter 3
msf auxiliary(syn) > run
[*] TCP OPEN 192.168.1.155:135
[*] TCP OPEN 192.168.1.155:139
[*] TCP OPEN 192.168.1.155:445
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(syn) >
From the results, you can see at that ports 135, 139, and 445 are open on
IP address 192.168.1.155, leveraging the portscan syn module within Metasploit.
Targeted Scanning
When you are conducting a penetration test, there is no shame in looking
for an easy win. A targeted scan looks for specific operating systems, services,
program versions, or configurations that are known to be exploitable and
that provide an easy door into a target network. For example, it is common
to scan a target network quickly for the vulnerability MS08-067, as this is
(still) an extremely common hole that will give you SYSTEM access much
more quickly than scanning an entire target network for vulnerabilities.
Server Message Block Scanning
Metasploit can scour a network and attempt to identify versions of Microsoft
Windows using its smb_version module.
NOTE If you are not familiar with Server Message Block (SMB, a common file-sharing protocol),
study up a bit on the different protocols and their purposes before you continue. You will
need to understand basic port information to learn how to attack a system successfully.
We run the module, list our options, set RHOSTS, and begin scanning:
msf > use scanner/smb/smb_version
msf auxiliary(smb_version) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
RHOSTS yes The target address range or CIDR identifier
THREADS 1 yes The number of concurrent threads
msf auxiliary(smb_version) > set RHOSTS 192.168.1.155
RHOSTS => 192.168.1.155
msf auxiliary(smb_version) > run
[*] 192.168.1.155 is running Windows XP Service Pack 2 (language: English)
(name:DOOKIE-FA154354) (domain:WORKGROUP)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
Intelligence Gathering 27
As you can see at the smb_version scanner has pinpointed the operating
system as Windows XP with Service Pack 2. Because we are scanning only one
system, we leave THREADS set to 1. If we had been scanning a number of systems,
such as a class C subnet range, we might consider upping the THREADS using the
set THREADS number option. The results of this scan are stored in the Metasploit
database for use at a later time and to be accessed with the db_hosts command.
msf auxiliary(smb_version) > db_hosts -c address,os_flavor
Hosts
=====
address os_flavor Svcs Vulns Workspace
------- --------- ---- ----- ---------
192.168.1.155 Windows XP 3 0 default
msf auxiliary(smb_version) >
We have discovered a system running Windows XP without having to do
a full scan of the network. This is a great way to target hosts quickly and quietly
that are likely to be more vulnerable when our goal is avoid being noticed.
Hunting for Poorly Configured Microsoft SQL Servers
Poorly configured Microsoft SQL Server (MS SQL) installations often provide
an initial way into a target network. In fact, many system administrators don’t
even realize that they have MS SQL servers installed on their workstations at
all, because the service is installed as a prerequisite for some common software,
such as Microsoft Visual Studio. These installations are often unused,
unpatched, or never even configured.
When MS SQL is installed, it listens by default either on TCP port 1433
or on a random dynamic TCP port. If MS SQL is listening on a dynamic port,
simply query UDP port 1434 to discover on what dynamic TCP port MS SQL
is listening. Of course, Metasploit has a module that can make use of this
“feature”: mssql_ping.
Because mssql_ping uses UDP, it can be quite slow to run across entire
subnets because of issues with timeouts. But on a local LAN, setting THREADS
to 255 will greatly speed up the scan. As Metasploit finds MS SQL servers, it
displays all the details it can extract from them including, perhaps most importantly,
the TCP port on which the server is listening.
Here’s how you might run an mssql_ping scan, which includes starting the
scan, listing and setting options, and the results.
msf > use scanner/mssql/mssql_ping
msf auxiliary(mssql_ping) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
PASSWORD no The password for the specified username
RHOSTS yes The target address range or CIDR identifier
28 Chapter 3
THREADS 1 yes The number of concurrent threads
USERNAME sa no The username to authenticate as
WORKSPACE no The name of the workspace to report data into
msf auxiliary(mssql_ping) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(mssql_ping) > set THREADS 255
THREADS => 255
msf auxiliary(mssql_ping) > run
[*] SQL Server information for 192.168.1.155:
[*] ServerName = V-XPSP2-BARE
[*] InstanceName = SQLEXPRESS
[*] IsClustered = No
[*] Version = 10.0.1600.22
[*] tcp = 1433
As you can see, not only does the scanner locate a MS SQL server at ,
but it also identifies the instance name at , the SQL server version at , and
the TCP port number at on which it is listening. Just think of how much
time this targeted scan for SQL servers would save over running nmap against
all ports on all machines in a target subnet in search of the elusive TCP port.
SSH Server Scanning
If during your scanning you encounter machines running Secure Shell (SSH),
you should determine which version is running on the target. SSH is a secure
protocol, but vulnerabilities in various implementations have been identified.
You never know when you might get lucky and come across an old machine
that hasn’t been updated. You can use the Framework’s ssh_version module to
determine the SSH version running on the target server.
msf > use scanner/ssh/ssh_version
msf auxiliary(ssh_version) > set THREADS 50
THREADS => 50
msf auxiliary(ssh_version) > run
[*] 192.168.1.1:22, SSH server version: SSH-2.0-dropbear_0.52
[*] Scanned 044 of 256 hosts (017% complete)
[*] 192.168.1.101:22, SSH server version: SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1
[*] Scanned 100 of 256 hosts (039% complete)
[*] 192.168.1.153:22, SSH server version: SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1
[*] 192.168.1.185:22, SSH server version: SSH-2.0-OpenSSH_4.3
This output tells us that a few different servers are running with various
patch levels. This information could prove useful if, for example, we wanted
to attack a specific version of OpenSSH as found with the ssh_version scan.
Intelligence Gathering 29
FTP Scanning
FTP is a complicated and insecure protocol. FTP servers are often the easiest
way into a target network, and you should always scan for, identify, and fingerprint
any FTP servers running on your target.
Next, we scan our XP box for FTP services using the Framework’s
ftp_version module:
msf > use scanner/ftp/ftp_version
msf auxiliary(ftp_version) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
FTPPASS mozilla@example.com no The password for the specified username
FTPUSER anonymous no The username to authenticate as
RHOSTS yes The target address range or CIDR identifier
RPORT 21 yes The target port
THREADS 1 yes The number of concurrent threads
WORKSPACE no The name of the workspace to report data into
msf auxiliary(ftp_version) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(ftp_version) > set THREADS 255
THREADS => 255
msf auxiliary(ftp_version) > run
[*] 192.168.1.155:21 FTP Banner: Minftpd ready
The scanner successfully identifies an FTP server at . Now let’s see if
this FTP server allows anonymous logins using the Framework’s scanner/ftp/
anonymous.
msf > use auxiliary/scanner/ftp/anonymous
msf auxiliary(anonymous) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(anonymous) > set THREADS 50
THREADS => 50
msf auxiliary(anonymous) > run
[*] Scanned 045 of 256 hosts (017% complete)
[*] 192.168.1.155:21 Anonymous READ/WRITE (220 Minftpd ready)
The scanner reports at that anonymous access is allowed and that
anonymous users have both read and write access to the server; in other
words, we have full access to the remote system and the ability to upload or
download any file that can be accessed by the FTP server software.
30 Chapter 3
Simple Network Management Protocol Sweeping
The Simple Network Management Protocol (SNMP) is typically used in network
devices to report information such as bandwidth utilization, collision
rates, and other information. However, some operating systems also have
SNMP servers that can provide information such as CPU utilization, free
memory, and other system-specific details.
Convenience for the system administrator can be a gold mine for the
penetration tester, and accessible SNMP servers can offer considerable information
about a specific system or even make it possible to compromise a
remote device. If, for instance, you can get the read/write SNMP community
string for a Cisco router, you can download the router’s entire configuration,
modify it, and upload it back to the router.
The Metasploit Framework includes a built-in auxiliary module called
scanner/snmp/snmp_enum that is designed specifically for SNMP sweeps. Before
you start the scan, keep in mind that the read-only (RO) and read/write (RW)
community strings will play an important role in the type of information you
will be able to extract from a given device. On Windows-based devices configured
with SNMP, you can often use the RO or RW community strings to
extract patch levels, running services, usernames, uptime, routes, and other
information that can make things much easier for you during a pen test.
(Community strings are essentially passwords used to query a device for information
or to write configuration information to the device.)
After you guess the community strings, SNMP itself (depending on the
version) can allow anything from excessive information disclosure to full system
compromise. SNMPv1 and v2 are inherently flawed protocols. SNMPv3,
which incorporates encryption and better check mechanisms, is significantly
more secure. To gain access to a switch, you’ll first need to attempt to find its
community strings. The Framework’s use scanner/snmp/snmp_login module
will try a word list against one or a range of IP addresses.
msf > use use scanner/snmp/snmp_login
msf auxiliary(snmp_login) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(snmp_login) > set THREADS 50
THREADS => 50
msf auxiliary(snmp_login) > run
[*] >> progress (192.168.1.0-192.168.1.255) 0/30208...
[*] 192.168.1.2 'public' 'GSM7224 L2 Managed Gigabit Switch'
[*] 192.168.1.2 'private' 'GSM7224 L2 Managed Gigabit Switch'
[*] Auxiliary module execution completed
msf auxiliary(snmp_login) >
A quick Google search for GSM7224 from the output tells us that the
scanner has found both the public and private community strings for a
Netgear switch. This result, believe it or not, has not been staged for this book.
These are the default factory settings for this switch.
Intelligence Gathering 31
You will encounter many jaw-dropping situations like these throughout
your pen testing career, because many administrators simply attach devices to a
network with all their defaults still in place. The situation is even scarier when
you find these devices accessible from the Internet within a large corporation.
Writing a Custom Scanner
Many applications and services lack custom modules in Metasploit. Thankfully,
the Framework has many features that can be useful when you’re building
a custom scanner, including offering access to all of its exploit classes
and methods, and support for proxies, Secure Sockets Layer (SSL), reporting,
and threading. It can be very useful to write your own scanner during
security assessments, because doing so will allow you to locate every instance
of a bad password or unpatched service quickly on a target system.
The Metasploit Framework scanner modules include various mixins, such as
exploit mixins for TCP, SMB, and so on, and the auxiliary scanner mixin that
is built into the Framework. Mixins are portions of code with predefined
functions and calls that are preconfigured for you. The Auxiliary::Scanner
mixin overloads the Auxiliary run method; calls the module method at runtime
with run_host(ip), run_range(range), or run_batch(batch); and then processes
the IP addresses. We can leverage Auxiliary::Scanner to call additional,
built-in Metasploit functionality.
Following is a Ruby script for a simple TCP scanner that will connect to a
remote host on a default port of 12345 and upon connecting, send “HELLO
SERVER,” receive the server response, and print it out along with the server’s
IP address.
#Metasploit
require 'msf/core'
class Metasploit3 < Msf::Auxiliary
include Msf::Exploit::Remote::Tcp
include Msf::Auxiliary::Scanner
def initialize
super(
'Name' => 'My custom TCP scan',
'Version' => '$Revision: 1 $',
'Description' => 'My quick scanner',
'Author' => 'Your name here',
'License' => MSF_LICENSE
)
register_options(
[
Opt::RPORT(12345)
], self.class)
end
32 Chapter 3
def run_host(ip)
connect()
sock.puts('HELLO SERVER')
data = sock.recv(1024)
print_status("Received: #{data} from #{ip}")
disconnect()
end
end
This simple scanner uses the Msf::Exploit::Remote::Tcp mixin to handle
the TCP networking, and the Msf::Auxiliary::Scanner mixin exposes the various
settings that are required for scanners within the Framework . This
scanner is configured to use the default port of 12345 , and upon connecting
to the server, it sends a message , receives the reply from the server, and
then prints it out to the screen along with the server IP address .
We have saved this custom script under modules/auxiliary/scanner/ as
simple_tcp.rb. The saved location is important in Metasploit. For example, if
the module is saved under modules/auxiliary/scanner/http/, it would show up
in the modules list as scanner/http/simple_tcp.
To test this rudimentary scanner, we set up a netcat listener on port 12345
and pipe in a text file to act as the server response.
root@bt:/# echo "Hello Metasploit" > banner.txt
root@bt:/# nc -lvnp 12345 < banner.txt
listening on [any] 12345...
Next, we load up msfconsole, select our scanner module, set its parameters,
and run it to see if it works.
msf > use auxiliary/scanner/simple_tcp
msf auxiliary(simple_tcp) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
RHOSTS yes The target address range or CIDR identifier
RPORT 12345 yes The target port
THREADS 1 yes The number of concurrent threads
msf auxiliary(simple_tcp) > set RHOSTS 192.168.1.101
RHOSTS => 192.168.1.101
msf auxiliary(simple_tcp) > run
[*] Received: Hello Metasploit from 192.168.1.101
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(simple_tcp) >
activities as the second step in a penetration test. Your
goals during intelligence gathering should be to gain
accurate information about your targets without revealing
your presence or your intentions, to learn how the
organization operates, and to determine the best route
of entry. If you don’t do a thorough job of intelligence gathering, you may
miss vulnerable systems or viable attack vectors. It takes time and patience to
sort through web pages, perform Google hacking, and map systems thoroughly
in an attempt to understand the infrastructure of a particular target.
Intelligence gathering requires careful planning, research, and, most importantly,
the ability to think like an attacker. At this step, you will attempt to collect
as much information about the target environment as possible. This can
be an expansive amount of information, and even the most trivial data gathered
during this stage can prove useful later on, so pay attention.
Before you begin intelligence gathering, consider how you will record
everything you do and the results you achieve. You must remember and record
16 Chapter 3
as many details of your penetration test as possible. Most security professionals
quickly learn that detailed notes can mean the difference between a successful
and a failed penetration test. Just as a scientist needs to achieve reproducible
results, other experienced penetration testers should be able to reproduce
your work using your documentation alone.
Intelligence gathering is arguably the most important aspect of a penetration
test, because it provides the foundation for all work that follows. When
recording your work, be methodical, accurate, and precise. And, as stated
earlier, be sure that before you fire off your exploits, you have learned all
that you can about your target.
The excitement for most people comes in exploiting systems and getting
to root, but you need to learn to walk before you can run.
WARNING If you follow the procedures in this chapter, you can actually damage your system and
your target’s system, so be sure to set up your test environment now. (For help, see
Appendix A.) Many of the examples in these chapters can be destructive and make a
target system unusable. The activities discussed in this chapter could be considered
illegal if they are undertaken by someone with bad intentions, so follow the rules and
don’t be stupid.
Passive Information Gathering
By using passive and indirect information gathering, you can discover information
about targets without touching their systems. For example, you can use
these techniques to identify network boundaries, identify the network maintainers,
and even learn what operating system and web server software is in
use on the target network.
Open source intelligence (OSINT) is a form of intelligence collection that
uses open or readily available information to find, select, and acquire information
about a target. Several tools make passive information gathering
almost painless, including complex tools such as Yeti and the humble whois.
In this section, we’ll explore the process of passive information gathering
and the tools that you might use for this step.
Imagine, for example, an attack against http://www.secmaniac.net/. Our
goal is to determine, as a part of a penetration test, what systems the company
owns and what systems we can attack. Some systems may not be owned
by the company and could be considered out of scope and unavailable for
attack.
whois Lookups
Let’s begin by using Back|Track’s whois lookup to find the names of
secmaniac.net’s domain servers.
msf > whois secmaniac.net
[*] exec: whois secmaniac.net
. . . SNIP . . .
Intelligence Gathering 17
Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
Domain Name: SECMANIAC.NET
Created on: 03-Feb-10
Expires on: 03-Feb-12
Last Updated on: 03-Feb-10
Domain servers in listed order:
NS57.DOMAINCONTROL.COM
NS58.DOMAINCONTROL.COM
We learn at that the Domain Name System (DNS) servers are hosted
by DOMAINCONTROL.COM, so this is a good example of systems that would
not be included in a penetration test because we would have no authority to
attack them. In most large organizations, the DNS servers are housed within
the company and are viable attack vectors. Zone transfers and similar DNS
attacks can often be used to learn more about a network from both the inside
and outside. In this scenario, because DOMAINCONTROL.COM is not owned
by secmaniac.net, we should not attack these systems and will instead move on
to a different attack vector.
Netcraft
Netcraft (http://searchdns.netcraft.com/) is a web-based tool that we can use to find
the IP address of a server hosting a particular website, as shown in Figure 3-1.
Figure 3-1: Use Netcraft to find the IP address of the server hosting a particular website.
Having identified secmaniac.net’s IP address as 75.118.185.142, we do
another whois lookup on that IP address:
msf > whois 75.118.185.142
[*] exec: whois 75.118.185.142
WideOpenWest Finance LLC WIDEOPENWEST (NET-75-118-0-0-1)
75.118.0.0 - 75.118.255.255
WIDEOPENWEST OHIO WOW-CL11-1-184-118-75 (NET-75-118-184-0-1)
75.118.184.0 - 75.118.191.255
We see from the whois lookup and a quick search that this IP
(WIDEOPENWEST) appears to be a legitimate service provider. While
the actual subnet range isn’t specifically registered to secmaniac.net or
secmaniac.com, we can tell that this site appears to be hosted inside the
author’s home, because the IP block appears to be part of a residential
range.
18 Chapter 3
NSLookup
To get additional server information, we’ll use Back|Track to leverage nslookup, a
tool built into most operating systems, to find information about secmaniac.net.
root@bt:~# nslookup
set type=mx
> secmaniac.net
Server: 172.16.32.2
Address: 172.16.32.2#53
Non-authoritative answer:
secmaniac.net mail exchanger = 10 mailstore1.secureserver.net.
secmaniac.net mail exchanger = 0 smtp.secureserver.net.
We see in this listing that the mail servers are pointing to mailstore1
.secureserver.net and smtp.secureserver.net. Some quick research on these mail
servers tells us that this website is hosted by a third party, which would not
be within the scope of our penetration test.
At this point, we have gathered some valuable information that we might
be able to use against the target later on. Ultimately, however, we have to
resort to active information gathering techniques to determine the actual
target IP, which is 75.118.185.142.
NOTE Passive information gathering is an art that is not easily mastered in just a few pages
of discussion. See the Penetration Testing Execution Standard (PTES; http://
www.pentest-standard.org/) for a list of potential ways to perform additional passive
intelligence gathering.
Active Information Gathering
In active information gathering, we interact directly with a system to learn
more about it. We might, for example, conduct port scans for open ports on
the target or conduct scans to determine what services are running. Each system
or running service that we discover gives us another opportunity for exploitation.
But beware: If you get careless while active information gathering, you
might be nabbed by an IDS or intrusion prevention system (IPS)—not a
good outcome for the covert penetration tester.
Port Scanning with Nmap
Having identified the target IP range with passive information gathering as
well as the secmaniac.net target IP address, we can begin to scan for open ports
on the target by port scanning, a process whereby we meticulously connect to
ports on the remote host to identify those that are active. (Obviously, in a
larger enterprise, we would have multiple IP ranges and things to attack
instead of only one IP.)
Nmap is, by far, the most popular port scanning tool. It integrates with
Metasploit quite elegantly, storing scan output in a database backend for
Intelligence Gathering 19
later use. Nmap lets you scan hosts to identify the services running on each,
any of which might offer a way in.
For this example, let’s leave secmaniac.net behind and turn to the virtual
machine described in Appendix A, with IP address 172.16.32.131. Before we
get started, take a quick look at the basic nmap syntax by entering nmap from
the command line on your Back|Track machine.
You’ll see immediately that nmap has a quite a few options, but you’ll use
just a few of them for the most part.
One of our preferred nmap options is -sS. This runs a stealth TCP scan
that determines whether a specific TCP-based port is open. Another preferred
option is -Pn, which tells nmap not to use ping to determine whether a system
is running; instead, it considers all hosts “alive.” If you’re performing Internetbased
penetration tests, you should use this flag, because most networks
don’t allow Internet Control Message Protocol (ICMP), which is the protocol
that ping uses. If you’re performing this scan internally, you can probably
ignore this flag.
Now let’s run a quick nmap scan against our Windows XP machine using
both the -sS and -Pn flags.
root@bt:~# nmap -sS -Pn 172.16.32.131
Nmap scan report for 172.16.32.131
Host is up (0.00057s latency).
Not shown: 990 closed ports
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
1025/tcp open NFS-or-IIS
1433/tcp open ms-sql-s
3389/tcp open ms-term-serv
Nmap done: 1 IP address (1 host up) scanned in 14.34 seconds
As you can see, nmap reports a list of open ports, along with a description
of the associated service for each.
For more detail, try using the -A flag. This option will attempt advanced
service enumeration and banner grabbing, which may give you even more
details about the target system. For example, here’s what we’d see if we were
to call nmap with the -sS and -A flags, using our same target system:
root@bt:~# nmap -Pn -sS -A 172.16.32.131
Nmap scan report for 172.16.32.131
Host is up (0.0035s latency).
Not shown: 993 closed ports
PORT STATE SERVICE VERSION
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds
20 Chapter 3
777/tcp open unknown
1039/tcp open unknown
1138/tcp open msrpc Microsoft Windows RPC
1433/tcp open ms-sql-s Microsoft SQL Server 2005 9.00.1399; RTM
. . . SNIP . . .
Device type: general purpose
Running: Microsoft Windows XP|2003
OS details: Microsoft Windows XP Professional SP2 or Windows Server 2003
Network Distance: 1 hop
Service Info: OS: Windows
Host script results:
|_nbstat: NetBIOS name: V-MAC-XP, NetBIOS user: <unknown>, NetBIOS MAC:
00:0c:29:c9:38:4c (VMware)
|_smbv2-enabled: Server doesn't support SMBv2 protocol
| smb-os-discovery:
| OS: Windows XP (Windows 2000 LAN Manager)
| Name: WORKGROUP\V-MAC-XP
Working with Databases in Metasploit
When you’re running a complex penetration test with a lot of targets, keeping
track of everything can be a challenge. Luckily, Metasploit has you covered
with expansive support for multiple database systems.
To ensure that database support is available for your system, you should
first decide which database system you want to run. Metasploit supports
MySQL and PostgreSQL; because PostgreSQL is the default, we’ll stick with
it in this discussion.
First, we start the database subsystem using the built-in Back|Track init.d
scripts.
root@bt~# /etc/init.d/postgresql-8.3 start
After PostgreSQL has started, we tell the Framework to connect to the
database instance. This connection requires a username, password, name of
the host on which the database is running, and the database name we want to
use. Back|Track’s default PostgreSQL username is postgres with the password
toor, but we’ll use msfbook as the database name. Let’s make the connection.
msf > db_connect postgres:toor@127.0.0.1/msfbook
If this were the first time we connected to the database name, we would
see a lot of text output as Metasploit sets up all the necessary tables. Otherwise,
the command will return to the msfconsole prompt.
Metasploit provides a number of commands that we can use to interact
with the database, as you’ll see throughout this book. (For a complete list,
enter help.) For now, we’ll use db_status to make sure that we’re connected
correctly.
Intelligence Gathering 21
msf > db_status
[*] postgresql connected to msfbook
Everything seems to be set up just fine.
Importing Nmap Results into Metasploit
When you are working with other team members, with various individuals
scanning at different times and from different locations, it helps to know
how to run nmap on its own and then import its results into the Framework.
Next, we’ll examine how to import a basic nmap-generated XML export file
(generated with nmap’s -oX option) into the Framework.
First, we scan the Windows virtual machine using the -oX option to generate
a Subnet1.xml file:
nmap -Pn -sS -A -oX Subnet1 192.168.1.0/24
After generating the XML file, we use the db_import command to import
it into our database. We can then verify that the import worked by using the
db_hosts command, which lists the systems entries that have been created, as
shown here:
msf > db_connect postgres:toor@127.0.0.1/msf3
msf > db_import Subnet1.xml
msf > db_hosts -c address
Hosts
=====
address
-------
192.168.1.1
192.168.1.10
192.168.1.101
192.168.1.102
192.168.1.109
192.168.1.116
192.168.1.142
192.168.1.152
192.168.1.154
192.168.1.171
192.168.1.155
192.168.1.174
192.168.1.180
192.168.1.181
192.168.1.2
192.168.1.99
msf >
22 Chapter 3
This tells us that we’ve successfully imported the output of our nmap
scans into Metasploit, as evidenced by the IP addresses populated when we
run the db_hosts commands.
Advanced Nmap Scanning: TCP Idle Scan
A more advanced nmap scan method, TCP idle scan, allows us to scan a target
stealthily by spoofing the IP address of another host on the network. For this
type of scan to work, we first need to locate an idle host on the network that
uses incremental IP IDs (which are used to track packet order). When we
discover an idle system that uses incremental IP IDs, the IP IDs become predictable,
and we can then predict the next ID. However, when spoofing the
address of an idle host while scanning a target’s responses from open ports,
we can see a break in the predictability of the IP ID sequence, which indicates
that we have discovered an open port. (To learn more about this module
and IP ID sequences, visit http://www.metasploit.com/modules/auxiliary/
scanner/ip/ipidseq/.)
Use the Framework’s scanner/ip/ipidseq module to scan for a host that fits
the TCP idle scan requirements, as shown next:
msf > use auxiliary/scanner/ip/ipidseq
msf auxiliary(ipidseq) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
GWHOST no The gateway IP address
INTERFACE no The name of the interface
LHOST no The local IP address
RHOSTS yes The target address range or CIDR identifier
RPORT 80 yes The target port
SNAPLEN 65535 yes The number of bytes to capture
THREADS 1 yes The number of concurrent threads
TIMEOUT 500 yes The reply read timeout in milliseconds
This listing displays the required options for the ipidseq scan. One notable
one, RHOSTS at , can take IP ranges (such as 192.168.1.20–192.168.1.30);
Classless Inter-Domain Routing (CIDR) ranges (such as 192.168.1.0/24);
multiple ranges separated by commas (such as 192.168.1.0/24, 192.168.3.0/24);
and a text file with one host per line (such as file:/tmp/hostlist.txt). All these
options give us quite a bit of flexibility in specifying our targets.
The THREADS value at sets the number of concurrent threads to use
while scanning. By default, all scanner modules have their THREADS value initially
set to 1. We can raise this value to speed up our scans or lower it to reduce
network traffic. In general, you should not set the THREADS value greater 16
when running Metasploit on Windows, and not greater than 128 on UNIXlike
operating systems.
Intelligence Gathering 23
Now let’s set our values and run the module. We’ll set the value for RHOSTS
to 192.168.1.0/24, set THREADS to 50, and then run the scan.
msf auxiliary(ipidseq) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(ipidseq) > set THREADS 50
THREADS => 50
msf auxiliary(ipidseq) > run
[*] 192.168.1.1's IPID sequence class: All zeros
[*] 192.168.1.10's IPID sequence class: Incremental!
[*] Scanned 030 of 256 hosts (011% complete)
[*] 192.168.1.116's IPID sequence class: All zeros
[*] 192.168.1.109's IPID sequence class: Incremental!
[*] Scanned 128 of 256 hosts (050% complete)
[*] 192.168.1.154's IPID sequence class: Incremental!
[*] 192.168.1.155's IPID sequence class: Incremental!
[*] Scanned 155 of 256 hosts (060% complete)
[*] 192.168.1.180's IPID sequence class: All zeros
[*] 192.168.1.181's IPID sequence class: Incremental!
[*] 192.168.1.185's IPID sequence class: All zeros
[*] 192.168.1.184's IPID sequence class: Randomized
[*] Scanned 232 of 256 hosts (090% complete)
[*] Scanned 256 of 256 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(ipidseq) >
Judging by the results of our scan, we see a number of potential idle hosts
that we can use to perform idle scanning. We’ll try scanning a host using the
system at 192.168.1.109 shown at by using the -sI command line flag to
specify the idle host:
msf auxiliary(ipidseq) > nmap -PN -sI 192.168.1.109 192.168.1.155
[*] exec: nmap -PN -sI 192.168.1.109 192.168.1.155
Idle scan using zombie 192.168.1.109 (192.168.1.109:80); Class: Incremental
Interesting ports on 192.168.1.155:
Not shown: 996 closed|filtered ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
MAC Address: 00:0C:29:E4:59:7C (VMware)
Nmap done: 1 IP address (1 host up) scanned in 7.12 seconds
msf auxiliary(ipidseq) >
By using the idle host, we were able to discover a number of open ports
on our target system without sending a single packet to the system.
24 Chapter 3
Running Nmap from MSFconsole
Now that we’ve performed advanced enumeration on our target, let’s connect
nmap with Metasploit. To do this, we first connect to the msfbook database:
msf > db_connect postgres:toor@127.0.0.1/msf3
Now we should be able to enter the db_nmap command from within
msfconsole to run nmap and have its results automatically stored in our new
database.
NOTE We’ll be attacking only one system in this instance, but you can specify IPs by CIDR
notation and even ranges (for example, 192.168.1.1/24 or 192.168.1.1–254).
msf > db_nmap -sS -A 172.16.32.131
Warning: Traceroute does not support idle or connect scan, disabling...
Nmap scan report for 172.16.32.131
Host is up (0.00056s latency).
Not shown: 990 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
25/tcp open smtp Microsoft ESMTP 6.0.2600.2180
80/tcp open http Microsoft IIS webserver 5.1
|_html-title:
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
443/tcp open https?
445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds
1025/tcp open msrpc Microsoft Windows RPC
1433/tcp open ms-sql-s Microsoft SQL Server 2005 9.00.1399; RTM
3389/tcp open microsoft-rdp Microsoft Terminal Service
MAC Address: 00:0C:29:EA:26:7C (VMware)
Device type: general purpose
Running: Microsoft Windows XP|2003
OS details: Microsoft Windows XP Professional SP2 or Windows Server 2003
Network Distance: 1 hop
Service Info: Host: ihazsecurity; OS: Windows
Host script results:
|_nbstat: NetBIOS name: IHAZSECURITY, NetBIOS user: <unknown>, NetBIOS MAC: 00:0c:29:ea:26:7c
| smb-os-discovery:
| OS: Windows XP (Windows 2000 LAN Manager)
| Name: WORKGROUP\IHAZSECURITY
|_smbv2-enabled: Server doesn't support SMBv2 protocol
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/.
Nmap done: 1 IP address (1 host up) scanned in 33.51 seconds
Notice a series of open ports , software versions , and even a prediction
about the target’s operating system .
Intelligence Gathering 25
To check that the results from the scan are stored in the database, we
run db_services:
msf > db_services
Services
========
host port proto name state info
---- ---- ----- ---- ----- ----
172.16.32.131 135 tcp msrpc open Microsoft Windows RPC
172.16.32.131 139 tcp netbios-ssn open
172.16.32.131 445 tcp microsoft-ds open Microsoft Windows XP microsoft-ds
172.16.32.131 777 tcp unknown open
172.16.32.131 1433 tcp ms-sql-s open Microsoft SQL Server 2005 9.00.1399; RTM
We’re beginning to develop a picture of our target and exposed ports for
use as potential attack vectors.
Port Scanning with Metasploit
In addition to its ability to use third-party scanners, Metasploit has several
port scanners built into its auxiliary modules that directly integrate with most
aspects of the Framework. In later chapters, we’ll use these port scanners to
leverage compromised systems to access and attack; his process, often called
pivoting, allows us to use internally connected systems to route traffic to a network
that would otherwise be inaccessible.
For example, suppose you compromise a system behind a firewall that is
using Network Address Translation (NAT). The system behind the NAT-based
firewall uses private IP addresses, which you cannot contact directly from the
Internet. If you use Metasploit to compromise a system behind a NAT, you
might be able to use that compromised internal system to pass traffic (pivot)
to internally hosted and private IP-based systems to penetrate the network
farther behind the firewall.
To see the list of port scanning tools that the Framework offers, enter the
following:
msf > search portscan
Let’s conduct a simple scan of a single host using Metasploit’s SYN Port
Scanner. In the following listing, we start the scan with use scanner/portscan/
syn, set RHOSTS to 192.168.1.155, set THREADS to 50, and then run the scan.
msf > use scanner/portscan/syn
msf auxiliary(syn) > set RHOSTS 192.168.1.155
RHOSTS => 192.168.1.155
msf auxiliary(syn) > set THREADS 50
THREADS => 50
26 Chapter 3
msf auxiliary(syn) > run
[*] TCP OPEN 192.168.1.155:135
[*] TCP OPEN 192.168.1.155:139
[*] TCP OPEN 192.168.1.155:445
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(syn) >
From the results, you can see at that ports 135, 139, and 445 are open on
IP address 192.168.1.155, leveraging the portscan syn module within Metasploit.
Targeted Scanning
When you are conducting a penetration test, there is no shame in looking
for an easy win. A targeted scan looks for specific operating systems, services,
program versions, or configurations that are known to be exploitable and
that provide an easy door into a target network. For example, it is common
to scan a target network quickly for the vulnerability MS08-067, as this is
(still) an extremely common hole that will give you SYSTEM access much
more quickly than scanning an entire target network for vulnerabilities.
Server Message Block Scanning
Metasploit can scour a network and attempt to identify versions of Microsoft
Windows using its smb_version module.
NOTE If you are not familiar with Server Message Block (SMB, a common file-sharing protocol),
study up a bit on the different protocols and their purposes before you continue. You will
need to understand basic port information to learn how to attack a system successfully.
We run the module, list our options, set RHOSTS, and begin scanning:
msf > use scanner/smb/smb_version
msf auxiliary(smb_version) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
RHOSTS yes The target address range or CIDR identifier
THREADS 1 yes The number of concurrent threads
msf auxiliary(smb_version) > set RHOSTS 192.168.1.155
RHOSTS => 192.168.1.155
msf auxiliary(smb_version) > run
[*] 192.168.1.155 is running Windows XP Service Pack 2 (language: English)
(name:DOOKIE-FA154354) (domain:WORKGROUP)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
Intelligence Gathering 27
As you can see at the smb_version scanner has pinpointed the operating
system as Windows XP with Service Pack 2. Because we are scanning only one
system, we leave THREADS set to 1. If we had been scanning a number of systems,
such as a class C subnet range, we might consider upping the THREADS using the
set THREADS number option. The results of this scan are stored in the Metasploit
database for use at a later time and to be accessed with the db_hosts command.
msf auxiliary(smb_version) > db_hosts -c address,os_flavor
Hosts
=====
address os_flavor Svcs Vulns Workspace
------- --------- ---- ----- ---------
192.168.1.155 Windows XP 3 0 default
msf auxiliary(smb_version) >
We have discovered a system running Windows XP without having to do
a full scan of the network. This is a great way to target hosts quickly and quietly
that are likely to be more vulnerable when our goal is avoid being noticed.
Hunting for Poorly Configured Microsoft SQL Servers
Poorly configured Microsoft SQL Server (MS SQL) installations often provide
an initial way into a target network. In fact, many system administrators don’t
even realize that they have MS SQL servers installed on their workstations at
all, because the service is installed as a prerequisite for some common software,
such as Microsoft Visual Studio. These installations are often unused,
unpatched, or never even configured.
When MS SQL is installed, it listens by default either on TCP port 1433
or on a random dynamic TCP port. If MS SQL is listening on a dynamic port,
simply query UDP port 1434 to discover on what dynamic TCP port MS SQL
is listening. Of course, Metasploit has a module that can make use of this
“feature”: mssql_ping.
Because mssql_ping uses UDP, it can be quite slow to run across entire
subnets because of issues with timeouts. But on a local LAN, setting THREADS
to 255 will greatly speed up the scan. As Metasploit finds MS SQL servers, it
displays all the details it can extract from them including, perhaps most importantly,
the TCP port on which the server is listening.
Here’s how you might run an mssql_ping scan, which includes starting the
scan, listing and setting options, and the results.
msf > use scanner/mssql/mssql_ping
msf auxiliary(mssql_ping) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
PASSWORD no The password for the specified username
RHOSTS yes The target address range or CIDR identifier
28 Chapter 3
THREADS 1 yes The number of concurrent threads
USERNAME sa no The username to authenticate as
WORKSPACE no The name of the workspace to report data into
msf auxiliary(mssql_ping) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(mssql_ping) > set THREADS 255
THREADS => 255
msf auxiliary(mssql_ping) > run
[*] SQL Server information for 192.168.1.155:
[*] ServerName = V-XPSP2-BARE
[*] InstanceName = SQLEXPRESS
[*] IsClustered = No
[*] Version = 10.0.1600.22
[*] tcp = 1433
As you can see, not only does the scanner locate a MS SQL server at ,
but it also identifies the instance name at , the SQL server version at , and
the TCP port number at on which it is listening. Just think of how much
time this targeted scan for SQL servers would save over running nmap against
all ports on all machines in a target subnet in search of the elusive TCP port.
SSH Server Scanning
If during your scanning you encounter machines running Secure Shell (SSH),
you should determine which version is running on the target. SSH is a secure
protocol, but vulnerabilities in various implementations have been identified.
You never know when you might get lucky and come across an old machine
that hasn’t been updated. You can use the Framework’s ssh_version module to
determine the SSH version running on the target server.
msf > use scanner/ssh/ssh_version
msf auxiliary(ssh_version) > set THREADS 50
THREADS => 50
msf auxiliary(ssh_version) > run
[*] 192.168.1.1:22, SSH server version: SSH-2.0-dropbear_0.52
[*] Scanned 044 of 256 hosts (017% complete)
[*] 192.168.1.101:22, SSH server version: SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1
[*] Scanned 100 of 256 hosts (039% complete)
[*] 192.168.1.153:22, SSH server version: SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1
[*] 192.168.1.185:22, SSH server version: SSH-2.0-OpenSSH_4.3
This output tells us that a few different servers are running with various
patch levels. This information could prove useful if, for example, we wanted
to attack a specific version of OpenSSH as found with the ssh_version scan.
Intelligence Gathering 29
FTP Scanning
FTP is a complicated and insecure protocol. FTP servers are often the easiest
way into a target network, and you should always scan for, identify, and fingerprint
any FTP servers running on your target.
Next, we scan our XP box for FTP services using the Framework’s
ftp_version module:
msf > use scanner/ftp/ftp_version
msf auxiliary(ftp_version) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
FTPPASS mozilla@example.com no The password for the specified username
FTPUSER anonymous no The username to authenticate as
RHOSTS yes The target address range or CIDR identifier
RPORT 21 yes The target port
THREADS 1 yes The number of concurrent threads
WORKSPACE no The name of the workspace to report data into
msf auxiliary(ftp_version) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(ftp_version) > set THREADS 255
THREADS => 255
msf auxiliary(ftp_version) > run
[*] 192.168.1.155:21 FTP Banner: Minftpd ready
The scanner successfully identifies an FTP server at . Now let’s see if
this FTP server allows anonymous logins using the Framework’s scanner/ftp/
anonymous.
msf > use auxiliary/scanner/ftp/anonymous
msf auxiliary(anonymous) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(anonymous) > set THREADS 50
THREADS => 50
msf auxiliary(anonymous) > run
[*] Scanned 045 of 256 hosts (017% complete)
[*] 192.168.1.155:21 Anonymous READ/WRITE (220 Minftpd ready)
The scanner reports at that anonymous access is allowed and that
anonymous users have both read and write access to the server; in other
words, we have full access to the remote system and the ability to upload or
download any file that can be accessed by the FTP server software.
30 Chapter 3
Simple Network Management Protocol Sweeping
The Simple Network Management Protocol (SNMP) is typically used in network
devices to report information such as bandwidth utilization, collision
rates, and other information. However, some operating systems also have
SNMP servers that can provide information such as CPU utilization, free
memory, and other system-specific details.
Convenience for the system administrator can be a gold mine for the
penetration tester, and accessible SNMP servers can offer considerable information
about a specific system or even make it possible to compromise a
remote device. If, for instance, you can get the read/write SNMP community
string for a Cisco router, you can download the router’s entire configuration,
modify it, and upload it back to the router.
The Metasploit Framework includes a built-in auxiliary module called
scanner/snmp/snmp_enum that is designed specifically for SNMP sweeps. Before
you start the scan, keep in mind that the read-only (RO) and read/write (RW)
community strings will play an important role in the type of information you
will be able to extract from a given device. On Windows-based devices configured
with SNMP, you can often use the RO or RW community strings to
extract patch levels, running services, usernames, uptime, routes, and other
information that can make things much easier for you during a pen test.
(Community strings are essentially passwords used to query a device for information
or to write configuration information to the device.)
After you guess the community strings, SNMP itself (depending on the
version) can allow anything from excessive information disclosure to full system
compromise. SNMPv1 and v2 are inherently flawed protocols. SNMPv3,
which incorporates encryption and better check mechanisms, is significantly
more secure. To gain access to a switch, you’ll first need to attempt to find its
community strings. The Framework’s use scanner/snmp/snmp_login module
will try a word list against one or a range of IP addresses.
msf > use use scanner/snmp/snmp_login
msf auxiliary(snmp_login) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(snmp_login) > set THREADS 50
THREADS => 50
msf auxiliary(snmp_login) > run
[*] >> progress (192.168.1.0-192.168.1.255) 0/30208...
[*] 192.168.1.2 'public' 'GSM7224 L2 Managed Gigabit Switch'
[*] 192.168.1.2 'private' 'GSM7224 L2 Managed Gigabit Switch'
[*] Auxiliary module execution completed
msf auxiliary(snmp_login) >
A quick Google search for GSM7224 from the output tells us that the
scanner has found both the public and private community strings for a
Netgear switch. This result, believe it or not, has not been staged for this book.
These are the default factory settings for this switch.
Intelligence Gathering 31
You will encounter many jaw-dropping situations like these throughout
your pen testing career, because many administrators simply attach devices to a
network with all their defaults still in place. The situation is even scarier when
you find these devices accessible from the Internet within a large corporation.
Writing a Custom Scanner
Many applications and services lack custom modules in Metasploit. Thankfully,
the Framework has many features that can be useful when you’re building
a custom scanner, including offering access to all of its exploit classes
and methods, and support for proxies, Secure Sockets Layer (SSL), reporting,
and threading. It can be very useful to write your own scanner during
security assessments, because doing so will allow you to locate every instance
of a bad password or unpatched service quickly on a target system.
The Metasploit Framework scanner modules include various mixins, such as
exploit mixins for TCP, SMB, and so on, and the auxiliary scanner mixin that
is built into the Framework. Mixins are portions of code with predefined
functions and calls that are preconfigured for you. The Auxiliary::Scanner
mixin overloads the Auxiliary run method; calls the module method at runtime
with run_host(ip), run_range(range), or run_batch(batch); and then processes
the IP addresses. We can leverage Auxiliary::Scanner to call additional,
built-in Metasploit functionality.
Following is a Ruby script for a simple TCP scanner that will connect to a
remote host on a default port of 12345 and upon connecting, send “HELLO
SERVER,” receive the server response, and print it out along with the server’s
IP address.
#Metasploit
require 'msf/core'
class Metasploit3 < Msf::Auxiliary
include Msf::Exploit::Remote::Tcp
include Msf::Auxiliary::Scanner
def initialize
super(
'Name' => 'My custom TCP scan',
'Version' => '$Revision: 1 $',
'Description' => 'My quick scanner',
'Author' => 'Your name here',
'License' => MSF_LICENSE
)
register_options(
[
Opt::RPORT(12345)
], self.class)
end
32 Chapter 3
def run_host(ip)
connect()
sock.puts('HELLO SERVER')
data = sock.recv(1024)
print_status("Received: #{data} from #{ip}")
disconnect()
end
end
This simple scanner uses the Msf::Exploit::Remote::Tcp mixin to handle
the TCP networking, and the Msf::Auxiliary::Scanner mixin exposes the various
settings that are required for scanners within the Framework . This
scanner is configured to use the default port of 12345 , and upon connecting
to the server, it sends a message , receives the reply from the server, and
then prints it out to the screen along with the server IP address .
We have saved this custom script under modules/auxiliary/scanner/ as
simple_tcp.rb. The saved location is important in Metasploit. For example, if
the module is saved under modules/auxiliary/scanner/http/, it would show up
in the modules list as scanner/http/simple_tcp.
To test this rudimentary scanner, we set up a netcat listener on port 12345
and pipe in a text file to act as the server response.
root@bt:/# echo "Hello Metasploit" > banner.txt
root@bt:/# nc -lvnp 12345 < banner.txt
listening on [any] 12345...
Next, we load up msfconsole, select our scanner module, set its parameters,
and run it to see if it works.
msf > use auxiliary/scanner/simple_tcp
msf auxiliary(simple_tcp) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
RHOSTS yes The target address range or CIDR identifier
RPORT 12345 yes The target port
THREADS 1 yes The number of concurrent threads
msf auxiliary(simple_tcp) > set RHOSTS 192.168.1.101
RHOSTS => 192.168.1.101
msf auxiliary(simple_tcp) > run
[*] Received: Hello Metasploit from 192.168.1.101
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(simple_tcp) >