Slashdot Mirror
Network Attacks Via DNS
Iphtashu Fitz writes "Without DNS the internet wouldn't be all that useful. Despite being a ubiquitous part of the internet it is overlooked by many as a potential security hole. At this weekends Defcon 12 conference in Las Vegas, security researcher Dan Kaminsky warned that DNS can open up seemingly secure networks to attack. Because most firewalls and other security devices treat DNS requests as harmless it provides an excellent conduit for transferring covert data in and out of otherwise protected systems. At Defcon, Kaminsky demonstrated some software that allows a server to act as a communications hub using DNS. This let him transmit instant messages and even audio streams over an encrypted connection carried by spoofed DNS requests."
"Because the data looked like typical DNS traffic it wouldn't be detected or logged by firewalls or intrusion detection systems. He also pointed out that monitoring DNS could help in other unrelated ways: because the recent MSBlast worm did lookups on windowsupdate.com infected machines could have been detected by simply monitoring DNS server logs."
nessus has been pointing this out as a security hole in it's scan results for at least 3 months now...
Layering services over dns has been a discussed topic in books / seminars for at least a decade already.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
An interesting property of DNS is that there are servers all over the net which will happily relay your message. Even if your only connection to the net is through application level proxies, you probably have a local DNS resolver. That's all you need. No packet has to traverse the firewall directly.
They may have used spoofed DNS packets just to bypass a firewall, but information can also be tunneled in real DNS packets, so even if you only allow DNS to/from certain servers, you're still not safe from this leak.
Here's a link:
0
http://cgi.nessus.org/plugins/dump.php3?id=1158
>ufortunately, djbdns is not open-source.
Incorrect, it is open source.
It isn't GPL.
There's a big difference.
>Until a true open source alternative to BIND appears, we're stuck with it.
By "true alternative" do you mean it has to be GPLable?
Get real. djbdns' source is 100% available for you to look at and patch to your hearts content. If you find an error, send a fix to DJB and he'll add it after review. He'll even give you $500 as a reward for your hard work. Find me a GPL program that makes an offer like that.
Now, if he doesn't like your patch, you can post the patch on the internet. You can even put it alongside the source. You can even make an autopatch program that will patch djbdns during make so that dumb users can handle the process
For the disbelievers, here's the source code.
Here's bernstein's statement about the freedom of his software. Feel free to print it out and sign it if you're insane on the idea he can revoke your license.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
No doubt you'll be on +5 informative soon for this 15 year old information.
BIND hasn't been vulnerable to DNS Poisoning since about version 4.8 unless you set it up allowing external updates from 0.0.0.0 (have to be specified as they're not allowed by default).
And djbdns is about as useful as a condom machine in the vatican for anyone needing more than a dns cache for a LAN.
Here's a link:
http://cgi.nessus.org/plugins/dump.php3?id=11580
And here's a clickable hyperlink (you may have seen these before):
http://cgi.nessus.org/plugins/dump.php3?id=11580
Seriously, it's not that hard! In Slashdot all you have to do is put <URL: at the start and > at the end.
That is why any GOOD sysadmin will set up the system so that there is a single DNS server for the plant, and that server and that server alone is allowed to send and receive DNS packets to the greater Internet - all other machines are to use the local DNS server.
Not only does this GREATLY reduce the amount of DNS traffic a shop produces (by caching all requests locally) it helps prevent this sort of foolishness by requiring all packets to be well formed DNS packets - else the server drops them.
Then, you can block any client that makes more than a few requests a second.
Yes, it is easier to set up a firewall to be very porous to outbound traffic, but it is more secure to deny all direct access, and force clients to run through proxies for the various services.
www.eFax.com are spammers
OK, let me repeat.
:-)
Throwing arbitrary data in DNS -- NOT a big deal.
Even doing network tunneling over DNS -- ALSO not that big a deal; NSTX has been doing this for a while.
DNS radio is new. By segmenting audio into small chunks, we actually get universal caching of the streaming signal -- a functionality we've never really had before. Generally, audio broadcast over the Internet falls apart after a few thousand users. Based on this ring-buffer-into-BIND architecture, combined with the utterly minimal bandwidth load of Speex, we should be able to host audio for a much greater number of listeners.
The entire suite of incoming attacks to firewalls are also new. DNS trusts the hierarchy to tell it the next hop to its target name; since I can acquire second level domains in the hierarchy for minimal cost, it's trivial for me to insert arbitrary destinations along the DNS route path. In technical terms, whenever a recursing resolver comes to my name server to resolve a name, rather than providing an answer, I can redirect that request to another, supposedly authoritative server. That server can be at any address -- even one I cannot IP route to -- but if the resolver communicating with me can route to that address (say 10.0.1.11) my communication will reach that host. If there's an SSH over DNS daemon running on 10.0.1.11, I've now achieved incoming connectivity to the network of my choice, completely bypassing firewalls and a trojan's need to poll.
Recursion on dual hosted interfaces is not even necessary. There are large numbers of applications that, upon receiving untrusted traffic, execute DNS name lookups. Most commonly, they are reverse PTR lookups, but occasionally there are other types (MX from mail servers, most notably) that can be easily induced. When they are induced, the hierarchy is followed. When the hierarchy is followed, the attacks previously discussed start working. In practice, this means an IDS triggers the DNS server to start proxying traffic between an external attacker host and an internal trojaned machine. Nasty.
There's some other stuff -- check out the slides and the code -- but long story short, there's some new stuff out
--Dan
Most trojans need to poll the outside world periodically, to determine whether they have a new set of operations to execute. With this approach, no polling is necessary -- there's an open pipe _into_ the organization, and the trojan can remain perfectly silent.
--Dan