And DJB's $500 is safe for another day
July 9, 2008 6:57 PM Subscribe
A major flaw in the DNS system is promised to be revealed at the next Black Hat conference. Convinced it was too important to wait, security researcher Dan Kaminsky (video, autoplays) convinced several software vendors to issue emergency patches today, before publicizing details of the attack. It can't be that serious though, can it? Oh yes it can.
Nah, it's not that simple. Dan has said that, even knowing the patch, it's very hard to construct an attack. He figures 4 weeks (and note that this is using Dan Kaminsky's definition of "very hard", not some script kiddie's). So by the time he gives his talk, it's expected that exploits will be out there anyway.
posted by intermod at 7:49 PM on July 9, 2008
posted by intermod at 7:49 PM on July 9, 2008
No, mindsound, it hasn't been revealed. Read Kaminsky's blog:
Excellent design protects you against things you don’t have any information about. And so we are deploying this excellent design to provide no information.posted by finite at 7:50 PM on July 9, 2008
Only stupid people do the following:
a) Use a non-encrypted non-authenticated connection for anything important
b) Share passwords between unimportant and/or unauthenticated and important sites
While someone spoofing queries might be rather annoying my systems will be tooling along not giving a shit. Somebody might man in the middle MeFi, thus giving someone my MeFi password. So someone can make me look like a fool. Great. I already do that well enough myself.
Maybe they won't do as good a job, thus making me look smarter.
They aren't getting anything important out of the deal unless they figure out how to forge an SSL certificate or my SSH2 keys. I spent many years of my life being annoyed by script kiddies taking down web sites, routers, IRC servers, and everything else. Somehow I'm not feeling the need to run around like a chicken with my head cut off here.
I'll just remind my users to pls make sure not to do anything over an unencrypted connection they wouldn't mind their worst enemy seeing. So I'll be telling them the same thing I've been telling them for years.
Besides, if people can spoof TCP packets (and they can, even with sequence number randomization, it's just harder than it used to be), they can still spoof DNS responses, even with port randomization, so the fix isn't much of a fix, if that's really all that's being done at this point.
posted by wierdo at 7:53 PM on July 9, 2008
a) Use a non-encrypted non-authenticated connection for anything important
b) Share passwords between unimportant and/or unauthenticated and important sites
While someone spoofing queries might be rather annoying my systems will be tooling along not giving a shit. Somebody might man in the middle MeFi, thus giving someone my MeFi password. So someone can make me look like a fool. Great. I already do that well enough myself.
Maybe they won't do as good a job, thus making me look smarter.
They aren't getting anything important out of the deal unless they figure out how to forge an SSL certificate or my SSH2 keys. I spent many years of my life being annoyed by script kiddies taking down web sites, routers, IRC servers, and everything else. Somehow I'm not feeling the need to run around like a chicken with my head cut off here.
I'll just remind my users to pls make sure not to do anything over an unencrypted connection they wouldn't mind their worst enemy seeing. So I'll be telling them the same thing I've been telling them for years.
Besides, if people can spoof TCP packets (and they can, even with sequence number randomization, it's just harder than it used to be), they can still spoof DNS responses, even with port randomization, so the fix isn't much of a fix, if that's really all that's being done at this point.
posted by wierdo at 7:53 PM on July 9, 2008
mindsound:
Kind of- the CERT advisories have general information about the fixes and the category of attack, but I think the issue is that Dan has figured out a way to make the attack practical using an (as of yet) unpublished technique. The possibility of this type of attack has been known since at least '03.
What's amazing to me is that every major vendor is vulnerable despite the presence of several independent server implementations; there was a fundamental flaw in one of the basic protocols of the Internet and it's taken 25 years for someone to find it.
posted by theclaw at 7:59 PM on July 9, 2008
Kind of- the CERT advisories have general information about the fixes and the category of attack, but I think the issue is that Dan has figured out a way to make the attack practical using an (as of yet) unpublished technique. The possibility of this type of attack has been known since at least '03.
What's amazing to me is that every major vendor is vulnerable despite the presence of several independent server implementations; there was a fundamental flaw in one of the basic protocols of the Internet and it's taken 25 years for someone to find it.
posted by theclaw at 7:59 PM on July 9, 2008
The poster's phrasing was that a "major flaw" was promised to be revealed. Dan will be, I gather, releasing a description of how to exploit the flaw, but the flaw itself ("insufficient entropy") and its fixes have already been promulgated. Not to say that Dan Kaminsky isn't a crazy security badass, or that his talk at Black Hat won't be fascinating and novel, but the attack vector is out in the open.
posted by mindsound at 8:08 PM on July 9, 2008
posted by mindsound at 8:08 PM on July 9, 2008
weirdo:
They aren't getting anything important out of the deal unless they figure out how to forge an SSL certificate or my SSH2 keys.
Perhaps you're underestimating the severity of this problem. If I can inject a DNS response, all I need to do is copy your bank's SSL certificate to my own webserver, and poof, successful phish. The cert isn't tied to a particular IP address.
posted by mark242 at 8:18 PM on July 9, 2008
They aren't getting anything important out of the deal unless they figure out how to forge an SSL certificate or my SSH2 keys.
Perhaps you're underestimating the severity of this problem. If I can inject a DNS response, all I need to do is copy your bank's SSL certificate to my own webserver, and poof, successful phish. The cert isn't tied to a particular IP address.
posted by mark242 at 8:18 PM on July 9, 2008
Well, no; if you can get access to the bank's SSL private key, you've won already. That's kind of the whole point of SSL -- the information you get by verifying the server's identity is insufficient to impersonate the server.
posted by teraflop at 8:26 PM on July 9, 2008
posted by teraflop at 8:26 PM on July 9, 2008
Uh, will someone please put this in layman's terms?
posted by autodidact at 8:45 PM on July 9, 2008
posted by autodidact at 8:45 PM on July 9, 2008
mark242: If my bank is stupid enough to make it possible for you to get their private key, I'm fucked anyway. You can get me through any number of other attacks if you can do that. You can even run your scam entirely from their server. No need to do a phishing attack with poisoned DNS.
posted by wierdo at 8:52 PM on July 9, 2008
posted by wierdo at 8:52 PM on July 9, 2008
Or what teraflop said.
autodidact: It means that an attacker could cause your computer to connect to badsite.com when you type in metafilter.com.
There have been cache poisoning attacks around for years. It's never been that big of a deal. It's possible this one is different, (perhaps more easily done?) but it still won't defeat SSL, although it does remove one layer of difficulty from a phishing attack, among other things. Basically, it's a pain in the ass, but not the end of the world.
posted by wierdo at 8:58 PM on July 9, 2008
autodidact: It means that an attacker could cause your computer to connect to badsite.com when you type in metafilter.com.
There have been cache poisoning attacks around for years. It's never been that big of a deal. It's possible this one is different, (perhaps more easily done?) but it still won't defeat SSL, although it does remove one layer of difficulty from a phishing attack, among other things. Basically, it's a pain in the ass, but not the end of the world.
posted by wierdo at 8:58 PM on July 9, 2008
> Uh, will someone please put this in layman's terms?
Okay ... basically, when you type a web address, like "www.metafilter.com", into your computer, it has to be resolved into an IP address, like 74.53.68.130, in order to actually communicate with it.
This is done using the DNS system. It's a big distributed database for turning domain names into IP addresses. The protocol it uses is quite old, and doesn't really involve much security. There's very little assurance that the DNS server you're using to resolve names into IP addresses is really the one you think it is.
Typically, most people use a DNS server supplied by their ISP. (You get the address for it automatically, as part of connecting to the Internet.) You send domain names to it, it sends back IP addresses. But if someone can forge DNS responses -- which is what we're talking about here -- they could conceivably tell your computer that their computer is www.metafilter.com (or any other site). You'd think that you were talking to the legit MetaFilter site, but in reality you'd be talking to the bad guy's, who would be monitor everything you send.
Hence, they could (if there's no encryption or anything) get your passwords and then proceed to own you.
However, it's harder to do that for non-trivial systems (like banks and other sites that use SSL) because there's an additional layer they'd have to fake -- the SSL certificate. You'd type in "mybank.com", they would inject the DNS response and make you connect to their computer, but since they don't have mybank.com's SSL certificate, you'd see an invalid certificate warning. They'd only own you if you decided to disregard that warning.
So, in short ... pay attention to SSL certificate warnings, especially when connecting to banks and other important sites from untrusted networks (public wifi, etc.).
posted by Kadin2048 at 9:00 PM on July 9, 2008 [7 favorites]
Okay ... basically, when you type a web address, like "www.metafilter.com", into your computer, it has to be resolved into an IP address, like 74.53.68.130, in order to actually communicate with it.
This is done using the DNS system. It's a big distributed database for turning domain names into IP addresses. The protocol it uses is quite old, and doesn't really involve much security. There's very little assurance that the DNS server you're using to resolve names into IP addresses is really the one you think it is.
Typically, most people use a DNS server supplied by their ISP. (You get the address for it automatically, as part of connecting to the Internet.) You send domain names to it, it sends back IP addresses. But if someone can forge DNS responses -- which is what we're talking about here -- they could conceivably tell your computer that their computer is www.metafilter.com (or any other site). You'd think that you were talking to the legit MetaFilter site, but in reality you'd be talking to the bad guy's, who would be monitor everything you send.
Hence, they could (if there's no encryption or anything) get your passwords and then proceed to own you.
However, it's harder to do that for non-trivial systems (like banks and other sites that use SSL) because there's an additional layer they'd have to fake -- the SSL certificate. You'd type in "mybank.com", they would inject the DNS response and make you connect to their computer, but since they don't have mybank.com's SSL certificate, you'd see an invalid certificate warning. They'd only own you if you decided to disregard that warning.
So, in short ... pay attention to SSL certificate warnings, especially when connecting to banks and other important sites from untrusted networks (public wifi, etc.).
posted by Kadin2048 at 9:00 PM on July 9, 2008 [7 favorites]
Ugh, sorry. After we're done talking about the "DNS system", we'll discuss "ATM machines"...
posted by Kadin2048 at 9:01 PM on July 9, 2008 [2 favorites]
posted by Kadin2048 at 9:01 PM on July 9, 2008 [2 favorites]
Seeing the invalid certificate warning presumes, of course, that they can't get a certificate for www.mybank.com from a CA whose root certificate is installed by default in your browser. If they can, your browser doesn't know not to trust it.
Of course, many, if not most, really important sites use EV certificates now, which certify both the web site and the entity offering them, so if I go to www.bankofamerica.com and log in, Fx3 will say "Bank of America, Inc." in the address bar, letting me know that the CA claims that I am really talking to Bank of America and not joe hacker who they were dumb enough to issue a regular cert for www.bankofamerica.com to.
The absolute best protection is to right now go to any important sites you deal with and take note of their certificate's "fingerprint," and compare that with the fingerprint you get in the future. Faking that is much harder than convincing some CA to sign a certificate request for a domain you don't actually own.
Also be wary of typing in one address and being redirected to another subdomain, as it might be easier for an attacker to get a certificate signed for blah.bankofamerica.com than it is for www.bankofamerica.com. Of course, many sites will redirect you from, say, metafilter.com to www.metafilter.com. That's pretty normal. Sadly, my bank redirects to something like inet-banking.mybank.com, and it wouldnt' be possible for someone who hadn't been paying attention in the past to know that was OK and some attacker hadn't conned a CA into issuing them an SSL certificate for that particular subdomain.
posted by wierdo at 9:14 PM on July 9, 2008
Of course, many, if not most, really important sites use EV certificates now, which certify both the web site and the entity offering them, so if I go to www.bankofamerica.com and log in, Fx3 will say "Bank of America, Inc." in the address bar, letting me know that the CA claims that I am really talking to Bank of America and not joe hacker who they were dumb enough to issue a regular cert for www.bankofamerica.com to.
The absolute best protection is to right now go to any important sites you deal with and take note of their certificate's "fingerprint," and compare that with the fingerprint you get in the future. Faking that is much harder than convincing some CA to sign a certificate request for a domain you don't actually own.
Also be wary of typing in one address and being redirected to another subdomain, as it might be easier for an attacker to get a certificate signed for blah.bankofamerica.com than it is for www.bankofamerica.com. Of course, many sites will redirect you from, say, metafilter.com to www.metafilter.com. That's pretty normal. Sadly, my bank redirects to something like inet-banking.mybank.com, and it wouldnt' be possible for someone who hadn't been paying attention in the past to know that was OK and some attacker hadn't conned a CA into issuing them an SSL certificate for that particular subdomain.
posted by wierdo at 9:14 PM on July 9, 2008
Typically, most people use a DNS server supplied by their ISP. (You get the address for it automatically, as part of connecting to the Internet.) You send domain names to it, it sends back IP addresses. But if someone can forge DNS responses -- which is what we're talking about here -- they could conceivably tell your computer that their computer is www.metafilter.com (or any other site). You'd think that you were talking to the legit MetaFilter site, but in reality you'd be talking to the bad guy's, who would be monitor everything you send.
So, uh, how is it different then any other DNS attack that's cropped up in the past? I mean, I think people understand how DNS works. What's so special about this attack?
Or does no one actually know?
posted by delmoi at 9:35 PM on July 9, 2008
So, uh, how is it different then any other DNS attack that's cropped up in the past? I mean, I think people understand how DNS works. What's so special about this attack?
Or does no one actually know?
posted by delmoi at 9:35 PM on July 9, 2008
I don't think anyone here actually knows, and it seems that the source port randomization fixes it but isn't the source of the problem. Presumably you can do something tricksy if you can predict what port the server is going to use next, but maybe it's something completely different like sniffing the chosen source ports would enable an attacker to learn some secret about the server or something.
*happily running djbdns*
posted by breath at 9:41 PM on July 9, 2008
*happily running djbdns*
posted by breath at 9:41 PM on July 9, 2008
there was a fundamental flaw in one of the basic protocols of the Internet and it's taken 25 years for someone to find itTo be fair, once the security model changed to assume a thoroughly untrustworthy network, they developed things like DNSSEC. (Which would solve problems like these, but might or might not be a perfect solution.) Verisign/NetSol will never implement it, though.
Also: Ten years ago.
posted by hattifattener at 10:02 PM on July 9, 2008
Is this something I'd need a computer to care about?
posted by yort at 10:58 PM on July 9, 2008 [1 favorite]
posted by yort at 10:58 PM on July 9, 2008 [1 favorite]
Uh, will someone please put this in layman's terms?Surely you can figure it out on your own :)
posted by autodidact at 8:45 PM on July 9 [+] [!]
posted by scope the lobe at 11:04 PM on July 9, 2008 [7 favorites]
You'd think that you were talking to the legit MetaFilter site, but in reality you'd be talking to the bad guy's
...where my priceless snark would - no doubt - be completely disemvowelled.
posted by UbuRoivas at 11:26 PM on July 9, 2008 [1 favorite]
...where my priceless snark would - no doubt - be completely disemvowelled.
posted by UbuRoivas at 11:26 PM on July 9, 2008 [1 favorite]
but since they don't have mybank.com's SSL certificate, you'd see an invalid certificate warning.
From what I gather it's more serious than that. If you've got somebody who is smart enough to exploit this unpublished vulnerability, couldn't they change the resolution for certificate validation? Say redirect your browser's requests to Verisign to their own machine which will in turn say "yeah dude, this certificate is totally legit." I'm not a wizard sysadmin type, so if someone smart could explain why my logic is wrong I'd appreciate it. Otherwise, seems pretty scary.
In addition to that, couldn't they just issue a new certificate from their own machine, all spoofed and the like? And since your computer believes you are BofA.com, wouldn't it all be seemless?
posted by braksandwich at 11:28 PM on July 9, 2008
From what I gather it's more serious than that. If you've got somebody who is smart enough to exploit this unpublished vulnerability, couldn't they change the resolution for certificate validation? Say redirect your browser's requests to Verisign to their own machine which will in turn say "yeah dude, this certificate is totally legit." I'm not a wizard sysadmin type, so if someone smart could explain why my logic is wrong I'd appreciate it. Otherwise, seems pretty scary.
In addition to that, couldn't they just issue a new certificate from their own machine, all spoofed and the like? And since your computer believes you are BofA.com, wouldn't it all be seemless?
posted by braksandwich at 11:28 PM on July 9, 2008
The CA's certificate comes with your browser. There's no need to contact Verisign to see whether they've signed a particular certificate—you just need their certificate and the one you're testing.
posted by oaf at 11:42 PM on July 9, 2008
posted by oaf at 11:42 PM on July 9, 2008
Brak: all browsers come with the public keys for all the major certificate authorities.
When your browser connects to http://www.mybank.com, MyBank sends its public key, including a signature section that was generated by the CA's private key. Your browser, using its copy of the CA key, can verify that the signature is authentic, and that the key being presented as MyBank's is precisely what was signed by the CA. You can be mathematically certain that the key is correct and hasn't been tampered with, and presuming you trust the CA's vetting process, can also be sure that it's from who it says it's from.
At no point do you ever see anyone's private key, only public ones. Just using the public keys, you can be sure that A) the public key you're being offered has been signed by the CA's private key, and B) that all traffic sent to you by the website is encrypted with the website's private key.
Even the CA never sees the website's private key; only the public key is ever shared with anyone.
posted by Malor at 12:01 AM on July 10, 2008
When your browser connects to http://www.mybank.com, MyBank sends its public key, including a signature section that was generated by the CA's private key. Your browser, using its copy of the CA key, can verify that the signature is authentic, and that the key being presented as MyBank's is precisely what was signed by the CA. You can be mathematically certain that the key is correct and hasn't been tampered with, and presuming you trust the CA's vetting process, can also be sure that it's from who it says it's from.
At no point do you ever see anyone's private key, only public ones. Just using the public keys, you can be sure that A) the public key you're being offered has been signed by the CA's private key, and B) that all traffic sent to you by the website is encrypted with the website's private key.
Even the CA never sees the website's private key; only the public key is ever shared with anyone.
posted by Malor at 12:01 AM on July 10, 2008
When HSBC issued an electronic 6-digit code generator to account holders on top of the usual loginID/password combo for online transactions here in Hong Kong, I was irritated with the extra step.
No longer.
posted by bwg at 12:13 AM on July 10, 2008 [1 favorite]
No longer.
posted by bwg at 12:13 AM on July 10, 2008 [1 favorite]
Ugh, sorry. After we're done talking about the "DNS system", we'll discuss "ATM machines"...
What's wrong with ATM machines? I typed my PIN number into one just last night.
posted by rokusan at 2:10 AM on July 10, 2008 [3 favorites]
What's wrong with ATM machines? I typed my PIN number into one just last night.
posted by rokusan at 2:10 AM on July 10, 2008 [3 favorites]
What's amazing to me is that every major vendor is vulnerable
As alluded to in the Matasano and the title, djbdns was never vulnerable to this.
Also there are plenty of vectors that don't rely on SSL being spoofed for DNS to be a Big Problem. Kaminsky himself has done some pretty excellent/hilarious work with spoofing DNS to get at internal network resources (now kittensplayingfootball.com resolves to a hilarious image, two seconds from now it'll resolve to the internal IP address of your printer which has a kernel vulnerability and now your private network is pwned). Combined with being able to spoof existing, non-SSL domains and you can access a visitor's auth cookies, get into their gmail account and change all their existing accounts. There's a lot of potential meat here, that's just the trivially obvious exploit.
The killer link to me was Ptacek's backpeddle. It takes a big man to admit he was completely wrong :)
posted by Skorgu at 5:04 AM on July 10, 2008
As alluded to in the Matasano and the title, djbdns was never vulnerable to this.
Also there are plenty of vectors that don't rely on SSL being spoofed for DNS to be a Big Problem. Kaminsky himself has done some pretty excellent/hilarious work with spoofing DNS to get at internal network resources (now kittensplayingfootball.com resolves to a hilarious image, two seconds from now it'll resolve to the internal IP address of your printer which has a kernel vulnerability and now your private network is pwned). Combined with being able to spoof existing, non-SSL domains and you can access a visitor's auth cookies, get into their gmail account and change all their existing accounts. There's a lot of potential meat here, that's just the trivially obvious exploit.
The killer link to me was Ptacek's backpeddle. It takes a big man to admit he was completely wrong :)
posted by Skorgu at 5:04 AM on July 10, 2008
How many people would really notice if going to www.citibank.com didn't redirect you to their SSL server as part of the login?
posted by smackfu at 5:40 AM on July 10, 2008
posted by smackfu at 5:40 AM on July 10, 2008
rokusan - "DNS system" is saying system twice, just like Automatic Teller Machines-machines is saying machines twice.
posted by dabitch at 6:11 AM on July 10, 2008
posted by dabitch at 6:11 AM on July 10, 2008
I don't know if anyone's posted the link to the CERT vuln report -- I can't find it in here -- but here it is.
posted by fiercecupcake at 6:57 AM on July 10, 2008
posted by fiercecupcake at 6:57 AM on July 10, 2008
dabitch, it's also like "PIN number" is saying number twice. Which was the joke rokusan made.
posted by sdodd at 7:05 AM on July 10, 2008 [1 favorite]
posted by sdodd at 7:05 AM on July 10, 2008 [1 favorite]
What's especially neat about this situation is how (according to Kaminsky's blog, linked above) this over-broad solution fixes not just this bug but a number of other outstanding bugs in some implementations. It's an excuse to force some folks to take some medicine they've been avoiding thus far.
posted by sdodd at 7:21 AM on July 10, 2008
posted by sdodd at 7:21 AM on July 10, 2008
The absolute best protection is to right now go to any important sites you deal with and take note of their certificate's "fingerprint,"
So, uh, how would I do this?
posted by adamdschneider at 7:54 AM on July 10, 2008
So, uh, how would I do this?
posted by adamdschneider at 7:54 AM on July 10, 2008
we'll discuss "ATM machines"..
And a good thing too. Most of them come with NIC cards nowadays and could be vulnerable.
posted by quin at 8:13 AM on July 10, 2008 [2 favorites]
And a good thing too. Most of them come with NIC cards nowadays and could be vulnerable.
posted by quin at 8:13 AM on July 10, 2008 [2 favorites]
So, yeah. I'm Dan Kaminsky. It's a little weird and cool to see myself on the blue :)
The issue is pretty bad. The vendors know how bad it is, which is how we got everyone to issue patches simultaneously. Tom Ptacek knows how bad it is, which is why he posted his public about-face. (I do not fault him his skepticism in the slightest, however. Extraordinary claims, no available evidence.) But, no, nobody has publicly figured out what I'm up to.
Yet. We're trying. We may last the month. We wouldn't last much longer.
As a note, I think people imagine SSL is far more deployed than it actually is. Also, you can't filter by fingerprint, because you have entire clusters of SSL accelerators all with different prints but the same Subject Name.
posted by effugas at 8:58 AM on July 10, 2008 [29 favorites]
The issue is pretty bad. The vendors know how bad it is, which is how we got everyone to issue patches simultaneously. Tom Ptacek knows how bad it is, which is why he posted his public about-face. (I do not fault him his skepticism in the slightest, however. Extraordinary claims, no available evidence.) But, no, nobody has publicly figured out what I'm up to.
Yet. We're trying. We may last the month. We wouldn't last much longer.
As a note, I think people imagine SSL is far more deployed than it actually is. Also, you can't filter by fingerprint, because you have entire clusters of SSL accelerators all with different prints but the same Subject Name.
posted by effugas at 8:58 AM on July 10, 2008 [29 favorites]
I'm running legacy name servers (Bind 8.3.7) and have restricted recursion. Am I safe?
posted by psyche7 at 11:30 AM on July 10, 2008
posted by psyche7 at 11:30 AM on July 10, 2008
So, yeah. I'm Dan Kaminsky. It's a little weird and cool to see myself on the blue :)
I love this site so damned much.
posted by cavalier at 1:37 PM on July 10, 2008
I love this site so damned much.
posted by cavalier at 1:37 PM on July 10, 2008
Yeah, moments like that really make this place cool.
Keep up the good work Dan, er... effugas. Your efforts are certainly appreciated.
posted by quin at 2:09 PM on July 10, 2008
Keep up the good work Dan, er... effugas. Your efforts are certainly appreciated.
posted by quin at 2:09 PM on July 10, 2008
adamdschneider: If you're using Firefox 3, when you're on a secure site, click the icon (or blank space that's blue) just to the left of the address bar, then click 'more info,' followed by 'view certificate.'
I hadn't thought of effugas' point that some sites may use multiple certificates with the same CN, although it seems rather silly to me that they would bother doing that rather than using the same certificate. You might doublecheck that any sites whose fingerprint you've written down are the same tomorrow if you really care.
I haven't checked the big bank sites personally. I'm not too concerned with all this. It helps that I don't use many of the hugely popular services that people might seek to attack, nor do I stay logged in to the others. I probably ought to change my home network to use a different IP block, though.
I probably should get my clients mail clients to use TLS when connecting to their mail servers, though. Wouldn't want their passwords snarfed. (when they're using other people's DNS servers, ours have already been upgraded)
posted by wierdo at 2:35 PM on July 10, 2008
I hadn't thought of effugas' point that some sites may use multiple certificates with the same CN, although it seems rather silly to me that they would bother doing that rather than using the same certificate. You might doublecheck that any sites whose fingerprint you've written down are the same tomorrow if you really care.
I haven't checked the big bank sites personally. I'm not too concerned with all this. It helps that I don't use many of the hugely popular services that people might seek to attack, nor do I stay logged in to the others. I probably ought to change my home network to use a different IP block, though.
I probably should get my clients mail clients to use TLS when connecting to their mail servers, though. Wouldn't want their passwords snarfed. (when they're using other people's DNS servers, ours have already been upgraded)
posted by wierdo at 2:35 PM on July 10, 2008
And a good thing too. Most of them come with NIC cards nowadays and could be vulnerable.
That'll be covered too at the Blackhat conference. Remember to RSVP please.
posted by ALongDecember at 3:10 PM on July 10, 2008
That'll be covered too at the Blackhat conference. Remember to RSVP please.
posted by ALongDecember at 3:10 PM on July 10, 2008
dabitch, it's also like "PIN number" ...
aaarghhh, dying inside for not spotting that. truly. And in front of Dan Kaminsky himself too! triple-aaargh!
posted by dabitch at 5:05 PM on July 10, 2008
aaarghhh, dying inside for not spotting that. truly. And in front of Dan Kaminsky himself too! triple-aaargh!
posted by dabitch at 5:05 PM on July 10, 2008
wierdo--
You're never supposed to copy a private key. A lot of hardware won't even let you. So, you generate a ton of keypairs, and sign 'em all with your Subject name. It's not rare.
cortex--
:)
Overall: "If it recurses, patch it or kill it." There are no provisos or exceptions to that statement. Client resolvers have issues too, patch 'em if you can, but it's much harder to exploit those.
posted by effugas at 7:35 PM on July 10, 2008
You're never supposed to copy a private key. A lot of hardware won't even let you. So, you generate a ton of keypairs, and sign 'em all with your Subject name. It's not rare.
cortex--
:)
Overall: "If it recurses, patch it or kill it." There are no provisos or exceptions to that statement. Client resolvers have issues too, patch 'em if you can, but it's much harder to exploit those.
posted by effugas at 7:35 PM on July 10, 2008
effugas: You mean you're never supposed to copy a private key over a channel not known to be secure. For some people, that may mean no copying at all, but for most, a flash drive is fine, provided it's securely wiped (and preferably physically destroyed) afterwards.
Still, it's nice to know there are truly paranoid folks out there, their paranoia is what drives security forward, not folks like me.
posted by wierdo at 7:55 PM on July 10, 2008
Still, it's nice to know there are truly paranoid folks out there, their paranoia is what drives security forward, not folks like me.
posted by wierdo at 7:55 PM on July 10, 2008
So, yeah. I'm Dan Kaminsky.
Damn, and he's got a lower usernumber than me, so I can't go "haha n00b!" like I did when Woz showed up.
posted by UbuRoivas at 8:39 PM on July 10, 2008
Damn, and he's got a lower usernumber than me, so I can't go "haha n00b!" like I did when Woz showed up.
posted by UbuRoivas at 8:39 PM on July 10, 2008
Some pre-Black Hat details on the attack.
Matasano has a blog post that hit my rss reader (but not their website...) with more. Basically it combines cache poisoning (racing to resolve AAAA.VICTIM.COM, AAAB., etc.) with Additional RRs that are in scope of the domain to force the poisoning up from the spoofed subdomain. If I read it right, it leads to cache poisoning of the entire, arbitrary domain for the resolver as a whole and anyone who queries it.
posted by Skorgu at 1:27 PM on July 21, 2008
Matasano has a blog post that hit my rss reader (but not their website...) with more. Basically it combines cache poisoning (racing to resolve AAAA.VICTIM.COM, AAAB., etc.) with Additional RRs that are in scope of the domain to force the poisoning up from the spoofed subdomain. If I read it right, it leads to cache poisoning of the entire, arbitrary domain for the resolver as a whole and anyone who queries it.
posted by Skorgu at 1:27 PM on July 21, 2008
At the risk of pissing off Kaminsky (because, let's face it, he's the last guy you want mad at you), here's a copy of the response to Skorgu's link that was itself so juicy that it got pulled. (You can't "pull" something you've published on the Web, folks.)
Since I'm here, I gotta share the joy of having your mind blown: read Kaminsky's 2002 presentation on Scanrand [PPT warning]. It's so good that six years later I can remember where I was when I first read it. "Packet content can be overloaded." I'll say!
posted by sdodd at 7:57 PM on July 21, 2008 [1 favorite]
Since I'm here, I gotta share the joy of having your mind blown: read Kaminsky's 2002 presentation on Scanrand [PPT warning]. It's so good that six years later I can remember where I was when I first read it. "Packet content can be overloaded." I'll say!
posted by sdodd at 7:57 PM on July 21, 2008 [1 favorite]
Zero Day's summary. I don't really see where they get off calling it a 'debacle.'
I certainly didn't expect the embargo to last till August but I don't reasonably see what anyone involved could have done differently. Sure Matasano probably should have exercised tighter control on their part and they're eating crow for it but besides that this looks like a decent compromise (hell, nearly exactly 15 days of 30) between the full-disclosure crowd and the disclose-later crowd. Who, realistically, are never going to agree.
posted by Skorgu at 8:22 AM on July 22, 2008
I certainly didn't expect the embargo to last till August but I don't reasonably see what anyone involved could have done differently. Sure Matasano probably should have exercised tighter control on their part and they're eating crow for it but besides that this looks like a decent compromise (hell, nearly exactly 15 days of 30) between the full-disclosure crowd and the disclose-later crowd. Who, realistically, are never going to agree.
posted by Skorgu at 8:22 AM on July 22, 2008
Having read the presumed explanation ... so clever, and like so many clever things seems so obvious in retrospect. Effugas is a ninja. I envy my blackhat-bound coworkers.
posted by These Premises Are Alarmed at 9:32 AM on July 22, 2008
posted by These Premises Are Alarmed at 9:32 AM on July 22, 2008
> I envy my blackhat-bound coworkers.
At first I didn't realize you meant that your coworkers were going to the Black Hat conference -- I thought you meant your coworkers were going to become black hat hackers. I was very much interested in exactly how that sort of thing could happen. Recruiting drive? Exchange program?
posted by sdodd at 3:11 PM on July 22, 2008
At first I didn't realize you meant that your coworkers were going to the Black Hat conference -- I thought you meant your coworkers were going to become black hat hackers. I was very much interested in exactly how that sort of thing could happen. Recruiting drive? Exchange program?
posted by sdodd at 3:11 PM on July 22, 2008
Threat level interview.
Speaking of clever, the DNS server test (here or a widget on Kaminsky's blog) that returns a result evaluating the randomness of your source ports is great. We had a 'fully patched' server, but after running this test realized a config option in BIND was still restricting the source ports.
Type "nslookup -type=txt -timeout=30 porttest.dns-oarc.net", please.
posted by These Premises Are Alarmed at 6:16 AM on July 23, 2008
Speaking of clever, the DNS server test (here or a widget on Kaminsky's blog) that returns a result evaluating the randomness of your source ports is great. We had a 'fully patched' server, but after running this test realized a config option in BIND was still restricting the source ports.
Type "nslookup -type=txt -timeout=30 porttest.dns-oarc.net", please.
posted by These Premises Are Alarmed at 6:16 AM on July 23, 2008
Given the grave situation we are in, please, post and send the leaked details to whoever needs them to justify a fix. I know I put a lot of people in a situation they did not have procedure for. Some patched, some started patching, some couldn't yet patch.
The first set is larger than I imagined it could be.
The second set is in more danger than I'd like.
The third set can now get to work.
posted by effugas at 10:19 PM on July 23, 2008
The first set is larger than I imagined it could be.
The second set is in more danger than I'd like.
The third set can now get to work.
posted by effugas at 10:19 PM on July 23, 2008
sdodd--
Remind me to finally upload Paketto 2.99, you know, with versions of Scanrand that still compile :)
posted by effugas at 10:19 PM on July 23, 2008
Remind me to finally upload Paketto 2.99, you know, with versions of Scanrand that still compile :)
posted by effugas at 10:19 PM on July 23, 2008
OpenDNS Wildly Popular After Kaminsky Flaw Disclosure
posted by homunculus at 4:00 PM on August 6, 2008
posted by homunculus at 4:00 PM on August 6, 2008
The PowerPoint slide deck from Kaminsky's talk is available. I just finished reading it. As I read the first couple dozen slides my shoulders sagged and my head drooped with the gathering sense of doom. It's unpleasant when so many of your fundamental assumptions are counterfeited all at once.
And then along comes slide 77: "Domain Validation: How SSL Certificate Authorities use DNS to determine whether you get a certificate," and it's like a punch in the gut. But slide 82, "Click here if you forgot your password," is the kick square in the nuts.
Forget about Hollywood horror movies and TV shows about serial killers. This presentation is scary.
posted by sdodd at 12:44 PM on August 7, 2008
And then along comes slide 77: "Domain Validation: How SSL Certificate Authorities use DNS to determine whether you get a certificate," and it's like a punch in the gut. But slide 82, "Click here if you forgot your password," is the kick square in the nuts.
Forget about Hollywood horror movies and TV shows about serial killers. This presentation is scary.
posted by sdodd at 12:44 PM on August 7, 2008
Kaminsky's Grandmother Bakes Session Cookies for Black Hat
posted by homunculus at 3:05 PM on August 7, 2008 [1 favorite]
posted by homunculus at 3:05 PM on August 7, 2008 [1 favorite]
Can't believe I missed the thread while it had started.
A lot of us OS X admins (and just admins who deal with Apple) are really pretty upset at how Apple handled this whole thing.
They rolled this patch out 3 weeks after everyone else, and it was bundled with other security updates. Where they waiting so they didn't have to post update after update (ARDAgent.app permission escalation was a big deal also, took them 3 months to patch).
John C Welch summarizes a lot of our frustration here.
To add insult to injury, one admin who *did* get a response from someone at Apple (by submitting a bug report under the subject of feature enhancement, "speed up delay in security responses"), that said: "we are working on it, but don't see it as a rush, as it does not appear to be targeting our customers yet, and we are seeing some issues with some of our customers with the patch, so we don't want to rush it"... It's not like they can get root on an unpatched dns server guys, it is about how the protocol is broken, and to delay your update for a product you claims requires "no IT" because you let people setup improper configurations isn't that great of an answer either.
Of course, they STILL haven't fixed the clients yet.
And then there is the fact that people are seeing performance issues with the -p1 version of the patch for BIND, and looks like there will be a -P2 version soon. No statement from Apple when that will come out, so people will have to suffer with the performance hit until Apple gets around to testing it out.
posted by mrzarquon at 10:18 PM on August 8, 2008
A lot of us OS X admins (and just admins who deal with Apple) are really pretty upset at how Apple handled this whole thing.
They rolled this patch out 3 weeks after everyone else, and it was bundled with other security updates. Where they waiting so they didn't have to post update after update (ARDAgent.app permission escalation was a big deal also, took them 3 months to patch).
John C Welch summarizes a lot of our frustration here.
To add insult to injury, one admin who *did* get a response from someone at Apple (by submitting a bug report under the subject of feature enhancement, "speed up delay in security responses"), that said: "we are working on it, but don't see it as a rush, as it does not appear to be targeting our customers yet, and we are seeing some issues with some of our customers with the patch, so we don't want to rush it"... It's not like they can get root on an unpatched dns server guys, it is about how the protocol is broken, and to delay your update for a product you claims requires "no IT" because you let people setup improper configurations isn't that great of an answer either.
Of course, they STILL haven't fixed the clients yet.
And then there is the fact that people are seeing performance issues with the -p1 version of the patch for BIND, and looks like there will be a -P2 version soon. No statement from Apple when that will come out, so people will have to suffer with the performance hit until Apple gets around to testing it out.
posted by mrzarquon at 10:18 PM on August 8, 2008
« Older Good dance moves for two right feet | Futility Closet Newer »
This thread has been archived and is closed to new comments
- SECURITY UPDATE: Randomize UDP query source ports to improve forgery resilience.
- References CVE-2008-1447
So it's already been "revealed"... transparency always trumps cloak-and-dagger in software security.posted by mindsound at 7:20 PM on July 9, 2008