5 ms·

A lock with many keys: Spoofing DNSSEC-signed domains in 8.8.8.8

133 points by sintax 5y ago

dutchmartin 5y ago
Very cool to see a SIDN labs post here. SIDN operates the .nl extension and puts the money earned into these kinds of research projects that benefit everyone.
- stingraycharles 5y ago
  And they’re also a major sponsor of NLNetLabs since forever, which funds the Unbound DNS server, among other things.
rvz 5y ago
> For reporting this bug, we received $5,000 from Google's bug bounty programme. Excuse me? That's quite an urgent and serious bug and I'm afraid that is too low, especially from a $1TN dollar company with billions of users.
- deleted 5y ago
  [deleted]
- hannob 5y ago
  It's really not. Not many things rely on DNSSEC. Things that do rely on DNSSEC usually tend to have their own verifying resolver. (Because the idea of "we need signed DNS records, but we'll let google check that and maybe not even encrypt our connection to google" is not a very good one.)
- rosndo 5y ago
  There’s no such thing as a serious DNSSEC bypass.
- Avamander 5y ago
  The very few who actually enforce DNSSEC, so that it would actually matter, probably don't trust Google.
- tptacek 5y ago
  Google overbid this bounty by something like $4,999. The root DNSSEC keys could land on Pastebin tomorrow and almost nobody in the entire industry would need to be paged, because virtually no one relies on DNSSEC --- even the people who performatively enable it aren't actually relying on it. This sounds like hyperbole, but it's not. That's how much of a mess DNSSEC is. Try to reason through what kind of entity would need to get paged over a DNSSEC breach, and tabletop it. It's hard for me to think of anybody who would need to care; even the people who "use" DNSSEC could wait until their next maintenance window to respond.
teddyh 5y ago
TLDR: Google Public DNS would, until 23 February, not check that the ZSK (signing key used to sign DNSSEC DNS responses) was in turn signed by the KSK. Google would accept any signed response, by any ZSK. Even worse, they would cache this response, and present it to end users as being non-DNSSEC signed. Upon further testing, only Google was found to have had this problem.
- jeffbee 5y ago
  Condensation of these wordy vulnerability disclosures is a true service to the public.
jzer0cool 5y ago
What free or (non-free) DNS services is everyone using?
- teddyh 5y ago
  Run your own resolver, on your local machine. It’s the only way. Only if you have a local network of machines can you consider making one of these machines the resolver for the local network. A typical example of this might be your router. This machine should then not forward the DNS requests to some centralized resolver, it should resolve DNS queries itself.
  - 1vuio0pswjnm7 5y ago
    "Run your own resolver, on your local machine. It's the only way." It is not the only way. I use scan.io as one source of DNS data. No need for resolvers. The needed data can be saved to a zone file for a local authoritative server or a map file for a forward proxy. The later option requires no DNS at all.
    - 1vuio0pswjnm7 5y ago
      s/scan/&s/
  - cubesnooper 5y ago
    But that would leak all of my DNS queries in cleartext. I use cloudflared to do DNS lookups via Cloudflare’s Tor onion. It’s weak to vulnerabilities like this one, but it disassociates my DNS lookups from myself, and TLS certificates mitigate the risk of hitting spoofed sites.
    - teddyh 5y ago
      > But that would leak all of my DNS queries in cleartext. The longer-term solution is to wait for DoT to become prevalent in authorative servers. But, realistically, won’t you “leak” your IP anyway when you make your actual connection? I mean, why are you looking up things in the DNS if not to connect to them? And if you make a connection, you leak your IP. If you’re not concerned with the other party’s DNS servers, but with the root servers and TLD DNS servers snooping on your queries, I think you’ll have to wait for QNAME minimization to arrive.

133 points by sintax 5y ago

Very cool to see a SIDN labs post here. SIDN operates the .nl extension and puts the money earned into these kinds of research projects that benefit everyone.

stingraycharles 5y ago
And they’re also a major sponsor of NLNetLabs since forever, which funds the Unbound DNS server, among other things.

rvz 5y ago

> For reporting this bug, we received $5,000 from Google's bug bounty programme. Excuse me? That's quite an urgent and serious bug and I'm afraid that is too low, especially from a $1TN dollar company with billions of users.

deleted 5y ago
[deleted]
hannob 5y ago
It's really not. Not many things rely on DNSSEC. Things that do rely on DNSSEC usually tend to have their own verifying resolver. (Because the idea of "we need signed DNS records, but we'll let google check that and maybe not even encrypt our connection to google" is not a very good one.)
rosndo 5y ago
There’s no such thing as a serious DNSSEC bypass.
Avamander 5y ago
The very few who actually enforce DNSSEC, so that it would actually matter, probably don't trust Google.
tptacek 5y ago
Google overbid this bounty by something like $4,999. The root DNSSEC keys could land on Pastebin tomorrow and almost nobody in the entire industry would need to be paged, because virtually no one relies on DNSSEC --- even the people who performatively enable it aren't actually relying on it. This sounds like hyperbole, but it's not. That's how much of a mess DNSSEC is. Try to reason through what kind of entity would need to get paged over a DNSSEC breach, and tabletop it. It's hard for me to think of anybody who would need to care; even the people who "use" DNSSEC could wait until their next maintenance window to respond.

teddyh 5y ago

TLDR: Google Public DNS would, until 23 February, not check that the ZSK (signing key used to sign DNSSEC DNS responses) was in turn signed by the KSK. Google would accept any signed response, by any ZSK. Even worse, they would cache this response, and present it to end users as being non-DNSSEC signed. Upon further testing, only Google was found to have had this problem.

jeffbee 5y ago
Condensation of these wordy vulnerability disclosures is a true service to the public.

jzer0cool 5y ago

What free or (non-free) DNS services is everyone using?

teddyh 5y ago
Run your own resolver, on your local machine. It’s the only way. Only if you have a local network of machines can you consider making one of these machines the resolver for the local network. A typical example of this might be your router. This machine should then not forward the DNS requests to some centralized resolver, it should resolve DNS queries itself.
- 1vuio0pswjnm7 5y ago
  "Run your own resolver, on your local machine. It's the only way." It is not the only way. I use scan.io as one source of DNS data. No need for resolvers. The needed data can be saved to a zone file for a local authoritative server or a map file for a forward proxy. The later option requires no DNS at all.
  - 1vuio0pswjnm7 5y ago
    s/scan/&s/
- cubesnooper 5y ago
  But that would leak all of my DNS queries in cleartext. I use cloudflared to do DNS lookups via Cloudflare’s Tor onion. It’s weak to vulnerabilities like this one, but it disassociates my DNS lookups from myself, and TLS certificates mitigate the risk of hitting spoofed sites.
  - teddyh 5y ago
    > But that would leak all of my DNS queries in cleartext. The longer-term solution is to wait for DoT to become prevalent in authorative servers. But, realistically, won’t you “leak” your IP anyway when you make your actual connection? I mean, why are you looking up things in the DNS if not to connect to them? And if you make a connection, you leak your IP. If you’re not concerned with the other party’s DNS servers, but with the root servers and TLD DNS servers snooping on your queries, I think you’ll have to wait for QNAME minimization to arrive.