The idea of this tool is that you can run just about any program and/or copy files to/from the machine, say an ssh session, using DNS packets to/from the client. In other words, a workstation sitting on a network somewhere, behind the companies firewalls, IPS/IDS, AV, etc., etc. could communicate with a system on the Internet, using DNS packets. Thus completely bypassing the security that the company has setup. Certainly not something that a company would want to happen. Also hard to detect, since DNS queries are a common thing on a network.
You should know that from a attack/defend perspective, I am currently, much more of a defender than an attacker. That is to say, when I learn about tools like this, my brain starts to think “okay how do I defend against or stop this?”.
The answer in this case is that the clients (i.e. workstations/other internal devices) are not allowed to get information about any domain on the Internet. In other words any request from them for say www.google.com or www.cnn.com would get back a response from their DNS server(s) of does not exist, period the end. The internal DNS servers to the company would perform recursive DNS calls but only for the internal zone.
Then how do they reach the Internet for say www.cnn.com? The clients must use proxies. The proxy server(s) are allowed to talk with specific DNS servers inside the DMZ that would allow recursive queries from only the proxy servers and thus enable the proxy to fetch the data from www.cnn.com, for example.
Compared to say an Internet Cafe offering free WiFi service, such a corporate network would seem very restrictive and probably not considered “friendly” to the employees. On the other hand if I was the owner of the company or the CSO I’d sleep better at night. Defense in depth is something I learned early on in my days of information security and continue to refine.
Of course these same rules apply within the company as well. If a particular area needs additional protections, then it should treat the rest of the company just like the Internet and barricade itself off.
What do you think?
Ever since I wrote dnscat, I’ve been trying to think of ways to defend against it (I get asked that a lot — my answer is usually “bah, defense is for suckers”
). You way does sound promising, but I can’t help but think it wouldn’t work in the real world. I’d love to hear if you have any luck implementing that type of defense, though!
Ron
I admit this would probably be considered a radical idea in many corporate board rooms and data centers. On the other hand, I bet many banks and other financial institutions already run this way. As you know it is always a tradeoff between security and ease of use. It depends on the perceived value of what is being protected. A bank would be willing to live with this, I bet a company like twitter would not. I hear the trend is to move to more open perimeters and extranets and then I come across tools like dnscat and I think no way, the perimeter should get tighter.
My first thought of where this might fail would be on anything that has to look up reverse addresses. At one time, I tried giving my servers no DNS server to prevent this type of attack, but certain things (like ssh) became sloooow — I eventually realized that it was trying to do reverse lookups on my ip address and failing. I’m sure you could track down every instance where this type of thing happened and turn it off, but that might be a lot of effort.
One of my customers has been asking me about how to prevent dnscat from working (“You wrote the tool, now find me a solution!”) — I passed this on to him, and he thinks it’s an interesting idea.
Reverse should work just fine. A server/workstation sitting inside a corporate network (not in the DMZ), should never see an inbound connection from an IP space that is is not under corporate control. A reverse lookup on the incoming connections IP should work, as in 10.1.168.192.in-addr.arpa.
A server sitting in the DMZ is different. If the company allowed inbound SSH to a server, then either disable reverse lookups or accept slower login times. I would have no problem disabling reverse lookups in this case. Plus I would certainly hope that once logged into the box, other rules would severely restrict further jumping off, including no external DNS queries.
At some point a company has to trust its employees not to cause harm to the company. Employees with the right level of permissions could cause harm, mitigating those means RBAC. Which is different than a compromised device, both of which need to considered and planned for.
True @ never seeing an external address on the inside.
One thing that inevitably happens, I’ve noticed, is a few “bypass” rules for sites that don’t play well with proxies. The most common ones, it seems, are auto-updaters for applications, or any kind of thick applications. Although the domain:ip can be hardcoded into your DNS server in addition to poking a small hole in the firewall, that’s extra maintenance.
And yes, that’s bad practice.. but that’s the real world
Again, I don’t think it’s an end all situation. Your solution is an interesting one, for sure.
Sorry for the double post, but I find this funny:
If people start implementing your idea, I’m going to start reading the local proxy server and sending HTTP CONNECT requests to it, with my dnscat domains. My dnscat server will return NXDOMAIN so the proxy connection will never go through. But I’ll still get the data out
This wouldn’t be a two-way shell, though, so it’s still a win overall. But I could grab your data, at least!
No worries. I should have mentioned in my post, if I step back and look at the tool itself, this is a very nice hack, in the classic sense of the word. Talk about using a protocol in a way for which it was never designed or intended, nice job!
Certainly proxies are not an end all solution for everything. While they do mitigate risks, they not without risk. I’ll have to think your proposed change to see how I would deal with it.
Thanks! I’m not disagreeing at all with what you’re saying — after all, I *am* working on the side that has to defend against this stuff. I’m planning on \doing a SANS504 paper on DNS backdoors, and I need to figure out some countermeasures. So far, the idea behind using a Web proxy is the best countermeasure I’ve heard. I’ll definitely reference this when I start writing my paper.
LOL, I had a GCIH (expired now, but plan to renew) and also have a GCFW. Someday want a GSE, but money and time are limiting factors right now. Reference the http-connect thing, only domains listed in file X on the DNS server are allowed to be queried for. Obviously a management nightmare to maintain, etc., but it would work. The proxy could try to lookup evil-domain but since evil-domain is not listed in the allowed list on the DNS server, no query will leave the network.
When I get time I want to look at dnscat on the wire.