Articles

Metasploit Framework Windows Tutorial
Remote Desktop Connection
Windows Processes That May Be Dangerous
How-To use NetCat a Tutorial
Common Linux Commands
Common Ports
Netcat Commands
HTTP Response Codes
War-Google Hack Terms
Wardriving
Avoiding Social Engineering and Phishing Attacks
Intrusion Detection on Linux
Linux Intrusion Detection
Penetration Testing Guide
Penetration Testing Tools
Social Engineering Fundamentals, Part I: Hacker Tactics
Social engineering (computer security)
The Psychology of Social Engineering

The Archives

General GSO
GovernmentSecurity.org News & Suggestions
In The News
Open Topic
General Security Information
Trash Can
Exploit & Vulnerability Mailing List Archives
Trial Member Forum
Product and Program Reviews GSO Tutorials
System Security
Windows Systems
Beginners Section
Linux & Unix Systems
File Downloads
Exploit Research & Discussion Trojan & Virus Errata
Networking Security / Firewall / IDS / VPN / Routers
System Hardening
E-Mail Security
Wifi Security
Trial Member Uploads
Upload discovered Trojans & Mal ware
GSO Programming Section
C , C++ , VC++
Visual Basic.NET
Perl /CGI
Java/Javascript
PHP/XML/ASP/HTML
Assembly + Other
The Cork Board
Network Security Consultant Directory
Network Security Jobs
The Archives
Encryption Information
General Network Security
Internet Anonymity
HTTP Protocol Security
Linux Security
MS IIS Information
Exploit Articles
Programming / Tool Design
GSO Software Projects
Public Downloads
Microsoft Security Questions and Papers

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.