Are you Snoopable?!
Rick Wisser //
All right, you’ve taken all the precautions related to your network. You have lockout controls in place, you use awesome password policies (20 characters with uppercase, lowercase, special characters, and wingdings…. ) Two factor is everywhere, web apps are locked down, cross-site-scripting and SQL injection are not viable. You are feeling good about the security of your infrastructure.
So why may you still be worried (other than you are a systems admin)? It seems like Social Engineering is becoming the new attack vector these days. Why? Because it is easier to find out information on specific people in your organization and target them for valuable information as opposed to getting it from the network. Eventually, everyone will have networks so secure that you don’t need to worry about them any more (Right ☺)… Here at BHIS, we could only hope so, but in the meantime, we will keep pumping out blog posts and helping find the vulnerabilities.
You may wonder where I am going with this. Well, sometimes we overlook little things like Domain Name Server (DNS) Cache Snooping.
Many non-technical readers may wonder what the heck a DNS is and what it does?
Without getting too technical, a DNS is utilized to translate human-readable format to the machine language, in this case, the IP address of the system you are trying to reach. For example, if you type www.peanuts.com into your browser the request will be sent to a DNS server that searches for the record (IP) that goes with www.peanuts.com. The record for this example would translate to an IP address of 184.108.40.206. You can see how typing in an easy to remember name is easier than typing in the IP address. Many have used the analogy of a phone book for correlating the naming convention with the IP address of the system.
Several organizations have and manage their own Domain Name Server(s) depending on the number of IPs that they have and if they are frequently changing machines, hostnames or IP addresses. It is easier to manage changes to the DNS locally than having to fax or fill out paperwork to a third party to make changes. If your organization manages its own DNS then this blog would be intended for you.
DNS uses recursive and non-recursive lookups depending if the site has been cached (stored locally) or not.
- Recursive – This type of lookup is utilized if the website is not known by your DNS. The Domain Naming Server will have to poll other servers to get the information to resolve the website name to an IP address and route your traffic correctly
- Non-Recursive – This type of lookup is stored in the cache of your Domain Name Server so it is easily accessed without going out and polling other servers, as it would have to do with a Recursive lookup
DNS cache snooping is used by attackers to gather information about your organization’s browsing habits. This information can be utilized to plan an attack against your company, such as email phishing or spearfishing campaigns. This can also disclose sensitive information such as financial institutions that have been visited recently or other sensitive websites that a company might not want to be public knowledge.
Depending on how your DNS server(s) is configured and sitting on the network may determine the level of risk. For example, if you are sitting inside your network, your Domain Name Server may allow caching of websites for people that are on the local network and not for those external to your network. It is always recommend testing from outside of your network to determine if cache snooping is valid from public spaces. Although cache snooping may be realized within your network, the risk would be lower since an attacker would have to have access from within your network before they are able to snoop.
A simple test is to use Nmap with a dns-snoop-cache.nse script. Below I have run the script to on the Google DNS at 220.127.116.11 to validate that it is caching websites. By default the Nmap command utilized is a non-recursive lookup, therefore the output relates to those sites that are cached on the server.
As you can see from the output above there are 61 of 100 of the domains cached at Googles 18.104.22.168 DNS.
I should also point out that Nmap uses a pre-configured set of the top 100 domains to check against for determining if they are cached or not. You can supply the list of domains if you would like and thus make it more specific to your organization. By utilizing an argument along with the Nmap command to specify the domains you would like to check. The argument is:
The screenshot below demonstrates an output of using specific domains or hosts.
Supplying Specific Domains
If you want to find out which sites have been visited recently you can use the argument ‘dns-cache-snoop.mode=timed’ this can only run reliably once since it also caches to the server.
Using Timing Argument with Nmap
You can see that the most recent sites visited are a little different than when the Nmap command was run without the ‘dns-cache-snoop.mode=timed’ argument was included.
Depending on how your DNS server is set-up you may not get any information. It also may depend on if your organization is blocking certain domains. Many organizations will block the top 100 domains since a majority of them are related to social or shopping sites. If this is the case you might want to check for specific domains such as wellfargo.com or chase.com. You can also go to a specific site on your network and then check to see if you DNS has cached it.
There are other vulnerabilities related to DNS, such as cache poisoning, Distributed Denial of Service (DDoS) or DNS amplification attacks. I will save these for future discussion since for many DNS is not as exciting as things like cute kitty videos that we all love.
Bonus Points – What show is the image of in this blog and what is the character’s name? Tweet us @BHinfoSecurity if you know the answer!
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
June 21, 2017 @ 8:44 am
not 504.201.160.175 bu 22.214.171.124
June 27, 2017 @ 4:15 pm
Thanks! We’ve updated this.