That's right. You read that correctly. NMAP, the world's leading port scanner and one of the few
tools that should be in every single tester's toolkit, can help you determine a lot of information
regarding a target. Host discovery, my friends. NMAP can help you discover lots of information
about the hosts on the outward-facing interfaces of a network.
And it does all this without touching the hosts in question.
That's right. You can perform lots of recon with nmap without slinging a single packet at
the target hosts.
Previously, we've discussed using Maltego to determine host information (IP's, owner
information, etc). Now we're going to do the same from the command line (and do it a might bit
quicker, too). But first a little history ...
1. Setting the Wayback Machine to 199x
The Internet runs mainly because a service, provided by Domain Name System (DNS), translates
“friendly names” (like “www.google.com”) to IP addresses (74.125.91.106) and then routes
packets around networks until they reach the proper destination. Kind of in the way a phone
book translates a “friendly name” like “Bob Smith” to his phone number (212) 555-1212, so you
can call him.
Now, that's an overly simplified depiction of the situation, but it works for the purposes of
background to our nmap story.
2. DNS Records
DNS is a fairly easy system to follow along with, even if you're fairly new to Information
Technology. DNS simply holds and retrieves records about specific servers in your network range.
Typically, it holds the following types of records:
1. MX Record – Mail Exchange Record – this record indicates what servers are designated as
your mail servers
2. NS Record – Name Server Record – this record indicates what servers are designated as
your DNS servers (typically open for UDP 53, at the very least)
3. A Record – Address Record – this record maps a domain name (or sub-domain name) to
an Ipv4 address
4. AAAA Record – Address Record – this record maps a domain name (or sub-domain name) to an Ipv6 address
5. SOA Record – Start of Authority Record – defines global parameters for a zone (domain) – it can define what server is your primary name server (DNS server)
6. CNAME Record – Canonical Name Record – defines a server's canonical name, rather than any of the aliases it may have within the domain
7. PTR Record – Pointer Record – provides information for Reverse DNS (see below) – also, has become an “authoritative” way to determine spammers around the Internet
8. SRV Record – Service – provides information for specific services, such as SIP and XMPP (that's right, Jabber/GTalk). For some in-depth information on SRV records and their structure, please take a look at: http://en.wikipedia.org/wiki/SRV_record
Interesting note: MX and SRV records must point to an address record (A or AAAA record).
3. Reverse DNS
Reverse DNS performs the exact same service, only in reverse. Reverse DNS lookups (rDNS) determines the domain name (“friendly name”) that is associated with a given IP address.
4. Using Nslookup
For years, nslookup was the defacto standard tool with which to interact with DNS servers and glean information. However, in recent years, this has been shown to be a flawed tool with problematic results. A detailed write up can be found here (http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.html) , but the long and short of it is that:
1. nslookup performs hidden queries
If you are trying to perform reconnaissance work, you want to be as quiet as possible. By performing hidden queries, nslookup is not exactly a “quiet” utility. In fact, it's rather noisy.
2. nslookup uses its own internal DNS client
Also when performing recon work, you want to ensure the data you're getting in return is accurate. When put up against standard DNS utils, it has been found that nslookup's returned data was inaccurate. This means that, in the long run, you can't really and truly trust what you're seeing from nslookup.
What, then, is a poor pen tester to do?
Use “dig” and “host”, of course. (And nmap, too)
5. Using Host
For in-depth guidance on how to use host, check out their man page here: http://linux.die.net/man/1/host
But let's say, for just a moment, that you wanted to use the “host” command to query a zone for all the name server (ns) records. You would want to use the following command:
host -t ns domain
and let's say you also wanted to query for all the mail server records (mx)
host -t mx domain
and let's say you wanted to … well, you get the idea, right? Just pass a “-t” parameter and use the abbreviation for the type of record you want to retrieve.
host -t srv domain
will provide you with all the SRV records for the domain or sub-domain.
So, for an example, I ran the host query against ISC.org (the CISSP organization):
user@host:~$ host -t mx isc.org
isc.org mail is handled by 10 mx.ams1.isc.org.
isc.org mail is handled by 10 mx.pao1.isc.org.
and then I wanted to find their name servers:
user@host:~$ host -t ns isc.org
isc.org name server ns.isc.afilias-nst.info.
isc.org name server ams.sns-pb.isc.org.
isc.org name server ord.sns-pb.isc.org.
isc.org name server sfba.sns-pb.isc.org.
As you can see from the above, you can very quickly begin to piece together your target hostnames from using the information displayed from these commands.
Now, if you want to perform a zone transfer (with host, you can use any one of a number of utils to do this) and grab all the records for yourself, then what you want to do is the following:
host -l domain or host -l -v -t any domain
Both of these will attempt a zone transfer and give you all the host records or all the records (as a whole) for the zone
6.Using dig
dig has a lot of switches and parameters you can use to customize its output, but for some in-depth guidance, you can check out dig's man page here: http://linux.die.net/man/1/dig
However, it is most important for you to remember to add on the “+answer” to any dig lookup.
For instance, let's say we wanted to use the dig command to find information about the MX records for “isc.org”. We would want to issue the following query:
dig isc.org MX +answer
This will print out the following output:
user@host:~$ dig isc.org MX +answer
; <<>> DiG 9.7.3 <<>> isc.org MX +answer
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43599
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;isc.org. IN MX
;; ANSWER SECTION:
isc.org. 7200 IN MX 10 mx.pao1.isc.org.
isc.org. 7200 IN MX 10 mx.ams1.isc.org.
;; Query time: 87 msec
;; SERVER: 167.206.245.129#53(167.206.245.129)
;; WHEN: Sun May 15 09:35:31 2011
;; MSG SIZE rcvd: 73
A lot of stuff to sort through, I know! However, if you step back a bit and just take it one piece at a time, you can sort through this easily.
First off: there's a lot of comments. And those comments can be trimmed out by passing dig the “+nocomments” parameter. That would get rid of this part of the output:
; <<>> DiG 9.7.3 <<>> isc.org MX +answer
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43599
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
Then, you probably want to get rid of that last section as well the part that reads like this:
;; Query time: 87 msec
;; SERVER: 167.206.245.129#53(167.206.245.129)
;; WHEN: Sun May 15 09:35:31 2011
;; MSG SIZE rcvd: 73
This is the “stats” section and can be trimmed from the output of your dig command by passing dig the “+nostats” parameter.
So, really, if we wanted to boil the dig output down to something fairly easy to read we would issue the following command:
dig isc.org MX +nocomments +answer +nostats
and get back:
; <<>> DiG 9.7.3 <<>> isc.org MX +nocomments +answer +nostats
;; global options: +cmd
;isc.org. IN MX
isc.org. 7200 IN MX 10 mx.ams1.isc.org.
isc.org. 7200 IN MX 10 mx.pao1.isc.org.
Easy peasy, no? We now get back very useful output.
We see our query:
;isc.org. IN MX
and the answers we wanted:
isc.org. 7200 IN MX 10 mx.ams1.isc.org.
isc.org. 7200 IN MX 10 mx.pao1.isc.org
Dig can be useful and helpful to a pen tester and can even be used to perform a zone transfer, as well. And we all know what happens if you successfully transfer the zone? Right, you get all the host records for a domain. And what protocol does that use on port 53? Right, TCP. Where most queries use UDP, Zone Transfers use TCP.
Using nmap (with other tools) for Information Gathering
Most of us know that nmap is the most awesome port scanner on the planet. So awesome (read: useful) that there is no other I use. I know, I know. There's utilities like “amap” and “LANguard” and a slew of others. I get it. Just like the different editions of the STAR WARS movies, they all have their uses. However, if you're done preaching religious differences (yes, Han shot first, we all know that), let's all settle down, take our seats and talk about the only port scanner that matters: nmap.
Yes, you can use it to perform a wide array of scans and perform host discovery through active scanning.
However, you might not know that you can use nmap to perform list scanning, which never touches the target box. This kind of scan helps you, the pen tester, in gathering information about a target.
You can start by using “host” and “dig” to get an initial set of hosts/IPs to begin your data mining.
So, using the examples above, we know the following:
QUERY: dig isc.org MX +nocomments +answer +nostats
ANSWER: isc.org. 7200 IN MX 10 mx.pao1.isc.org.
So, we can then further “dig” for:
QUERY: dig mx.pao1.isc.org +nocomments +answer +nostats
ANSWER: mx.pao1.isc.org. 3600 IN A 149.20.64.53
So, now we have an IP address. Using the “whois” command, we can determine the network block of IP's that this server is contained in.
QUERY: whois 149.20.64.53
ANWER: user@host:~$ whois 149.20.64.53
#
# Query terms are ambiguous. The query is assumed to be:
# "n 149.20.64.53"
#
# Use "?" to get help.
SINE IIT Bombay
Wegilant SINE IIT Bombay 9 Website: www.wegilant.com,
CM – 04, Fourth Floor www.wegversity.com
KReSIT Building IIT Bombay Email: info@wegilant.com
Powai Mumbai 76 Landline: 022-25721329
#
#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=149.20.64.53?showDetails=true&showARIN=false
#
NetRange: 149.20.0.0 - 149.20.255.255
CIDR: 149.20.0.0/16
OriginAS:
NetName: ISC-NET3
NetHandle: NET-149-20-0-0-1
Parent: NET-149-0-0-0-0
We now know that isc.org owns 149.20.0.0 – 149.20.255.255 or in CIDR notation 149.20.0.0/16.
We can use this particular information to feed into nmap and have nmap perform a reverse DNS lookup. This reverse DNS lookup will determine what IP's are useful to use to start active scanning (if that is what we wish). Or we can use the information gleaned from nmap to start doing targeted queries of ports.
A list scan is an unobtrusive way to gather information to help you choose individual machines for targeting later.
So, let's use nmap now to perform a list scan of isc.org.
user@host:~$ nmap -sL isc.org/16
Starting Nmap 5.21 ( http://nmap.org ) at 2011-05-15 10:44 EDT
Nmap scan report for test-test-test.isc.org (149.20.64.1)
Nmap scan report for res1.sjc3.isc.org (149.20.64.2)
Nmap scan report for sfba.sns-pb.isc.org (149.20.64.3)
Nmap scan report for dlv.sfba.sns-pb.isc.org (149.20.64.4)
Nmap scan report for 149.20.64.5
Nmap scan report for 149.20.64.6
…
…
Nmap scan report for 149.20.64.19
Nmap scan report for bind.odvr.dns-oarc.net (149.20.64.20)
Nmap scan report for unbound.odvr.dns-oarc.net (149.20.64.21)
Nmap scan report for iana-testbed.odvr.dns-oarc.net (149.20.64.22)
Nmap scan report for 149.20.64.23
Nmap scan report for 149.20.64.24
Nmap scan report for sie.isc.org (149.20.64.25)
Nmap scan report for tools.isc.org (149.20.64.26)
Nmap scan report for zfa.sie.isc.org (149.20.64.27)
Nmap scan report for 149.20.64.28
Nmap scan report for 149.20.64.29
Nmap scan report for 149.20.64.30
…
So, as you can see, nmap has performed rDNS lookups on a number of hosts in the range and we now know a lot more hostnames than we did before. Now, we can start to infer uses and other information from the host names.
Conclusion
By using a combination of some simple tools, we, the pen tester, can quickly produce information about a target network that will become useful to us for more targeted attacks. If there's a point where you are hired to perform a pen test and the customer wants you to have absolutely zero information beforehand, these techniques are extremely useful for getting a starting point.
thankyou.....
tools that should be in every single tester's toolkit, can help you determine a lot of information
regarding a target. Host discovery, my friends. NMAP can help you discover lots of information
about the hosts on the outward-facing interfaces of a network.
And it does all this without touching the hosts in question.
That's right. You can perform lots of recon with nmap without slinging a single packet at
the target hosts.
Previously, we've discussed using Maltego to determine host information (IP's, owner
information, etc). Now we're going to do the same from the command line (and do it a might bit
quicker, too). But first a little history ...
1. Setting the Wayback Machine to 199x
The Internet runs mainly because a service, provided by Domain Name System (DNS), translates
“friendly names” (like “www.google.com”) to IP addresses (74.125.91.106) and then routes
packets around networks until they reach the proper destination. Kind of in the way a phone
book translates a “friendly name” like “Bob Smith” to his phone number (212) 555-1212, so you
can call him.
Now, that's an overly simplified depiction of the situation, but it works for the purposes of
background to our nmap story.
2. DNS Records
DNS is a fairly easy system to follow along with, even if you're fairly new to Information
Technology. DNS simply holds and retrieves records about specific servers in your network range.
Typically, it holds the following types of records:
1. MX Record – Mail Exchange Record – this record indicates what servers are designated as
your mail servers
2. NS Record – Name Server Record – this record indicates what servers are designated as
your DNS servers (typically open for UDP 53, at the very least)
3. A Record – Address Record – this record maps a domain name (or sub-domain name) to
an Ipv4 address
4. AAAA Record – Address Record – this record maps a domain name (or sub-domain name) to an Ipv6 address
5. SOA Record – Start of Authority Record – defines global parameters for a zone (domain) – it can define what server is your primary name server (DNS server)
6. CNAME Record – Canonical Name Record – defines a server's canonical name, rather than any of the aliases it may have within the domain
7. PTR Record – Pointer Record – provides information for Reverse DNS (see below) – also, has become an “authoritative” way to determine spammers around the Internet
8. SRV Record – Service – provides information for specific services, such as SIP and XMPP (that's right, Jabber/GTalk). For some in-depth information on SRV records and their structure, please take a look at: http://en.wikipedia.org/wiki/SRV_record
Interesting note: MX and SRV records must point to an address record (A or AAAA record).
3. Reverse DNS
Reverse DNS performs the exact same service, only in reverse. Reverse DNS lookups (rDNS) determines the domain name (“friendly name”) that is associated with a given IP address.
4. Using Nslookup
For years, nslookup was the defacto standard tool with which to interact with DNS servers and glean information. However, in recent years, this has been shown to be a flawed tool with problematic results. A detailed write up can be found here (http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.html) , but the long and short of it is that:
1. nslookup performs hidden queries
If you are trying to perform reconnaissance work, you want to be as quiet as possible. By performing hidden queries, nslookup is not exactly a “quiet” utility. In fact, it's rather noisy.
2. nslookup uses its own internal DNS client
Also when performing recon work, you want to ensure the data you're getting in return is accurate. When put up against standard DNS utils, it has been found that nslookup's returned data was inaccurate. This means that, in the long run, you can't really and truly trust what you're seeing from nslookup.
What, then, is a poor pen tester to do?
Use “dig” and “host”, of course. (And nmap, too)
5. Using Host
For in-depth guidance on how to use host, check out their man page here: http://linux.die.net/man/1/host
But let's say, for just a moment, that you wanted to use the “host” command to query a zone for all the name server (ns) records. You would want to use the following command:
host -t ns domain
and let's say you also wanted to query for all the mail server records (mx)
host -t mx domain
and let's say you wanted to … well, you get the idea, right? Just pass a “-t” parameter and use the abbreviation for the type of record you want to retrieve.
host -t srv domain
will provide you with all the SRV records for the domain or sub-domain.
So, for an example, I ran the host query against ISC.org (the CISSP organization):
user@host:~$ host -t mx isc.org
isc.org mail is handled by 10 mx.ams1.isc.org.
isc.org mail is handled by 10 mx.pao1.isc.org.
and then I wanted to find their name servers:
user@host:~$ host -t ns isc.org
isc.org name server ns.isc.afilias-nst.info.
isc.org name server ams.sns-pb.isc.org.
isc.org name server ord.sns-pb.isc.org.
isc.org name server sfba.sns-pb.isc.org.
As you can see from the above, you can very quickly begin to piece together your target hostnames from using the information displayed from these commands.
Now, if you want to perform a zone transfer (with host, you can use any one of a number of utils to do this) and grab all the records for yourself, then what you want to do is the following:
host -l domain or host -l -v -t any domain
Both of these will attempt a zone transfer and give you all the host records or all the records (as a whole) for the zone
6.Using dig
dig has a lot of switches and parameters you can use to customize its output, but for some in-depth guidance, you can check out dig's man page here: http://linux.die.net/man/1/dig
However, it is most important for you to remember to add on the “+answer” to any dig lookup.
For instance, let's say we wanted to use the dig command to find information about the MX records for “isc.org”. We would want to issue the following query:
dig isc.org MX +answer
This will print out the following output:
user@host:~$ dig isc.org MX +answer
; <<>> DiG 9.7.3 <<>> isc.org MX +answer
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43599
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;isc.org. IN MX
;; ANSWER SECTION:
isc.org. 7200 IN MX 10 mx.pao1.isc.org.
isc.org. 7200 IN MX 10 mx.ams1.isc.org.
;; Query time: 87 msec
;; SERVER: 167.206.245.129#53(167.206.245.129)
;; WHEN: Sun May 15 09:35:31 2011
;; MSG SIZE rcvd: 73
A lot of stuff to sort through, I know! However, if you step back a bit and just take it one piece at a time, you can sort through this easily.
First off: there's a lot of comments. And those comments can be trimmed out by passing dig the “+nocomments” parameter. That would get rid of this part of the output:
; <<>> DiG 9.7.3 <<>> isc.org MX +answer
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43599
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
Then, you probably want to get rid of that last section as well the part that reads like this:
;; Query time: 87 msec
;; SERVER: 167.206.245.129#53(167.206.245.129)
;; WHEN: Sun May 15 09:35:31 2011
;; MSG SIZE rcvd: 73
This is the “stats” section and can be trimmed from the output of your dig command by passing dig the “+nostats” parameter.
So, really, if we wanted to boil the dig output down to something fairly easy to read we would issue the following command:
dig isc.org MX +nocomments +answer +nostats
and get back:
; <<>> DiG 9.7.3 <<>> isc.org MX +nocomments +answer +nostats
;; global options: +cmd
;isc.org. IN MX
isc.org. 7200 IN MX 10 mx.ams1.isc.org.
isc.org. 7200 IN MX 10 mx.pao1.isc.org.
Easy peasy, no? We now get back very useful output.
We see our query:
;isc.org. IN MX
and the answers we wanted:
isc.org. 7200 IN MX 10 mx.ams1.isc.org.
isc.org. 7200 IN MX 10 mx.pao1.isc.org
Dig can be useful and helpful to a pen tester and can even be used to perform a zone transfer, as well. And we all know what happens if you successfully transfer the zone? Right, you get all the host records for a domain. And what protocol does that use on port 53? Right, TCP. Where most queries use UDP, Zone Transfers use TCP.
Using nmap (with other tools) for Information Gathering
Most of us know that nmap is the most awesome port scanner on the planet. So awesome (read: useful) that there is no other I use. I know, I know. There's utilities like “amap” and “LANguard” and a slew of others. I get it. Just like the different editions of the STAR WARS movies, they all have their uses. However, if you're done preaching religious differences (yes, Han shot first, we all know that), let's all settle down, take our seats and talk about the only port scanner that matters: nmap.
Yes, you can use it to perform a wide array of scans and perform host discovery through active scanning.
However, you might not know that you can use nmap to perform list scanning, which never touches the target box. This kind of scan helps you, the pen tester, in gathering information about a target.
You can start by using “host” and “dig” to get an initial set of hosts/IPs to begin your data mining.
So, using the examples above, we know the following:
QUERY: dig isc.org MX +nocomments +answer +nostats
ANSWER: isc.org. 7200 IN MX 10 mx.pao1.isc.org.
So, we can then further “dig” for:
QUERY: dig mx.pao1.isc.org +nocomments +answer +nostats
ANSWER: mx.pao1.isc.org. 3600 IN A 149.20.64.53
So, now we have an IP address. Using the “whois” command, we can determine the network block of IP's that this server is contained in.
QUERY: whois 149.20.64.53
ANWER: user@host:~$ whois 149.20.64.53
#
# Query terms are ambiguous. The query is assumed to be:
# "n 149.20.64.53"
#
# Use "?" to get help.
SINE IIT Bombay
Wegilant SINE IIT Bombay 9 Website: www.wegilant.com,
CM – 04, Fourth Floor www.wegversity.com
KReSIT Building IIT Bombay Email: info@wegilant.com
Powai Mumbai 76 Landline: 022-25721329
#
#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=149.20.64.53?showDetails=true&showARIN=false
#
NetRange: 149.20.0.0 - 149.20.255.255
CIDR: 149.20.0.0/16
OriginAS:
NetName: ISC-NET3
NetHandle: NET-149-20-0-0-1
Parent: NET-149-0-0-0-0
We now know that isc.org owns 149.20.0.0 – 149.20.255.255 or in CIDR notation 149.20.0.0/16.
We can use this particular information to feed into nmap and have nmap perform a reverse DNS lookup. This reverse DNS lookup will determine what IP's are useful to use to start active scanning (if that is what we wish). Or we can use the information gleaned from nmap to start doing targeted queries of ports.
A list scan is an unobtrusive way to gather information to help you choose individual machines for targeting later.
So, let's use nmap now to perform a list scan of isc.org.
user@host:~$ nmap -sL isc.org/16
Starting Nmap 5.21 ( http://nmap.org ) at 2011-05-15 10:44 EDT
Nmap scan report for test-test-test.isc.org (149.20.64.1)
Nmap scan report for res1.sjc3.isc.org (149.20.64.2)
Nmap scan report for sfba.sns-pb.isc.org (149.20.64.3)
Nmap scan report for dlv.sfba.sns-pb.isc.org (149.20.64.4)
Nmap scan report for 149.20.64.5
Nmap scan report for 149.20.64.6
…
…
Nmap scan report for 149.20.64.19
Nmap scan report for bind.odvr.dns-oarc.net (149.20.64.20)
Nmap scan report for unbound.odvr.dns-oarc.net (149.20.64.21)
Nmap scan report for iana-testbed.odvr.dns-oarc.net (149.20.64.22)
Nmap scan report for 149.20.64.23
Nmap scan report for 149.20.64.24
Nmap scan report for sie.isc.org (149.20.64.25)
Nmap scan report for tools.isc.org (149.20.64.26)
Nmap scan report for zfa.sie.isc.org (149.20.64.27)
Nmap scan report for 149.20.64.28
Nmap scan report for 149.20.64.29
Nmap scan report for 149.20.64.30
…
So, as you can see, nmap has performed rDNS lookups on a number of hosts in the range and we now know a lot more hostnames than we did before. Now, we can start to infer uses and other information from the host names.
Conclusion
By using a combination of some simple tools, we, the pen tester, can quickly produce information about a target network that will become useful to us for more targeted attacks. If there's a point where you are hired to perform a pen test and the customer wants you to have absolutely zero information beforehand, these techniques are extremely useful for getting a starting point.
thankyou.....
Comments
Post a Comment