PACKET HACKING VILLAGE - Bitsquatting: Passive DNS Hijacking
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Miles, Ed
The Domain Name System is one of the foundational technologies that allow the internet to function, but unfortunately, DNS is surprisingly brittle to certain issues, such as bitsquatting. Lookups to names that are a "bitflip" away from well-known sites (like 'amczon.com' instead of 'amazon.com' since 'c' and 'a have a single bit difference) can be caused by memory failing due to defect or overheating situations, rogue cosmic rays, or even (allegedly) radiation caused by nuclear reactions. I was curious how realistic the last case really was - can we 'detect' active nuclear tests based solely on bitsquatting data? To find out, I revisited bitsquatting. First I'll briefly introduce the key concepts required for understanding bitsquatting (including ASCII, DNS and HTTP, Internet infrastructure, and memory error scenarios). I'll show the tools and techniques used to identify and register over 30 newly identified bitsquat domains, monitor DNS and HTTP requests, and process, enrich, and investigate the data. Finally, I will discuss any observations gathered from the data, with a focus on regional trends, specific devices, and current events - and try and see if I could prove any correlation. In the end, attendees should leave with knowledge of the prevalence of bitsquatting and how it has evolved since the phrase was coined 8 years ago, as well as a few techniques for analyzing bitsquatting data and drawing some interesting conclusions.
 Alright, thank you everybody. I'm Ed Miles as he said. I'm here today to talk about bit squatting which can effectively provide pass of 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 DV 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 Mt. 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's 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 kind of 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 typosquatting but for bit flip domains which hopefully not too many of you aren't unfamiliar but just a quick refresher. Typosquatting is when you make a typographical error in your domain name. In this case you might type Microsoft as Microsoft's fifth 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 autocomplete. I visit a lot of the same sites. So that seemed like a pretty good number. But just for reference I pulled that off a quora. Very scientific like I said. So yeah, we have 15 typed URLs per day but the issue here is not in those typed URLs. It's in the domains that come from automatically generated traffic. So when you load a website there will 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 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 all boxing.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 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 try to induce memory failures with direct heating components to try and attack the JVM. But interestingly while doing the background research on to these issues I found this Google paper where they actually studied the DRAM error rates and causes across their 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 is 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. The next one which is pretty interesting to me is cosmic rays. 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 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 study was from guys at IVM and they found significant component of the error rates that you'll see in memory can be attributed to cosmic rays. Not only that but the effect of the error rates increases dramatically at higher altitudes. If you flew here or if you fly a lot you're exposing yourself to possible bit flips. 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 study 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, cosmo errors and particularly they caused repeat errors. So always scan your memory when you're studying a new box. If you're into hardware hacking at all, you know of course that electrical stuff you can cause glitches and CPUs. It 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 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 Asian new sites as well as Hau123 which is, I don't even know, just a 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 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 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 in just how much DNS traffic there is. In terms of the DNS results, the Hau123 flip was by far the, well not by far I guess. It was pretty close but definitely a lot of requests for those and then blogspot and chase.com came up next. On the DNS results Hau123 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 the DNS system. 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 8. HTTP request 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 the 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 but we're just about done. Alright. 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. So all 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. Alright. Thanks guys.
 Alright, thank you everybody. I'm Ed Miles as he said. I'm here today to talk about bit  squatting which can effectively provide pass of 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 DV 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 Mt. 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's  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 kind of 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 typosquatting but for bit flip domains which hopefully not too  many of you aren't unfamiliar but just a quick refresher. Typosquatting is when you make  a typographical error in your domain name. In this case you might type Microsoft as  Microsoft's fifth 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 autocomplete. I visit a lot of  the same sites. So that seemed like a pretty good number. But just for reference I pulled  that off a quora. Very scientific like I said. So yeah, we have 15 typed URLs per day but  the issue here is not in those typed URLs. It's in the domains that come from automatically  generated traffic. So when you load a website there will 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  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 all boxing.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 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 try to induce  memory failures with direct heating components to try and attack the JVM. But interestingly  while doing the background research on to these issues I found this Google paper where  they actually studied the DRAM error rates and causes across their 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 is 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. The next one which is  pretty interesting to me is cosmic rays. 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 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 study  was from guys at IVM and they found significant component of the error rates that you'll see  in memory can be attributed to cosmic rays. Not only that but the effect of the error  rates increases dramatically at higher altitudes. If you flew here or if you fly a lot you're  exposing yourself to possible bit flips. 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 study 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, cosmo errors and particularly they caused repeat errors. So  always scan your memory when you're studying a new box. If you're into hardware hacking  at all, you know of course that electrical stuff you can cause glitches and CPUs. It  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 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 Asian  new sites as well as Hau123 which is, I don't even know, just a 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 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 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 in just how much DNS traffic there is. In terms of the DNS results, the  Hau123 flip was by far the, well not by far I guess. It was pretty close but definitely  a lot of requests for those and then blogspot and chase.com came up next. On the DNS results  Hau123 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  the DNS system. 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 8. HTTP request 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 the 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  but we're just about done. Alright. 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. So all  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. Alright. Thanks guys.
DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_0_3011.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_3012_3215.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_3216_4355.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_4356_5375.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_5376_8555.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_8556_8891.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_8892_9263.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_9264_9803.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_9804_11219.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_11220_12719.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_12720_16631.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_16632_17387.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_17388_18539.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_18540_19895.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_19896_20495.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_20496_20555.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_20556_23699.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_23700_24695.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Ed_Miles_-_Bitsquatting_Passive_DNS_Hijacking_yKeB8c6Kz_g_24696_24864.png