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.
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.
And what to you propose, Troll!
I won't run DJB's authoritative server as it violates the spec by not answering queries that have the recursive bit set. (The spec doesn't require honoring the bit, just answering the query out of what is knows would do).
... 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...
Frankly, yes. The basic concepts of a DNS server are fairly straightforward, but as demonstrated by this attack, the devil is in the details. This attack uses reasonably advanced cryptanalysis, and exploits the predictable behaviour of DNS clients. I suspect that this attack would also have been mitigated by the use of DNSSEC, but the roll-out of that has been held up for years - and DNSSEC itself introduces even more cryptographic complexity.
OpenBSD's patched and native Bind9 is immune to this attack and has been for many years.
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!
I bet there's a way to incorporate some qrbgs randomness to improve the security.
OpenBSD's patched and native Bind9 is immune to this attack and has been for many years.
But this article isn't about the OpenBSD stock, or about the DJB stock, it's about the -current version. Running BIND is like running sendmail... pretty stupid unless you *really* know what you're doing.
Why UNIX?
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.
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
OpenBSD++
ISC-- The patch would probably be in BSD licence. I don't know what licence the ISC use. Maybe I'll look sometime.
Why UNIX?
Neat trick, considering bind9 is only 7 years old.
A large number of programmers can make minor modifications to small software applications.
A medium number of programmers can make minor modifications to medium-sized software applications.
Very few programmers can make any sort of modification to very large software applications. Very, very few.
Bind is a very large, complex piece of software. A good portion of that complexity is due to poor documentation and badly designed algorithms (a problem I've had with bind from the first release on through today), but at this point the majority of the complexity is due to feature creep. I still use bind simply because I do not have the desire to write a replacement for it, and because the only other really good DNS package has a copyright and licence on it that makes it virtually unusable. Software gets stale as it gets older... if I can't keep software up to date after the original author has lost interest then I have no interest incorporating said software, no matter how good it is.
-Matt
I personally like my DNS servers to follow the relevent standards personally.
Of course I could go ahead and run the recommended DJB configuring using rsync + openssh to propogate zone files. Then I would avoid the 10 vulnerabilities filed against BIND9 over it's seven year life span, but open myself to the 40 or so against OpenSSH, 30 or so against OpenSSL, and 10 or so against rsync.
I'm pretty sure you also use gcc, then why not use powerdns-recursor ? I'm pretty sure it has the same license.
:-)
Ohh, euh... I think I know what the problem is.
Please, please, please, could you implement a good swapcontext and getcontext
implementation for the BSD's ?
New things are always on the horizon
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.
Yes, universal deployment of DNSSEC would have completely defeated this attack.
"Of course I could go ahead and run the recommended DJB configuring using rsync + openssh to propogate zone files. Then I would avoid the 10 vulnerabilities filed against BIND9 over it's seven year life span, but open myself to the 40 or so against OpenSSH, 30 or so against OpenSSL, and 10 or so against rsync"
Looks good on paper, but in reality how many bugs have *ss* caused in real world name service? Zero.
How many compromised nameservers have there been because of bugs in bind? Non-zero.
Need Mercedes parts ?
You seriously think there have never been real world compromises from OpenSSL and OpenSSH? Absolutely none?
If you look at the specifics of the vulnerabilities, none of the ones discovered so far in the BIND9 codebase have been privilege escalation. Mostly DoS, a couple cache poisons, one client side vulnerability in the backwards compatability stub resolver that's disabled by default, and a case of some leaked environmental variables. In the case of *ss* there are numberous code execution bugs. And yes, some exploits in the wild that led to real compromises.
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.
unless of course you are of the opinion that BSD is dying.
ZERO ZERO ONE ZERO ONE ZERO ONE ONE! Just brushing up for my next big invention: Ethernet over Voice (EoV)
That's goatse. And that will teach me to look at random ip addresses ...