hacking contest

hacking exploits security forum
hacking
compliance articles
upgrade backup exec
information security consultant

Full Version: Dns Tricks
myth
This is more of a follow up to the previous thread about DNS Zone Transfers.

Not an indepth post, but should give you some ideas how to use DNS servers for your informations gain. Using *nix commands, but windows users can find alternatives, DNS is cross platform tongue.gif

Using a program called dig, im going to give you a couple pointers to get some valuable information from the DNS servers.

Basic usage:

CODE
rt001:~# dig google.com

; <<>> DiG 9.2.4 <<>> google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36072
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             121     IN      A       216.239.57.99
google.com.             121     IN      A       216.239.37.99
google.com.             121     IN      A       216.239.39.99

;; AUTHORITY SECTION:
google.com.             39566   IN      NS      ns1.google.com.
google.com.             39566   IN      NS      ns2.google.com.
google.com.             39566   IN      NS      ns3.google.com.
google.com.             39566   IN      NS      ns4.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.         212365  IN      A       216.239.32.10
ns2.google.com.         212365  IN      A       216.239.[CODE]34.10
ns3.google.com.         39996   IN      A       216.239.36.10
ns4.google.com.         39996   IN      A       216.239.38.10

;; Query time: 4977 msec
;; SERVER: 192.168.13.51#53(192.168.13.51)
;; WHEN: Sun Jun 26 21:37:26 2005
;; MSG SIZE  rcvd: 212



(from now on i will be grep-ing out the important information, dig by itself is very verberos)

That command used my local DNS server to lookup the IP of google.com. [NOTE] NS Records, are Name Servers - or IP's - responsible for that domain name, usually atleast 2 for every domain-name. In the end, if i wanted to contact google.com i'd be using the IP 216.239.57.99. Becuase of the A Record, which are alias's - simple name to ip converstion.

Here i can actually use Google's DNS server to lookup google.com

CODE
rt001:~# dig @ns1.google.com google.com | grep A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55132
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4
;google.com.                    IN      A
;; ANSWER SECTION:
google.com.             300     IN      A       216.239.37.99
google.com.             300     IN      A       216.239.57.99
google.com.             300     IN      A       216.239.39.99
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
ns1.google.com.         345600  IN      A       216.239.32.10
ns2.google.com.         345600  IN      A       216.239.34.10
ns3.google.com.         345600  IN      A       216.239.36.10
ns4.google.com.         345600  IN      A       216.239.38.10


Not a great example for use of grep, but you get the idea. It resolves to the same IP but this time I used their DNS server.

This can be used because, sometimes DNS servers see the Internal Network and the External Network. So query-ing that DNS will often produce extra results.

Another example of dig usage is selecting the Record Types. For example, what happens if I wanted to know the domains primary mail server ? I would request, instead of the default A record - or automated NS record - I want the MX Record.

CODE
rt001:~# dig @ns1.google.com -t MX google.com

; <<>> DiG 9.2.4 <<>> @ns1.google.com -t MX google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46142
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 8

;; QUESTION SECTION:
;google.com.                    IN      MX

;; ANSWER SECTION:
google.com.             3600    IN      MX      10 smtp2.google.com.
google.com.             3600    IN      MX      40 smtp3.google.com.
google.com.             3600    IN      MX      40 smtp4.google.com.
google.com.             3600    IN      MX      10 smtp1.google.com.

{Cut - without using grep this time :P}

;; Query time: 449 msec
;; SERVER: 216.239.32.10#53(ns1.google.com)
;; WHEN: Sun Jun 26 21:48:48 2005
;; MSG SIZE  rcvd: 316



And there we go, if we needed to send an email, or had a exploit for an email server and wanted to know that domains server, there it is. Simple asking for the MX Record Type. Also, a less trivial is the Reverse Lookup DB, or the PTR Record Types but using the switch '-t PTR <IP>'

As shown in the previous thread with the client host, here I will also demonstrate the same method, but also using dig because it has all our DNS needs.

As mentioned in the previous thread, about my friends DNS server, what I dont think I said was only one of his DNS servers was actually vulnerable. Using the output of host, i could tell which one it was. Anyway, using dig as shown below im sending the srvr.weak.dns server a DNS Zone Transfer Request or an AXFR record query regarding the weak.dns domain.

CODE
brad@rt001:/root$ dig @srvr.weak.dns -t AXFR weak.dns

; <<>> DiG 9.2.4 <<>> @srvr.weak.dns -t AXFR weak.dns
;; global options:  printcmd
weak.dns.        3600    IN      SOA     ns.weak.dns. hostmaster.weak.dns. 2005061602 3600 900 600000 3600
weak.dns.        3600    IN      NS      ns.weak.dns.
weak.dns.        3600    IN      NS      ns2.weak.dns.
weak.dns.        3600    IN      NS      some.weak.dns.
weak.dns.        3600    IN      NS      other.weak.dns.
weak.dns.        3600    IN      MX      10 mail-in.weak.dns.
weak.dns.        3600    IN      MX      200 relay1.weak.dns.
weak.dns.        3600    IN      A       x.x.x.x
filer0-501.weak.dns. 3600 IN     A       x.x.x.x
xxx-xx-xxx-xx.weak.dns. 3600 IN  A       x.x.x.x
xxx-xx-xxx-xx.weak.dns. 3600 IN  A       x.x.x.x


http://www.governmentsecurity.org/forum/in...showtopic=15240

If a successful transfer is made, and the DNS knew about the internal networks, you will recieve a complete list of every computer that DNS Server knows about, and makes planning complex attacks so much easier...

Another tip is for getting the version of bind they are running, as described by whiskah Click Here to Scroll Down

Also great for pen-test as others have mentioned. Secure Your DNS.

dw-chow
not bad, finding higher efficiency in the programs you already know and love.
packet
Great howto! I suggest everyone who manages a network to do this to their own internal DNS servers and restrict transfer requests to only trusted systems (i.e., not users). One of my pen test tools is to scan internal and external DNS for juicy tidbits. Very surpising what you find in there sometimes.

--P>G>>
whiskah
I would like to add something to this post..
Determining BIND Version using DIG..As you can see from the result the BIND version is 9.2.5

CODE

root@localhost root#dig @ns1.target.com version.bind chaos txt

<<>> DiG 9.2.4 <<>> @ns1.target.com version.bind chaos txt
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37425
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; ANSWER SECTION:
version.bind.           0       CH      TXT     "9.2.5"

;; AUTHORITY SECTION:
version.bind.           0       CH      NS      version.bind.

;; Query time: 154 msec
;; SERVER: xxx.xxx.xxx.xxx#53(ns1.target.com)
;; WHEN: Tue Jun 28 08:37:43 2005
;; MSG SIZE  rcvd: 62
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.

 
Invision Power Board © 2001-2005 Invision Power Services, Inc.