 Alright, thank you everybody. I'm Ed Miles as he said. I'm here today to talk about bit squatting, which can effectively provide passive DNS hijacking. I am a security enthusiast. This is not my 20th DEF CON, but this is the 20th anniversary of my first DEF CON attendance, so I'm very excited to be speaking here. I'm a drum and bass DJ. I'll be spinning at the Blanket Ford Con later and I'm a bit of a threat researcher. That's most of my actual security background, which means I mostly analyze malware and malware accessories. The first slide you may have noticed, I work for DD Labs. I know if I get any questions about this talk, people will ask me about my employer. We're basically the Chinese Uber, but we have a research and development team in Mount View, as well as Los Angeles and Toronto. I'm a little nervous and out of breath about all this. But really, this concept is all due to Artem Dynaberg, first and foremost. He presented this at DEF CON 19. I unfortunately did not see his talk that year, but I saw Jason Schultz speak about it at DEF CON 21, which is really where it stuck in my mind. Robert also spoke at DEF CON 21 about DNS, and there have been a few other papers and talks at various places over the years. So really quickly, I'm going to introduce what I'm talking about, bit squatting, some background about it, which hopefully will not be too boring. I don't know what all the skill levels actually are in here, but then I'll talk about what my motivations are, why I think it's really interesting. A little bit about the data I found and some of the mitigations. So of course, what is bit squatting? Well, it's like type of squatting, but for bit flip domains, which hopefully not too many of you aren't unfamiliar, but just a quick refresher. Type of squatting is when you make a typographical error in your domain name. In this case, you might type Microsoft as Microsoft, because you know, the P is right there next to the O. There's a bunch of other possible typos that could result from Microsoft.com, but I don't want to get into that too much. So the basics. Obviously, bit squatting relies on DNS. Also, the way ASCII works, the way the character encoding works is important to how all this fits together. And then we'll be talking about memory errors, which is where the bit flips happen and put it all together and hopefully figure out a way to profit. So hopefully not to be too introductory here. Obviously, you type a URL into your browser. Your browser has to figure out where it is. That's where DNS comes in. The domain name system looks up those names, translates them to addresses, and everything should be good. But if you've been an admin or have troubleshooted networks, you might know that DNS is a little trickier than it might need to be, although most of those issues come from human error. But we'll be talking about computer errors in this case. To get an idea of kind of the magnitude of what we're talking about, I did a very highly scientific survey, which resulted in the numbers of about 15 URLs type per day. It may vary upon how you browse the internet, how you use your computer. I know for me, most of my browsing is kind of auto complete. I visit a lot of the same sites. So that seemed like a pretty good number, but just for reference, I pulled that off of Quora. Very scientific, like I said. So yeah, we have 15 typed URLs per day, but the issue here is that it's not in those type URLs. It's in the domains that come from automatically generated traffic. So when you load a website, you know, there'll be secondary content, media, JavaScript, ads, whatever. And so I looked at the numbers from OpenDNS. They claim they have 65 million users daily who generate 135 billion events, or queries rather. So that comes out to be, you know, just about 2100 DNS queries per day, per user. And only 15 of those are manually generated. So we're talking about the vast majority are automatically generated by computer. And so this, I hope, is not too introductory or not too small. I don't know if you guys can see it in the back, but this is just a basic DNS query. I don't advise trying this particular domain out, since this was from an exploit kit sample run, unless you want to try finding some Russian malware or something. But you can see at the bottom part that's highlighted, the string allboxing.ru is actually in the raw DNS query. So that actually goes over the wire plain text. And the response comes back plain text as well. It's not highlighted in this case. I have the IP address highlighted, but it's in there. And so yeah, to understand a little more, it helps to know what ASCII is. But this is a, I thought this was really cool, kind of the history of ASCII before ASCII. It's a five bit character encoding called Bodeau. Not very important to this talk, but I thought it was really cool. This is a older US ASCII code chart. It's valid, but obviously if you read it, it looks a little weird. And shout out to man pages anytime you want to look up something. I highly recommend man pages. They got the ASCII character map in there and everything. Yeah, basically what we're talking about is how these characters are encoded in memory and physically they represent actual ones and zeros. Some of you may or may not be familiar with this lovely DRAM stick here. All those black chips are actual, the actual memory modules. And this isn't the best zoom, but you can tell that the blocks are a little fuzzy and that's where, you know, the cells for the memory actually are. They're in rows and columns and each one actually contains a zero one. But DRAM is prone to errors. Some of you may know. Hopefully you haven't encountered too many terrible errors in your life, but quickly let's talk about some of the error modes that can cause issues with your memory. First of all, I think everybody will be well aware of the heat here in Vegas. This is definitely a factor in computing errors. There's been some very specific research. Sudkar here tried to do an experimental setup where they tried to induce memory failures with direct heating components to try and attack the JVM. But interestingly, while doing the background research onto these issues, I found this Google paper where they actually studied the DRAM error rates and causes across their, you know, very large infrastructure. They found that surprisingly heat was not very strong of a signal for error rates. It's definitely has a correlation, but they found that utilization was actually the strongest signal for when an error will occur. There's also a lot more data in there, so if you're interested in that kind of data stuff, definitely check out the paper. Next one, which is pretty interesting to me is cosmic rays. You know, when I was younger, I heard this, you know, the standard bastard operator from hell was like, oh, cosmic ray caused that error. I can't do anything about it. But it's real, right? These rays can come from deep space, from, you know, whatever astrophysical anomaly or phenomenon and come down to earth, hit your chip in just the right place and cause memory errors. This has been experimentally tested in multiple cases. I think this was, this study was from guys at IBM and they found significant component of the error rates that you'll see in memory can be attributed to cosmic rays. And not only that, but the effect of the error rates increases dramatically at higher altitudes. So if you flew here or if you fly a lot, you're exposing yourself to possible bit flips. So if you're browsing on the airport Wi-Fi or the airline Wi-Fi, you know, be careful. Gotta go a little fast. So cosmic rays, this was kind of a follow-up paper where they studied cosmic rays. They found that the incidence was pretty low. I don't know if times have changed. There's fewer cosmic rays, but in their study they found that the hard errors from things like manufacturing defects, physical issues with the circuits cause more errors and particularly they cause repeat errors. So always scan your memory when you're setting up a new box. If you're into hardware hacking at all, you know of course that electrical stuff, you can cause glitches in CPUs, you can, you know, cause security faults and whatnot. I'm actually missing a slide I think from when my computer crashed. So there's also manufacturing defects like I mentioned before. Some of these can be in the form of actual physical defects, but there's also been a number of cases of radioactive material being in the chip packaging and causing periodic soft errors. It's kind of an interesting, you know, permanent state of soft errors rather than a hard error. But practically speaking, all of this we want to see flip a zero to a one or a one to zero. And, you know, in specific terms when we see the flip, you know, it might take the place here of flipping the zero in the A and causing it to become a C. So why am I interested in this? Well, nuclear radiation is also one of the sources. And since we have nuclear testing happening in our day and age, I thought it kind of came back into my mind. Of course, this is also experimentally tested. This paper is literally titled the evaluation of high density DRAMs as a nuclear detector. Of course, there are some issues with the range of detection, but, you know, still very cool to me. But really, in the end, users can be failed simply by the technology that they rely on, you know, and do nothing wrong on their own to be exposed to potential risks. Or they may be, you know, cursed by the gods in the universe. So for my test here, I registered just about 30 domains. I tried to focus on new sites, some ad networks, and, you know, particularly Asian focused sites. So there's a couple of Asian new sites as well as how one, two, three, which is, I don't even know, just a big, big Chinese site. So overall, I found a lot of activity, which is not surprising given the amount of crawlers and, you know, automated scans that happen on the internet these days. Just registering a domain will cause traffic to happen, basically. So the top graph is the DNS results. I saw about 25,000 DNS queries per week over the monitoring period. You'll notice a couple of gaps there where somebody actually reported my infrastructure. So I had an outage for like a week. And then my script had an error. So I fixed that and then I got back up. The lower one is HTTP, obviously. Significantly fewer requests actually came through HTTP. So it was very interesting to see the difference and just how much DNS traffic there is. In terms of the DNS results, the how one, two, three flip was by far the, well not by far I guess. It's pretty close. But definitely a lot of requests for those. And then blogspot and chase.com came up next. On the DNS results, how one, two, three was still, oh wait, skip one. So you may have noticed actually that those first two graphs had a slight time difference. I had some issues with the HTTP monitor and essentially in this graph I redid the time for the DNS. So these requests were definitely geographically scattered. Although you can see a very hot spot on the west coast. That's essentially from Google's infrastructure. Everybody loves using the Quad 8s. HTTP request geo is basically the same. But you can see that there's a larger hot spot in China. And certainly a lot of Chinese traffic in general. DNS sources again Google by far the number one source. And mostly large infrastructure. HTTP was pretty similar but Beijing moves up quite a bit. Or sorry, the Beijing Baidu network moves way up in the ranks. So some interesting results that I found. Unfortunately this was the only DNS side bit flip. What that means is that in this case the host header is actually for the real domain. But the DNS and HTTP requests came to my domain. So somewhere in the DNS path, the bit flipped and the DNS request went to Google user content with a C in the middle. And that came from India on a really crappy, like, worst smartphone ever. I don't know. I also saw a bunch of weird Android stuff from the Android search bot app. I don't know if this was all legit. I definitely spent a whole lot of time basically just filtering out bots in this experiment. We're just about done. All right. So I guess that's about it. There was some iOS home screen stuff too. I thought this was interesting because this is specifically when you tag a website to your home screen. And all of this traffic came from China, basically. Saw these weird tags that I assume is some guy's scanner. The tag itself is a base 64 string that decodes to force SR with a Tibetan character behind it. And then there's bot cases, bot cases, bot cases. You know, some really interesting scans that use like this one they're trying to identify maybe different content that comes with use refer or not essentially lots of vulnerability scanners, lots of content scanners. So yeah. All right. Thanks, guys.