Administrators should not wait any longer to install available patches for their nameservers. By assigning a random source port for each DNS query, these ensure that the attacker will not only have to guess the transaction ID, but also the UDP port. Unfortunately, this still does not solve the problem, but only defers it. For that reason, there is talk of introducing DNSSEC across the board, since the authenticity of the responding server is established via PKI key verification.
Originally posted by: paulxcook
I've entered the DNS server IPs into my router and the changes were accepted but I'm still not passing the DNS test. Ideas anybody? I even checked the walkthru on the OpenDNS site to make sure I wasn't stupid and my linksys screen matches theirs.
Originally posted by: RESmonkey
Firefox warned me of a DNS name change in a website I was shopping at; said if I didn't trust it, I should hit CANCEL. I did.
^Is that related to any of this? BTW, this happened earlier today. Firefox figured that a redirection to another *similar site* might be unsafe.
I'm not sure how waiting a month on releasing the exploit details would make it easier to pull off posioning attacks. Now on the other hand I can certainly see how releasing the exploit details early could allow for attacks to be more likely to succeed.Originally posted by: Chiropteran
Originally posted by: ViRGE
If it was ignored, and it was forever, that would be true. But it wasn't ignored, some 100+ vendors all worked on the problem and had patches ready to go on Super Patch Tuesday. And the entire details of the situation were going to be released a month after that, so that everyone had a chance to regression test the patches and get their stuff updated.
Terminating the window for regression testing and patching is irresponsible at best, threatening at worst.
And what if they did wait, and millions of users had bank account numbers stolen in the meantime? Would you have personally paid for all the damage done?
Your router provides its own DNS tables that includes its own entry for "server". Since you switched to OpenDNS, you need to switch to accessing it by IP.Originally posted by: StarsFan4Life
Ok, sort of a problem here. Earlier, I changed my router DNS ip's to the OpenDNS ip's from the first page of this post:
208.67.222.222
208.67.220.220
When I got home today, I tried to log onto my server (media server I have) whose computer name is "Server". When I tried to use Remote Desktop, typing in the computer name would not find the computer. However, if I typed in the IP (192.168.0.100) I could connect.
I ran a tracert to "Server", it did a route all over the internet, finishing with one of the DNS ip's I put in from OpenDNS. Strange.
I took the DNS ip's out that I put in, restarted the router and I could connect to "Server" using RDP. I switched the DNS back to the OpenDNS IP's, I couldn't connect to "Server", but could connect via IP.
Any ideas on why this is?
They're verified to be secure. They've said that they've patched their servers, and by feeding them random subdomain requests for a specific domain, we can see what ports and transaction IDs are used; they're perfectly random like they should be. This is not to say that their service doesn't suck for other reasons, but no one should be poisoning their DNS records.Originally posted by: aphex
I know this has probably been discussed at length somewhere before, and I've been curious about this in the past.
How do we know Open DNS is safe either? (Not necessarily just from this exploit, but in general as well)
Originally posted by: ViRGE
Your router provides its own DNS tables that includes its own entry for "server". Since you switched to OpenDNS, you need to switch to accessing it by IP.Originally posted by: StarsFan4Life
Ok, sort of a problem here. Earlier, I changed my router DNS ip's to the OpenDNS ip's from the first page of this post:
208.67.222.222
208.67.220.220
When I got home today, I tried to log onto my server (media server I have) whose computer name is "Server". When I tried to use Remote Desktop, typing in the computer name would not find the computer. However, if I typed in the IP (192.168.0.100) I could connect.
I ran a tracert to "Server", it did a route all over the internet, finishing with one of the DNS ip's I put in from OpenDNS. Strange.
I took the DNS ip's out that I put in, restarted the router and I could connect to "Server" using RDP. I switched the DNS back to the OpenDNS IP's, I couldn't connect to "Server", but could connect via IP.
Any ideas on why this is?
Originally posted by: StarsFan4Life
Ok, sort of a problem here. Earlier, I changed my router DNS ip's to the OpenDNS ip's from the first page of this post:
208.67.222.222
208.67.220.220
When I got home today, I tried to log onto my server (media server I have) whose computer name is "Server". When I tried to use Remote Desktop, typing in the computer name would not find the computer. However, if I typed in the IP (192.168.0.100) I could connect.
I ran a tracert to "Server", it did a route all over the internet, finishing with one of the DNS ip's I put in from OpenDNS. Strange.
I took the DNS ip's out that I put in, restarted the router and I could connect to "Server" using RDP. I switched the DNS back to the OpenDNS IP's, I couldn't connect to "Server", but could connect via IP.
Any ideas on why this is?
Originally posted by: spidey07
Originally posted by: StarsFan4Life
Ok, sort of a problem here. Earlier, I changed my router DNS ip's to the OpenDNS ip's from the first page of this post:
208.67.222.222
208.67.220.220
When I got home today, I tried to log onto my server (media server I have) whose computer name is "Server". When I tried to use Remote Desktop, typing in the computer name would not find the computer. However, if I typed in the IP (192.168.0.100) I could connect.
I ran a tracert to "Server", it did a route all over the internet, finishing with one of the DNS ip's I put in from OpenDNS. Strange.
I took the DNS ip's out that I put in, restarted the router and I could connect to "Server" using RDP. I switched the DNS back to the OpenDNS IP's, I couldn't connect to "Server", but could connect via IP.
Any ideas on why this is?
Your router supports dynamic DNS registration used by windows. The router will be the DNS server for your LAN and provide itself as the DNS server for clients via DHCP. Windows will register it's name so you have name resolution for that machine. OpenDNS can't be expected, nor should they support that.
Just stick to IP address for now otherwise you'll have to mess with netbios over TCP for name resolution and without a netbios name server that can be real ugly.
Originally posted by: StarsFan4Life
So when will this damn EXPLOIT be fixed. Sounds like someone should be held responsible for the potential to bring down "The Internet"
Originally posted by: RESmonkey
I called my ISP, and there are only min.wage "tech support" people who have no clue.
Originally posted by: RESmonkey
I called my ISP, and there are only min.wage "tech support" people who have no clue.
Usually it's 192.168.1.1Originally posted by: StarsFan4Life
So what do I do here?
Today Black Hat held a preview webcast with [Dan Kaminsky] about the massive DNS bug he discovered. On July 8th, multiple vendors announced a patch for an undisclosed DNS vulnerability. [Dan Kaminisky] did not release the details of the vulnerability at that time, but encouraged security researchers to not release their work, if they did happen to discover the bug. On the 21st, the full description of the vulnerability was leaked.
In today's webcast, [Dan] covered how he felt about the handling of the vulnerability and answered a few questions about it. He started out by talking about how he stumbled across the bug; he was working on how to make content distribution faster by using DNS to find the server closest to the client. The new attack works because DNS servers not using port randomization make it easy for the attacker to forge a response. You can read the specifics of the attack here.
[Dan] talked about the work that had been done since the July 8th announcement. A handful of researchers had contacted him with exact bug in hand, but as requested, did not release the information. When first announced, 86% of all servers voluntarily tested using the checker on doxpara.com were vulnerable. 13 days later, the vulnerability was published and only 52% of the people using the checker are vulnerable. That's not perfect, but 13 days gave plenty of companies enough time to both test and roll out their patches.
[Jerry Dixon], the former Director of the National Cyber Security Division, pointed out that even though the vulnerability was eventually leaked, the patches had already been out for 13 days; this isn't a zero day vulnerability with no fix. So, we're in a fairly good position. That being said, even since our Metasploit announcement yesterday, they've pushed new module code that will take over an entire domain. Security researcher [Rich Mogull] has feels that producing this exploit code quickly was "bullshit" and "only helps the bad guys".
[Dan] pointed out that some related work people have been doing to mitigate DNS cache poisoning using firewalls. [Michael Rash] wrote about using iptables in Linux to randomize outbound requests and [Jon Hart] covered using PF in OpenBSD. The team is actively contacting vulnerable servers to get them to patch. They've also advised IDS vendors to look for multiple replies with the same ID as a telltale sign of this attack.
You can check your DNS servers using the tool on doxpara.com. We've personally switched our machines to OpenDNS's servers 208.67.222.222 and 208.67.220.220. Not only did it give us some piece of mind, but the performance is way better than our ISP's overloaded DNS.