Amazon and Google Patch Major Bug in Their DNS-as-a-Service Platforms (therecord.media) 11
At the Black Hat security conference Wednesday, two security researchers have disclosed a security issue impacting hosted DNS service providers that can be abused to hijack the platform's nodes, intercept some of the incoming DNS traffic, and then map customers' internal networks. From a report: Discovered by Shir Tamari and Ami Luttwak from cloud security company Wiz, the vulnerability highlights the amount of sensitive information collected by managed DNS platforms and their attractiveness from a cyber-espionage and intelligence data collection standpoint.
Also known as DNS-as-a-Service providers, these companies effectively rent DNS servers to corporate entities. While it's not hard to run your own DNS name server, the benefit of using a service like AWS Route53 or the Google Cloud Platform is that companies can offload managing DNS server infrastructure to a third-party and take advantage of better uptime and top-notch security. Companies that sign up for a managed DNS provider typically have to onboard their internal domain names with the service provider. This typically means companies have to go to a backend portal and add their company.com and other domains to one of the provider's name servers (i.e., ns-1611.awsdns-09.co.uk). Once this is done, when a company employee wants to connect to an intranet app or an internet website, their computer will query the third-party DNS server for the IP address it needs to connect. What the Wiz team discovered was that several managed DNS providers did not blacklist their own DNS servers inside their backends.
Also known as DNS-as-a-Service providers, these companies effectively rent DNS servers to corporate entities. While it's not hard to run your own DNS name server, the benefit of using a service like AWS Route53 or the Google Cloud Platform is that companies can offload managing DNS server infrastructure to a third-party and take advantage of better uptime and top-notch security. Companies that sign up for a managed DNS provider typically have to onboard their internal domain names with the service provider. This typically means companies have to go to a backend portal and add their company.com and other domains to one of the provider's name servers (i.e., ns-1611.awsdns-09.co.uk). Once this is done, when a company employee wants to connect to an intranet app or an internet website, their computer will query the third-party DNS server for the IP address it needs to connect. What the Wiz team discovered was that several managed DNS providers did not blacklist their own DNS servers inside their backends.
Why on earth would you ever expose your internal (Score:5, Insightful)
networks to the Internet?
Split DNS, with some external only IP's and no routeable internal networks to or from the Internet. Derp.
Re: (Score:2)
Re: (Score:2)
I don't disagree entirely but "Split DNS" has lead to a lot of confusing, hard to diagnose issue, and its own fair share of security problems.
Really what would be 'good for' most shops and all thumbs admins is filtered DNS. One set of records, but only those explicitly marked public are returned unless the request came from inside, otherwise NXDOMAIN or SRVFAIL.
Of course that is still a config or NAT - related booboo away from fill disclosure but at least that can be tested validated easily.
Re: (Score:2)
I don't disagree entirely but "Split DNS" has lead to a lot of confusing, hard to diagnose issue, and its own fair share of security problems.
Really what would be 'good for' most shops and all thumbs admins is filtered DNS. One set of records, but only those explicitly marked public are returned unless the request came from inside, otherwise NXDOMAIN or SRVFAIL.
Of course that is still a config or NAT - related booboo away from fill disclosure but at least that can be tested validated easily.
That sounds effectively the same as split DNS except that there are no names that appear both externally and internally.
One problem with your "filtered instead of split" proposal is that you *want* some names to appear both internally and externally. The most obvious names would be your fnord.com and www.fnord.com names. You probably want differing "A" records and "MX" records for internal vs external fnord.com.
If you want to avoid having the same names existing in both internal and external split DNS,
True, but not really an answer to this (Score:2)
Of course you don't make your internal network directly accessible the the internet. That doesn't really solve this problem, though, does it.
I mean you could also post "don't leave your key under the doormat" - good advice, but not entirely relevant.
Re: True, but not really an answer to this (Score:1)
Re: Why on earth would you ever expose your intern (Score:1)
Top-notch security? (Score:4, Funny)
Apparently not...
Filtering the internet. (Score:3)
While it's not hard to run your own DNS name server, the benefit of using a service like AWS Route53 or the Google Cloud Platform is that companies can offload managing DNS server infrastructure to a third-party and take advantage of better uptime and top-notch security.
There's also value-add of DNS-filtering. [cloudflare.com] to keep from going to bad places. And all one has to do is change a router setting.
Oh well. It seemed like a good idea at the time. (Score:2)
Maybe better uptime but the security aspect? Seems to be lacking a little something... Oh yeah, the "top-notch" part of top-notch security.