Bit-squatting – DNS hijacking by cosmic rays/memory errors | Hacker News Reader

Bit-squatting – DNS hijacking by cosmic rays/memory errors

nakedsecurity.sophos.com

61 pointsjoshwa18 comments

I still can't accept that these are memory errors... The chance of that seems just too small. You get 600k errors an hour globally but they still have to hit the exact place where the domain is stored - in ~3GB of memory. Additionally it must happen during or shortly before the request. How can this produce a sustained ~80 unique hits per day?

They should probably create some domains with 2, 3, 4, 5 bits swapped and show that the proportion of traffic drops dramatically to prove their theory about memory issues. Otherwise, I'm tempted to say - what about dangling pointers? What are the chances of that happening instead?

Some of these problems could be mitigated by checksumming DNS entries when created.

That shouldn't be necessary - responses return the domain name you're requesting. So if you think you send a request for microsoft.com, but get back response for mi2rosoft.com - it should not be treated as a correct one.

It doesn't seem like those errors are caused by bitflips on the network.

I'd be more convinced if he'd also registered domains with two, three and four bit-errors in them. Having gathered as much statistics as he did, they should show clearly half as much, resp. 1/4th and 1/8th as much hits.

If that would indeed have been the case, he could say with very high confidence that his hits were indeed caused by bit-flip errors, and not by character errors or who knows what other unknown anomalies.

So far, he's advocating to upgrade memory to prevent this vulnerability, but there's only a rough hypothesis that this might be caused by memory bitflip errors.

And even then, between the client and the DNS-server, there's a lot of machines, the bitflip could occur anywhere, right? How can he say upgrading client memory will solve anything??

> half as much, resp 1/4 and 1/8 as much hits

No. These errors are very rare. You only get any of them (according to the hypothesis we're considering here) because there are so many DNS requests made. The probability of getting two bit-flip errors in a single request is much smaller than the probability of getting one, so the expected number of 2-bit hits would be way less than 1.

Something like this might be a useful check in a different way: bit-flipping errors will almost always be single-bit errors, whereas typos and suchlike won't. So if the bit-flipping theory is correct, you'll see systematically more single-bit than multi-bit errors.

His math was wrong, but his point stands, it's a simple test to see why these hits show up.

There's an example in this article:

http://domainincite.com/bit-squatting-%E2%80%93-the-latest-r...

Also, could ECC memory for clients solve this problem?

They changed microsoft.com to mic2soft.com: only 1 bit difference between the two.

I'm astonished that they got so many hits with that. Someone bit-squatting with many different combinations of the same domain can really do some damage...

Forgive me, genuinely interested - how does 1-bit difference turn microsoft into mic2soft.. ?

In ASCII, microsoft is:

0110110101101001011000110_1_1100100110111101110011011011110110011001110100

micr2soft is:

0110110101101001011000110_0_1100100110111101110011011011110110011001110100

The important bit is the one between the underscores.

Gotcha - thank you.

I think the question is made more relevant when taking into account that the poster above omitted the 'r' ("mic2soft"), thus causing the name to be shortened which is, indeed, very hard to call a 1-bit error.

Sorry, I made a typo: please replace mic2soft with mic2osoft.

And by the way, there are "only" 72 (9 characters x 8 bits) domains to register to cover all the 1-bit error for microsoft.com. If one discards not-valid characters like _,. or A-Z, it might actually be way less...

I saw this talk at DEFCON.

ECC memory solves the problem, however there are many components that don't have it, even in servers: NICs, HDDs/SSDs, or routers on the path.

The most hits reported by the researcher were related to FarmVille, and what appeared to be caching of DNS entries by a Facebook CDN. But there were instances of Windows software updates and iPhone activations as well.

previously on hn: http://news.ycombinator.com/item?id=2846812

That article didn't have numbers & stats in it though.

Earlier comment I wrote on another HN discussion:

Assuming DNS resolvers work as they should, most bitflips on the wire shouldn't result to anything else than a failed DNS query since DNS packets include the original requested FQDN in the result.

Scenario 1) Lets say we have normal Windows computer asking what is update.microsoft.com as an A-record. The computer's resolver sends its request to its ISP's DNS server it was assigned via DHCP. One bit is flipped on transit and the DNS server receives request to resolve update.mic2osoft.com and it does so. Then it returns the result via UDP telling the Windows computer that update.mic2osoft.com is 1.2.3.4, but the computer's resolver was expecting an answer for update.microsoft.com so it rejects(should reject) the result even though the transaction ID is what it expected. Also UDP checksum poses a problem the recursor could reject the packet and not do anything.

Scenario 2) Another scenario is where the bit corrupts on transit while the ISP's DNS recursor is querying the Verisign .com root servers for microsoft.com (assuming it's not cached) and one bit corrupts in transit. Verisign's server answers that mic2osoft.com DNS servers are ns1.mic2rosoft.com and ns2 and it provides the glue records for them (IP addresses) if necessary. DNS recursor receives an answer for mic2rosoft.com while it expects answer for microsoft.com and rejects the result before querying nsX.mic2rosoft.com. UDP checksum also a problem here.

Scenario 3) Bit flip on the Windows computer's RAM before gethostbyname() is called so they call gethostbyname(update.mic2osoft.com). Another timeframe for a successful bitflip is while the OS is running gethostbyname(update.microsoft.com) but before the request is sent. gethostbyname() only returns the IP address so the function caller will not know if its wrong. This is the most plausible scenario, ECC is also rare in consumer hardware so that shouldn't pose a problem.

Scenario 4) Bit flip on the DNS recursors RAM. This depends on whether the address to be queried is stored in several variables in the DNS server so the DNS answer packet to the Windows computer has the correct FQDN but the DNS server queried for the wrong address due to the bit flip. Servers usually have ECC so this is implausible but not impossible. Also if this happened, the DNS server's cache could also get the incorrect entry and give it out to many many many clients if it was a popular ISP's DNS server.

An interesting thought would be what if IP-addresses bit-flipped. If Microsoft had all their update servers in 80.100.2.0/24 and an attacker owned 16.100.2.0/24 with one bit flipped. How much traffic would the network receive? If bit flipped on transit while the server is returning answer for update.microsoft.com UDP checksum should be incorrect but what if a popular ISP's DNS recursor's cache had a flipped IP address for update.microsoft.com. Very implausible but would result in lot of traffic. One more scenario comes to mind about IP bit-flipping. If ns1.microsoft.com was at 5.1.1.1 and an attacker owned 1.1.1.1 he could also configure his DNS server (more specifically the UDP stack on the Linux kernel) to ignore the invalid UDP checksums and serve falsified DNS answers.

The bitsquatted domain sends two records, one for the squatted domain and one for the original name, pointing to the squatter's server. The parent article isn't as detailed as the paper/talk was, but this is a point that the DEFCON presentation included (and I reckon the BH one as well)

Reply on news.ycombinator.com