DevSecOps

Incremental DNS Zone Transfers

Share

A seldom used but sometimes useful method of enumerating hosts in a target network is the use of incrementatal zone transfers.
Lets say that target system personnel have foolishly decided to prevent DNS Zone transfers by blocking TCP port 53 instead of configuring a list of servers allowed to do zone transfers on the DNS. Everyone knows that zone transfers occur over TCP port 53 and queries occur over UDP port 53. So blocking TCP port 53 should block zone transfers right? Wrong.
Well first of all, if the targets zone file is less than 512 bytes you can transfer it over UDP using DIG with the +notcp option. (Note: dig on my Mac does a TCP transfer regardless of whether or not I specify +notcp. Dig on BT5 works fine.)
[email protected]:~# dig @ns2.targetnameserver.tgt targetdomain.tgt axfr +notcp
If the zone file is larger than 512 bytes the DNS server will only transfer the data over TCP. You may still be able to obtain part of the DNZ zone using an incremental DNS transfer. An incremental DNZ zone transfer will transfer all of the records since a given update “serial number”. To get part of a zone file we will need to know what the current DNS serial number is. If the last incremental zone transfer was less than 512 bytes then we might be able to retrieve that data. Then we can decrement our serial number getting more and more zone data until we exceed the 512 byte limit. So the first thing you need is the serial number that the DNS server is currently on. You can get that information by querying the SOA record for the domain.
# dig @ns2.targetDNSserver.tgt targetDomain.tgt SOA
; <<>> DiG 9.7.0-P1 <<>> @ns1.targetDNSserver.tgt targetDomain.tgt SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57117 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;targetDomain.tgt.INSOA ;; ANSWER SECTION: targetDomain.tgt.86400INSOAns1.targetDNSserver.tgt. 2010122201 86400 7200 2592000 86400

The first number after the name of the DNS server (in bold above) is the serial number of the last transfer. Cool. Lets use it to do an incremental zone transfer.
# dig @ns1.targetDNSserver.tgt targetDomain.tgt ixfr=2010122201 +notcp
; <<>> DiG 9.7.0-P1 <<>> @ns1.targetDNSServer.tgt targetDomain.tgt ixfr=2010122201 +notcp
; (1 server found)
;; global options: +cmd
targetDomain.tgt.86400INSOAns1.targetDNSserver.tgt. 2010122201 86400 7200 2592000 86400
targetDomain.tgt.86400INA10.10.166.136
….truncated/modified/forged…
targetDomain.tgt.86400INSOAns1.targetDNSserver.tgt. 2010122201 86400 7200 2592000 86400
;; Query time: 40 msec
;; SERVER: 10.10.125.10#53(10.10.125.10)
;; WHEN: Wed Oct 19 21:14:41 2011
;; MSG SIZE rcvd: 458

Now decrement the serial number and try it again for the last two incremental zone transfers. Then decrement it again for the last 3. Lather, rinse, repeat until the number of records inside the incremental files exceeds 512 bytes. Even if the organization has taken no precautions to block full zone file transfers there may still be useful data inside the incremental zone file transfers. Changes and deletions from zone files can provide information about other software on targets. For example if the target organization decommissioned an old web server but left it in the DMZ to continue to act as an SSH server. The name change of that host might be the clue that we need to abuse the old web services that are still installed on that host.
By default dig will try to use TCP for all AXFR and IXFR operations, but the +notcp option forces it to use UDP if the version of dig you are running supports it.
After pillaging your targets DNS records be sure to list the way they ATTEMPTED to control DNS zone transfers as a finding. Instead of blocking TCP port 53 they should only allow zone transfers to occur with their designated primary, secondary and tertiary DNZ servers.
Tweets – @markbaggett
Join me and Ed Skoudis for SANS 560 Network Penetration Testing and Ethical Hacking vLive ! Starting January 10, 2012 (wow.. 2012 already) CLICK HERE for more information.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.