Skip to content
0:00 / 0:00

#bit-squatting#dnshijacking#bitflips

DEF CON 19 - Artem Dinaburg - Bit-squatting: DNS Hijacking Without Exploitation

DEFCONConference

419K subscribers • 61 videos on Hallway • Conference channel

YouTube
  • Recommended by 2 people: 2 on Hacker News.
  • A classic. People kept recommending it from 2018 to 2022.
  • Presented by Artem Dinaburg, security researcher

Intermediate. Assumes working knowledge.

4K views13 years ago2 recommendations

SecuritySystems programmingExploits and vulnerabilitiesNetworking and protocolsMemory management

Artem Dinaburg explains how hardware bit flips in DRAM can be exploited to hijack DNS requests without any software vulnerabilities.

Artem Dinaburg - Bit-squatting: DNS Hijacking Without Exploitation defcon.org/images/defcon-19/dc-19-presentations/Dinaburg/DEF… We are generally accustomed to assuming that computer hardware will work as described, barring deliberate sabotage. This assumption is mistaken. Poor manufacturing, errant radiation, and heat can cause malfunction. Commonly, such malfunction DRAM chips manifest as flipped bits. Security researchers have known about the danger of such bit flips but these attacks have not been very practical. Thanks to ever-higher DRAM densities and the use of computing devices outdoors and in high-heat environments, that has changed. This presentation will show that far from being a theoretical nuisance, bit flips pose a real attack vector. First the presentation will describe bit-squatting, an attack akin to typo-squatting, where an attacker controls domains one bit away from a commonly queried domain (e.g. mic2osoft.com vs. microsoft.com). To verify the seriousness of the issue, I bit-squatted several popular domains, and logged all HTTP and DNS traffic. The results were shocking and surprising, ranging from misdirected DNS queries to requests for Windows updates. The presentation will show an analysis of 6 months of real DNS and HTTP traffic to bit-squatted domains. The traffic will be shown in terms of affected platform, domain queried, and HTTP resources requested. Using this data the presentation will also attempt to ascertain the cause of the bit-flip, such as corruption on the wire, in requestor RAM, or in the RAM of a third party. The presentation will conclude with potential mitigations of bit-squatting and other bit-flip attacks, including both hardware and software solutions. By the end I hope to convince the audience that bit-squatting, and other attacks enabled by bit-flip errors are practical and serious, and should be addressed by software and hardware vendors. Artem Dinaburg currently works as a security researcher at Raytheon, investigating a broad range of security related topics. Prior to joining Raytheon, Artem worked as a security researcher building automated malware analysis systems, investigating web-based exploit kits, and identifying botnet command-and-control domains. While a graduate student at Georgia Tech he created hypervisor-based dynamic malware analysis platforms under Dr. Wenke Lee.

Why it's here

2 people recommend this

What people say. Highly recommended as a classic security talk explaining how physical memory corruption can lead to predictable domain hijacking.

hayst4ckon Hacker News • Recommends

On “iPhone app receives notification for another app”

A really fun DefCon talk on bitsquatting. Bitsquatting is the practice of registering domains that are one bit off from a popular one: link to this video google.com vs ooogle.com >>> chr(int('0b1100111', 2)) 'g' >>> chr(int('0b1101111', 2)) 'o' If the 4th to last bit of 'g' were to flip before writing to disk, you could get persistent requests to ooogle.com Having done queries against very large datasets at a large company, I can say for certain that this happens much more than you think it might.

btschaeggon Hacker News • Recommends

On “1/0 = 0”

Regarding "some hardware errors": This might include operationg conditions you didn't consider; say: The divisor in your code went through a non-ECC DRAM module (maybe in a disk drive) that runs hotter than its specified operating temperature would allow and a random bit-flip changes your `1` into a `0`. On this topic, the talk on Bitsquatting from Artem Dinaburg during Defcon 19 is worth watching. The most interesting part on bit flips starts around 15:05 minutes: link to this video

dfeojm-zlibon Hacker News • Mentions

On “Battle testing data integrity verification with ZFS and Btrfs”

The thing about ECC vs. non-ECC. If you don't have ECC, you don't know silent bit corruption is happening, and when it's finally (if it's ever) discovered, there's nothing that can be done. ECC (SECDED) keeps data safer than it would be otherwise. ECC is necessary for anything real or important based on the financial cost of losing data. For everything else, it can be optional. Plus, don't forget the security issues of bitsquatting and other attacks that are the real results of silent bitflips. DEF CON 19 - Artem Dinaburg - Bit-squatting: DNS Hijacking Without Exploitation link to this video

jstriebon Hacker News • Mentions

On “Cosmic rays causing 30k network malfunctions in Japan each year”

This reminds me of Bitsquatting, which is like typosquatting but uses domains one bit-flip away instead of one mistyped letter away.0 In a small experiment, for some popular domains, the author reportedly got a lot of hits. In the associated DEFCON talk, the author notes that even if you use ECC memory, it's unlikely that the DRAM in your hard drives does too.1 0: link 1: link to this video

josephgon Hacker News • Mentions

On “ECC RAM on AMD Ryzen 7000 Desktop CPUs”

Encryption and signing don't protect against memory corruption. For example, I download software from the internet then hash it. The hash matches. Before the bytes are written to disk locally, a bit flips in RAM. The corrupted data is written to disk and used. Likewise, dnssec doesn't protect you against DNS bitsquatting attacks1 because the domain name can be changed before the DNS request is made. So the DNS response your computer makes for a-azon.com might be totally valid and signed. It can come through DoH or whatever. The problem is that your browser thought it was the response for amazon.com and chrome send a bitsquatter your amazon cookies. (Oops). 1 link to this video