
New DNS hijacking technique exploits RAM errors - gtank
http://domainincite.com/bit-squatting-%E2%80%93-the-latest-risk-to-domain-name-owners/
======
trotsky
One bit in one gigabyte of RAM is 1 in 8,589,934,592. Wolfram Alpha estimates
there are "over one billion computers" in the world.

Let's be charitable and say that every single one of those is connected to the
internet 24x7 and they love microsoft so much that they visit the url every
hour, so 24 times a day. To get even more accommodating, let's imagine every
single computer in the world has a single bit error occur every hour as well,
right before they head to microsoft.com.

In that case you'd expect about 3 hits a day.

I'm sure it can happen, but I'd be surprised if most of the traffic wasn't
caused by other things. I can't be the only one who noticed in mic2osoft.com
the number 2 is only two keys away from r. It may not be the most common typo
in the world, but I bet the odds are a lot higher than 1 in 8.5 billion.

I almost think it's an inside joke, Kaminsky sounded just a wee bit too blown
away while he was raving about the presentation last night. Or maybe that was
just the booze tallking.

~~~
4ad
You assume error happens in RAM. Occurring on the wire seems far more likely.
Don't forget that DNS is UDP and DNS servers cache their requests.

~~~
trotsky
While I suspect you're right that the network path is more likely to error,
udp does have a checksum that covers the entire payload so the DNS server
would ignore the packet.

Also, the dns client is waiting for an address for the host that it requested.
If it asks "where is alice?" and the dns server replies "bob is at x.x.x.x" it
won't go there because the names don't match. So the error pretty much has to
have happened on the client, but it could be a disk error, dma glitch, bug,
malware or maybe a bad proxy/firewall.

~~~
tlb
The UDP checksum is fairly weak, so a packet with two bit errors can pass the
checksum.

Still, I would attribute hits on mic2soft.com to human error with higher
likelihood than transmission errors. Human error is around 10^-2
[<http://panko.shidler.hawaii.edu/HumanErr/Basic.htm>] compared to
transmission errors below 10^-9 for non-broken networks.

------
strmpnk
This seems pretty unlikely with ECC modules. Worst reported error rate for
regular RAM was 1 bit per hour per GB (via wikipedia) while other reports
claim it'd take a century for that same amount of error.

Regardless, this is ever more reason to use something like TLS to initiate a
trusted identity with another party. Even in the null cipher case, it's useful
to exchange a certificate.

~~~
gtank
Sections 7 and 8 of this paper [1] discuss inducing memory faults and
potential countermeasures. Specifically they indicate that many desktop PCs
shipped without ECC hardware at the time of writing (2003). I'm not sure to
what extent that's still true, but I imagine it could be a problem for the
masses of cheap/old hardware in use around the world.

edit: I found some more recent numbers via [2]. Relevant quote: "Our ﬁrst
observation is that memory errors are not rare events. About a third of all
machines in the ﬂeet experience at least one memory error per year (see column
CE Incid. %) and the average number of correctable errors per year is over
22,000. These numbers vary across platforms, with some platforms (e.g.
Platform A and B) seeing nearly 50% of their machines aﬀected by correctable
errors, while in others only 12–27% are aﬀected. The median number of errors
per year for those machines that experience at least one error ranges from 25
to 611." They were using server-class machines with ECC.

[1] <http://sip.cs.princeton.edu/pub/memerr.pdf>

[2] <http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf>

~~~
justincormack
Desktop machines still do not ship with ECC, other than a few high end ones
that use server hardware.

------
mef
Would this not be compensated in the end-to-end TCP checksumming? And couldn't
the traffic to bit-squatting domains be accounted for by the myriad bots that
constantly scan the web on port 80?

~~~
jrockway
DNS is not a TCP protocol.

~~~
bysin
It can be either TCP or UDP. Regardless, UDP has a checksum as well.

The likelihood of a bit-flip is very uncommon. Even taking into account the
volume of computers out there, the likelihood of a bit-flip at the exact spot
(in the domain name) and moment of a DNS lookup (before the checksum is
calculated) is astronomically uncommon. This article is garbage.

~~~
Florin_Andrei
I wonder if there are more sources of error than just RAM bit-flipping. The
bit could be flipped anywhere it's stored or passing through. If that is the
case, the error rate would be orders of magnitude higher.

------
zopf
Here's some [probably faulty] code to test a given domain name for bit-flip
variants that are unregistered.

<https://gist.github.com/1126162>

------
peterpeters
I wonder how likely these errors are

~~~
nbpoole
> _Normally a couple hundred IPs a day will visit popular bitsquatted
> destinations. #blackhat_

<https://twitter.com/#!/dakami/status/98910873044791297>

~~~
fla
Someone posted a gist wich looks like DNS hits for facebook content delivery
network (fbcdn.net) <https://gist.github.com/1125307> plus another one about
top domains <https://gist.github.com/1125203> . It seems the odds are around 1
over 1 billion, or even less. Edit : Can it be something else? maybe IP/UDP
checksum collision over corrupted packets ?

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

Seems like the author's DEFCON speak will be held next Sunday, he probably
knows much much more about the subject than what I just wrote. I will
definitely read his slides/whitepaper.

