Friday, May 2, 2014

Learning about an organization through its DNS – Reconnaissance

Many organizations name their devices records based on references such as:
OS (Windows_DC), Role (rtr_1), Manufacturer (cisco_6500), Location (north), etc. or even a combination of these, eg. cisco_rtr_6500_ca. 

Because of the above information, if an attacker manages to gain access to the list of DNS entries, all devices within the organization and their likely roles can be immediately identified.

Let’s look at this in practice.

For this lab a CentOS 6.5 server (10.0.0.101) running Berkley Internet Name Domain (BIND) and a Windows 2012 server (10.0.0.105) running Microsoft DNS will be used. Our attacker will be a Kali (10.0.0.100) based system. 


As always, this traffic will also be captured for later analysis
 

[root@seuritynik_srv ~]# named –v
BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1

Since our attacker is Linux based, we will evaluate some of the various Linux commands which can be used to learn about the organization.


First let’s use the “host” command

For this to work, we must first configure our /etc/resolv.conf to point to the nameservers for the domain securitynik.lab

root@securitynik:~# echo "nameserver 10.0.0.101" > /etc/resolv.conf && cat /etc/resolv.conf 
nameserver 10.0.0.101

Now that we have our nameserver configured for the CentOS DNS Servers, let’s use the host command to see what we get.














As can be seen we were able to successfully grab all DNS records from the CentOS DNS Server.

Let’s target the Windows 2012 server
root@securitynik:~# echo "nameserver 10.0.0.105" > /etc/resolv.conf && cat /etc/resolv.conf 
nameserver 10.0.0.105












Once again, we were successful in retrieving all DNS records. 
In addition, as can be seen in both cases, the various DNS entries seems to suggest the roles of these devices.

Let’s “dig” a little – pun intended ?














Once again, using the dig command we were able to download the DNS records for both the BIND DNS Server and the Windows DNS server.

The Linux based version of the nslookup does not support zone transfers. This is the primary reason why it was not used in this example.

If using a Windows client to initiate the zone transfer the following can be done from the command prompt.
nslookup
set type=any
server 10.0.0.101
ls –d securitynik.lab

How to remediate this?
The good news is for Windows 2012 by default dns-transfers are allowed “Only to servers listed on the name server tab”.
However, if for one reason or the other your server is not currently configured this way and you have no need for zone transfers, you can disable all zone transfers by unchecking the “Allow Zone Transfers” under the properties of the zone or via the console using “dnscmd . /ZoneResetSecondaries securitynik.lab /NoXfr

For BIND the situation is a bit different. By default BIND allows zone transfers. However, the caveat is by default BIND only listens on 127.0.0.1. If your BIND is listening on other interfaces you can restrict zone transfers using the “allow-zone transfer” option. Eg. of these are as follows:
allow zone-transfer { any; }; # This option is basically what you get by default. This allows zone transfers to any host which is what we do not wish to have
allow zone-transfer { 10.0.0.105; }; # this will only allow zone transfers to 10.0.0.105
another option is to use “acl” to define the hosts which should be allowed to perform zone transfers
acl allowed_transfer_hosts { 10.0.0.105; };

Once the acl has been defined, we then use it as follows
allow zone-transfer { allowed_transfer_hosts; };

In the next post, we will analyze a zone transfer to see if we can identify this after the fact.

Additional Readings:

No comments:

Post a Comment