Determining where mail is handled is a great starting place to locate the target
organization’s firewall network. Often in a commercial environment, mail is handled on
the same system as the firewall, or at least on the same network. Therefore, we can use
the host command to help harvest even more information:
[bash]$ host example.com
example.com has address 192.168.1.7
example.com mail is handled (pri=10) by mail.example.com
example.com mail is handled (pri=20) by smtp-forward.example.com
শনিবার, ২৮ মে, ২০১১
DNS Interrogation-Zone Transfers
Now we begin to query the DNS. DNS is a distributed database used to map IP addresses to hostnames, and vice versa. If DNS isconfigured insecurely, it is possible to obtain revealing information about the organization.
One of the most serious misconfigurations a system administrator can make is
allowing untrusted Internet users to perform a DNS zone transfer. While this technique
has become almost obsolete, we include it here for three reasons:
1. This vulnerability allows for signifi cant information gathering on a target.
2. It is often the springboard to attacks that would not be present without it.
3. Believe it or not, you can fi nd many DNS servers still allowing this feature.
A zone transfer allows a secondary master server to update its zone database from the
primary master. This provides for redundancy when running DNS, should the primary
name server become unavailable. Generally, a DNS zone transfer needs to be performed
only by secondary master DNS servers. Many DNS servers, however, are misconfigured
and provide a copy of the zone to anyone who asks. This isn’t necessarily bad if the only
information provided is related to systems that are connected to the Internet and have
valid hostnames, although it makes it that much easier for attackers to find potential
targets. The real problem occurs when an organization does not use a public/private
DNS mechanism to segregate its external DNS information (which is public) from its
internal, private DNS information. In this case, internal hostnames and IP addresses are
disclosed to the attacker. Providing internal IP address information to an untrusted user
over the Internet is akin to providing a complete blueprint, or roadmap, of an organization’s
internal network.
Let’s take a look at several methods we can use to perform zone transfers and the
types of information that can be gleaned. Although many different tools are available to
perform zone transfers, we are going to limit the discussion to several common types.
A simple way to perform a zone transfer is to use the nslookup client that is usually
provided with most UNIX and Windows implementations. We can use nslookup in
interactive mode, as follows:
[bash]$ nslookup
Default Server: ns1.example.com
Address: 10.10.20.2
> 192.168.1.1
Server: ns1.example.com
Address: 10.10.20.2
Name: gate.example.com
Address: 192.168.1.1
> set type=any
> ls -d example.com. >\> /tmp/zone_out
We first run nslookup in interactive mode. Once started, it will tell us the default
name server that it is using, which is normally the organization’s DNS server or a DNS
server provided by an ISP. However, our DNS server (10.10.20.2) is not authoritative for
our target domain, so it will not have all the DNS records we are looking for. Therefore,
we need to manually tell nslookup which DNS server to query. In our example, we want
to use the primary DNS server for example.com (192.168.1.1).
Next we set the record type to “any.” This will allow us to pull any DNS records
available (man nslookup) for a complete list.
Finally, we use the ls option to list all the associated records for the domain. The –d
switch is used to list all records for the domain. We append a period (.) to the end to
signify the fully qualified domain name—however, you can leave this off most times. In
addition, we redirect our output to the file /tmp/zone_out so that we can manipulate
the output later.
After completing the zone transfer, we can view the file to see whether there is any
interesting information that will allow us to target specific systems. Let’s review simulated
output for example.com:
bash]$ more zone_out
acct18 ID IN A 192.168.230.3
ID IN HINFO “Gateway2000” “WinWKGRPS”
ID IN MX 0 exampleadmin-smtp
ID IN RP bsmith.rci bsmith.who
ID IN TXT “Location:Telephone Room”
ce ID IN CNAME aesop
au ID IN A 192.168.230.4
ID IN HINFO “Aspect” “MS-DOS”
ID IN MX 0 andromeda
ID IN RP jcoy.erebus jcoy.who
ID IN TXT “Location: Library”
acct21 ID IN A 192.168.230.5
ID IN HINFO “Gateway2000” “WinWKGRPS”
ID IN MX 0 exampleadmin-smtp
ID IN RP bsmith.rci bsmith.who
ID IN TXT “Location:Accounting”
We won’t go through each record in detail, but we will point out several important
types. We see that for each entry we have an “A” record that denotes the IP address of
the system name located to the right. In addition, each host has an HINFO record that
identifies the platform or type of operating system running (see RFC 952). HINFO records
are not needed, but they provide a wealth of information to attackers. Because we saved
the results of the zone transfer to an output file, we can easily manipulate the results
with UNIX programs such as grep, sed, awk, or perl.
Suppose we are experts in SunOS/Solaris. We could programmatically find out the
IP addresses that have an HINFO record associated with Sparc, SunOS, or Solaris:
[bash]$ grep -i solaris zone_out |wc –l
388
We can see that we have 388 potential records that reference the word “Solaris.”
Obviously, we have plenty of targets.
Suppose we wanted to find test systems, which happen to be a favorite choice for
attackers. Why? Simple: they normally don’t have many security features enabled, often
have easily guessed passwords, and administrators tend not to notice or care who logs
in to them. They’re a perfect home for any interloper. Thus, we can search for test systems
as follows:
[bash]$ grep –I tes t /tmp/zone_out |wc –l
96
So we have approximately 96 entries in the zone file that contain the word “test.”
This should equate to a fair number of actual test systems. These are just a few simple
examples. Most intruders will slice and dice this data to zero in on specific system types
with known vulnerabilities.
Keep a few points in mind. First, the aforementioned method queries only one
nameserver at a time. This means you would have to perform the same tasks for all
nameservers that are authoritative for the target domain. In addition, we queried only
the example.com domain. If there were subdomains, we would have to perform the same
type of query for each subdomain (for example, greenhouse.example.com). Finally, you
may receive a message stating that you can’t list the domain or that the query was
refused. This usually indicates that the server has been configured to disallow zone
transfers from unauthorized users. Therefore, you will not be able to perform a zone
transfer from this server. However, if there are multiple DNS servers, you may be able to
find one that will allow zone transfers.
Now that we have shown you the manual method, there are plenty of tools that
speed the process, including host, Sam Spade, axfr, and dig.
The host command comes with many flavors of UNIX. Some simple ways of using
host are as follows:
host -l example.com
and
host -l -v -t any example.com
If you need just the IP addresses to feed into a shell script, you can just cut out the IP
addresses from the host command:
host -l example.com |cut - f 4 -d"" "" >\> /tmp/ip_out
Not all footprinting functions must be performed through UNIX commands. A
number of Windows products, such as Sam Spade, provide the same information.
The UNIX dig command is a favorite with DNS administrators and is often used to
troubleshoot DNS architectures. It too can perform the various DNS interrogations
mentioned in this section. It has too many command-line options to list here; the man
page explains its features in detail.
Finally, you can use one of the best tools for performing zone transfers: axfr (http://
packetstormsecurity.nl/groups/ADM/axfr-0.5.2.tar.gz) by Gaius. This utility will
recursively transfer zone information and create a compressed database of zone and host
files for each domain queried. In addition, you can even pass top-level domains such as
.com and .edu to get all the domains associated with .com and .edu, respectively.
However, this is not recommended due to the vast number of domains within each of
these TLDs.
To run axfr, you would type the following:
[bash]$ axfr example.com
axfr: Using default directory: /root/axfrdb
Found 2 name servers for domain ''example.com.'':
Text deleted.
Received XXX answers (XXX records).
To query the axfr database for the information just obtained, you would type the
following:
[bash]$ axfrcat example.com
One of the most serious misconfigurations a system administrator can make is
allowing untrusted Internet users to perform a DNS zone transfer. While this technique
has become almost obsolete, we include it here for three reasons:
1. This vulnerability allows for signifi cant information gathering on a target.
2. It is often the springboard to attacks that would not be present without it.
3. Believe it or not, you can fi nd many DNS servers still allowing this feature.
A zone transfer allows a secondary master server to update its zone database from the
primary master. This provides for redundancy when running DNS, should the primary
name server become unavailable. Generally, a DNS zone transfer needs to be performed
only by secondary master DNS servers. Many DNS servers, however, are misconfigured
and provide a copy of the zone to anyone who asks. This isn’t necessarily bad if the only
information provided is related to systems that are connected to the Internet and have
valid hostnames, although it makes it that much easier for attackers to find potential
targets. The real problem occurs when an organization does not use a public/private
DNS mechanism to segregate its external DNS information (which is public) from its
internal, private DNS information. In this case, internal hostnames and IP addresses are
disclosed to the attacker. Providing internal IP address information to an untrusted user
over the Internet is akin to providing a complete blueprint, or roadmap, of an organization’s
internal network.
Let’s take a look at several methods we can use to perform zone transfers and the
types of information that can be gleaned. Although many different tools are available to
perform zone transfers, we are going to limit the discussion to several common types.
A simple way to perform a zone transfer is to use the nslookup client that is usually
provided with most UNIX and Windows implementations. We can use nslookup in
interactive mode, as follows:
[bash]$ nslookup
Default Server: ns1.example.com
Address: 10.10.20.2
> 192.168.1.1
Server: ns1.example.com
Address: 10.10.20.2
Name: gate.example.com
Address: 192.168.1.1
> set type=any
> ls -d example.com. >\> /tmp/zone_out
We first run nslookup in interactive mode. Once started, it will tell us the default
name server that it is using, which is normally the organization’s DNS server or a DNS
server provided by an ISP. However, our DNS server (10.10.20.2) is not authoritative for
our target domain, so it will not have all the DNS records we are looking for. Therefore,
we need to manually tell nslookup which DNS server to query. In our example, we want
to use the primary DNS server for example.com (192.168.1.1).
Next we set the record type to “any.” This will allow us to pull any DNS records
available (man nslookup) for a complete list.
Finally, we use the ls option to list all the associated records for the domain. The –d
switch is used to list all records for the domain. We append a period (.) to the end to
signify the fully qualified domain name—however, you can leave this off most times. In
addition, we redirect our output to the file /tmp/zone_out so that we can manipulate
the output later.
After completing the zone transfer, we can view the file to see whether there is any
interesting information that will allow us to target specific systems. Let’s review simulated
output for example.com:
bash]$ more zone_out
acct18 ID IN A 192.168.230.3
ID IN HINFO “Gateway2000” “WinWKGRPS”
ID IN MX 0 exampleadmin-smtp
ID IN RP bsmith.rci bsmith.who
ID IN TXT “Location:Telephone Room”
ce ID IN CNAME aesop
au ID IN A 192.168.230.4
ID IN HINFO “Aspect” “MS-DOS”
ID IN MX 0 andromeda
ID IN RP jcoy.erebus jcoy.who
ID IN TXT “Location: Library”
acct21 ID IN A 192.168.230.5
ID IN HINFO “Gateway2000” “WinWKGRPS”
ID IN MX 0 exampleadmin-smtp
ID IN RP bsmith.rci bsmith.who
ID IN TXT “Location:Accounting”
We won’t go through each record in detail, but we will point out several important
types. We see that for each entry we have an “A” record that denotes the IP address of
the system name located to the right. In addition, each host has an HINFO record that
identifies the platform or type of operating system running (see RFC 952). HINFO records
are not needed, but they provide a wealth of information to attackers. Because we saved
the results of the zone transfer to an output file, we can easily manipulate the results
with UNIX programs such as grep, sed, awk, or perl.
Suppose we are experts in SunOS/Solaris. We could programmatically find out the
IP addresses that have an HINFO record associated with Sparc, SunOS, or Solaris:
[bash]$ grep -i solaris zone_out |wc –l
388
We can see that we have 388 potential records that reference the word “Solaris.”
Obviously, we have plenty of targets.
Suppose we wanted to find test systems, which happen to be a favorite choice for
attackers. Why? Simple: they normally don’t have many security features enabled, often
have easily guessed passwords, and administrators tend not to notice or care who logs
in to them. They’re a perfect home for any interloper. Thus, we can search for test systems
as follows:
[bash]$ grep –I tes t /tmp/zone_out |wc –l
96
So we have approximately 96 entries in the zone file that contain the word “test.”
This should equate to a fair number of actual test systems. These are just a few simple
examples. Most intruders will slice and dice this data to zero in on specific system types
with known vulnerabilities.
Keep a few points in mind. First, the aforementioned method queries only one
nameserver at a time. This means you would have to perform the same tasks for all
nameservers that are authoritative for the target domain. In addition, we queried only
the example.com domain. If there were subdomains, we would have to perform the same
type of query for each subdomain (for example, greenhouse.example.com). Finally, you
may receive a message stating that you can’t list the domain or that the query was
refused. This usually indicates that the server has been configured to disallow zone
transfers from unauthorized users. Therefore, you will not be able to perform a zone
transfer from this server. However, if there are multiple DNS servers, you may be able to
find one that will allow zone transfers.
Now that we have shown you the manual method, there are plenty of tools that
speed the process, including host, Sam Spade, axfr, and dig.
The host command comes with many flavors of UNIX. Some simple ways of using
host are as follows:
host -l example.com
and
host -l -v -t any example.com
If you need just the IP addresses to feed into a shell script, you can just cut out the IP
addresses from the host command:
host -l example.com |cut - f 4 -d"" "" >\> /tmp/ip_out
Not all footprinting functions must be performed through UNIX commands. A
number of Windows products, such as Sam Spade, provide the same information.
The UNIX dig command is a favorite with DNS administrators and is often used to
troubleshoot DNS architectures. It too can perform the various DNS interrogations
mentioned in this section. It has too many command-line options to list here; the man
page explains its features in detail.
Finally, you can use one of the best tools for performing zone transfers: axfr (http://
packetstormsecurity.nl/groups/ADM/axfr-0.5.2.tar.gz) by Gaius. This utility will
recursively transfer zone information and create a compressed database of zone and host
files for each domain queried. In addition, you can even pass top-level domains such as
.com and .edu to get all the domains associated with .com and .edu, respectively.
However, this is not recommended due to the vast number of domains within each of
these TLDs.
To run axfr, you would type the following:
[bash]$ axfr example.com
axfr: Using default directory: /root/axfrdb
Found 2 name servers for domain ''example.com.'':
Text deleted.
Received XXX answers (XXX records).
To query the axfr database for the information just obtained, you would type the
following:
[bash]$ axfrcat example.com
শুক্রবার, ২৭ মে, ২০১১
Hacking start IP-Related Searches
That pretty well takes care of the domain-related searches, but what about IP-related
registrations? As explained earlier, IP-related issues are handled by the various RIRs
under ICANN’s ASO. Let’s see how we go about querying this information.
The WHOIS server at ICANN (IANA) does not currently act as an authoritative
registry for all the RIRs as it does for the TLDs, but each RIR does know which IP ranges
it manages. This allows us to simply pick any one of them to start our search. If we pick
the wrong one, it will tell us which one we need to go to.
Let’s say that while perusing your security logs (as I’m sure you do religiously,
right?), you run across an interesting entry with a source IP of 61.0.0.2. You start by
entering this IP into the WHOIS search at http://www.arin.net, which tells
you that this range of IPs is actually managed by APNIC. You then go to APNIC’s site athttp://www.apnic.net to continue your search. Here you find out that this
IP address is actually managed by the National Internet Backbone of India.
This process can be followed to trace back any IP address in the world to its owner,
or at least to a point of contact that may be willing to provide the remaining details. As
with anything else, cooperation is almost completely voluntary and will vary as you deal
with different companies and different governments. Always keep in mind that there are
many ways for a hacker to masquerade their true IP. In today’s cyberworld, it’s more
likely to be an illegitimate IP address than a real one. So the IP that shows up in your logs
may be what we refer to as a laundered IP address—almost untraceable.
We can also find out IP ranges and BGP autonomous system numbers that an
organization owns by searching the RIR WHOIS servers for the organization’s literal
name. For example, if we search for “Google” at http://www.arin.net, we see the IP
ranges that Google owns under its name as well as its AS number, AS15169.It might be useful to explain why finding BGP data would be useful. IP address
information is probably pretty obvious. BGP info is probably not obvious.
The administrative contact is an important piece of information because it may tell
you the name of the person responsible for the Internet connection or firewall. Our query
also returns voice and fax numbers. This information is an enormous help when you’re
performing a dial-in penetration review. Just fire up the war-dialers in the noted range,
and you’re off to a good start in identifying potential modem numbers. In addition, an
intruder will often pose as the administrative contact using social engineering on
unsuspecting users in an organization. An attacker will send spoofed e-mail messages
posing as the administrative contact to a gullible user. It is amazing how many users will
change their passwords to whatever you like, as long as it looks like the request is being
sent from a trusted technical support person.The record creation and modification dates indicate how accurate the information is.
If the record was created five years ago but hasn’t been updated since, it is a good bet
some of the information (for example, administrative contact) may be out of date.
The last piece of information provides us with the authoritative DNS servers, which
are the sources or records for name lookups for that domain or IP. The first one listed is
the primary DNS server; subsequent DNS servers will be secondary, tertiary, and so on.
We will need this information for our DNS interrogation.
Additionally, we can try to use the network range listed as a starting point for our
network query of the ARIN database.
registrations? As explained earlier, IP-related issues are handled by the various RIRs
under ICANN’s ASO. Let’s see how we go about querying this information.
The WHOIS server at ICANN (IANA) does not currently act as an authoritative
registry for all the RIRs as it does for the TLDs, but each RIR does know which IP ranges
it manages. This allows us to simply pick any one of them to start our search. If we pick
the wrong one, it will tell us which one we need to go to.
Let’s say that while perusing your security logs (as I’m sure you do religiously,
right?), you run across an interesting entry with a source IP of 61.0.0.2. You start by
entering this IP into the WHOIS search at http://www.arin.net, which tells
you that this range of IPs is actually managed by APNIC. You then go to APNIC’s site athttp://www.apnic.net to continue your search. Here you find out that this
IP address is actually managed by the National Internet Backbone of India.
This process can be followed to trace back any IP address in the world to its owner,
or at least to a point of contact that may be willing to provide the remaining details. As
with anything else, cooperation is almost completely voluntary and will vary as you deal
with different companies and different governments. Always keep in mind that there are
many ways for a hacker to masquerade their true IP. In today’s cyberworld, it’s more
likely to be an illegitimate IP address than a real one. So the IP that shows up in your logs
may be what we refer to as a laundered IP address—almost untraceable.
We can also find out IP ranges and BGP autonomous system numbers that an
organization owns by searching the RIR WHOIS servers for the organization’s literal
name. For example, if we search for “Google” at http://www.arin.net, we see the IP
ranges that Google owns under its name as well as its AS number, AS15169.It might be useful to explain why finding BGP data would be useful. IP address
information is probably pretty obvious. BGP info is probably not obvious.
The administrative contact is an important piece of information because it may tell
you the name of the person responsible for the Internet connection or firewall. Our query
also returns voice and fax numbers. This information is an enormous help when you’re
performing a dial-in penetration review. Just fire up the war-dialers in the noted range,
and you’re off to a good start in identifying potential modem numbers. In addition, an
intruder will often pose as the administrative contact using social engineering on
unsuspecting users in an organization. An attacker will send spoofed e-mail messages
posing as the administrative contact to a gullible user. It is amazing how many users will
change their passwords to whatever you like, as long as it looks like the request is being
sent from a trusted technical support person.The record creation and modification dates indicate how accurate the information is.
If the record was created five years ago but hasn’t been updated since, it is a good bet
some of the information (for example, administrative contact) may be out of date.
The last piece of information provides us with the authoritative DNS servers, which
are the sources or records for name lookups for that domain or IP. The first one listed is
the primary DNS server; subsequent DNS servers will be secondary, tertiary, and so on.
We will need this information for our DNS interrogation.
Additionally, we can try to use the network range listed as a starting point for our
network query of the ARIN database.
Hacking start Domain-Related Searches
It’s important to note that domain-related items (such as sitewelder.com) are
registered separately from IP-related items (such as IP net-blocks, BGP autonomous
system numbers, etc.). This means we will have two different paths in our methodology
for finding these details. Let’s start with domain-related details, using keyhole.com as an
example.
The first order of business is to determine which one of the many WHOIS servers
contains the information we’re after. The general process flows like this: the authoritative
Registry for a given TLD, “.com” in this case, contains information about which Registrar
the target entity registered its domain with. Then you query the appropriate Registrar to
find the Registrant details for the particular domain name you’re after. We refer to these
as the “Three Rs” of WHOIS: Registry, Registrar, and Registrant.
There are many places on the Internet that offer one-stop-shopping for WHOIS
information, but it’s important to understand how to find the information yourself for
those times that the auto-magic tools don’t work. Since the WHOIS information is based
on a hierarchy, the best place to start is the top of the tree—ICANN. As mentioned above,
ICANN (IANA) is the authoritative registry for all of the TLDs and is a great starting
point for all manual WHOIS queries If we surf to http://whois.iana.org, we can search for the authoritative registry for all
of .com. This search shows us that the authoritative registry for .com is
Verisign Global Registry Services at http://www.verisign-grs.com. If we go to that site
and click the Whois link to the right, we get the Verisign Whois Search page where we
can search for keyhole.com and find that keyhole.com is registered through http://
www.markmonitor.com. If we go to that site and search their “Search Whois” field on the
right, we can query this registrar’s WHOIS server via their web interface to
find the registrant details for keyhole.com—voilà!
This registrant detail provides physical addresses, phone numbers, names, e-mail
addresses, DNS server names, IPs, and so on. If you follow this process carefully, you shouldn’t have too much trouble finding registrant details for any (public) domain name
on the planet. Remember, some domains like .gov and .mil may not be accessible to the
public via WHOIS.
To be thorough, we could have done the same searches via the command-line WHOIS
client with the following three commands:
[bash]$ whois com –h whois.iana.org
[bash]$ whois keyhole.com –h whois.verisign-grs.com
[bash]$ whois keyhole.com –h whois.omnis.com
There are also several websites that attempt to automate this process with varying
degrees of success:
• http://www.allwhois.comhttp://www.uwhois.com
• http://www.internic.net/whois.html
Last but not least, there are several GUIs available that will also assist you in your
searches:
• SamSpade http://www.samspade.org
• SuperScan http://www.foundstone.com
• NetScan Tools Pro http://www.nwpsw.com
Once you’ve homed in on the correct WHOIS server for your target, you may be able
to perform other searches if the registrar allows it. You may be able to find all the domains
that a particular DNS server hosts, for instance, or any domain name that contains a
certain string. These types of searches are rapidly being disallowed by most WHOIS
servers, but it is still worth a look to see what the registrar permits. It may be just what
you’re after.
registered separately from IP-related items (such as IP net-blocks, BGP autonomous
system numbers, etc.). This means we will have two different paths in our methodology
for finding these details. Let’s start with domain-related details, using keyhole.com as an
example.
The first order of business is to determine which one of the many WHOIS servers
contains the information we’re after. The general process flows like this: the authoritative
Registry for a given TLD, “.com” in this case, contains information about which Registrar
the target entity registered its domain with. Then you query the appropriate Registrar to
find the Registrant details for the particular domain name you’re after. We refer to these
as the “Three Rs” of WHOIS: Registry, Registrar, and Registrant.
There are many places on the Internet that offer one-stop-shopping for WHOIS
information, but it’s important to understand how to find the information yourself for
those times that the auto-magic tools don’t work. Since the WHOIS information is based
on a hierarchy, the best place to start is the top of the tree—ICANN. As mentioned above,
ICANN (IANA) is the authoritative registry for all of the TLDs and is a great starting
point for all manual WHOIS queries If we surf to http://whois.iana.org, we can search for the authoritative registry for all
of .com. This search shows us that the authoritative registry for .com is
Verisign Global Registry Services at http://www.verisign-grs.com. If we go to that site
and click the Whois link to the right, we get the Verisign Whois Search page where we
can search for keyhole.com and find that keyhole.com is registered through http://
www.markmonitor.com. If we go to that site and search their “Search Whois” field on the
right, we can query this registrar’s WHOIS server via their web interface to
find the registrant details for keyhole.com—voilà!
This registrant detail provides physical addresses, phone numbers, names, e-mail
addresses, DNS server names, IPs, and so on. If you follow this process carefully, you shouldn’t have too much trouble finding registrant details for any (public) domain name
on the planet. Remember, some domains like .gov and .mil may not be accessible to the
public via WHOIS.
To be thorough, we could have done the same searches via the command-line WHOIS
client with the following three commands:
[bash]$ whois com –h whois.iana.org
[bash]$ whois keyhole.com –h whois.verisign-grs.com
[bash]$ whois keyhole.com –h whois.omnis.com
There are also several websites that attempt to automate this process with varying
degrees of success:
• http://www.allwhois.comhttp://www.uwhois.com
• http://www.internic.net/whois.html
Last but not least, there are several GUIs available that will also assist you in your
searches:
• SamSpade http://www.samspade.org
• SuperScan http://www.foundstone.com
• NetScan Tools Pro http://www.nwpsw.com
Once you’ve homed in on the correct WHOIS server for your target, you may be able
to perform other searches if the registrar allows it. You may be able to find all the domains
that a particular DNS server hosts, for instance, or any domain name that contains a
certain string. These types of searches are rapidly being disallowed by most WHOIS
servers, but it is still worth a look to see what the registrar permits. It may be just what
you’re after.
Hacking start WHOIS & DNS Enumeration
While much of the Internet’s appeal stems from its lack of centralized control, in
reality several of its underlying functions must be centrally managed in order to ensure
interoperability, prevent IP conflicts, and ensure universal resolvability across
geographical and political boundaries. This means that someone is managing a vast
amount of information. If you understand a little about how this is actually done, you
can effectively tap into this wealth of information! The Internet has come a long way
since its inception. The particulars of how all this information is managed, and by whom,
is still evolving as well.
So who is managing the Internet today, you ask? These core functions of the Internet
are managed by a nonprofit organization, the Internet Corporation for Assigned Names
and Numbers (ICANN; http://www.icann.org).
ICANN is a technical coordination body for the Internet. Created in October 1998 by
a broad coalition of the Internet’s business, technical, academic, and user communities,
ICANN is assuming responsibility for a set of technical functions previously performed
under U.S. government contract by the Internet Assigned Numbers Authority (IANA;
http://www.iana.org) and other groups. (In practice, IANA still handles much of the
day-to-day operations, but these will eventually be transitioned to ICANN.)
Specifically, ICANN coordinates the assignment of the following identifiers that
must be globally unique for the Internet to function:
• Internet domain names
• IP address numbers
• Protocol parameters and port numbers
In addition, ICANN coordinates the stable operation of the Internet’s root DNS server
system.
As a nonprofit, private-sector corporation, ICANN is dedicated to preserving the
operational stability of the Internet; to promoting competition; to achieving broad
representation of global Internet communities; and to developing policy through privatesector,
bottom-up, consensus-based means. ICANN welcomes the participation of any
interested Internet user, business, or organization.
While there are many parts to ICANN, three of the suborganizations are of particular
interest to us at this point:
• Address Supporting Organization (ASO), http://www.aso.icann.org
• Generic Names Supporting Organization (GNSO), http://www.gnso.icann.org
• Country Code Domain Name Supporting Organization (CCNSO), http://www
.ccnso.icann.org
The ASO reviews and develops recommendations on IP address policy and advises
the ICANN board on these matters. The ASO allocates IP address blocks to various
Regional Internet Registries (RIRs) who manage, distribute, and register public Internet
number resources within their respective regions. These RIRs then allocate IPs to
organizations, Internet service providers (ISPs), or in some cases, National Internet
Registries (NIRs) or Local Internet Registries (LIRs) if particular governments require it
(mostly in communist countries, dictatorships, etc.):
• APNIC (http://www.apnic.net) Asia-Pacifi c region
• ARIN (http://www.arin.net) North and South America, Sub-Sahara Africa
regions
• LACNIC (http://www.lacnic.net) Portions of Latin America and the
Caribbean
• RIPE (http://www.ripe.net) Europe, parts of Asia, Africa north of the equator,
and the Middle East regions
• AfriNIC (http://www.afrinic.net, currently in observer status) Eventually
both regions of Africa currently handled by ARIN and RIPE
The GNSO reviews and develops recommendations on domain-name policy for all
generic top-level domains (gTLDs) and advises the ICANN Board on these matters. It’s
important to note that the GNSO is not responsible for domain-name registration, but
rather is responsible for the generic top-level domains (for example, .com, .net, .edu, .org,
and .info), which can be found at http://www.iana.org/gtld/gtld.htm.
The CCNSO reviews and develops recommendations on domain-name policy for all
country-code top-level domains (ccTLDs) and advises the ICANN Board on these
matters. Again, ICANN does not handle domain-name registrations. The definitive list
of country-code top-level domains can be found at http://www.iana.org/cctld/cctldwhois.
htm.
Here are some other links you may find useful:
• http://www.iana.org/assignments/ipv4-address-space IP v4 allocation
• http://www.iana.org/ipaddress/ip-addresses.htm IP address services
• http://www.rfc-editor.org/rfc/rfc3330.txt Special-use IP addresses
• http://www.iana.org/assignments/port-numbers Registered port numbers
• http://www.iana.org/assignments/protocol-numbers Registered protocol
numbers
With all of this centralized management in place, mining for information should be
as simple as querying a central super-server farm somewhere, right? Not exactly. While
the management is fairly centralized, the actual data is spread across the globe in
numerous WHOIS servers for technical and political reasons. To further complicate
matters, the WHOIS query syntax, type of permitted queries, available data, and
formatting of the results can vary widely from server to server. Furthermore, many of the
registrars are actively restricting queries to combat spammers, hackers, and resource
overload; to top it all off, information for .mil and .gov have been pulled from public
view entirely due to national security concerns.
You may ask, “How do I go about finding the data I’m after?” With a few tools, a little
know-how, and some patience, you should be able to mine successfully for domain- or
IP-related registrant details for nearly any registered entity on the planet!
reality several of its underlying functions must be centrally managed in order to ensure
interoperability, prevent IP conflicts, and ensure universal resolvability across
geographical and political boundaries. This means that someone is managing a vast
amount of information. If you understand a little about how this is actually done, you
can effectively tap into this wealth of information! The Internet has come a long way
since its inception. The particulars of how all this information is managed, and by whom,
is still evolving as well.
So who is managing the Internet today, you ask? These core functions of the Internet
are managed by a nonprofit organization, the Internet Corporation for Assigned Names
and Numbers (ICANN; http://www.icann.org).
ICANN is a technical coordination body for the Internet. Created in October 1998 by
a broad coalition of the Internet’s business, technical, academic, and user communities,
ICANN is assuming responsibility for a set of technical functions previously performed
under U.S. government contract by the Internet Assigned Numbers Authority (IANA;
http://www.iana.org) and other groups. (In practice, IANA still handles much of the
day-to-day operations, but these will eventually be transitioned to ICANN.)
Specifically, ICANN coordinates the assignment of the following identifiers that
must be globally unique for the Internet to function:
• Internet domain names
• IP address numbers
• Protocol parameters and port numbers
In addition, ICANN coordinates the stable operation of the Internet’s root DNS server
system.
As a nonprofit, private-sector corporation, ICANN is dedicated to preserving the
operational stability of the Internet; to promoting competition; to achieving broad
representation of global Internet communities; and to developing policy through privatesector,
bottom-up, consensus-based means. ICANN welcomes the participation of any
interested Internet user, business, or organization.
While there are many parts to ICANN, three of the suborganizations are of particular
interest to us at this point:
• Address Supporting Organization (ASO), http://www.aso.icann.org
• Generic Names Supporting Organization (GNSO), http://www.gnso.icann.org
• Country Code Domain Name Supporting Organization (CCNSO), http://www
.ccnso.icann.org
The ASO reviews and develops recommendations on IP address policy and advises
the ICANN board on these matters. The ASO allocates IP address blocks to various
Regional Internet Registries (RIRs) who manage, distribute, and register public Internet
number resources within their respective regions. These RIRs then allocate IPs to
organizations, Internet service providers (ISPs), or in some cases, National Internet
Registries (NIRs) or Local Internet Registries (LIRs) if particular governments require it
(mostly in communist countries, dictatorships, etc.):
• APNIC (http://www.apnic.net) Asia-Pacifi c region
• ARIN (http://www.arin.net) North and South America, Sub-Sahara Africa
regions
• LACNIC (http://www.lacnic.net) Portions of Latin America and the
Caribbean
• RIPE (http://www.ripe.net) Europe, parts of Asia, Africa north of the equator,
and the Middle East regions
• AfriNIC (http://www.afrinic.net, currently in observer status) Eventually
both regions of Africa currently handled by ARIN and RIPE
The GNSO reviews and develops recommendations on domain-name policy for all
generic top-level domains (gTLDs) and advises the ICANN Board on these matters. It’s
important to note that the GNSO is not responsible for domain-name registration, but
rather is responsible for the generic top-level domains (for example, .com, .net, .edu, .org,
and .info), which can be found at http://www.iana.org/gtld/gtld.htm.
The CCNSO reviews and develops recommendations on domain-name policy for all
country-code top-level domains (ccTLDs) and advises the ICANN Board on these
matters. Again, ICANN does not handle domain-name registrations. The definitive list
of country-code top-level domains can be found at http://www.iana.org/cctld/cctldwhois.
htm.
Here are some other links you may find useful:
• http://www.iana.org/assignments/ipv4-address-space IP v4 allocation
• http://www.iana.org/ipaddress/ip-addresses.htm IP address services
• http://www.rfc-editor.org/rfc/rfc3330.txt Special-use IP addresses
• http://www.iana.org/assignments/port-numbers Registered port numbers
• http://www.iana.org/assignments/protocol-numbers Registered protocol
numbers
With all of this centralized management in place, mining for information should be
as simple as querying a central super-server farm somewhere, right? Not exactly. While
the management is fairly centralized, the actual data is spread across the globe in
numerous WHOIS servers for technical and political reasons. To further complicate
matters, the WHOIS query syntax, type of permitted queries, available data, and
formatting of the results can vary widely from server to server. Furthermore, many of the
registrars are actively restricting queries to combat spammers, hackers, and resource
overload; to top it all off, information for .mil and .gov have been pulled from public
view entirely due to national security concerns.
You may ask, “How do I go about finding the data I’m after?” With a few tools, a little
know-how, and some patience, you should be able to mine successfully for domain- or
IP-related registrant details for nearly any registered entity on the planet!
Hacking start Search Engines, Usenet, and Resumes
The search engines available today are truly fantastic. Within seconds, you can find just
about anything you could ever want to know. Many of today’s popular search engines
provide for advanced searching capabilities that can help you home in on that tidbit
of information that makes the difference. Some of our favorite search engines are
http://www.google.com, http://search.yahoo.com, http://www.altavista.com, and
http://www.dogpile.com (which sends your search to multiple search engines such as
Google, Yahoo, Microsoft Live Search, and Ask.com). It is worth the effort to become
familiar with the advanced searching capabilities of these sites. There is so much sensitive
information available through these sites that there have even been books written on
how to “hack” with search engines—for example, Google Hacking for Penetration Testers
Vol. 2, by Johnny Long (Syngress, 2007).
Here is a simple example: If you search Google for “allinurl:tsweb/default.htm,”
Google will reveal Microsoft Windows servers with Remote Desktop Web Connection
exposed. This could eventually lead to full graphical console access to the server via the
Remote Desktop Protocol (RDP) using only Internet Explorer and the ActiveX RDP client
that the target Windows server offers to the attacker when this feature is enabled. There
are literally hundreds of other searches that reveal everything from exposed web cameras
to remote admin services to passwords to databases. We won’t attempt to reinvent the
wheel here but instead will refer you to one of the definitive Google hacking sites
available at http://johnny.ihackstuff.com. Johnny Long compiled the Google Hacking
Database (GHDB): http://johnny.ihackstuff.com/ghdb.php. Despite this hacking
database not being updated frequently, it offers a fantastic basic listing of many of the
best Google search strings that hackers will use to dig up information on the Web.
Of course, just having the database of searches isn’t good enough, right? A few tools
have been released recently that take this concept to the next level: Athena 2.0 by Steve
at snakeoillabs (http://www.snakeoillabs.com); SiteDigger 2.0 (http://www.foundstone.
com); and Wikto 2.0 by Roelof and the crew (http://www.sensepost.com/research/
wikto). They search Google’s cache to look for the plethora of vulnerabilities, errors,
configuration issues, proprietary information, and interesting security nuggets hiding
on websites around the world. SiteDigger allows you to target specific
domains, uses the GHDB or the streamlined Foundstone list of searches, allows you to
submit new searches to be added to the database, allows for raw searches, and—best of
all—has an update feature that downloads the latest GHDB and/or Foundstone searches
right into the tool so you never miss a beat.
The Usenet discussion forums or news groups are a rich resource of sensitive
information, as well. One of the most common uses of the news groups among IT
professionals is to get quick access to help with problems they can’t easily solve
themselves. Google provides a nice web interface to the Usenet news groups, complete
with its now-famous advanced searching capabilities. For example, a simple search for
“pix firewall config help” yields hundreds of postings from people requesting help with
their Cisco PIX firewall configurations. Some of these postings
actually include cut-and-pasted copies of their production configuration, including IP
addresses, ACLs, password hashes, network address translation (NAT) mappings, and
so on. This type of search can be further refined to home in on postings from e-mail
addresses at specific domains (in other words, @company.com) or other interesting search
strings.
If the person in need of help knows to not post their configuration details to a public
forum like this, they might still fall prey to a social engineering attack. An attacker could
respond with a friendly offer to assist the weary admin with their issue. If the attacker
can finagle a position of trust, they may end up with the same sensitive information
despite the initial caution of the admin.
Another interesting source of information lies in the myriad of resumes available
online. With the IT profession being as vast and diverse as it is, finding a perfect employeeto-
position match can be quite difficult. One of the best ways to reduce the large number
of false positives is to provide very detailed, often sensitive, information in both the job
postings and in the resumes.Imagine that an organization is in need of a seasoned IT security professional to
assume very specific roles and job functions. This security professional needs to be
proficient with this, that, and the other thing, as well as able to program this and that—
you get the idea. The company must provide those details in order to get qualified leads
(vendors, versions, specific responsibilities, level of experience required, etc.). If the
organization is posting for a security professional with, say, five or more years’ experience
working with CheckPoint firewalls and Snort IDS, what kind of firewall and IDS do you
think they use? Maybe they are advertising for an intrusion-detection expert to develop
and lead their IR team. What does this say about their current incident detection and
response capabilities? Could they be in a bit of disarray? Do they even have one currently?
If the posting doesn’t provide the details, maybe a phone call will. The same is true for
an interesting resume—impersonate a headhunter and start asking questions. These
kinds of details can help an attacker paint a detailed picture of security posture of the
target organization—very important when planning an attack!
If you do a search on Google for something like “company resume firewall,” where
company is the name of the target organization, you will most likely find a number of
resumes from current and/or past employees of the target that include very detailed
information about technologies they use and initiatives they are working on. Job sites
like http://www.monster.com and http://www.careerbuilder.com contain tens of
millions of resumes and job postings. Searching on organization names may yield
amazing technical details. In order to tap into the vast sea of resumes on these sites, you
have to be a registered organization and pay access fees. However, it is not too hard for
an attacker to front a fake company and pay the fee in order to access the millions of
resumes.
about anything you could ever want to know. Many of today’s popular search engines
provide for advanced searching capabilities that can help you home in on that tidbit
of information that makes the difference. Some of our favorite search engines are
http://www.google.com, http://search.yahoo.com, http://www.altavista.com, and
http://www.dogpile.com (which sends your search to multiple search engines such as
Google, Yahoo, Microsoft Live Search, and Ask.com). It is worth the effort to become
familiar with the advanced searching capabilities of these sites. There is so much sensitive
information available through these sites that there have even been books written on
how to “hack” with search engines—for example, Google Hacking for Penetration Testers
Vol. 2, by Johnny Long (Syngress, 2007).
Here is a simple example: If you search Google for “allinurl:tsweb/default.htm,”
Google will reveal Microsoft Windows servers with Remote Desktop Web Connection
exposed. This could eventually lead to full graphical console access to the server via the
Remote Desktop Protocol (RDP) using only Internet Explorer and the ActiveX RDP client
that the target Windows server offers to the attacker when this feature is enabled. There
are literally hundreds of other searches that reveal everything from exposed web cameras
to remote admin services to passwords to databases. We won’t attempt to reinvent the
wheel here but instead will refer you to one of the definitive Google hacking sites
available at http://johnny.ihackstuff.com. Johnny Long compiled the Google Hacking
Database (GHDB): http://johnny.ihackstuff.com/ghdb.php. Despite this hacking
database not being updated frequently, it offers a fantastic basic listing of many of the
best Google search strings that hackers will use to dig up information on the Web.
Of course, just having the database of searches isn’t good enough, right? A few tools
have been released recently that take this concept to the next level: Athena 2.0 by Steve
at snakeoillabs (http://www.snakeoillabs.com); SiteDigger 2.0 (http://www.foundstone.
com); and Wikto 2.0 by Roelof and the crew (http://www.sensepost.com/research/
wikto). They search Google’s cache to look for the plethora of vulnerabilities, errors,
configuration issues, proprietary information, and interesting security nuggets hiding
on websites around the world. SiteDigger allows you to target specific
domains, uses the GHDB or the streamlined Foundstone list of searches, allows you to
submit new searches to be added to the database, allows for raw searches, and—best of
all—has an update feature that downloads the latest GHDB and/or Foundstone searches
right into the tool so you never miss a beat.
The Usenet discussion forums or news groups are a rich resource of sensitive
information, as well. One of the most common uses of the news groups among IT
professionals is to get quick access to help with problems they can’t easily solve
themselves. Google provides a nice web interface to the Usenet news groups, complete
with its now-famous advanced searching capabilities. For example, a simple search for
“pix firewall config help” yields hundreds of postings from people requesting help with
their Cisco PIX firewall configurations. Some of these postings
actually include cut-and-pasted copies of their production configuration, including IP
addresses, ACLs, password hashes, network address translation (NAT) mappings, and
so on. This type of search can be further refined to home in on postings from e-mail
addresses at specific domains (in other words, @company.com) or other interesting search
strings.
If the person in need of help knows to not post their configuration details to a public
forum like this, they might still fall prey to a social engineering attack. An attacker could
respond with a friendly offer to assist the weary admin with their issue. If the attacker
can finagle a position of trust, they may end up with the same sensitive information
despite the initial caution of the admin.
Another interesting source of information lies in the myriad of resumes available
online. With the IT profession being as vast and diverse as it is, finding a perfect employeeto-
position match can be quite difficult. One of the best ways to reduce the large number
of false positives is to provide very detailed, often sensitive, information in both the job
postings and in the resumes.Imagine that an organization is in need of a seasoned IT security professional to
assume very specific roles and job functions. This security professional needs to be
proficient with this, that, and the other thing, as well as able to program this and that—
you get the idea. The company must provide those details in order to get qualified leads
(vendors, versions, specific responsibilities, level of experience required, etc.). If the
organization is posting for a security professional with, say, five or more years’ experience
working with CheckPoint firewalls and Snort IDS, what kind of firewall and IDS do you
think they use? Maybe they are advertising for an intrusion-detection expert to develop
and lead their IR team. What does this say about their current incident detection and
response capabilities? Could they be in a bit of disarray? Do they even have one currently?
If the posting doesn’t provide the details, maybe a phone call will. The same is true for
an interesting resume—impersonate a headhunter and start asking questions. These
kinds of details can help an attacker paint a detailed picture of security posture of the
target organization—very important when planning an attack!
If you do a search on Google for something like “company resume firewall,” where
company is the name of the target organization, you will most likely find a number of
resumes from current and/or past employees of the target that include very detailed
information about technologies they use and initiatives they are working on. Job sites
like http://www.monster.com and http://www.careerbuilder.com contain tens of
millions of resumes and job postings. Searching on organization names may yield
amazing technical details. In order to tap into the vast sea of resumes on these sites, you
have to be a registered organization and pay access fees. However, it is not too hard for
an attacker to front a fake company and pay the fee in order to access the millions of
resumes.
বৃহস্পতিবার, ২৬ মে, ২০১১
Privacy or Security Policies and Technical Details Indicating and Archived Information
Any piece of information that provides insight into the target organization’s privacy or
security policies or technical details regarding hardware and software used to protect the
organization can be useful to an attacker for obvious reasons. Opportunities will most
likely present themselves when this information is acquired.
It’s important to be aware that there are sites on the Internet where you can retrieve
archived copies of information that may no longer be available from the original source.
This could allow an attacker to gain access to information that has been deliberately
removed for security reasons. Some examples of this are the Wayback Machine at http://
www.archive.org, http://www.thememoryhole.org and
the cached results you see under Google’s cached results .
security policies or technical details regarding hardware and software used to protect the
organization can be useful to an attacker for obvious reasons. Opportunities will most
likely present themselves when this information is acquired.
It’s important to be aware that there are sites on the Internet where you can retrieve
archived copies of information that may no longer be available from the original source.
This could allow an attacker to gain access to information that has been deliberately
removed for security reasons. Some examples of this are the Wayback Machine at http://
www.archive.org, http://www.thememoryhole.org and
the cached results you see under Google’s cached results .
এতে সদস্যতা:
পোস্টগুলি (Atom)