If your DNS queries LoOk liKE tHIs, it's not a ransom note, it's a security improvement
- Reference: 1674109753
- News link: https://www.theregister.co.uk/2023/01/19/google_dns_queries/
- Source link:
This means queries for a domain like example.com, if handled by Google Public DNS, could be reformatted eXaMpLe.coM when the request is transmitted to DNS servers to look up. While this may get noticed by admins scrutinizing network traffic, the spicy formatting is not visible to the general public so no one should be any the wiser – if everything goes well.
When people try to visit a website – such as theregister.com – whatever browser or app they're using queries the site's domain name using the Domain Name System (DNS) to discover the IP addresses for the servers hosting the site. Such a DNS query commonly passes through a recursive DNS service that contacts other name servers until it ultimately gets an answer from an authoritative name server.
[1]
To hasten this multi-step process, DNS query responses may be cached by these intermediary name servers. This opens up the possibility of [2]cache poisoning attacks .
[3]
[4]
Such an attack involves hitting one of these intermediary name servers with a bunch of DNS queries for domains that aren't in its cache. The victim server then contacts other name servers that can help it answer these queries. At the same time, the attacker floods the victim server with bogus responses disguised to look like legit responses from those other name servers.
The aim of the game is to get the victim server to accept one or more of these forged responses – and cache that wrong answer – so that criminals can take advantage of the misdirection. For example, the faked response could resolve a valuable domain name – such as superbigbank.com – to a server that masquerades as the bank and steals people's login details. If the victim server caches that bad info, browsers and apps subsequently using that server to connect to superbigbank.com end up at the wrong IP address.
[5]
This is all possible because DNS servers rely on UDP – a network protocol that's faster than TCP but doesn't make guarantees about connections and is consequently more vulnerable to spoofing. It also works because DNS query IDs are 16-bit fields, meaning their possible values can range only from 0 to 65,535 – a small enough range to guess with a deluge of malicious requests.
There's a detailed breakdown of this attack [6]here if you're curious. And, yes, [7]DNSSEC is supposed to thwart these kinds of cache poisoning attacks, when it's supported and used.
Back in 2008, Internet Engineering Task Force (IETF) published a [8]draft proposal to defend against cache poisoning. "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity" describes a way to randomize the case of letters used in queries.
[9]
The technique is called DNS-0x20 encoding, in reference to the hexadecimal number 0x20 (32 in decimal) and its relationship to ASCII characters. Its binary representation (0b100000) has all of its bits set to zero except for the fifth, counting from zero – which for ASCII characters determines whether a letter is upper or lower case. For example, 01000001 (65 in decimal) is the ASCII code for an upper-case A, while 01100001 (decimal 97) is the ASCII code for a lower-case a.
Described in more detail in an [10]an academic paper [PDF], DNS-0x20 encoding expands the range of possibilities an attacker must guess without confusing the resolution of DNS names and IP addresses.
Essentially, you randomly toggle the 0x20 bit in a query to jumble up the case, send that out to be resolved, and expect the response to have the same matching case. If the cases don't match, you may be caught up in a cache poisoning attack, as the attacker won't know which case bits will be set or cleared by you when doing their poisoning.
[11]All your DNS were belong to us: AWS and Google Cloud shut down spying vulnerability
[12]Chromium cleans up its act – and daily DNS root server queries drop by 60 billion
[13]Internet root keymasters must think they're cursed: First, a dodgy safe. Now, coronavirus upends IANA ceremony
[14]Q: Why pay for DNS?
DNS servers mostly don't differentiate between queries in ALL CAPS, lower case, or SoME miX OF the TWo. But the added complexity of mixed case queries matters to attackers, in proportion to the length of the domain name. "Each bit of DNS-0x20 encoding doubles the work an attacker must perform to achieve similar poisoning results," the paper explains.
Google has been toying with the idea since 2009, when it began testing the cache poisoning defense on a small number of name servers. Last August, the search and ad giant began deploying the technique more broadly.
"The case-randomized query name in the request will be expected to exactly match the name in the question section of the DNS server's reply, including the case of each ASCII letter (A–Z and a–z)," [15]explained Google software engineer Tianhao Chi in a post on the Google Public DNS mailing list. "For example, if 'ExaMplE.CoM' is the name sent in the request, the name in the question section of the response must also be 'ExaMplE.CoM' rather than, e.g., 'example.com.' Responses that fail to preserve the case of the query name may be dropped as potential cache poisoning attacks."
Chi noted that only a small number of name servers (less than 1,000 IP addresses) do not handle case randomization correctly.
On Tuesday, Chi [16]said that the web goliath has successfully deployed case randomization for some regions in North America, Europe and Asia, covering about 90 percent of queries not already protected by DNS over TLS.
"We are still deploying this feature incrementally, location by location," said Chi. "This is slower than originally planned because of the carefulness and our estimate of global enabling is around March to April 2023."
Chi said Google is watching for problems from non-compliant name servers and recommends that name servers preserve the query case in the response or support TCP as a fallback.
When all is said and done, the internet should be just a bit more secure. ®
Get our [17]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Y8ki1T2E3j9l7rE33mwePAAAAEg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://developers.google.com/speed/public-dns/docs/security#cache_poisoning_attacks
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y8ki1T2E3j9l7rE33mwePAAAAEg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Y8ki1T2E3j9l7rE33mwePAAAAEg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y8ki1T2E3j9l7rE33mwePAAAAEg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
[7] https://www.theregister.com/2016/02/23/dnssec_more_problem_than_solution/
[8] https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Y8ki1T2E3j9l7rE33mwePAAAAEg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] https://astrolavos.gatech.edu/articles/increased_dns_resistance.pdf
[11] https://www.theregister.com/2021/08/06/aws_google_dns/
[12] https://www.theregister.com/2021/02/04/chromium_dns_traffic_drop/
[13] https://www.theregister.com/2020/04/22/iana_key_signing_delay_coronavirus/
[14] https://www.theregister.com/2010/10/19/sysadmin_pay_for_dns/
[15] https://groups.google.com/g/public-dns-discuss/c/aHSyiIlBfjo/m/H-4m1zYYAQAJ
[16] https://lists.dns-oarc.net/pipermail/dns-operations/2023-January/021947.html
[17] https://whitepapers.theregister.com/
Colour me surprised (in upper case)
Obviously I'm getting senile; I had thought that DNS requests were case sensitive.
Re: Colour me surprised (in upper case)
They're not, neither are email addresses. However, anything past the first slash in a URL can be as that is no longer a DNS matter, you're then sending instructions to a specific resolved FQDN.
Re: Colour me surprised (in upper case)
The comment about email addresses is not strictly true. The domain part (after the @) is case-insensitive, but the local part (before the @) "MUST be interpreted and assigned semantics only by the host specified in the domain part of the address" (RFC 5321). Whilst in practice many mail servers will handle the local part in a case-insensitive manner, one shouldn't rely on that behaviour.
Re: Colour me surprised (in upper case)
I stand, no, wait, sit corrected. Thank you. Accuracy matters!
Am I being Dense?
So, if this hack.... (for in my mind it is a 'hack') is a workaround to prevent cache poisoning, then surely the workaround for the workaround is to poison with all the variants.
www.theregister.com
www.TheRegister.com
www.THeregister.com
ad infinitum?
Re: Am I being Dense?
I think the point is that poisoning with all the possible variants requires several orders of magnitude more effort, and so makes it impractical.
Re: Am I being Dense?
Surely it is finite. AlL iT IS is 2 to the number of alpha chars. ie. aa.com Aa.com AA.com AA.com 2^2 - 4 and so on.
And how is the alphabet factory going to handle those foreigners that don't just some ascii chars?
Just check the calendar and it is not April 1. This has got to be one of the most stupid proposals that ever came our of google. Are they using their own AI to generate this crap?
Re: Am I being Dense?
Oddly, they've thought of that, and it's even quoted in the article. They only mess with a-zA-Z.
Re: Am I being Dense?
Finite but large; for 17 chars like www.theregister.com that's a 2^17 (about 130,000) increase in the number of bogus responses an attacker has to create.
But I agree it seems a bit of a weird hack. AIUI you are trying to defeat the caching of DNS servers you don't control. If any of these servers start using case insensitive cache lookups to return case sensitive answers, you're back to square 1.
Re: Am I being Dense?
This is for (Google) caches talking to authoritative servers. The Google caches are not talking to other caches.
Re: Am I being Dense?
Ah, of course... Thanks.
Re: Am I being Dense?
The server you are targeting will query upstream with a 16 bit query ID - 65k possible values. You have to thrash the server with fake replies in the hope that one of your fake replies has the correct ID and hits the server before the genuine reply. A single case-unknown character will expand this to 128k, then 256k etc.
Yes it's finite, but when most servers reply in ~5-10ms, it becomes far less likely you will get the right ID and case in time. It's a perfectly reasonable idea to try and reduce the effectiveness of cache poisoning without requiring the entire world to modify their DNS systems. The biggest issue as mentioned in the article is servers that happen to reply with the case changed as they will effectively get completely rejected, although that isn't many servers. I don't believe it was ever specified that servers *must* respond in the same case as the query, but I haven't checked. It seems all the major DNS software (bind/unbound/etc) does.
Also, as far as I'm aware, all international domain names are (at least currently) converted to pure ascii for DNS lookups.
Re: Am I being Dense?
It's not just harder, you also elevate the chance of detection and so prompt a cache refresh. This stuff only works if nobody notices that it's happening.
Umm... My home resolver has been doing this for years.
In case you are wondering, I haven't noticed any breakage.
If I understand it correctly, this means that facebook.com is better protected than nsa.gov. Length really counts, always and everywhere (I'm speaking about passwords).
"Length really counts, always and everywhere "
Anyone who say "size doesn't matter" hasn't hung wallpaper.
Do be evil
Is this only implementing the IETF draft, which seems like not a great idea since it's a draft, or is this a new trick to evade privacy measures? 'forums.theregister.com' would be 20 bits for Google to leak data from one service to another. If the IETF is followed, blocking those bits would cause the DNS response to be rejected.
(The TLDR of the draft is that DNS caches remain case sensitive but the response must use the original case. This makes blind, brute-force forgery of DNS responses over UDP more difficult.)