Here's some [probably faulty] code to test a given domain name for bit-flip variants that are unregistered.
New DNS hijacking technique exploits RAM errors
21–29 of 29 posts
Re: New DNS hijacking technique exploits RAM errors
#22Would 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?
TCP (or UDP) checksums only cover the packet when it is in transit & don't protect the information when it is stored in a device such as a DNS server.
Re: New DNS hijacking technique exploits RAM errors
#23One 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…
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.
Re: New DNS hijacking technique exploits RAM errors
#24One 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…
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.
Wire transmissions are less likely to error because they have more checksums and other self-correcting mechanisms. A bad bit over the wire will get the entire data package dropped.
Re: New DNS hijacking technique exploits RAM errors
#25One 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…
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.
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.
Re: New DNS hijacking technique exploits RAM errors
#26Earlier quoted context omitted.
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.
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 happ…
The IP checksum is only 16 bits, so it will be fooled occassionally on a noisy line. Software that cares about correctness must use a proper error detection code of its own.
Re: New DNS hijacking technique exploits RAM errors
#27Earlier quoted context omitted.
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.
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 happ…
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.
Re: New DNS hijacking technique exploits RAM errors
#28Earlier quoted context omitted.
As far as I can tell, most or all of the one-bit errors on those are already registered by typosquatters.
I hadn't thought of that... I tried flipping the first 7 bits of google and got woogle, ooogle, coogle, eoogle - which are all registered. I don't think it would be that hard to write a bit-flip miner though. It wouldn't surprise me if sites other than the biggest (maybe ycombinator.com, techcrunch.com, makezine.com) have bit flipped versions avilable. I guess it would be more likely with longer domain names too.
I built a 'bit flip miner' tonight. As expected, every variation of microsoft.com and google.com are registered, but there are many bit flipped versions of ycombinator.com, wordpress.com, and paypal.com (yikes!) are actually available (among others).
The best thing would be if the owner of a very busy domain name set up a redirect as I mentioned before (on a domain that would be hard to be a typo), didn't tell anyone, then compared the traffic with the traffic on the real domain.
Re: New DNS hijacking technique exploits RAM errors
#29Assuming 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.