
Bit-squatting – DNS hijacking by cosmic rays/memory errors - joshwa
http://nakedsecurity.sophos.com/2011/08/10/bh-2011-bit-squatting-dns-hijacking-without-exploitation/
======
viraptor
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?

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

~~~
viraptor
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.

------
tripzilch
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??

~~~
gjm11
> 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.

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

------
Mithrandir
There's an example in this article:

[http://domainincite.com/bit-squatting-%E2%80%93-the-
latest-r...](http://domainincite.com/bit-squatting-%E2%80%93-the-latest-risk-
to-domain-name-owners/)

Also, could ECC memory for clients solve this problem?

~~~
joss82
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...

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

~~~
Mithrandir
In ASCII, microsoft is:

0110110101101001011000110_1_1100100110111101110011011011110110011001110100

micr2soft is:

0110110101101001011000110_0_1100100110111101110011011011110110011001110100

The important bit is the one between the underscores.

~~~
unwind
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.

------
xd
previously on hn: <http://news.ycombinator.com/item?id=2846812>

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

------
tuomasb
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.

~~~
inaequitas
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)

