Google, Roku, Sonos To Fix DNS Rebinding Attack Vector (bleepingcomputer.com) 56
The developer teams from Google Home, Roku TV, and Sonos, are preparing security patches to prevent DNS rebinding attacks on their devices. From a report: Roku has already started deploying updates, while Google and Sonos are expected to deploy patches next month. DNS rebinding is not a new attack vector by any stretch of the imagination. Researchers have known about it since 2007 when it was first detailed in a Stanford research paper. The purpose of a DNS rebinding attack is to make a device bind to a malicious DNS server and then make the device access unintended domains.
Browser solution (Score:1)
Browsers could start ignoring DNS answers that point to addresses in the local LAN, unless the request was for a record that matches the local DNS domain or the answer comes from mDNS. That should be a relatively quick 90% solution that still keeps e.g. Active Directory working. It will even work for both IPv4 and IPv6.
And yes, fellow Slashdotters, I know you have networks where such assumptions will break. You also have the knowledge to enter about:config or to reconfigure your DNS server or network as app
Re: (Score:2)
Yes, and this story has nothing to do with browsers.
In most cases the only thing you can achieve with a DNS rebind attack is sending a HTTP or HTTPS request to a target. Usually it will be a browser that sends that request. Many modern email clients can also send HTTP(S) requests, I had forgotten to consider those since I find that extremely silly.
But you are right, email clients that implement HTTP(S) should just a) stop doing that (I know, won't happen) or at least b) block all HTTP(S) access to RFC1918, RFC6598, link-local IPv6, ULA IPv6. And those client
Re: (Score:2)
That is only a fraction of the attack vector they are mentioning. The rest of it will be making devices connect to valid public IP addresses.
Example, the user types www.mybank.com and he is directed to the fake hacker site that looks just like his bank site and the hacker steals your credentials when you enter them.
Re: (Score:3, Informative)
For DNS rebind to work like that, the hacker has control of the DNS servers hosting your bank's domain.
That's already pretty bad news. With complete DNS control of your banks domain they can obtain certificates and pose as a secure copy of your banks website and steal your credentials that way. No DNS rebind attack required.
Public websites that are hosted as virtual hosts aren't vulnerable to rebind attackers either, as they use the HTTP Host header to determine how to handle the request. A rebind attack me
Re: (Score:3)
"With complete DNS control of your banks domain they can obtain certificates and pose as a secure copy of your banks website and steal your credentials that way."
yea, um no... you can't "just get a certificate" like that.
You have to get a publicly trusted CA to issue you a Certificate for a domain you don't own and a CA is not going to do that unless they want to risk going out of business or becoming untrusted defeating the entire purpose of being a CA. And if you go an create your own, well how are you g
Re: (Score:2)
See my other post just below.
For DNS rebind to work like that, the hacker has control of the DNS servers hosting your bank's domain.
Nope, sorry this is not how it works.
1) You would simply make the device connect to your fake DNS server.
2) In your fake DNS server, you would simply hardcode your fake web server IP to return when asked to resolve "www.mybank.com" so, there is no need to control the bank DNS server.
3) In your website virtualhosts config, you would simply create a domain "www.mybank.com"
This is not only limited to web attacks but it extents to anything trying to connect anywhere by hostname.
Some user will just enter mybank.com to connect to their bank. Normally, the website will redirect them to https://www.mybank.com/ [mybank.com] (TLS site). Your fake website won't and will allow connections with plain http. No certificate needed.
Remember that for such an attack to pay off, only 1% of users falling for it is a lot!
Obviously, this isn't limited to banking sites and HTTP connections.
That's not DNS rebind. Rebind attacks local (Score:2)
If you get the victim to start using an attacker-controlled DNS server, you can indeed do bad things. That's not what DNS rebind is, though.
Let me explain what DNS rebind is.
The attacker creates a web page which has an iframe for http://nest.attacker.net/temp/... [attacker.net]
The attacker sets the DNS record to for nest.attacker.net to be 192.168.1.2
The browser then connects to 192.168.1.2, which is the victims thermostat, and requests temp/90
The victim has now turned their thermostat up to 90
--
The attacker doesn't know
Re: (Score:2)
Give me control of your domains DNS server and I'll get a Let's Encrypt certificate issued in 5 minutes.
Let's Encrypt use the ACME protocol to verify control of the domain. It's a completely automated process requiring only a webserver running on the IP address listed on the A record of the domain.
Re: (Score:2)
For DNS rebind to work like that, the hacker has control of the DNS servers hosting your bank's domain.
Nope, sorry this is not how it works.
1) You would simply make the device connect to your fake DNS server.
2) In your fake DNS server, you would simply hardcode your fake web server IP to return when asked to resolve "www.mybank.com" so, there is no need to control the bank DNS server.
3) In your website virtualhosts config, you would simply create a domain "www.mybank.com"
This is not only limited to web attacks but it extents to anything trying to connect anywhere by hostname.
Re: (Score:2)
1) You would simply make the device connect to your fake DNS server.
That is not part of the DNS Rebind attack. You can accomplish that WITH a DNS Rebind attack that messes with the CPE settings, but then you have already won. My proposal stops the DNS Rebind attack from messing with the CPE settings in the first place.
Re: (Score:2)
That can be mitigated by HSTS being used by your bank
Their browser would refuse to connect without HTTPS to www.mybank.com if they have already visited it before, therefore requiring the attacker to have a valid certificate to perform the redirect.
Your scenario also requires control of the network configuration of the victim.
A DNS rebind attack is re-binding a domain during an attack to a different IP to get around same origin protections.
What you described is not a DNS rebind attack, it's DNS hijacking. Th
Re: (Score:2)
Example, the user types www.mybank.com and he is directed to the fake hacker site that looks just like his bank site and the hacker steals your credentials when you enter them.
That is not a rebind attack. You'd need a cache poisoning attack or a full takeover of the victim's DNS server to do that. My mitigation obviously does not fix that, that's what certificates are for.
Re: (Score:2)
That is not a rebind attack.
You are correct. I didn't know the term and reading TFS and TFA didn't help me.
So, I googled for it and reading the Wikipedia page enabled me to understand in 2 paragraphs.
Thanks!
https://en.wikipedia.org/wiki/... [wikipedia.org]
The attacker registers a domain (such as attacker.com) and delegates it to a DNS server under the attacker's control. The server is configured to respond with a very short time to live (TTL) record, preventing the response from being cached. When the victim browses to the malicious domain, the attacker's DNS server first responds with the IP address of a server hosting the malicious client-side code. For instance, they could point the victim's browser to a website that contains malicious JavaScript or Flash scripts that are intended to execute on the victim's computer.
The malicious client-side code makes additional accesses to the original domain name (such as attacker.com). These are permitted by the same-origin policy. However, when the victim's browser runs the script it makes a new DNS request for the domain, and the attacker replies with a new IP address. For instance, they could reply with an internal IP address or the IP address of a target somewhere else on the Internet.
Re:Browser solution (Score:4, Insightful)
NO NO NO NO NO NO NO NO NO!!!!!
Don't even DARE to come up with the idea that browsers should be performing these functions. The browser needs to do only one thing... trust the DNS server that gave it data because the USER or Admins configured it... OTHER more suitable tools (like inline network devices/services) should be doing this security. It is NOT just about what will or will not break with this, it is also about the thought of Google, Microsoft, Firefox, and Opera deciding what is good or bad DNS and then also dealing with false positives and bugs that is going to definitely come with attempting this. Not only that but this kind of functionality will now be tested on browsers and become included in their "security profiles".
It's just a terrible terrible idea, like putting a governor in every car connected to GPS to make sure it NEVER goes over the speed limit.
Hackers would waste NO TIME in compromising this garbage in a browser and system would become even less secure just having it in them NOT MORE secure.
I cannot expound on how terrible the idea you just had is!
Re: (Score:3)
Bad news:
https://blog.nightly.mozilla.o... [mozilla.org]
Firefox and chrome are both advocating for ignoring the system DNS resolver and baking DNS resolving into their code (also, shifting from DNS over UDP to DNS over HTTPS, with etiher json or the traditional binary format. Instead of trusting your dns server, it trusts https://mozilla.cloudflare-dns... [cloudflare-dns.com] as the equivalent of the DNS server, ignoring the local network suggested settings.
Of course, I presume they must be doing something to support non-internet names to b
Re: (Score:2)
DNS recursive servers are notoriously bad. Anything that comes in through DNS should be viewed with extreme suspicion, unless it is DNSSEC validated.
You COULD implement my proposed defense in the recursive DNS server, like OpenDNS has an option to do, instead of in the browser itself. However, that would mean you are exposed when connecting to a public hotspot with a captive portal that mangles DNS requests and prevents you from connecting to a trustworthy server.
Re: (Score:2)
Browsers could start ignoring DNS answers that point to addresses in the local LAN,
Despite your original post seeming intelligent, this is not. Are you really this naive about the typical home broadband installation? Where almost always the router is doing DNS duty, thereby pushing out on DHCP itself as the first DNS server. This is standard on millions of devices, and you propose breaking it?
Re: (Score:2)
Despite your original post seeming intelligent, this is not. Are you really this naive about the typical home broadband installation? Where almost always the router is doing DNS duty, thereby pushing out on DHCP itself as the first DNS server. This is standard on millions of devices, and you propose breaking it?
No, that is not my proposal. It is perfectly valid for the local CPE to be DNS server.
Imagine that the client, 192.168.1.10/24 asks the CPE, 192.168.1.1, what is the A record for www.harmless.com? 192.168.1.1 answers www.harmless.com IN A 88.44.22.11, which is a public internet address, so the browser accepts the answer. Then the same thing happens except the request is for evil.attacker.com, and it gets the answer (again coming from the CPE 192.168.1.1) evil.attacker.com IN A 192.168.1.50, which happens to
Re: (Score:2)
Enterprise networks can implement any policies they want in the DNS servers that they force the employees, or they can go extra evil and simply intercept all DNS requests from clients. They do not need the browser to help them, and if they do, they probably have more-easily-exploited holes anyway.
DoS against external targets will be a bit pathetic, SYN packets are small and rebind can't spoof the source. For later packets, the host header won't match, so the target is unlikely to spend more than minimal pro
Please don't break it for "security" (Score:1)
Re: (Score:2)
AFAICT, this proposal is designed to stop exactly that.
Too many people are obviously preventing android devices reporting to google.
Ignore the elephant in the room... (Score:2)
Prevent unknown third parties from running random code on your machine in the first place and this attack vector is nullified.
Quick! Find someone to stick their thumb in that hole over there!
Wrong definition ... (Score:2)
>DNS rebinding attack is to make a device bind to a malicious DNS server and then make the device access unintended domains
Thats not what DNS rebinding is. Impressive for an article to get it wrong while explaining how it works just few lines above :/. You dont "bind" to malicious servers, and you dont "access unintended domains". You contact one domain, and access "unintended" local IPs.
The true reason they are wanting to stop it. (Score:4, Interesting)
PiHole DNS servers
Anyone can pick up a raspberry pi for 35 bucks or fire up a Debian virtual machine and install PiHole dns.
It blocks advertisements at the dns level. I have a roku, Chromecast, and of course kodi attached to my TV, and both the Roku and Chromecast not to mention my tablet never gets ads on YouTube or any streaming service.
I bet this change is to try and stop pihole users from blocking ads on their devices so easily.