I wonder how long until patch. Or is this something adjustable in configuration?
Socially, I'll be watching to see how this plays out in the security community, media, and various fora. How critical will this vulnerability be rated? What reactions will we get to the rapid disclosure, rather than the notify-and-wait or high-secrecy project models of disclosure? What about Kris Kaspersky's vulnerabilities? Will Zone Alarm firewalls freak out again?
It'll be an interesting ride.
Discussion on:
View:
Show:
I thought using caps randomization on the FQDN was totally cool. Someone was indeed thinking outside the box. All sorts of extra entropy at virtually no cost.
In fact, randomizing the FQDN that way really helps people that have not been using query port randomization because their NAT routers and firewalls wouldn't allow it or the NAT router de-randomized the query port.
As for Kaspersky's claim, it appears that he's pulling a Kaminsky and will not reveal the jewels until the "Hack in the Box" security conference in October. Maybe it's the same sort of thing and he's giving vendors time to fix DNS.
His claim is that both Transaction ID and query port randomization aren't enough. The DNS experts already knew adding query port randomization is just a stop-gap fix. As is randomizing the FQDN. They couldn't say that we have to do this as it raises the security bar, but it's still broken. I must admit though Kaminsky in a sense did allude to that on his web site.
DNSSEC or a variation will be the ultimate answer, but that will take a huge mount of work and that's after they figure out several irritating deliver issues.
In fact, randomizing the FQDN that way really helps people that have not been using query port randomization because their NAT routers and firewalls wouldn't allow it or the NAT router de-randomized the query port.
As for Kaspersky's claim, it appears that he's pulling a Kaminsky and will not reveal the jewels until the "Hack in the Box" security conference in October. Maybe it's the same sort of thing and he's giving vendors time to fix DNS.
His claim is that both Transaction ID and query port randomization aren't enough. The DNS experts already knew adding query port randomization is just a stop-gap fix. As is randomizing the FQDN. They couldn't say that we have to do this as it raises the security bar, but it's still broken. I must admit though Kaminsky in a sense did allude to that on his web site.
DNSSEC or a variation will be the ultimate answer, but that will take a huge mount of work and that's after they figure out several irritating deliver issues.
Simple idea, using an existing option. Very efficient thinking.
I hope the additional entropy will buy enough time to really implement a new model for DNS, be it some version of DNSSEC or something new (or currently unknown).
I hope the additional entropy will buy enough time to really implement a new model for DNS, be it some version of DNSSEC or something new (or currently unknown).
I suspect that it will be yet another race. With the proof-of-concept attack validated, it only requires methods that will make it more efficient.
I'd be interested to see how the mainstream media would cover this (if they ever did) - I always shudder when they try to talk tech but something like this, I can only imagine how they'd mangle the explanation. Then everybody I know would be asking me "Is it true the Internet is poisonous?" or "is it safe to go on the interweb anymore?" or some variation.
Big media will never report this, it's just not sexy enough. So what, the entire planet could suddenly be cast asunder, in the dark, unable to communicate or conduct commerce... ho-hum. Are there any interns involved?
I have another very interesting piece coming up this week hopefully. It's another one of those that everyone should be aware of.
Hopefully the Georgian internet has been hardened.
Did DNS server poisoning serve as an attack vector?
Did DNS server poisoning serve as an attack vector?
If so, yes it was a DNS cache poisoning attack.
The idea was to totally overwhelm the DNS server under attack with fake query responses in order to see if he could get a collision. Which means that one of the fake query responses had the correct Transaction ID and query port. That packet will get accepted along with the payload which carries the IP address of the attacker's DNS server.
From that point on, when a query is sent for that specific domain, the attacker's DNS server is now authoritative and most likely will return an IP address for a spoofed site.
It boils down to a race between the attacker and the real authoritative DNS server. With the attacker having to guess the Transaction ID and query port.
The idea was to totally overwhelm the DNS server under attack with fake query responses in order to see if he could get a collision. Which means that one of the fake query responses had the correct Transaction ID and query port. That packet will get accepted along with the payload which carries the IP address of the attacker's DNS server.
From that point on, when a query is sent for that specific domain, the attacker's DNS server is now authoritative and most likely will return an IP address for a spoofed site.
It boils down to a race between the attacker and the real authoritative DNS server. With the attacker having to guess the Transaction ID and query port.
Actually my query was in regards to Georgia/Russia and the recent cyberspace-warfare.
Warfare tends to lead to faster advances than otherwise occur.
http://en.wikipedia.org/wiki/2008_South_Ossetia_war#Cyberattacks_and_censorship
Unfortunately this article is lacking in detail. It earlier had references to rental use of one or more of the major botnets. but "wikiality" is transient...
http://en.wikipedia.org/wiki/Wikipedia:Wikiality_and_Other_Tripling_Elephants
Warfare tends to lead to faster advances than otherwise occur.
http://en.wikipedia.org/wiki/2008_South_Ossetia_war#Cyberattacks_and_censorship
Unfortunately this article is lacking in detail. It earlier had references to rental use of one or more of the major botnets. but "wikiality" is transient...
http://en.wikipedia.org/wiki/Wikipedia:Wikiality_and_Other_Tripling_Elephants
I suspect that DDoS and just bombing DNS servers would be more what's going on. There's no real need to be subtle about things, unless there was an underlying reason like covert ops I suppose.
They are repeatedly and massively requesting pages from the affected sites, which will prevent legitimate requests from succeeding.
Any number of methods could accomplish this. They could be using botnets or dedicated machines to repeatedly connect to the sites. I suppose you could actually ask for millions of people to repeatedly try to access the site and get the same results, but automation is much simpler and more reliable if one is serious about the DDoS attack.
Any number of methods could accomplish this. They could be using botnets or dedicated machines to repeatedly connect to the sites. I suppose you could actually ask for millions of people to repeatedly try to access the site and get the same results, but automation is much simpler and more reliable if one is serious about the DDoS attack.
I found it before I found your post here.
Again, an excellent piece of work.
Again, an excellent piece of work.
gigE unrealistic? How about distributed computing via storm worm... 10hours or maybe just a few seconds.
It's sort of a catch-22 syndrome. DNS is rapidly reaching bandwidth capacity, so logically you increase that. Which in turn creates more capacity for an attacker to use in trying to beat the authoritative query response back to the recursive name server.
In the article, you say: "At a minimum, the FQDN will add 6-bits of entropy, three from www and three from the top-level domain characters (.com, .net, and so on)."
This assumes that every queried FQDN starts with "www" and ends with a three-letter TLD, which is not an accurate assumption.
TLDs can be as short as 2 letters (eg. most country code TLDS, .us, .uk, .ru, .de, etc.) and the second-level domain component can be as short as a single character, but IIRC, it must be a letter if it only has one character. Also, many query FQDNs do not contain the "www" prefix, nor do they need it in many cases, even for web traffic.
Thus, a domain name like g.cn (Google in China) represents an example of the minimum bytes of entropy added by the 0x20 proposal, at 3 bytes.
Regards,
Jon Heese
This assumes that every queried FQDN starts with "www" and ends with a three-letter TLD, which is not an accurate assumption.
TLDs can be as short as 2 letters (eg. most country code TLDS, .us, .uk, .ru, .de, etc.) and the second-level domain component can be as short as a single character, but IIRC, it must be a letter if it only has one character. Also, many query FQDNs do not contain the "www" prefix, nor do they need it in many cases, even for web traffic.
Thus, a domain name like g.cn (Google in China) represents an example of the minimum bytes of entropy added by the 0x20 proposal, at 3 bytes.
Regards,
Jon Heese
I forgot two simple words "for example" Thanks for pointing it out, Jon.
Has there ever actually been a confirmed case of this?
Quote:
BIND used fully randomized source port range, i.e. around 64000 ports. Two attacking servers, connected to the attacked one via GigE link, were used, each one attacked 1-2 ports with full ID range.
Don't DNS servers have firewalls? It seems like this would be easily fixed by blocking a particular IP range that send too many incorrect requests very quickly. Or have I missed the point completely?
Quote:
BIND used fully randomized source port range, i.e. around 64000 ports. Two attacking servers, connected to the attacked one via GigE link, were used, each one attacked 1-2 ports with full ID range.
Don't DNS servers have firewalls? It seems like this would be easily fixed by blocking a particular IP range that send too many incorrect requests very quickly. Or have I missed the point completely?
This is a brute force attack (possibly also
a form of DoS).After a set threshold (3
attempts from the same IP address?) that IP
address gets blocked. If the attack takes
10 hours on such a fast network - with a
direct connection that means a LARGE number
of packets need to be sent - even changing
your IP address in a pure class A network
will soon soon fall foul of the limit.
Make it so the count can only be manually
reset by an admin who is notified of
failled attempts - this may help in
locating bots. Having an auto-reset after a
time period would allow attackers to just
space out their attempts (if it is a big
target, does the difference between 10
hours and 10 weeks really matter?)
Based on the above article, it looks like
this researcher has only proven the success
of the previous fix. He has basically used
the same attack vector and shown that, even
on the latest and greatest equipment it
still takes several hours (on average) to
be successful.
a form of DoS).After a set threshold (3
attempts from the same IP address?) that IP
address gets blocked. If the attack takes
10 hours on such a fast network - with a
direct connection that means a LARGE number
of packets need to be sent - even changing
your IP address in a pure class A network
will soon soon fall foul of the limit.
Make it so the count can only be manually
reset by an admin who is notified of
failled attempts - this may help in
locating bots. Having an auto-reset after a
time period would allow attackers to just
space out their attempts (if it is a big
target, does the difference between 10
hours and 10 weeks really matter?)
Based on the above article, it looks like
this researcher has only proven the success
of the previous fix. He has basically used
the same attack vector and shown that, even
on the latest and greatest equipment it
still takes several hours (on average) to
be successful.
The attacker spoofs the IP address of the authoritative name server using a malformed packet (via raw sockets). Remember the DNS query response needs to have the correct IP address and correct port or the querying recursive name server will not accept the response.
So, you can't block that port or IP address.
So, you can't block that port or IP address.
As far as I know the latest attack is so new, (you heard it here almost first) that all DNS applications maybe vulnerable. I haven't read anything further, but I understand that all versions are going through the testing process.
Also there's no way for any of us to test our IPS's DNS server against this attack as of yet.
If any of the members have heard otherwise I really appreciate hearing about it.
Also there's no way for any of us to test our IPS's DNS server against this attack as of yet.
If any of the members have heard otherwise I really appreciate hearing about it.
as a quick fix to allow site visitors to verify the site would be to post the site's ip address, and suggest that visitors ping the site name and verify they are getting the ip address posted.
it doesn't stop the poisoning, nor is it a perfect solution, but if the site puts it's ip address up in an anti-bot "captcha" block it can help to improve visitor confidence until the dns system is fixed.
it doesn't stop the poisoning, nor is it a perfect solution, but if the site puts it's ip address up in an anti-bot "captcha" block it can help to improve visitor confidence until the dns system is fixed.
I like your line of thought, but wouldn't the user have to do that after actually being at the web site? So if the web site is spoofed, so could the the IP address that's supposed to be checked.
Does that make sense?
Does that make sense?
it's not perfect.
most people don't visit new sites that often, they hit a number of sites regularly, these sites they use daily they would see the ip in the catpcha box and might then twig if the dns cache serving the site is suddenly poisoned by an ip change in the captcha box.
Like the regular visitors to TR, most would notice an ip change, if the spoof site used the correct ip for TR hen a ping would show it as a spoof.
Big sites, like Amazon, Ebay, Paypal, Google, Yahoo, MSN would improve visitor confidence with it as a temporary measure to help protect visitors, the little guys wouldn't be getting the traffic levels to make spoofing them worthwhile generally.
most people don't visit new sites that often, they hit a number of sites regularly, these sites they use daily they would see the ip in the catpcha box and might then twig if the dns cache serving the site is suddenly poisoned by an ip change in the captcha box.
Like the regular visitors to TR, most would notice an ip change, if the spoof site used the correct ip for TR hen a ping would show it as a spoof.
Big sites, like Amazon, Ebay, Paypal, Google, Yahoo, MSN would improve visitor confidence with it as a temporary measure to help protect visitors, the little guys wouldn't be getting the traffic levels to make spoofing them worthwhile generally.
with McAfee. Impractical of course. I'm just trying to make light in my moment of terror! 
That's a good idea, just as long as they don't use DNS queries to the authoritative name servers. (Sorry, my poor attempt at humor.)
It's certainly an interesting subject and I wish I understood it more completely.
My next article is about SSL certificates and should be out today some time.
it seems good, but I am unclear on where its implemented, in the browser by the client, or on an isp level dns server? Where does the case randomization get initiated?
Time for google i guess...
Time for google i guess...
I like the 0x20 proposal a great deal as it's a clean hack and gains a great deal of entropy for virtually no cost.
It's a fix though and not a solution. DNS is just too important to have stop-gap measures all of the time.
The fix would be applied to recursive name servers or any device that queries authoritative names servers
It's a fix though and not a solution. DNS is just too important to have stop-gap measures all of the time.
The fix would be applied to recursive name servers or any device that queries authoritative names servers
I can't verify this but, there's evidence being discussed that some ISPs are capturing user DNS queries and resending them to the ISP's designated name servers.
I was listening to a Steve Gibson "Security Now" podcast and this was the portion that really caught my attention:
"Question from a listener:
Long ago I changed my static DNS entries in my Linksys home wireless to the IP addresses of OpenDNS. So during the recent discussions of DNS vulnerability I thought I had little to worry about.
However, the other day I fat-fingered a web request and got a Charter Communications "not found" result page. Wait a minute. Confused by this, I began to research. My router settings had not changed, and my client machine's IP config showed DNS set to the router IP and the two IP addresses of OpenDNS. Yet when I went to the DoxPara test page I found my DNS server was vulnerable to DNS cache poisoning, with all the requests being sent out over a single port. Anyway, Whois found that the IP address identified by DoxPara is owned by Charter Communications.
LEO: Well, that's - huh? That's interesting. I guess that's who's hosting his site. My questions are many. How could Charter intercept these? Oh. Maybe they don't own his site.
STEVE: Exactly.
LEO: How could I stop them from intercepting my DNS requests and use a security-aware DNS service? What are my options? So let me recap to make sure I understand. He's using OpenDNS, so theoretically all his DNS should go through it. But for some...
STEVE: Well, let's say he's configured to use OpenDNS.
LEO: For some reason Charter is intercepting these. What's going on?
STEVE: This is a problem. This means that, okay, and think about it, DNS is over UDP, that is not connection oriented and that has no TCP connection. And his ISP could do anything it wants with his packets. So they are receiving DNS queries coming from his network, out of his router, with a destination IP on the packet of OpenDNS. They know that it's a DNS query because it's aimed at port 53, which is a universal DNS query port. All DNS servers are listening for incoming UDP and TCP traffic on their port 53. Charter, for whatever reason, perhaps for the purpose of intercepting and putting up their own advertising page, they're ignoring the destination IP of his DNS packets and changing them, rewriting them to their own. So that...
LEO: Oh, man.
STEVE: ...no matter what he does, no matter what DNS configuration he uses at home, Charter is ignoring the destination IP, rewriting his packets on the fly so that they go to their DNS server. And if he, as he says, "fat-fingered," which I think means typo...
LEO: Mistyped it, yeah.
STEVE: Mistyped it. Then instead of his browser being told there's nothing at that IP, he's given an IP, his browser is given an IP of a server that Charter is running that brings up their own interception page for whatever purposes they choose.
LEO: Usually advertising. VeriSign did this for a while, and it was very...
STEVE: And, boy, they didn't do it for long because it really upset people.
LEO: A lot of ISPs do that. And they say, well, we do it as a convenience, we have a much better page. And it's true, if you don't do that, then you get that stupid Internet Explorer page saying I can't get anywhere.
STEVE: Okay, well, two things. First of all, you said many ISPs do this?
LEO: Yeah.
STEVE: The only way to do it is rewriting DNS.
LEO: Ah, interesting. Of course, yeah, of course.
STEVE: So that means all the ISPs that are able to present their own page are doing so by preventing you from going to the DNS server you have asked for. And secondly you'll notice that he ran the test at DoxPara, and it said all your requests are coming from one port. So not only is his ISP screwing up his deliberately configured-for-security DNS, but they're aiming it at an insecure server.
LEO: They're doing a bad job.
STEVE: Exactly. They've got a spoofable server, and they're forcing all of their customers to use their misconfigured spoofable server."
I thought this might be of interest to the members as some have mentioned that they were getting strange returns on the DoxPara DNS randomness test. If this is true than certain ISPs are hijacking DNS queries to known good DNS servers and forcing users to obtain query responses from insecure DNS servers that aren't even randomizing the source port.
I was listening to a Steve Gibson "Security Now" podcast and this was the portion that really caught my attention:
"Question from a listener:
Long ago I changed my static DNS entries in my Linksys home wireless to the IP addresses of OpenDNS. So during the recent discussions of DNS vulnerability I thought I had little to worry about.
However, the other day I fat-fingered a web request and got a Charter Communications "not found" result page. Wait a minute. Confused by this, I began to research. My router settings had not changed, and my client machine's IP config showed DNS set to the router IP and the two IP addresses of OpenDNS. Yet when I went to the DoxPara test page I found my DNS server was vulnerable to DNS cache poisoning, with all the requests being sent out over a single port. Anyway, Whois found that the IP address identified by DoxPara is owned by Charter Communications.
LEO: Well, that's - huh? That's interesting. I guess that's who's hosting his site. My questions are many. How could Charter intercept these? Oh. Maybe they don't own his site.
STEVE: Exactly.
LEO: How could I stop them from intercepting my DNS requests and use a security-aware DNS service? What are my options? So let me recap to make sure I understand. He's using OpenDNS, so theoretically all his DNS should go through it. But for some...
STEVE: Well, let's say he's configured to use OpenDNS.
LEO: For some reason Charter is intercepting these. What's going on?
STEVE: This is a problem. This means that, okay, and think about it, DNS is over UDP, that is not connection oriented and that has no TCP connection. And his ISP could do anything it wants with his packets. So they are receiving DNS queries coming from his network, out of his router, with a destination IP on the packet of OpenDNS. They know that it's a DNS query because it's aimed at port 53, which is a universal DNS query port. All DNS servers are listening for incoming UDP and TCP traffic on their port 53. Charter, for whatever reason, perhaps for the purpose of intercepting and putting up their own advertising page, they're ignoring the destination IP of his DNS packets and changing them, rewriting them to their own. So that...
LEO: Oh, man.
STEVE: ...no matter what he does, no matter what DNS configuration he uses at home, Charter is ignoring the destination IP, rewriting his packets on the fly so that they go to their DNS server. And if he, as he says, "fat-fingered," which I think means typo...
LEO: Mistyped it, yeah.
STEVE: Mistyped it. Then instead of his browser being told there's nothing at that IP, he's given an IP, his browser is given an IP of a server that Charter is running that brings up their own interception page for whatever purposes they choose.
LEO: Usually advertising. VeriSign did this for a while, and it was very...
STEVE: And, boy, they didn't do it for long because it really upset people.
LEO: A lot of ISPs do that. And they say, well, we do it as a convenience, we have a much better page. And it's true, if you don't do that, then you get that stupid Internet Explorer page saying I can't get anywhere.
STEVE: Okay, well, two things. First of all, you said many ISPs do this?
LEO: Yeah.
STEVE: The only way to do it is rewriting DNS.
LEO: Ah, interesting. Of course, yeah, of course.
STEVE: So that means all the ISPs that are able to present their own page are doing so by preventing you from going to the DNS server you have asked for. And secondly you'll notice that he ran the test at DoxPara, and it said all your requests are coming from one port. So not only is his ISP screwing up his deliberately configured-for-security DNS, but they're aiming it at an insecure server.
LEO: They're doing a bad job.
STEVE: Exactly. They've got a spoofable server, and they're forcing all of their customers to use their misconfigured spoofable server."
I thought this might be of interest to the members as some have mentioned that they were getting strange returns on the DoxPara DNS randomness test. If this is true than certain ISPs are hijacking DNS queries to known good DNS servers and forcing users to obtain query responses from insecure DNS servers that aren't even randomizing the source port.
He Sean,
What did you think about Charter and spoofing the user DNS?
What did you think about Charter and spoofing the user DNS?
The IETF is here in Minneapolis MN debating several topics, one of which is what to do about the Kaminsky bug:
http://www.ietf.org/meetings/73/
NetworkWorld has an interesting article about the proceedings:
http://www.networkworld.com/news/2008/112008-ietf-dns-debate.html?netht=rn_112008&nladname=112008
http://www.ietf.org/meetings/73/
NetworkWorld has an interesting article about the proceedings:
http://www.networkworld.com/news/2008/112008-ietf-dns-debate.html?netht=rn_112008&nladname=112008
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
