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
Bind9 isn't vulnerable to that. Heck, I doubt even bind8 was.. sounds like a pretty lame attack.
>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
That's what people call "shared source". Open Source requires that you can distribute modifications of the source. Bernstein doesn't allow that, so consequentially djbdns is not Open Source. This may or may not make it less valuable to you, but don't lie about the facts to lure others into misevaluating the situation.
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.
The title of the post is misleading. DNS can't be actually used to attack a network, only to slip sensitive data by firewalls.
The $500 guantee is worthless. How many hours do you think it takes to audit the djbdns source code? Anything more than 50, and you'd only need to make $10 an hour at your current job to make it a very unprofitable way to spend your time.
(Also: Who judges the "entrants" for the $500 prize? That's right, DJB does, and there are no formal rules as to exactly what qualifies as a security bug).
HAND.
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
Really? Last I checked X copy works in all web browsers (even graphical links!)
Mozilla: Select the url, middle click into a new tab. Bam.
Konqueror: Ibid.
Links (graphical): Select the url, hit g, middle click
The previous sig has been removed due to
Yes, for default installation only
It is quite simple and SHOULD be turned off
It is a mere matter of unchecking one box and setting up explicit rules for your local DNS server to comminicate to its external DNS resolovers
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
Recursive lookup support isn't required to achieve incoming connectivity (see induced lookups), and being able to do lookups against the outside world isn't identified by anyone as a risk.
--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
I think it may be worth the firewall's while to check if the DNS packets are in the right format - for example if the domain name in the request is ghjj!!&^ then one should frown ! I don't what kind of load this would mean for the firewall, though
Well the problem with that is you just mearly create an 'arms race' as it were. The format of the data could be ANYTHING. It could even look legit. For example Blah.blah.BLAH.somwhere.com could be an encode for some data. You can encode quite a bit of data into a request.
Even if you speed limit things you still are open to attack. As maybe I need to send 10k of data out I could 'dribble' the data over a couple of days. Would you even notice it then?
This is basic information hiding at its best. You will always be chasing it.
I was poking around the the FTP site that has nstx and I noticed migr. It's a hack to migrate processes between systems. The migration is not completely transparent to the migrated process since it will lose filepoint locations at least. It appears to reload the migrated process by installing it as a SEGV handler with signal stack and then unmapping most of the loader causing a segfault which starts the migrated process.