Slashdot Mirror
"DNS Forgery Pharming" Attack Against BIND 9
Monley writes "Help Net Security is running a story about a severe flaw in BIND's implementation that allows fraudsters to efficiently predict generated random numbers without the need to control the route between the user and the DNS server. (Here are HTML and PDF versions of the paper.) Using this vulnerability, fraudsters can remotely forge DNS responses and direct users to fraudulent websites, which can steal the user's sign-in credentials and do other mischief. The flaw was discovered by security researcher and Trusteer's CTO, Amit Klein." The ISC has released a patch to BIND 9.
anyone still running BIND should just cut their feet off..
tinydns for ya'll niggaz in ya right mizzinds
btw, frist!
Maybe the headline should read,"Exploit which bored college students figured out fifteen years ago is finally released to the mainstream".
the NPG electrode was replaced with carbon blac
Since when is a severe flaw in BIND's implementation news?
Proud member of the Weirdo-American community.
... the CTO's underlings doing the hard work and the CTO gets the credit.
IMHO, the story wouldn't garner any interest whatsoever if the summary did NOT include mentioning the CTO. Look at the grief your average employee get when they publish an exploit.
Got Trader Joe's? friendwich.com RSS feeds work now!
Come on, whoever marked this as troll has no idea of the history of BIND, or how many times many of us have had to patch BIND over the last ten years. Consider this: BIND is the only server that I've ever seen a distro package so as to be easily chrooted. Why do you suppose that is?
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
The TFA recommends using Trusteer's product to defeat this attack:
So, to recap. Vendor discovers a flaw and recommends their product.Film at 11:00.
It must have been something you assimilated. . . .
Say it isn't so!
Isn't it part of the INSTALL doc to run it in a VM/Jail/Chroot?
Bind was and is a mess. The patch is to use something else....
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Only clueless (windows) admins will install and run bind nowayday. There you go...
Hmmm. Is a DNS server really that complicated?
Also consider the dhclient shipped with at least all Red Hat-based installs.
Fragile software, non-standard cmdline option parsing, requires certain kernel parameter set (socket filtering for UDP) and is slow and quite big (for its functionality). Media-disconnects or booting without network cable is not handled (the latter resulting in an unreachable box even when the cable is re-attached).
Don't get me even started.
What about this one:
y /935964.mspx
http://www.microsoft.com/technet/security/advisor
Punk.
Bind has been around since the dawn of Vint Cerf's IP, but it has been redesigned and rewritten several times. The RFC that says replies go via UDP make it a security risk, but also make the net work better.
In 2007, where 1000,s of "researchers" spend their lives trying to break the Internet.... This stuff happens. BIND, SendMail and classic solutions are attacked. Amazingly they hold up better than Windows!
nice change of terminology there. quite refreshing, fraudsters . .. . .
If you're interested in facts I'll tell you what they are and I'll give you sources - Chomsky on The Big Idea
Last line in the article:
"Mutual authentication solutions, such as Trusteer's Rapport, which strongly authenticates the destination website and prevents access to unauthenticated websites, can defeat the attack."
Seriously, how feasible is this attack against the common web surfer?
I bet there's a way to incorporate some qrbgs randomness to improve the security.
I've been using djbdns for years. It takes some getting used to if you're coming from BIND-land but it's worth making the effort.
no longer working for cnet
Moron,
It is related to MS DNS -- a SYSTEM you said did not have any vulnerabilities.
It's not hard to get a connection and a rooted machine in somebody's internal network. Also -- I can't think of anybody that would use MS DNS server outside on the Internet. If you do then that confirms my opinion of you.
If only BIND were open source, this kind of stuff would never happen.
Oh, wait...
Why the hell is bind trying to implement its own random number generator? It's a piece of junk compared to the random numbers modern BSD OS's generate via libc.
-Matt
At my organization, I've configured our DNS as split-split. Split-split means that the outside world only gets nonrecursive advertisements of our authoritative domains, separate servers are configured for the inside to do recursive queries(i.e. forwarders), and a last set is for our user land dns servers which forward to our recursive nameservers. Only these dns servers are allowed to talk to the forwarders, which sit in their own DMZ.
Now, my servers may have the same vulnerability as yours, but the risk of it being exploited is much lower. This buys me time to patch any given flaw without panicking too much.
To those that knock BIND, for its lack of security: if a system (i.e a group os servers meant to provide a service) is designed and then configured securely, even when flaws are discovered, the chances of getting hit can be vastly reduced. Yes, there are more secure versions of DNS out there, but BIND is the most popular. DJBDNS has a great reputation, but my solution works just fine and I don't have to learn yet another version of something that when passed on to the next person will go on neglected for years.
Lets see, it has to be GPLed or BSDed, run on every platform, be insanely robust, free as in beer, tested so thoroughly that it ought to make the law of gravity look like shaky science. So, based on those criteria, what DNS software could hold up? Just wondering. Peace, V
Jon Postel, R.I.P. You are missed.
Shouldn't login into a web site be bi-directional? not only a user logs in a web site but the web site should log in a user by submitting to the user a password (let's name this password back-password).
The login sequence should be:
1) user submits his username.
2) site submits the back-password.
3) if back-password is correct, user submits his password.
By using bi-directional login, if the site is spoofed, the login process will fail, unless the spoofed site knows the back-password.
After login, communication should be encrypted so as that no 3rd party can eavesdrop on the communications.
Point all A records to 65.98.92.48!
ISC use the ISC license, which is basically a 2 clause BSD license. OpenBSD also uses the ISC license. The patch is not accepted because its a patch to use the operating system supplied RNG instead of including a worthless broken one. ISC is more concerned about their software running on operating systems that suck than they are about it being secure on operating systems that don't suck.
You need to be inside, or need to bypass the firewall or other controls.
He was talking about a split DNS server configuration.
In my experience this is where you have:
1) External DNS server(s)
2) Internal DNS server(s)
Configuration A
(where the internal DNS server is allowed to do DNS queries directly)
An External DNS server provides authoritative replies for the domains it is Authoritative for to externals.
An External DNS server does NO recursive queries for anyone.
An Internal DNS server only does recursive queries for all internal clients.
An Internal DNS server does those queries directly.
An Internal DNS server may provide authoritative replies to internals for the internal-only domains it is authoritative for.
Configuration B
(where the Internal server has no direct access to the outside world - all requests have to be "proxied/forwarded" via an external DNS server)
An External DNS server provides authoritative replies for its own names to externals.
An External DNS server only does recursive queries for the Internal DNS server.
An Internal DNS server does recursive queries for all internal clients.
An Internal DNS server forwards the queries to an External DNS server (if paranoid, it may be one just for that purpose that does not even answer external queries).
An Internal DNS server may provide authoritative replies to internals for the internal-only domains it is authoritative for.
As you can see, you can't really pollute the External DNS server from outside, especially in Configuration A (where the external server doesn't really care about making queries) or a Paranoid Config B (where it's a different external server involved). And you should not be able to even reach the Internal DNS server from outside.
Note: both the internal and external DNS servers may be authoritative for say www.thecompany.com (and thecompany.com), but resolve those to different IP addresses. So outsiders might get one site. Whereas insiders might see something else. And intranet.thecompany.com and other internal names might only exist on the internal DNS server, and not exist on the external DNS server. I believe this is good practice.
Note #2: In a fairly secure network config, NONE of the clients get direct access out, not even for DNS queries - they all have to use the DNS server or even a proxy. So it will be a lot rarer to have outsiders complain about your malware infested clients "attacking them" even if someone inadvertently brings one in.
Let's say this occurs with a spoofed site, this is what could happen:
1) user submits his username to spoofing site
2) spoofing site connects to actual site and submits user name
3) actual site submits the back-password to spoofing site
4) spoofing site submits back-password to user
5) user will see the same back-password he saw if he connected to the actual site
Why not just use SSL? How browsers guarantee a site using SSL is that there is a public and private key. Everyone has the public key but the private key is kept secret by the site. The public key can be used to validate that the corresponding private key was used to encrypt or sign data. Now you would think that a site could spoof SSL by generating their own public key and private key, and giving the user their public key instead of the actual site's public key. This is prevented by having certificate authorities. Sites submit a signing request to a certificate authority based on their public and private key. The certificate authority then uses their own private key to sign the request. The Certificate Authority's public key that the user uses to verify the signature is incorporated into your browser.
Basically, let's say John is talking to Mary. Mary goes to Andrew to vouch for her. John trusts Andrew, he's a good friend. Mary tells John who she is, and John verifies her identity with Andrew.
BIND 9 was a complete rewrite, and, unlike previous packages called "BIND", has a respectable security track record.
e _here_) instead" really aren't up on current technology in the DNS-software space.
These troglodytes who crawl out of the woodwork whenever there is a BIND-related security alert and mutter "who runs BIND anyway? just run a secure package like djbdns (or _insert_name_of_favorite_non-reference_DNS_packag
As for the references to chroot'ing, BIND has had built-in chroot capability for years now. Any distro that doesn't take advantage of that capability has only itself to blame.
That's goatse. And that will teach me to look at random ip addresses ...