Information Gathering
In this chapter we begin the information-gathering phase of penetration testing. The goal
of this phase is to learn as much about our clients as we can. Does the CEO reveal way too
much on Twitter? Is the system administrator writing to archived listservs, asking about
how to secure a Drupal install? What software are their web servers running? Are the
Internet-facing systems listening on more ports than they should? Or, if this is an
internal penetration test, what is the IP address of the domain controller?
We’ll also start to interact with our target systems, learning as much as we can about
them without actively attacking them. We’ll use the knowledge gained in this phase to
move on to the threat-modeling phase where we think like attackers and develop
plans of attack based on the information we’ve gathered. Based on the information we
uncover, we’ll actively search for and verify vulnerabilities using vulnerability-scanning
techniques, which are covered in the next chapter.
Open Source Intelligence Gathering
We can learn a good deal about our client’s organization and
infrastructure before we send a single packet their way, but information
gathering can still be a bit of a moving target. It isn’t feasible to study
the online life of every employee, and given a large amount of gathered
information, it can be dif- ficult to discern important data from noise. If
the CEO tweets frequently about a favorite sports team, that team’s
name may be the basis for her webmail password, but it could just as
easily be entirely irrelevant. Other times it will be easier to pick up on
something crucial. For instance, if your client has online job postings for a
system administrator who is an expert in certain software, chances are
those platforms are deployed in the client’s infrastructure.
1
All Rights Reserved.
Copyrights © by MRWEBSECURE
As opposed to intelligence gained from covert sources such as
dump- ster diving, dumping website databases, and social engineering,
open source intelligence (or OSINT) is gathered from legal sources like
public records and social media. The success of a pentest often depends
on the results of the information-gathering phase, so in this section, we
will look at a few tools to obtain interesting information from these
public sources.
Netcraft
Sometimes the information that web servers and web-hosting companies
gather and make publicly available can tell you a lot about a website. For
instance, a company called Netcraft logs the uptime and makes queries
about the underlying software. (This information is made publicly
available at http://www.netcraft.com/.) Netcraft also provides other
services, and their antiphishing offerings are of particular interest to
information security.
For example, Figure 5-1 shows the result when we query http://www
.netcraft.com/ for http://www.bulbsecurity.com. As you can see,
bulbsecurity.com was first seen in March 2012. It was registered through
GoDaddy, has an IP address of 50.63.212.1, and is running Linux with an
Apache web server.
Armed with this information, when pentesting bulbsecurity.com, we
could start by ruling out vulnerabilities that affect only Microsoft IIS
servers. Or, if we wanted to try social engineering to get credentials to
the website, we could write an email that appears to be from GoDaddy,
asking the adminis- trator to log in and check some security settings.
All Rights Reserved.
Copyrights © by MRWEBSECURE
Figure 5-1: Netcraft’s results for bulbsecurity.com
Whois Lookups
All domain registrars keep records of the domains they host. These
records contain information about the owner, including contact
information. For example, if we run the Whois command line tool on our
Kali machine to query for information about bulbsecurity.com, as shown in
Listing 5-1, we see that I used private registration, so we won’t learn much.
root@kali:~# whois bulbsecurity.com
Registered through: GoDaddy.com, LLC
(http://www.godaddy.com)Domain Name:
BULBSECURITY.COM
All Rights Reserved.
Copyrights © by MRWEBSECURE
Created on: 21-Dec-11
Expires on: 21-Dec-12
Last Updated on: 21-Dec-11
Registrant: Domains
By Proxy, LLC
DomainsByProxy.com
14747 N Northsight Blvd Suite 111, PMB 309
Scottsdale, Arizona 85260
United States
Private, Registration
BULBSECURITY.COM@domainsbyproxy.com
Domains By Proxy, LLC
DomainsByProxy.com
14747 N Northsight Blvd Suite 111, PMB 309
Scottsdale, Arizona 85260
United States
(480) 624-2599 Fax -- (480) 624-2598
Domain servers in listed order:
NS65.DOMAINCONTROL.COM
NS66.DOMAINCONTROL.COM
Listing 5-1: Whois information for bulbsecurity.com
This site has private registration, so both the registrant and technical
4
All Rights Reserved.
Copyrights © by MRWEBSECURE
contact are domains by proxy. Domains by proxy offer private
registra- tion, hiding your personal details in the Whois information for
the domains you own. However, we do see the domain servers for
bulbsecurity.com.
Running Whois queries against other domains will show more interesting
results. For example, if you do a Whois lookup on georgiaweidman.com,
you might get an interesting blast from the past, including my college
phone number.
DNS Reconnaissance
We can also use Domain Name System (DNS) servers to learn more about
a domain. DNS servers translate the human-readable URL
www.bulbsecurity.com into an IP address.
Nslookup
For example, we could use a command line tool such as Nslookup, as
shown in Listing 5-2.
root@Kali:~# nslookup www.bulbsecurity.com
Server:75.75.75.75
Address: 75.75.75.75#53
Non-authoritative answer:
www.bulbsecurity.com canonical name =
bulbsecurity.com.Name: bulbsecurity.com
All Rights Reserved.
Copyrights © by MRWEBSECURE
Listing 5-2: Nslookup information for www.bulbsecurity.com
Nslookup returned the IP address of www.bulbsecurity.com, as you
can see at .
We can also tell Nslookup to find the mail servers for the same
website by looking for MX records (DNS speak for email), as shown in
Listing 5-3.
root@kali:~# nslookup
> set type=mx
> bulbsecurity.com
Server:75.75.75.75
Address: 75.75.75.75#53
Non-authoritative answer:
bulbsecurity.com mail exchanger = 40
ASPMX2.GOOGLEMAIL.com. bulbsecurity.com mail
exchanger = 20 ALT1.ASPMX.L.GOOGLE.com.
bulbsecurity.com mail exchanger = 50
ASPMX3.GOOGLEMAIL.com. bulbsecurity.com mail
exchanger = 30 ALT2.ASPMX.L.GOOGLE.com.
bulbsecurity.com mail exchanger = 10
ASPMX.L.GOOGLE.com.
Listing 5-3: Nslookup information for bulbsecurity.com’s mail servers
Nslookup says bulbsecurity.com is using Google Mail for its email
6
All Rights Reserved.
Copyrights © by MRWEBSECURE
servers, which is correct because I use Google Apps.
Host
Another utility for DNS queries is Host. We can ask Host for the name
servers for a domain with the command host -t ns domain. A good
example for domain queries is zoneedit.com, a domain set up to
demonstrate zone transfer vulnerabilities, as shown here.
root@kali:~# host -t ns zoneedit.com
zoneedit.com name server
ns4.zoneedit.com.zoneedit.com name
server ns3.zoneedit.com.
--snip--
This output shows us all the DNS servers for zoneedit.com. Naturally,
because I mentioned that this domain was set up to demonstrate zone
transfers, that’s what we are going to do next.
Zone Transfers
DNS zone transfers allow name servers to replicate all the entries about a
domain. When setting up DNS servers, you typically have a primary
name server and a backup server. What better way to populate all the
entries in the secondary DNS server than to query the primary server
for all of its entries?
Unfortunately, many system administrators set up DNS zone transfers
insecurely, so that anyone can transfer the DNS records for a domain.
zoneedit.com is an example of such a domain, and we can use the host
7
All Rights Reserved.
Copyrights © by MRWEBSECURE
com- mand to download all of its DNS records. Use the -l option to specify
the domain to transfer, and choose one of the name servers from the
previous command, as shown in Listing 5-4.
root@kali:~# host -l zoneedit.com ns2.zoneedit.com
Using domain server:
Name: ns2.zoneedit.com
Address: 69.72.158.226#53
Aliases:
zoneedit.com name server
ns4.zoneedit.com. zoneedit.com name
server ns3.zoneedit.com. zoneedit.com
name server ns15.zoneedit.com.
zoneedit.com name server
ns8.zoneedit.com. zoneedit.com name
server ns2.zoneedit.com. zoneedit.com
has address 64.85.73.107
www1.zoneedit.com has address
64.85.73.41 dynamic.zoneedit.com has
address 64.85.73.112
bounce.zoneedit.com has address
64.85.73.100
--snip--
mail2.zoneedit.com has address 67.15.232.182
--snip--
Listing 5-4: Zone transfer of zoneedit.com
8
All Rights Reserved.
Copyrights © by MRWEBSECURE
There are pages and pages of DNS entries for zoneedit.com, which
gives us a good idea of where to start in looking for vulnerabilities for
our pen- test. For example, mail2.zoneedit.com is probably a mail
server, so we should look for potentially vulnerable software running on
typical email ports such as 25 (Simple Mail Transfer Protocol) and 110
(POP3). If we can find a web- mail server, any usernames we find may
lead us in the right direction so that we can guess passwords and gain
access to sensitive company emails.
Searching for Email Addresses
External penetration tests often find fewer services exposed than internal
ones do. A good security practice is to expose only those services that
must be accessed remotely, like web servers, mail servers, VPN servers,
and maybe SSH or FTP, and only those services that are mission critical.
Services like these are common attack surfaces, and unless employees use
two-factor authentication, accessing company webmail can be simple if an
attacker
can guess valid credentials.
One excellent way to find usernames is by looking for email
addresses on the Internet. You might be surprised to find corporate
email addresses publicly listed on parent-teacher association contact info,
sports team ros- ters, and, of course, social media.
You can use a Python tool called theHarvester to quickly scour thou-
sands of search engine results for possible email addresses. theHarvester
can automate searching Google, Bing, PGP, LinkedIn, and others for
email addresses. For example, in Listing 5-5, we’ll look at the first 500
results in all search engines for bulbsecurity.com.
9
All Rights Reserved.
Copyrights © by MRWEBSECURE
root@kali:~# theharvester -d bulbsecurity.com -l 500 -b
all
*****************************************************
**************
* *
* | |_| | /\ /\ __ | |_ _ *
*| | '_ \ / _ \ / /_/ / _` | ' \ \ / / _ \/ | /_\' |*
* | |_| | | | // / (_| | | \V/ /\ \ || /|
*
* \ |_| |_|\ | \/ /_/ \ ,_|_| \_/ \ || /\ \ |_|
*
* *
* TheHarvester Ver. 2.2a *
* Coded by Christian Martorella *
* Edge-Security Research *
* cmartorella@edge-security.com *
*****************************************************
**************
Full harvest..
[-] Searching in Google..
Searching 0 results...
Searching 100 results...
Searching 200 results...
Searching 300 results...
10
All Rights Reserved.
Copyrights © by MRWEBSECURE
--snip--
[+] Emails found:
georgia@bulbsecurity.com
[+] Hosts found in search engines:
50.63.212.1:www.bulbsecurity.com
--snip--
Listing 5-5: Running theHarvester against bulbsecurity.com
There’s not too much to be found for bulbsecurity.com, but
theHarvester does find my email address, georgia@bulbsecurity.com,
and the website,
www.bulbsecurity.com, as well as other websites I share virtual
hosting with. You may find more results if you run theHarvester
against your organization.
Google Hacking :
Google Hacking involves an attacker submitting queries to
Google’s search engine with the intention of finding sensitive
information residing on Web pages that have been indexed by
Google, or finding sensitive information with respect
11
All Rights Reserved.
Copyrights © by MRWEBSECURE
to vulnerabilities in applications indexed by Google. Google
Hacking is by no means confined to searching through the
Google search engine but can be applied to any of the major
search engines.
Detailed Description
As search engines crawl their way through web applications
with the intent of indexing their content they stumble upon
sensitive information. The more robust and sophisticated these
crawlers become the more coverage they get of a server
exposed to the web. Thus any information, accidentally
accessible through a web server or a web application will
quickly be picked up by a search engine. Sensitive information
may be on the personal level such as security numbers and
credit card numbers and passwords, but it also encompasses
technical and corporate sensitive information such as client
files, the company’s human resources files, or secret formulas
put accidentally on a server. Additionally the search engine
picks up information that may expose application
vulnerabilities such as error messages contained in the
server’s reply to the search engine’s request, directory listings
and so on. All this sensitive information is available for anyone
to see through the appropriate search terms.
Although the coined term highlights the giant search engine
Google, we consider the domain of this attack to include all
available search engines, including Yahoo!, Ask.com,
LiveSearch and others.
12
All Rights Reserved.
Copyrights © by MRWEBSECURE
Real-life examples of data leaking onto the Web and found
by Google include SUNY Stony Brook where the personal
information of 90,000 people was jeopardized when the
information was mistakenly put on the Web, Jax Federal Credit
Union where information was picked up by Google from a Web
site belonging to JFCU print service provider, and the
compromise of the personal details of several thousands
residents by the Newcastle-upon-Tyne city council.
Different resources exist which provide effective terms to use
for Google Hacking. Probably the most renowned source
is Johnny’s I Hack Stuff Google Hacking Database which
contains a comprehensive list of terms used to search the Web
for files containing authentication credentials, error codes and
vulnerable files and servers and even Web server detection.
Furthermore, Google Hacking may also be used as a tool for
fast proliferation of malicious code. The famous SantyWorm
defaced Web sites by exploiting a certain PHP vulnerability.
The SantyWorm spread to vulnerable machines by searching
Google for such machines and infecting them.
Search Engine Hacking Prevention:
Unfortunately, once sensitive information is available on the
Web, and thus available via a search engine, a professional
information-digger will most probably get his or her hands on
13
All Rights Reserved.
Copyrights © by MRWEBSECURE
it. However, there are a few measures one can easily apply to
prevent search engine related incidents. Prevention includes
making sure that a search engine does not index sensitive
information. An effective Web Application Firewall should have
such a configurable feature – with the ability to correlate
search engines’ user-agent or a range of search engines’ IP
addresses with patterns on requests and replies that hint of
sensitive information, such as non-public folder names like
“/etc” and patterns that look like credit card numbers, and
then blocking replies if there is a chance of leakage. Pattern
lists may also be found at Johnny’s I Hack Stuff resources.
Detection of sensitive data appearing in a web search includes
periodically checking Google to see whether information has
leaked. Available tools with just that task in mind may be
found on the Internet, such as GooScan and the Goolag
Scanner.
14
All Rights Reserved.
Copyrights © by MRWEBSECURE
