The Backstory of the Kaminsky Bug 122
Ant recommends a Wired piece on the background story of the Kaminsky DNS bug and its (temporary) resolution, decreasing the odds of a successful breach from 1 in 2^16 to 1 in 2^32. We've discussed this uber-hole a number of times. Wired follows the story arc from before Kaminsky's discovery of the bug to his public presentation of it in Las Vegas.
Slashdotted (Score:4, Interesting)
The site linked in the article is indeed slashdotted, but the bug in question has been overhyped in the media and, although it must be fixed to prevent future problems, it currently does not present a big obstacle for the current Internet...
Re:Slashdotted (Score:5, Interesting)
No kidding it has been overhyped.
From TFA The vulnerability gave him the power to transfer millions out of bank accounts worldwide.
How so?! I don't have millions, but I do run djbdns...
Re: (Score:3, Insightful)
Also From TFA, "Or, for the sheer geeky joy of it, he could reroute all of .com into his laptop, the digital equivalent of channeling the Mississippi into a bathtub." ... right.
Re:Slashdotted (Score:5, Insightful)
Re:Slashdotted (Score:4, Insightful)
I also liked A good hacker could reroute email, reset passwords, and transfer money out of accounts quickly.
Any financial institution that resets a password based solely off of an e-mail deserves to be raped. Most do forgotten password link -> sends e-mail to reset the pass with a unique URL -> user clicks on unique URL and answers additional verification questions
Re:Slashdotted (Score:5, Insightful)
Any financial institution that resets a password based solely off of an e-mail deserves to be raped. Most do forgotten password link -> sends e-mail to reset the pass with a unique URL -> user clicks on unique URL and answers additional verification questions
Right, but that's not the problem here. You don't even need the "recover password" feature. If a website that looks like the bank and has the url of the bank, most users would just buy it and type in their username and password. Or you could easily set up a proxy kind of webserver to make it look like everything is working as usual.
Re: (Score:2)
Re: (Score:2)
dangers of e-mail being delivered to the wrong host
If you can cause the bank's email being delivered to your own server, you can get an RapidSSL [rapidssl.com] certificate for the bank delivered to you, so as to avoid those pesky "bad certificate" warnings that would otherwise pop up on your mark's computer if they visited your phishing site or password-logging proxy. Technically, this is a "domain-validated" certificate, and an astute surfer could still tell the difference (it doesn't have the name of the organization in), but who manually doublechecks certificates that
Re: (Score:2, Insightful)
Or you could easily set up a proxy kind of webserver to make it look like everything is working as usual.
This possibility has always been there. The matter of a MITM proxy-based atttack is not what is in question here, it is the possibility of a DNS poisoning attack which would redirect the user to a non valid website, which is appearing as valid, and the additional verification questions on sensitive websites (i.e. banks and such) would prevent this from happening (at least from a DNS redirect of the email standpoint).
Re:Slashdotted (Score:4, Insightful)
If a website that looks like the bank and has the url of the bank, most users would just buy it and type in their username and password.
Which is why banks should do as PayPal does. If I ever see anything under the URL of http://www.paypal.com, I'll immediately suspect foul play, because PayPal uses https://www.paypal.com for everything.
In fact, it makes me wonder if a whitelist might be better than a blacklist, for phishing -- if a page looks suspiciously like my bank's page, but doesn't have the exact URL I'm expecting (https and all), raise a giant warning. No need to expose private info to Google, just a simple Firefox extension would do the trick...
Re: (Score:2, Insightful)
Right... but somebody MITM's both the CA and PayPal, they can run an encrypted server "at" https://www.paypal.com/ [paypal.com] -- and you just got phished, despite whatever precautions you thought would save you.
Re: (Score:3, Informative)
Right... but somebody MITM's both the CA and PayPal
They would have to MITM Mozilla and Opera first, as the CAs' root certificates get distributed with the browser.
Re: (Score:2)
All sane browsers and OSes that I know of distribute root certificates ahead of time, only to be updated via already-secure channels. The only way to make this work is to subvert that chain somewhere -- either convince an SSL vendor to trust that you are paypal, or somehow convince one of Microsoft, Apple, Mozilla, Opera, etc to distribute your new cert.
The first seems unlikely. You could use RapidSSL, in which case I'd be surprised and concerned to see the green bar go away, and I'd likely check my connect
Re: (Score:2)
Yahoo! has a nice login verification image that the user chooses that displays near the login credentials. If the image you chose isn't displayed, you're on a forged page.
Re: (Score:2)
The additional verification questions are ridiculously easy:
- click "I forget my password"
- capture that email using the Kaminsky's DNS error by pretending to be Customer@xyz.com
- click on emails' weblink
- answer "What is your mother's maiden name?" and then reset password to whatever.
- start withdrawing money from hacked account.
Repeat over-and-over until you have a few million withdrawn and then quietly retire. "The beauty of the Kaminsky attack, as it was now known, was that it left little trace.
Well, yeah. (Score:2)
It's a bit depressing how nobody takes the security implications of the internet seriously, and acts surprised when they're reminded of them.
Email is not secure. Using SSL for your POP/SMTP/IMAP connections secures your login to the server, but the mail itself is still transmitted in the clear. And people act surprised when you tell them that people can and likely do scan their email?
Then again, given that our financial institutions actively train their users to ignore security indicators [mail-archive.com] (a very exploitabl [cr.yp.to]
Re: (Score:2)
I like your ideal world, but it's become a bear at my small business to teach people how to get Firefox to accept the self-signed SSL certs on our employee-only applications. Their new warning roadblock is annoying.
I use SSL to make it secure, but because I don't shell out to the major CAs on something that no customers use and where self-signed should be good enough, it is frustrating (and I am talking about when they use machines that I don't control).
I do wish that most e-mail clients, including web,
Re: (Score:1)
Is there no better way to get those certs approved?
Is it possible to install Firefox with your own CA cert? Or maybe the employees install their own Firefox at your site?
Re: (Score:3, Informative)
The idea was that you'd target individual ISP or Enterprise name servers, which would be trivially reachable via a simple ad network. You'd hit com, then use basic caching to grab what you liked.
Re: (Score:2)
If that is true, I am even more terrified than I was for the safety and security of our banks.
You're telling me none of these banks properly implemented SSL? It never occurred to any of them to educate their users, and thus make their uber-expensive SSL certificates have a point?
Re: (Score:2, Insightful)
It never occurred to any of them to educate their users...
Both secure websites AND browsers have been educating users on security since the early days of the Internet. Nobody can stop a stupid and/or ignorant user from being redirected and not realizing that SSL is not implemented or invalid. SSL is properly implemented, however, the attack in question was redirecting the DNS. For instance, you create your own website and your own certifications and then trick the DNS into thinking your site is from Verisign and was created by them as well (since the source addre
Re: (Score:2)
For instance, you create your own website and your own certifications and then trick the DNS into thinking your site is from Verisign and was created by them as well (since the source address would be the same according to DNS).
Which would still require you to update Verisign's root certificate, which still requires you to have Verisign's old root certificate key.
If not, well, you're popping up a security notice, which will be very difficult to get past in Firefox.
Re: (Score:2)
Re: (Score:3, Insightful)
It's always traceable, but the answer in short is to use proxies. If somebody steals from a bank in the US and routes it through Sweden, some anti-US countries, and then China to boot, do you think everyone will be so willing to help the US government? Probably not. And of course, you could do the same to your IP address through proxies.
Re: (Score:2)
how do you transfer all that money without it being traceable
Money mules. You pretend that you are operating a business in Russia, and hire "agents" in the US or Europe (the "money mules") to collect payments from customers, and forward them to you via Western Union.
In reality, the "customers" are your victims. Rather than wiring the money directly to your own account, you wire them to your mules, who collect and send it to you via Western Union. Western Union is untracable, as you can collect the money using a pre-agreed password, without showing any kind of id.
A
Re: (Score:1)
Western Union is untracable, as you can collect the money using a pre-agreed password, without showing any kind of id.
Not true. Last (and only) time I used it, I was required to provide an ID. And so was the recipient of the transfer. The password was an extra security.
Re: (Score:2)
Re: (Score:2)
Not true. Last (and only) time I used it, I was required to provide an ID. And so was the recipient of the transfer. The password was an extra security.
The option used to be available, and probably security was tightened in response to exactly these kinds of frauds. In any case, this fraud is sufficiently real that Western Union themselves warn about it [westernunion.com].
Re: (Score:2)
How many people would blindly type in their password without looking for the nice little lock.
Shouldn't be too hard to write a Firefox extension which does exactly that -- warn you when you seem to be attempting to login to your bank, on a site that isn't the exact same URL as your bank.
Re: (Score:2)
To answer my own question, It looks like TFA mentions SSL, in a roundabout way:
But not anymore. Kaminsky's exploit would allow an attacker to redirect VeriSign's Web traffic to an exact functioning replica of the VeriSign site. The hacker could then offer his own encryption, which, of course, he could unlock later. Unsuspecting vendors would install the encryption and think themselves safe and ready for business.
In other words, you're telling me that it's worse -- even VeriSign doesn't know how to use SSL properly. You'd think, if you were downloading a new certificate, that you'd get it via SSL?
But thanks to journalists trying to dumb this down, I don't even know whether they're talking about SSL, let alone certificate distribution -- there are just some vague references to "encryption".
And then there is the part about catching return e
Re: (Score:3, Interesting)
In other words, you're telling me that it's worse -- even VeriSign doesn't know how to use SSL properly. You'd think, if you were downloading a new certificate, that you'd get it via SSL?
Encryption of the certificate is not the problem... the problem is el-cheapo "domain-validated" certification authorities [rapidssl.com] whose only "proof of domain ownership" is your ability to receive email at root@yourtarget.com and a phone number (any phone number will do). If you can spoof DNS so that this email really goes to your computer, and if you know where to buy a prepaid mobile plan, you can get a "valid" certificate for yourtarget.com .
It's a little bit like identity theft: rather than emptying your existi
Re: (Score:2)
ArsenneLupin, this topic must be right up your alley, since you've stolen your name from a master thief. :)
I was going to say, don't browsers have copies of the root certificates locally, and require a chain of signatures from them to anything they're going to accept without complaint. But I didn't realize that one could potentially get another cert for a domain without anyone checking with the people who have the first cert.
Now I understand how the pieces could fit together to play man-in
You're correct, but that's not the vulnerability. (Score:2)
No bank is going to get a cert from RapidSSL or the like. (At least, I hope not--given the security practices I've seen at banks, I'd be surprised if they didn't
This is, supposedly, what EV certificates provide, apart from a fat new revenue stream for selling those expensive bits (quick, someone explain why wildcard certs cost a single damned penny more than single-domain certs) and making anyone who can't afford them into second-class citizens.
There is, however, an attack which goes around that; as Dan Ber [cr.yp.to]
Re:You're correct, but that's not the vulnerabilit (Score:2)
Regarding EV, https://www.yourbank.com (EV cert) == https://www.yourbank.com (domain validated cert) -- as far as the browser's Same Origin Policy is concerned. So the attacker passes through enough EV for the bar to turn green, then switches over to DV for JS to come in. Not good.
Re: (Score:2)
This is, supposedly, what EV certificates provide
The real question is, then, can obtaining an EV cert also prevent RapidSSL from then issuing you another cert? Unless you've thoroughly trained your users to look for that green bar, they could still intercept https://yourbank.com/ [yourbank.com] using a brand-new RapidSSL cert for that same domain.
if you set up your fake server for hugebank.com, and have it serve up redirects to your newly registered (and certified!) hugebank.secure-banking.dom site, then the user will see a validated site that they got to by typing in their bank's address or following an email link.
There's no reason for a bank to send out a non-https link in an email. I am in the habit of typing https for several sites -- gmail being the main one.
And if it wasn't for the banks (including my current bank) which are Doing
Re: (Score:2)
Since the non-green-bar site has Javascript access to the green-bar site, the green bar doesn't actually mean anything.
Re: (Score:2)
Is this true of PayPal, specifically?
Re: (Score:2)
It's everyone with an EV cert.
Green bar is a great marketing ploy, but it really should be an httpsev:// URL handler if we wanted it to be secure. Collin Jackson's done some really good work around this, go google him.
The Backstory of the Kaminsky Bug (Score:2)
No kidding it has been overhyped.
From TFA The vulnerability gave him the power to transfer millions out of bank accounts worldwide. How so?! I don't have millions, but I do run djbdns...
Overhyped? are you kidding? "Kaminsky Bug" is going to be a major hit once it hits movie theaters!
Seriously though, The problem is major and we have found a pretty good workaround for it, can we move on? Most sysadmins will patch for it and then wait for the full fix and then install that. With something like blaster, you get a few users that patch and the rest just letting it go. I was doing a packet capture a few months ago (I work for an ISP) and I still see some systems out there that seem to be infec
DNS is Not Secure (Score:2, Funny)
For recursive acronym, see message subject. Also see the nearest mirror for an example of assmonkey.
DNSSEC (Score:2)
Re: (Score:2)
Of course if you can implement it, go for it but like anything with security, it adds additional level of complexity to entire system which may or may not be worth it. I'm not going to be signing any of my domains since they are just personal domains but I hope banks and such will.
Why we don't have DNSSEC yet (Score:2)
A few things have changed since my 2003 /. post [slashdot.org] which I've attached below, but the main difference is that Kaminsky's attack has made people realize that DNSSEC matters, and that it's time to get the ICANN and Department of Commerce to sign the root and have the registries sign .com and other major domains. (It's fun watching the Feds panic about it, because much of it's their fault.) And while widespread IPv6 deployment is closer, IPv6 DNS just uses the same packet format as IPv4 DNS with some new record
Do I not understand? (Score:2)
So, this is the first I've read in depth about this attack (its been 3 years since I was in IT, and in charge of DNS servers, patches, and all the rest...)
So the attack works by asking for a non-existant domain (ie nothere.domain.com), then blasting the DNS server with response packets that have a RR for www.domain.com, and then the DNS server caches the www RR because it passes the "baliwick" test...
So, uh... why not just turn off caching of everything besides the *ACTUAL* request? What would that break?
Re: (Score:2)
I don't quite understand it, but I was under the impression that he was asking for a non existant sub.domain.com, and then blasting "I am in charge of .domain.com".
But that doesn't seem to make sense to me since the ISP would've already cached the DNS for .domain.com
Re: (Score:3, Informative)
They have to update their cache at some point.
Re: (Score:3, Informative)
Re: (Score:1)
That way you cause your own cache miss, and the dns server goes away and updates itself again, but this time the hacker isn't busy bombarding it with fake responses.
Obviously not a scalable solution, since it would kill dns caching.
This also makes me wonder if widespread attacks of this kind would be self-defeating. hackers x, y, and z are busy attacking the same server, and every cache miss is wiping out t
Re: (Score:2)
So, the dirty fix is to always request a random bogus sub-domain before making the real request?
No, cache misses for A records don't make a recursive resolver go back to the parent domain for an updated NS record. If a cache was poisoned so it thought .bank.com queries were handled by w.x.y.z (the attackers IP), a request for nonexistant.bank.com would cause it to send an A request for the name to w.x.y.z, but not go back to the .com servers to find out which server is authoritative for .bank.com. (It will do that once the cached NS record for .bank.com expires, which could be weeks. Or until anot
Re: (Score:1, Informative)
You got most of it...except for a couple of important bits.
The attack involves asking for *multiple, changing* nonexistent subdomains. That is important because the NXDOMAIN response might be cached, depending on the DNS server you are attacking.
You then blast the server with responses for the non-existent record, also including the RRs you want to hijack in the glue section of your forged response. That additional RR is in-bailiwick, and therefore put into the cache and treated as true.
Now, your importan
Re: (Score:2)
I see that the glue is useful, if only in decreasing transaction volume. But my real question was "why do we cache the glue". I would say the rule should be "if it isn't exactly what I asked for, I won't cache it". This would stop someone being able to poison the cache through a response to a different question.
We could make the DNS servers smarter... IE if I ask for www.example.com and the root replies with a list of NS servers for .com, well I can use that answer including the glue IN THIS TRANSACTION
Re:Do I not understand? (Score:5, Informative)
So, uh... why not just turn off caching of everything besides the *ACTUAL* request?
Actually, as far as I understood, the attack is making the information "appear" to be relevant. For instance, DNS may contain aliases (CNAMEs) that do not directly resolve in an IP address, but rather into another name.
So, www.yourcompany.com may point to houdini.yourcompany.com, which itself resolves into 137.142.13.14.
When a client queries for www.yourcompany.com, the DNS server not only answers that query, but "helpfully" supplies the second leg, in order to save one round-trip.
Same thing with NS queries.
So, all the perp has to do is have nothere.domain.com pretend to be a CNAME for www.domain.com, and "helpfully" supply a mapping from www.domain.com to an IP under your control. Because the "unsolicited" mapping appears to be relevant, the client DNS server will cache it.
Re: (Score:2)
That's fine and all... but why does DNS cache the "extra" info at all? I can understand sending it along in an RR, as that saves a trip, but I would say the "rule" should be, no DNS server should cache anything it didn't explicitly ask for. That change alone eliminates this problem completely, and yeah it will increase some traffic because things can't be cached that are being cached now, but, it wouldn't be hard for the server to be set up if it gets a CNAME back, to then query specifically for that name
Re: (Score:2)
Indeed, when resolving test.mydomain.lu, the client nameserver first has to find out which server is responsible for mydomain.lu. In order to do so, it first asks the servers responsible for .lu to find out who is responsible for mydomain.lu. In most cases, the answer will be ns.mydomain.lu or somesuc
Re: (Score:2)
well... could you not condense the "baliwick" to say in this case the NS record is ns.mydomain.lu, so I can cache things in the glue that pertain to ONLY THAT exact host name?
To me the fundamental problem is that in the DNS system as it currently stands, the "client" can ask one question and get back an unrelated answer (IE I asked for the nothere.mydomain.com address, and got back an answer for www.mydomain.com (in the glue), so I'll happily cache that...) when I should only be caching things I asked for..
Re: (Score:1)
No, that's not it. If the perp controls the domain.com domain, they don't need to play any CNAME tricks, they can spoof www.domain.com directly.
In simple terms, the Kaminsky exploit fools a caching nameserver's notion of what addresses are associated with example.com's nameservers, by eliciting a bunch of doomed-to-failure queries of names underneath example.com (e.g. a.example.com, aa.example.com, xyz.example.com) along with fake, source-address-spoofed answers to those queries. Eventually the query ID #
Re: (Score:2)
I was as confused as you were by all this, since the article didn't say what the actual attack is. I eventually found something that explains it.
http://www.doxpara.com/DMK_BO2K8.ppt [doxpara.com] linked from http://www.isp-planet.com/equipment/2008/nominum+vantio.html [isp-planet.com]
See slide 17 in the presentation. But the trick is, your forged reply to a query for 83.foo.com is:
83.foo.com IN NS www.foo.com (83.foo.com is a subdomain, whose name server is www.foo.com)
www.foo.com IN A 6.6.6.6 (glue)
So I guess I sti
Re: (Score:2)
As I remember it, DJB thought glue was a bad idea, and dnscache always recursively gets its information starting with the root servers, caching only the data it fetched itself recursively.
This of course is not the case when run in caching-only mode where it queries a parent DNS server which may be faulty (and DJB doesn't recommend this usage).
Totallylookslike (Score:3, Funny)
Is it just me, or does Paul Vixie look like the Terminator?
why do people consider this hype? (Score:5, Insightful)
yes his attack only involves one dns server, but it is devastating and quick and effective. you can attach yourself vampirically to one dns server, sniff for bank info, redirect google, look at email, or whatever, and then quit shop before anyone raises alarm, and set up shop somewhere else, easily and quickly and invisibly
yes, you won't be able to take over ALL dns servers, but why is doing that the only thing that qualifies in your mind as truly threatening? kaminsky's attack, as described, is a hell of a scary hard core hack. its not hype, its the genuine frightening article. its the creme de la creme of hacks: simple, elegant, and as devastating as they come. any yahoo can move in, take over a dns server, victimize users downstream, and move on unnoticed and set up shop somewhere else. hardcore. devastating. frightening
is it some sort of ego thing? you have to belittle the validity of someone else's discovery? why do people consider this hype?
Re: (Score:3, Interesting)
Same reason why people don't believe in climate change. The potential risk is so mind-boggling, it's psychologically healthier to pretend it's not there.
Think of kids that cover their eyes and then reason that you cannot see them, because they cannot see you.
Re: (Score:2)
Re: (Score:2)
By your logic, if I wear sunglasses then I can see you, but you can't see me, right?
And no, the children are most definitely not onto something. This behavior is a classic tell-tale that the child's cognitive development is in a pre-operational phase and that it cannot distinguish between itself and the world around it. It supposes that every person sees the world just like the child itself does and has access to the same data. That assumption is obviously wrong, because the child, just like every other
Re: (Score:1)
yes his attack only involves one dns server
I think this is better said as "the attack undermines any vulnerable caching DNS resolver".
People need to distinguish between DNS servers and caching resolvers.
...invisibly
To be effective you need to redirect people to a machine under your control. Some "downstream" resolvers would log the poisoned results, thus getting you the IP of such a machine and a step closer to the perpetrator.
As far as hype, there are a lot of people out there who are quick to judge a situation based on perceived personalities rather than de
Re: (Score:2)
Glue distrust isn't that big of a deal. It's sufficiently damaging to the browser security model just to inject arbitrary subdomains into extant domains.
And, no offense to DJB, but port randomization is not by itself a sufficient response to the birthday attack. Come on, we've known not to have simultaneous outstanding requests for the same name for the last six years.
Re: (Score:1)
Glue distrust isn't that big of a deal.
Well, technically, glue trust is a big deal. It enables corruption of existing domains. That's a big deal. I think your point is that there are other, overshadowing problems. That may be the case; I am only familiar with this aspect of how DNS poisoning is a big deal. What specific problems arise from being able to add arbitrary subdomains in a browser context?
And, no offense to DJB, but port randomization is not by itself a sufficient response to the birthday attack. Come on, we've known not to have simultaneous outstanding requests for the same name for the last six years.
Port randomization helps. I don't think there's any offense to be had on DJB's part; port randomization was never said to be sufficient. Defen
Re: (Score:2)
Well, for one thing, 1.www.google.com has access to the www.google.com cookie. It's also a really good place to phish from. In some circumstances, document.domain is even set up such that 1.www.google.com has script level access to www.google.com. Not good.
At this point, BIND, Nominum, Unbound, and Microsoft all suppress colliding queries. The only name server I know of that doesn't is DJBDNS, and it drops its security level noticeably.
It was much lower than 2^16 (Score:1)
Yes, that's the cool part of the attack (Score:2)
DNS has two things that identify a UDP request - the transaction ID and the request's port number. 16 bits of ID seemed like plenty back in 1983, and many DNS versions didn't randomize the port number (since it's easier to just use 53 both ways through your firewall) before Kaminsky forced them to fix it. By requesting lots of bogus subdomains, you can birthday-attack the system, so you need ~256 guesses instead of 65536, and it's a lot easier to win that race against a real query.
But even the port-numb
Overhyped? (Score:4, Insightful)
Re: (Score:2)
The issue is so big that people from the entire IT industry, people driving the entire Internet can sit in same room at MS HQ which I believe was chosen for maximum security against espionage and agree on something and simultaneusly release updates without backstabbing eachother.
It must be one of the first in history.
That detail in page 3 ( http://www.wired.com/techbiz/people/magazine/16-12/ff_kaminsky?currentPage=3 [wired.com] ) impressed me.
Re: (Score:2)
All the DNS vendors except those who were already immune to the attack, you mean: djbdns always randomized port numbers, and never accepted answers to questions it didn't ask (glue).
Meanwhile, we're listening (DNSSEC) to the people who made and support broken (affected) nameservers, instead of to the people who made compatible, but unaffected and unbroken nameservers. This never ceases to bewilder me.
Re: (Score:2)
I thought that was SOP.
The fix or DJB's immunity's is still not enough (Score:2)
Yes, there were some DNS systems that randomized port numbers already, so they're safe against birthday attacks on the 16-bit ID. DJB's obsessively careful, and at times like this it shows. But the ID's still only 16 bits long, and port numbers only get you another ~16 bits, so a ~2^24 packet attack can still succeed. That's not always going to work, but attackers don't have to win every time to be dangerous - they don't need to attack your account at your bank, as long as they can rip off somebody's acc
Re: (Score:2)
You missed the part where djbdns ignores answers to questions it didn't ask.
That means that in addition to getting the 16-bit port number and the 16-bit transaction id, they have to do it after the TTL expired for the record in question, but before the legitimate content server has sent the new (refreshed) information.
That's ridiculously unlikely.
It's intellectually dishonest to say the only way to resolve it is DNSSEC or long XIDs. Furthermore, XIDs and DNSSEC require a similar amount of work to deploy- be
Re: (Score:2)
"What she said" or +1 Insightful
dnscache (the relevant part of djbdns [cr.yp.to]) is pretty smart, and pretty paranoid, and when things like this come up, DJB deserves a good round of "I told you so."
The problem here is that some people don't understand how anyone expects to attack these banking sites without also replicating their SSL certificates for secure login. The issue is that most banking sites and others with secure logins don't have a signed page for the login but for the target page of the login, and most
Re: (Score:2)
Kaminsky had credibility already (Score:2)
Kaminsky wasn't an unknown - he'd spoken at a couple of Codecon [codecon.org] conferences, doing increasingly heinous things to DNS. One year it was tunnelling SSH over DNS, which lets you break out of any firewall you're behind (and potentially lets malware do the same.) Another year it was the video-over-DNS hack referred to in the article. Codecon's not a big conference, but it's had a lot of high-quality presentations, and when I saw the announcement that Kaminsky had found a serious problem, it had to be more ser
We've been ARP cache poisoning for years... (Score:1)
Everyone I knew in IT in 2004 knew how to do it, even showed me how to do it - thats also the year I started taking Linux seriously, and actually learned how vastly interconnected everything is. Nowadays I have an exponentially greater knowledgebase on inter-networking and how all this stuff actually works, and just NOW it's important that "There is a bug in the Internet?" So if I list a bunch of really hush-hush secrets about how screwed up things REALLY are with the internet, will i get credited with expo
Re: (Score:2)
Oh come on, ARP cache poisoning is trivial :) There's also a good dozen ways on LAN to hijack all traffic, so you're never fixing that.
Re: (Score:2)
If you would bother to read the article you'd see that this bug was extremely serious and had the potential to easily hose much of the internet. Yes much of the Internet. Nothing your talking about would ever come close to what he figured out. If you really are interested in the way networks work then you'll find the article quite amusing to say the least.
Well done, very well done! (Score:1, Insightful)
Kaminsky, I just think that there are 2 types of flamers out there. One sort is the people who are jealous and wish they had found the bug and the other ones are the type who are angry that it didn't got leaked so fast and they didn't have the chance to use the security hole. I would say that Kaminsky has credit well earned, I cant even imagine what I would have done with that info. "Power tends to corrupt people, and ultimate power tends to corrupt ultimately" don't forget.
Re: (Score:2)
Re: (Score:2)
The money involved is billions. Lets not forget it. The Kaminsky flaming seems to come from jelousy, the .edu "mafia" and the fact that guy found some kind of security hole that it is there for 3 decades. It is a human thing really.
Working on multi billion Vista pre-release security should have give him enough credit already in professional terms and real life.
He deserves some kind of IT medal, that is what I thought while reading that excellently written article on my 320x200 phone screen and as I know he
Re: (Score:2)
Technically, everything in Paketto comes from a rather evil reading of TCP RFC's :)
painfully non-technical (Score:1)
I wasn't familiar with the attack, and this article isn't really helping much. I guess I'll just look it up elsewhere. I know its not for a technical audience, but I wish people wouldn't say things that are more or less wrong. Since when is a hostname = a web page? This is so wrong that it makes the article painful to read. (Which is unfortunate, because the personal story is somewhat interesting.) And the article has a few more-technical bits later, so why stoop to being so wrong at the start?
a coupl
The part that leaped out (Score:4, Interesting)
Re: (Score:1, Insightful)
It's a cliche to say that incompetence, greed and jealousy defines the security industry culture. But no other words can describe the leak. One group worked with operators and quietly patched the world's DNS servers, and went about their jobs. The other group, who demanded information about the vulnerability because they were "security professionals" and therefore deserved to know, promptly instead wrote blog articles and then "accidentally" released them.
It makes you wonder. If that security firm stores
Why "authoritative source for the domain"? (Score:1)
If this were changed the problem would be considerably mitigated: foof.google.com would be compromised, but www.google.com wouldn't.
So why not do this?
Re: (Score:2)
See http://www.doxpara.com/DMK_Neut_toor.ppt to see why this is still a problem.
Why not use 64-bit key? (Score:1)
Re: (Score:1, Informative)
Because they didn't increase the the key. They decreased the likelihood of success of the attack through other means, and they did so by enforcing source-port randomization. Now, not only does the attacker have to guess or know the TXID, they have to guess or know the source port of the request.
At least, that's my understanding of it.
It's too deeply embedded in the packet format (Score:2)
Go read the RFCs for DNS and look at the packet format picures- if you were writing DNS from scratch, that'd be an obvious thing to change (though I'd recommend 128 bits.) But the Transaction ID isn't one of the fields that you get to pick a size for, or one of the record types that you can replace with a newer record type such as IPv6's AAAA records instead of IPv4's A records or the various record types that DNSSEC uses. It's one of the early fields in the packet, always the same size, always 16 bits.
Powerpoint (Score:5, Informative)
Here's Kaminsky's powerpoint [doxpara.com] given at the Black Hat conference. (106 slides but thorough) This Wired article and the powerpoint is enough to make me panic. He literally broke the internet; unlock any website and spoof any logs. Now I see why there was so much panic in the article.
Re: (Score:1)
Vixie Celling Out (Score:2)
Is it just me, or does it seem like Vixie sometimes gets pretty stupid? He can't be a total idiot, considering all that he's accomplished. But insistence on using landlines for discussions of this issue are pretty laughable. It's true that analog cell conversations were open to anybody with the right kind of radio receiver. But by 2002, nobody who lived in an urban area was still using analog. I believe it's actually harder to tap a digital cell than it is a landline. After all, landlines are analog betwee
Some "bad guys" are governments (Score:2)
But insistence on using landlines for discussions of this issue are pretty laughable. It's true that analog cell conversations were open to anybody with the right kind of radio receiver. But by 2002, nobody who lived in an urban area was still using analog.
Not all "bad guys" are individuals. Some are governments.
We already KNOW the NSA can tap any GSM phone they want, anywhere, from satellites. Any bets on whether the Russians can, to? Or whether the Russian Mafia can get the info from them? Or whether
Re: (Score:2)
According to the story "Vixie knew how easy it was to listen in on cell calls". Doesn't sound like he was thinking of the NSA at all. More like all the casual cell eavesdroppers that used to be common when most people were still on analog.
But suppose the NSA is an issue. They never taps landlines? If you're going to be that uptight, you don't fixate on one particular vulnerability. You need a general security strategy. The includes never using any third party channel without securing it first.
What's particu
Re: (Score:1, Offtopic)
Much more exciting was the comic about the robotic poker player and the description of the AI methods it uses to win.
Re:They make him sound like some sort of James Bon (Score:2)
He had a lot to be modest about.
Seems to me he earned the right to brag.