Bit-squatting: DNS Hijacking Without Exploitation
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.
Dinaburg, Artem
Artem Dinaburg - Bit-squatting: DNS Hijacking Without Exploitation-19/dc-19-presentations/Dinaburg/DEFCON-19-Dinaburg-Bit-Squatting.pdf 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.
 My name is Artem Dinerberg. I work as a security researcher for Raytheon Company, and I'm here to talk to you about a vulnerability I discovered called bit squatting. So, in these slides, I always like to start off with a problem. And the problem is that you may be compromised even when you are following the very best web security practices. So, let's go into a little more detail. Let's pretend you're users somewhere around the world and you're browsing Facebook. When you're browsing Facebook, a lot of things get loaded in the background, such as images, JavaScript, and CSS. And sometimes they're not actually loaded from Facebook. They're loaded from a domain that's one bit away from Facebook. And Facebook isn't the only site that's vulnerable. Technically, any site is vulnerable, and the more popular website is, the more vulnerable it is. But some of you may be out there thinking, hey, I'm running Windows 7 and, you know, latest Chrome, so this problem isn't something I should be bothered by. But you're probably wrong. This slide has actual platforms that have requested resources from me instead of from the domain they originally were going to. The problem is actually platform operating system and hardware agnostic. You may be thinking, hey, this is pretty interesting. So it must need, you know, a lot of skills. But you'd be wrong. It's actually extremely easy. To perform bit squatting, all you need to do is, one, have knowledge of some simple math. Two, be able to register domains. And three, properly answer DNS for them. But there's got to be, you know, some resource constraint. Like, you know, maybe you need lots of money, but actually it's extremely cheap. Like I said, the only real requirements are domain registration and hosting. And the cost of registering at.com these days is about $8. Once again, the attack is called bit squatting. And it's called bit squatting because it's like typo squatting, but for bits. So I'm assuming we're all familiar with typo squatting. But if not, here's a good example. Let's say you want to go to Google, which is a popular search engine, but you type in extra G and you go to Google where you can win Walmart gift cards, free iPads, but sorry, they're out of MacBook Airs. And this is not what I'm talking about. Bit squatting requires absolutely no typing. And the reason is that while humans do a lot of typing and they make a lot of mistakes, computers make a lot more DNS queries. So the graph on the slide is actually to scale. If you look at that top right corner, you see the little guy circled in red. That's the proportion of DNS requests that humans make to the proportion of DNS requests that computers make. A little bit about how I got these numbers. The 1500 comes from doing some math on the open DNS blog. In a blog post dated this March, they said that they had 30 billion unique DNS queries per day. If you go to their website, it says that they have 20 million users. Doing some simple mathematics leads to 1500 DNS queries per user. Another website, visual economics dot com, calculated that people go to 89 different domains a month. Pro rated, 2 per day, that's 3. So while bit squatters are going after the three domains that you type in, type of bit squatting goes after the 1497 that you don't. And how can you take advantage of these 1497 domain lookups? Computer hardware errors. Just to clarify, I'm not talking about things like bad programming, buffer overflows or logic bugs. I'm talking about errors in the hardware that cause even perfectly written programs to misbehave. And the thing is, computers are devices made by mere mortals. And they have things like tolerances and mean times to failure. One of the potential failures that can arise is called a bit error. And in literature, these are sometimes referred to as single upset events. And this means that the electrical representation of a one gets transformed into a zero, or the electrical representation of a zero gets transformed into a one. And it's really important to notice that these bit errors happen in context. They don't happen in a void. If a bit changes from a one to a zero or a zero to a one, it happens in your, let's say, your linked lists, your trees, other data structures, maybe your login credentials, or maybe it happens in some cached HTML that happens to have a domain name. And maybe your browser will then look up that domain and fetch some JavaScript from it. So now that you've talked about bit errors, let's go through an introduction. I don't know if you all can tell what this man is doing, but he's actually working on the ENIAC. And what he's doing is he's replacing a vacuum tube. The ENIAC was made before modern transistor technology, and it's used vacuum tubes for memory storage and computation. And these vacuum tubes failed, and they failed a lot. Whenever one of these tubes had failed, the machine would either give incorrect answers or it would stop working at all. These were the first examples of bit errors, and they've been with us for a very long time. But, you know, we don't use vacuum tubes these days. We move it on to transistors and then integrated circuits, and they're much more reliable, and we should have never encountered any problems with ICs and random failure. Right, guys? Well, not quite. This is a RAM board from the Mitz-Altair 8800. The Mitz-Altair is actually a very famous computer. It ushered the mini-computer revolution. Microsoft's first product was Altair Basic. It helped launch the company. But we're not here to discuss that. What we're focused on is those purple chips at the top of the RAM board. Those are Intel 2107 series DRAM chips. And in 1978, two engineers from Intel, May and Woods, discovered that these chips were catastrophically failing. The problem was traced back through the supply chain, and eventually they found out that what had happened is that Intel had built a chip fab downstream from an old uranium mine. And during fabrication, these chips would be contaminated with radioactive alpha emitters. So then when this chip was running software, possibly Mitz-Altair Basic, an alpha particle would get emitted, it would shift from 1 to 0s, and your perfectly running application would crash. They published a paper on this, and the semiconductor industry took note. They took this very seriously. And they refined manufacturing processes, and this has certainly never happened again, right everyone? Fast forward to 2008. This is the, sorry, not 2008, 2001. This is a Sun Ultra Spark 2. The one in the slide is from 1997, but that's not what we're focused on. In 2001, a lot of very expensive Sun servers started randomly failing. And this server would be running, then it would crash, you would reboot it, you would do a full self-test, and it would say it's perfect, and then later it would randomly die again. And naturally there were a lot of angry customers, and Sun started to check what the problem was, and it turned out it was radioactive contamination of their L1 and L2 cache. To make things worse, the L1 and L2 cache on the Ultra Sparks had no air detection, so the only time you'd realize something was wrong is when your mission critical applications went down. But this had to be the last of it. There wouldn't really be something required, you know, no operating system ship, something to test hardware with its installation, do they? This is an Ubuntu installation. It's a direct screenshot. One of the options is test memory. Why would you ever want to test memory? Because a lot of the times your test will fail. And this is only for the only people who would actually know that it failed is the people who decided to run that test. Think about how many people are running with bad hardware components who don't even know it. And these bit errors have security implications, and these security implications range a lot further than just random data corruption. In fact, they range from things like sandbox escapes to extracting encryption keys out of proprietary devices. So, up first is a JVM sandbox escape. In 2003, Sudakar and Apple of Princeton University published an extremely interesting paper in IEEE Security and Privacy. They had found a way to use random bit errors to escape out of the Java JVM sandbox. What they would do is they would fill memory with two Java objects and references to those objects. And when a bit error would occur, it would change one of the references to point from one object to the other. Once you had two differently typed references to the same object, you could then establish a write what where primitive, and once you write executable code to anywhere in memory, it was game over. To test their experiment, they couldn't exactly wait for a bit error to happen, so they devised the apparatus you see in the slide. That is a heat lamp attached and pointing at their RAM, and it would heat the RAM to above its critical operating temperature to where random bit errors would happen. They were able to verify their results experimentally. Next security implication is a smart card piracy. There's actually an ongoing war between cable-to-v set-top box manufacturers and smart card pirates. Satellite signals are broadcast throughout, and they're encrypted, and the way you view satellite TV is if you have the decryption key in a smart card. Well, pirates want to be able to decrypt those signals as well and sell knockoff smart cards. One of the ways in which they get to the encryption key in the smart card is they will attach the smart card bus, and then they will induce a bit error in the smart card CPU, usually via direct electrical probing, to redirect execution to a pirate code, which will then proceed to dump RAM contents before it has a chance to lock itself. Now, there's other causes of bit errors besides probing by smart card pirates and heat lamps, and I'm going to get into four of them. So, cause number one is heat. It is a physical fact that heat affects properties of electrical devices, such as conductivity and resistivity. Now, this isn't too much of a problem in desktops and maybe even laptops because they're well-cooled and they're normally operated indoors, but when it comes to mobile devices, heat can be a serious issue. This is what happens when your iPhone gets too hot and eventually tells you. But did you ever wonder what happens maybe before the screen has a chance to come up in devices that don't have one, or even under what temperature it comes on anyway? So, I've got a handi-graph here for you guys. This is the iPhone operating temperature, as taken from the Apple website, plotted against two climates in North America, one here in Las Vegas and one in Montreal, Canada. Right now, since it's August, we are at the top of that blue curve. If you notice, it's well above the maximum iPhone operating temperature of 95 degrees. If you've used your iPhone outside today, congratulations, you've been violating its operating requirements. So, next cause of bit errors, electrical problems. This slide is actually very apt when I found the picture. The caption for it was that this is the backup power supply for a group of computers in rural India. We are all accustomed to always-on, very good AC power in the western world, but this isn't true for a lot of parts. Sometimes, your power is extremely unreliable, intermittent, or both, and sometimes, your backups or car batteries. When you have extremely unreliable input voltage, odds are that extremely unreliable effects may propagate through your electronics. Sometimes, though, it's the electronics on cells that are faulty. Picture here is a pirate capacitor. There's actually entire websites on the Internet dedicated to identifying faulty capacitors and common motherboards. Their list is a lot higher than you would think. So, whenever they bid components out to the lowest bidder, sometimes they get exactly what they pay for. Capacitors also aren't the only electronic components that are pirated. There's knockoffs of all kinds of things sold in the black market, and sometimes, to a skimpa buck or maybe pocket the difference, people making their electronics might not use the best ones. Even if they do use the very best components, as we saw earlier in the case of the Intel Drams and the Sun Ultra Spark, sometimes, you may just be radioactive contamination somewhere during manufacture. And speaking of radiation, that brings us back to the last, but certainly not least, cause of bid errors, and that is cosmic rays. Yes, I'm serious. And I specifically mean the intergalactic kind, not the solar kind. From all the research I've been able to do, the solar kind are generally not energetic enough to penetrate the upper atmosphere, but the intergalactic one certainly are. Potentially far from being a remote nuisance, there are some studies that indicate that cosmic rays are actually the number one source of bid errors at ground level. This is a graph taken directly from the IBM Journal of Research and Development, Volume 40, number one, page 13, for those who are interested. And what it's plotting here is altitude versus cosmic ray flux, which go hand in hand as the higher up you go, the more cosmic rays there are since there is less atmosphere. And if you notice these circles on the triangles, those are actually experimentally observed errors in cache and main memory. If you notice, they align exactly with the prediction for the cosmic ray flux. Now, this IBM study ran from 1978 to 1994, so it's entirely possible newer generations of RAM are differently affected, but cosmic rays is definitely something you want to consider. So, what's the distribution of various causes of bid errors that I see in the wild? Honestly, I don't really know. I can't go half way around the world and see what was wrong with somebody's iPhone, and it's entirely possible to cause a didn't consider. What is interesting to know is that these bid errors do happen, and they're real. We have mentioned DRAM for a bit, and I'm going to go into a little more in-depth discussion about DRAM. DRAM is the source of really great information density for bid errors to happen. It's hard to cool. The components are always cheap, and it happens to be where the previous majority of bid error studies have focused. So, I'll start off with some really good news. And the good news is that all errors in DRAM can be fixed by use of what is called ECC or error-correcting codes, and ECC can detect and fix all single-bit errors. There's actually forms of ECC that will detect all one, two, three, and four-bit errors. But ECC only works if you actually use it. A lot of you in the audience probably manage extensive server farms, and those typically have ECC memory, since hardware manufacturers know that bid errors do happen, and especially high-end ones. But have you thought about all the RAM in your server? I'm going to go with no. This is a hard drive pulled from one of these enterprise-class servers with ECC memory that chip there, highlighted in yellow, is 128-megabit DRAM. It does not have ECC. And this drive is actually a few years old. It only has 16 megabytes of cache, newer drives have 32 or even 64 megabytes of cache, and enterprise servers typically have five to eight of these drives. So the data in your enterprise-class server may be going through a lot of non-ECC memory. Let's look at some DRAM failure rates. Now that we've established there's probably a little bit of it in your server somewhere. This slide summarizes two different studies, one from a Terrazan semiconductor and one from Schroeder at the University of Toronto in association with some engineers from Google. And the first thing you notice is that the scale varies very widely. This is also a logarithmic scale. The lowest error rate is about 50, and the highest error rate is about 100,000 failures in test. And the failure in test is about one error in one billion operating hours. Another interesting thing to note here is if you see the manufacturer one to manufacturer six columns, those are from the Schroeder study, and those were bit error rates measured in actual servers in Google data centers. One of their conclusions was also that the vast majority of bit errors could be attributed to specific DIMS, counteracting the IBM study, and in fact suggesting that maybe manufacturing defects are in fact the number one cause of DRAM failures. But if you don't typically think in terms of one failure in one billion operating hours, so let's put this in a more usable perspective. If you go to Dell.com, the cheapest PC you can buy will have 4 gigabytes of RAM. Assuming the worst case scenario from the previous slide, that PC will encounter approximately 3 bit errors per hour. Assuming the best case scenario, it'll encounter approximately 3 bit errors per month. But also, it's not great to think of just a single PC. What we want to see is the emergent effect of all the DRAM on the Internet. And there are several studies that say that there are approximately 5 billion devices that are connected to the Internet in 2010. Assuming each of these devices has 128 megabytes of RAM, and now this assumption isn't really based on scientific fact, I felt it was a very fair compromise between the servers that have multiple, multiple gigabytes and your phone which may have, you know, 6 to 20. You will get approximately 600 petabytes of DRAM that is connected to the Internet. And using the lower end error estimates from the previous slide, that's approximately 600,000 bit errors that occur daily in all the world's Internet connected DRAM. Now, how many of those errors actually happen somewhere that is interesting? Well, I set up an experiment to find out. And this experiment is in three parts. Part one, register domain names. This list includes actual domain names that I registered. They are one bit away from certain very popular domain names. By one bit away, I mean is you take the domain name, then you put it in its ASCII representation, you expand it out as a binary string, change ones to zeros and zeros to ones. If it's still a valid domain name, when you put it back to ASCII, you register it. And the domain names they pick tended to be those of popular websites and more crucially advertising and content delivery networks. And the reason they pick those is because nobody ever types those addresses in, but you certainly look them up an extremely large amount of time. Experiment step two is you have to properly answer DNS. And this is actually very important, and I'm going to go through this via an example. So let's say somebody out there is trying to resolve a domain name you registered. Let's say it's mic20soft.com, one bit away from Microsoft. So you're going to get an A record request, and of course you will answer it. But the trick here is that we think that a bit error happened somewhere on that server that asked you for the domain name. Therefore, we will also send it back a second reply for the original domain we expected it to be. And the reason we do this is because if it's expecting a reply for microsoft.com, it will discard the reply for mic20soft.com, but silently accept the Microsoft one. If it did indeed query mic20soft.com, it will accept that reply, but discard the Microsoft reply. In an overview, for every domain, for every DNS request you receive, you have to send back two responses. And this isn't just A records. This is also other types of records such as NS requests. Assuming your bit squatting was successful, next thing that's going to happen is you will get an HTTP request. So you set up an HTTP listener, and you log the connection. And in this case, I chose to return HTTP 404 not found for every single request I received, since I wanted to avoid causing any damage to any of the requesting computers. Once again, that's you get a request, you log the request, you send it back a 404, and you close the connection. Then this is how I set up my experiment. And the first thing that really surprised me is that people actually show up. This is the traffic volume of raw HTTP requests for a six month period from the end of September to the beginning of May. As you can see, there is a steady background stream of requests, punctuated by several extreme spikes, the biggest which was approximately 3,500 HTTP requests per day. But raw requests isn't necessarily a fair comparison, since maybe some machines out there get in a loop and you have one guy requesting the same resource over and over again. So here instead is the traffic volume by unique IP address per day. Some of the peaks disappear, but others still remain. Aside from the steady stream of background noise, there's three major events labeled here as A, B, and C. Each of these caused by bit squatting, and I will get into detail of these in the next three slides. So what caused event A that affected more than 1,600 unique IPs on the Internet? And that critical application happens to be Farmville. Yes, I'm serious. The reason this says 1,300 IPs is because it could only attribute 1,300 of those directly to Farmville, but the other 300 are also of similar causes. So how exactly does this happen? Well, let's diagram this out. Let's pretend you're a user somewhere and you want to go play some Farmville. Then you request some stuff from Facebook, and a bit error happens in either the Facebook or the Farmville servers, and profile.aka.fbcdn.net changes to pbo file.aka.fbbdn.net. I happen to own fbbdn.net, and this bit error happens to happen in the URL of an ad server, and this URL gets cached and then served up to the 1,300 people who keep requesting that resource. Instead of requesting ads from Farmville, they're requesting ads from me. I could have sent them anything I wanted, but I chose the 404. Once again, an overview. You're doing nothing wrong going to play some Farmville. A bit error happens somewhere outside of your control in either Facebook or the Farmville servers. This bit error gets cached, served up to 1,300 people, and those 1,300 people request ads from me instead of from Farmville. That's event A, and event B was 456 unique IPs, and the cause of that was also Farmville. The reasoning behind it was actually also pretty much the same, except the bit error here was different. You would play Farmville, bit error changes fbbcdn.net to fbbgdn.net. Once again, this bit error gets cached somewhere in the Farmville cache, gets served up to 130 different people who request ads from me. And of course, you don't have to send them ads. I chose the 404s, but there's no reason somebody malicious couldn't send them some choice JavaScript. That's it for event B. Event C is actually the most interesting one of all, and I promise it's actually not Farmville, and it affected 246 unique IPs. What's interesting about event C is that it's an actual case of DNS poisoning caused by random bit errors. After looking through the logs for the days of event C, I noticed that all of the requests for those few days were one from the same slash 24, and two, they were all for the same server. And here is approximately what happened. So you're someone in that slash 24. You request your ISP to resolve s0.2mdn.net. A bit error occurs somewhere in your ISP's recursive domain server. Instead of requesting s0.2mdn.net, you request to resolve s0.2-dn.net, which I happen to own. If you recall from before, we always send two DNS replies. One of the replies we're going to send back is for s0.2mdn.net. This reply is going to, one, get cached in the DNS server, and two, get propagated to the original requestor, who will then request an ad from me instead of froma2mdn. And I will send them a 404, but of course, you can be more creative. As a full overview of the entire process, you are browsing some website, you request an ad. Your local ISP's DNS server cache happens to be empty. It queries instead s0.2-dn.net. I own that, I answer DNS authoritatively for it, and I say, hey, here's the IP address for s0.2mdn.net. That gets propagated, that gets cached, propagated to the original requestor, and now everybody in that slash 24, when they're requesting s0.2mdn.net, will instead request, will instead get my IP instead of the original one, until the DNS cache expires. So that concludes the three outlier events. And if you look at the traffic without outliers, you see that it's generally just a random trickle of requests. But even this, you can see by the blue line, that there's an average of 59 requests. This is 59 requests with only 32 domains. This can easily be linearly scaled up by any sort of organized person. Next thing I wanted to do after measuring the traffic volume, was to see the volume per hour. My intuition here was that there would be more bit errors when it's hotter outside during the day. Unfortunately, it also turns out that most people use their computers during the day, so it's impossible for me to separate the causes due to heat from simply more traffic use. But it is very interesting that this graph approximately mirrors North American internet traffic. And this only includes the traffic from those IPs that were geo-located within the United States. There is a steady start of traffic about 8 Eastern. It goes and levels off at about 2 p.m. and stays steady up until midnight where it rapidly drops off, only to resume again the next morning. Next thing I was curious about is, what operating system are all of these users using? So I have their user agent header, which conveniently tells me browser and operating system. So I decided to compare the operating system of people visiting my BitSquad domains to the people visiting Wikipedia for March of 2011. I'll start off with the commonalities. So there's a giant common share of Windows boxes, which is to be expected. Windows is the most popular OS. Then there's about 3% iPhones, 1% Linux users, and 1% Android. Now, the difference is what's really striking. First, for some reason, only 2% of the visitors to my BitSquad domains are users using Apple OS X, whereas 8% of the visitors to Wikipedia do. I do not have a conclusive explanation for this. My thoughts think from a potentially better build quality to maybe the aluminum casing being a better cosmic ray shield. Not really sure. And the crucial thing here is that other field, the other field for BitSquads is 5%, whereas the other field for Wikipedia is 2%. So I looked at the user agents of these others, and this is all kinds of handheld mobile devices and gaming platforms. Things I saw were Wii's, PlayStation 3's, PSP's, Sony Ericsson phones, Samsung phones, and other devices. And a lot of these phones also really like telling you what carrier they're on for some reason. Not sure of the logic behind that. Next, I wanted to know, so where are these people coming from? At first, I graphed this for all of the visitors, but I chose to limit it to Microsoft.com since some of the sites at BitSquad are disproportionately popular in the United States. I figured Microsoft would be a good target since the vast majority of DNS lookups would in fact be from automated Windows machines. The results here are actually extremely surprising. They do not correspond to population. They do not correspond to number of internet devices, and they do not correspond to number of internet users. I don't have a solid explanation for this. My only guesses include, potentially, that as we saw from before, not all BitSquads are equal. Sometimes you win the BitSquad lottery and get some server in Farmville. Sometimes you just BitSquad somebody's iPhone. It's entirely possible that it just happened to a BitSquad more useful places in China and Brazil. But this definitely warrants further research to see exactly what the issue is. Next, what I looked at was, which domain are these people looking up? And this includes outliers, so of course Facebook is by far and away the crowd favorite, and followed by BitSquads of Microsoft, followed by various content delivery and advertising domains. If you see there highlighted in yellow is MSN.com. If you were to look at the list of domains that I BitSquad'd, MSN.com wasn't actually on that list. So, how did MSN.com make it into the top 25 most popular domains, despite the fact that I didn't BitSquad it? Well, I'm going to explain it, but first I want to explain the places where BitEros can happen. There's two different places. One of these is the DNS path, and this happens during name resolution, and one of these is the content path, which occurs before DNS ever has a chance to work. We'll start off with the DNS path, and this is best illustrated by example. So, you request FBCDN.net from your ISP. A bit error occurs in your ISP's DNS server, and instead it requests FBBDN.net. I own FBBDN.net. I send two DNS replies. One of these is for the original domain, and this domain reply gets propagated back to the original requester. Then, this is crucial. The original requester will make an HTTP request to me. I don't know how many of you are familiar with the HTTP11 protocol, but HTTP11 requires that you use the host header, and the host header contains the domain that you are actually you think you're connecting to. So, in the case of bit errors during DNS, I will see a host header of the original domain in my HTTP logs. And of course, then you can send them whatever you want back. Once again as an overview, you request FBCDN.net. A bit error occurs somewhere in the DNS resolution path, and what ends up being requested is FBBDN.net. The bad reply gets propagated to the original requester, who then makes an HTTP connection, and crucially, in their host header, uses FBCDN.net, the original domain. Now, on to bit errors in the content path. And the content path is the farmville type bit errors. So, you're somebody browsing something like Facebook. A bit error happens somewhere in the extensive Facebook memory caching infrastructure, and let's say it's, you know, for a JavaScript, you're about to pull from it, and the domain changes from FBCDN.net to FBBDN.net. Then, you will connect to my BitSquad server, and in your host header, you will say FBBDN.net, because the bit error occurred before you ever looked the domain name up. You are bound to connect to FBBDN.net because of the bit error happened in the actual content. And now, this content didn't actually have to get corrupted somewhere on the server end. It could have entirely gotten corrupted in, let's say, the memory of your iPhone. Afterwards, I send them back a reply, and as an overview, you're browsing Facebook. A bit error happens somewhere in the content, either on the cache, or maybe somewhere in your memory, or maybe when you're parsing HTML. And crucially, when you make the HTTP request, your host header has the BitSquad domain and not the original domain. So, what's the actual breakdown of these that we see? 96% of the time, and this includes the outliers, since they were actually Cosby bit errors, 96% of the time, the host header that I see is the BitSquad host header. That means that all of the security research that you've been doing for DNS would not fix it. What we need is research on ensuring content integrity. The other 4% of the time, the error happens along the DNS path. And if you look, 1% of the domains aren't the BitSquad domain, they're not the original domain, they're, in fact, the other domain, such as the MSN.com that we saw earlier. And the reason this occurs is because of CNAME chains. This is an actual example that I observed. In a CNAME chain, when you want to resolve a domain, the domain is actually says, hey, I'm a canonical name for this other domain, and that domain is a canonical name for yet another one. And you follow this chain until you finally resolve a domain to an IP. If a bit error occurs anywhere following the CNAME chain, you will get redirected to a BitSquad domain instead of the original domain. And that's how I was able to get requests for Microsoft and this guy for ax.init.itunes.apple.com. Despite the fact that I did not BitSquad those domains. So, speaking of other domains, it's time for a series of real-life examples. I apologize if this is really small, but I couldn't think of a way to better convey it, so sorry for those of you in the back. The very top request is, of course, for ax.init.itunes.apple.com. And I believe that person is actually trying to activate their iPhone. I can only assume they were unsuccessful. There's a few of these for AdMob and there's a few for MSN. And I want to note that this is not an exhaustive list of the ones I saw. Quite a bit more of these, these are just the ones I chose to include. Next up is people browsing Facebook. These are people requesting JavaScripts from me while they're logged into and browsing their Facebook sessions. It doesn't take a lot of thinking to figure out that you can extremely easily steal their Facebook session cookies, send them some phishing pages, or do other really malicious activity. Next up is people requesting Windows updates. Some of these are for the initial Windows Update self-updater, but if you see that bottom one is somebody is actually requesting an exe from my server instead of the Windows Update server. I really hope they verify those signatures. Next up, people browsing their web mail and requesting ads from me while they're logged into their web mail session. This is also not an exhaustive list, but I hope you'll recognize the dangers of this. If you have JavaScript running when you're logged into your web mail session, I can potentially steal your web mail credentials. That's not a good thing. Also, the two examples here from live.com, I don't want to pick on them. I got lots of requests from various web mail sessions. These are just the ones that I have to find first and put in. Next example, Dr. Watson crash reports. So one of the biggest criticisms I got during this entire thing was that, hey, these things can't possibly be legitimate because you're going to, whenever a machine encounters bit errors, it's just going to crash and it'll die before you ever see anything useful. Well, I'm sure that certainly happens a very large percentage of the time, but some of the time the machine crashes and you can get something useful out of it. Interestingly enough, I don't know if you're familiar with Windows Air Reporting, but the server on the other end can actually potentially request a full memory dump from your machine. So if this happened to you, I could have potentially requested you to send me the contents of your RAM. My favorite is actually that second one. It's a Watson report from notepad.exe. We all know how unreliable that process is. So now that we've seen that these things happen, that they're very serious, let's talk about some mitigations. We'll start with mitigation number one, and that is ECC on everything. If you're in this room and you're in the charge of a bill of materials for the next mobile device, the next laptop, desktop, the next server, please make sure you use ECC memory everywhere. That includes things such as your drive and your Nick and your Nick and maybe your keyboard controller. Next mitigation, pre-register domains. This is actually the easiest you can do since bit squatting affects a very small percentage of all domain lookups. If you own a really, really popular domain, you also have the most money to register potential bit squats of that domain. There's actually a quick upper bound you can place on this. If you're only looking at single bit errors, the most possible bit squats that can exist is six times the amount of letters in your domain. That's only for single bit errors, though. The great thing about pre-registering is, one, you can do it right now. Two, it'll help all your users, even your users running in some really hot climate in really terrible power supplies with a really bad computer. And mitigation number three, trust but verify your data. As we noticed earlier, 96% of these bit errors occur during the content path. If you or somebody here responsible for building a really large memory caching infrastructure, you should check that what you put in your cache is actually what comes out of the cache when somebody requests it. Please include something like a CRC32 with every cache element. Modern CPUs actually have a CRC32 instruction, so performing this should actually be extremely quick. And you're probably going to be bound by network delay anyway. Another place where you should consider doing this is if you're developing mobile devices or something else that's going to work in high stress environments, please be sure to verify things like the integrity of your outgoing DNS queries. Some room for future research. Previously, it's only been possible to bit squat second level domain names, but ICANN has approved generic TLDs. It'd be entirely possible for somebody to out of know, register.con for conferences, and perhaps you would get a nice slice of the traffic for.com. I was actually talking to somebody in Black Hat, and apparently there's a 300 page guide of rules you have to follow to get one of these things, and they try to preclude similarities, but still you want to be sure. Another possible issue is punicode domains. I have not looked into what happens at bit errors in punicode domains. For those unfamiliar, punicode is how you would use internationalized characters and domain lookups, but it's quite possible that a bit error in a punicode domain in one language would actually be a domain in a completely different language, making the attempted use of trademark laws to get it back extremely difficult. I would like to give a special thanks to a few people, notably Robert Edmonds of ISC, who first noticed DNS bit errors in SAE data. Another person is Paula Royal, who helped me immensely when creating the white paper for this. Erin Lamasters for acting as the adversarial researcher. The entire Raytheon Roslin office for their support in helping me with many multiple reviews. My other patient and supportive reviewers, whom I begged to review my slides in my white paper. The DEF CON 19 staff for helping me actually present this to you guys. And to everybody who licenses your photography in a creative comments format, without you this presentation would not have been possible. And of course, to all of you guys who came to see my talk, I greatly appreciate it. And finally, I'd like to say if you want a quick tool to identify which bit squats of your domain are available, you can get a Python script at dinoburg.org. Thank you.
 My name is Artem Dinerberg. I work as a security researcher for Raytheon Company,  and I'm here to talk to you about a vulnerability I discovered called bit squatting.  So, in these slides, I always like to start off with a problem.  And the problem is that you may be compromised even when you are following the very best web security practices.  So, let's go into a little more detail.  Let's pretend you're users somewhere around the world and you're browsing Facebook.  When you're browsing Facebook, a lot of things get loaded in the background, such as images, JavaScript, and CSS.  And sometimes they're not actually loaded from Facebook.  They're loaded from a domain that's one bit away from Facebook.  And Facebook isn't the only site that's vulnerable.  Technically, any site is vulnerable, and the more popular website is, the more vulnerable it is.  But some of you may be out there thinking, hey, I'm running Windows 7 and, you know, latest Chrome,  so this problem isn't something I should be bothered by.  But you're probably wrong.  This slide has actual platforms that have requested resources from me  instead of from the domain they originally were going to.  The problem is actually platform operating system and hardware agnostic.  You may be thinking, hey, this is pretty interesting.  So it must need, you know, a lot of skills.  But you'd be wrong.  It's actually extremely easy.  To perform bit squatting, all you need to do is, one, have knowledge of some simple math.  Two, be able to register domains.  And three, properly answer DNS for them.  But there's got to be, you know, some resource constraint.  Like, you know, maybe you need lots of money, but actually it's extremely cheap.  Like I said, the only real requirements are domain registration and hosting.  And the cost of registering at.com these days is about $8.  Once again, the attack is called bit squatting.  And it's called bit squatting because it's like typo squatting, but for bits.  So I'm assuming we're all familiar with typo squatting.  But if not, here's a good example.  Let's say you want to go to Google, which is a popular search engine, but you type in extra G  and you go to Google where you can win Walmart gift cards, free iPads,  but sorry, they're out of MacBook Airs.  And this is not what I'm talking about.  Bit squatting requires absolutely no typing.  And the reason is that while humans do a lot of typing and they make a lot of mistakes,  computers make a lot more DNS queries.  So the graph on the slide is actually to scale.  If you look at that top right corner, you see the little guy circled in red.  That's the proportion of DNS requests that humans make to the proportion of DNS requests that computers make.  A little bit about how I got these numbers.  The 1500 comes from doing some math on the open DNS blog.  In a blog post dated this March, they said that they had 30 billion unique DNS queries per day.  If you go to their website, it says that they have 20 million users.  Doing some simple mathematics leads to 1500 DNS queries per user.  Another website, visual economics dot com, calculated that people go to 89 different domains a month.  Pro rated, 2 per day, that's 3.  So while bit squatters are going after the three domains that you type in,  type of bit squatting goes after the 1497 that you don't.  And how can you take advantage of these 1497 domain lookups?  Computer hardware errors.  Just to clarify, I'm not talking about things like bad programming, buffer overflows or logic bugs.  I'm talking about errors in the hardware that cause even perfectly written programs to misbehave.  And the thing is, computers are devices made by mere mortals.  And they have things like tolerances and mean times to failure.  One of the potential failures that can arise is called a bit error.  And in literature, these are sometimes referred to as single upset events.  And this means that the electrical representation of a one gets transformed into a zero,  or the electrical representation of a zero gets transformed into a one.  And it's really important to notice that these bit errors happen in context.  They don't happen in a void.  If a bit changes from a one to a zero or a zero to a one, it happens in your, let's say, your linked lists,  your trees, other data structures, maybe your login credentials,  or maybe it happens in some cached HTML that happens to have a domain name.  And maybe your browser will then look up that domain and fetch some JavaScript from it.  So now that you've talked about bit errors, let's go through an introduction.  I don't know if you all can tell what this man is doing, but he's actually working on the ENIAC.  And what he's doing is he's replacing a vacuum tube.  The ENIAC was made before modern transistor technology,  and it's used vacuum tubes for memory storage and computation.  And these vacuum tubes failed, and they failed a lot.  Whenever one of these tubes had failed, the machine would either give incorrect answers  or it would stop working at all.  These were the first examples of bit errors, and they've been with us for a very long time.  But, you know, we don't use vacuum tubes these days.  We move it on to transistors and then integrated circuits,  and they're much more reliable, and we should have never encountered any problems with ICs and random failure.  Right, guys?  Well, not quite.  This is a RAM board from the Mitz-Altair 8800.  The Mitz-Altair is actually a very famous computer.  It ushered the mini-computer revolution.  Microsoft's first product was Altair Basic.  It helped launch the company.  But we're not here to discuss that.  What we're focused on is those purple chips at the top of the RAM board.  Those are Intel 2107 series DRAM chips.  And in 1978, two engineers from Intel, May and Woods,  discovered that these chips were catastrophically failing.  The problem was traced back through the supply chain,  and eventually they found out that what had happened is that  Intel had built a chip fab downstream from an old uranium mine.  And during fabrication, these chips would be contaminated with radioactive alpha emitters.  So then when this chip was running software, possibly Mitz-Altair Basic,  an alpha particle would get emitted, it would shift from 1 to 0s,  and your perfectly running application would crash.  They published a paper on this, and the semiconductor industry took note.  They took this very seriously.  And they refined manufacturing processes,  and this has certainly never happened again, right everyone?  Fast forward to 2008.  This is the, sorry, not 2008, 2001.  This is a Sun Ultra Spark 2.  The one in the slide is from 1997, but that's not what we're focused on.  In 2001, a lot of very expensive Sun servers started randomly failing.  And this server would be running, then it would crash, you would reboot it,  you would do a full self-test, and it would say it's perfect,  and then later it would randomly die again.  And naturally there were a lot of angry customers,  and Sun started to check what the problem was,  and it turned out it was radioactive contamination of their L1 and L2 cache.  To make things worse, the L1 and L2 cache on the Ultra Sparks had no air detection,  so the only time you'd realize something was wrong  is when your mission critical applications went down.  But this had to be the last of it.  There wouldn't really be something required, you know,  no operating system ship, something to test hardware with its installation, do they?  This is an Ubuntu installation.  It's a direct screenshot.  One of the options is test memory.  Why would you ever want to test memory?  Because a lot of the times your test will fail.  And this is only for the only people who would actually know that it failed  is the people who decided to run that test.  Think about how many people are running with bad hardware components who don't even know it.  And these bit errors have security implications,  and these security implications range a lot further than just random data corruption.  In fact, they range from things like sandbox escapes  to extracting encryption keys out of proprietary devices.  So, up first is a JVM sandbox escape.  In 2003, Sudakar and Apple of Princeton University  published an extremely interesting paper in IEEE Security and Privacy.  They had found a way to use random bit errors to escape out of the Java JVM sandbox.  What they would do is they would fill memory with two Java objects  and references to those objects.  And when a bit error would occur,  it would change one of the references to point from one object to the other.  Once you had two differently typed references to the same object,  you could then establish a write what where primitive,  and once you write executable code to anywhere in memory, it was game over.  To test their experiment, they couldn't exactly wait for a bit error to happen,  so they devised the apparatus you see in the slide.  That is a heat lamp attached and pointing at their RAM,  and it would heat the RAM to above its critical operating temperature  to where random bit errors would happen.  They were able to verify their results experimentally.  Next security implication is a smart card piracy.  There's actually an ongoing war between cable-to-v set-top box manufacturers  and smart card pirates.  Satellite signals are broadcast throughout, and they're encrypted,  and the way you view satellite TV is if you have the decryption key in a smart card.  Well, pirates want to be able to decrypt those signals as well  and sell knockoff smart cards.  One of the ways in which they get to the encryption key in the smart card is  they will attach the smart card bus,  and then they will induce a bit error in the smart card CPU,  usually via direct electrical probing,  to redirect execution to a pirate code,  which will then proceed to dump RAM contents before it has a chance to lock itself.  Now, there's other causes of bit errors besides probing by smart card pirates and heat lamps,  and I'm going to get into four of them.  So, cause number one is heat.  It is a physical fact that heat affects properties of electrical devices,  such as conductivity and resistivity.  Now, this isn't too much of a problem in desktops and maybe even laptops  because they're well-cooled and they're normally operated indoors,  but when it comes to mobile devices, heat can be a serious issue.  This is what happens when your iPhone gets too hot and eventually tells you.  But did you ever wonder what happens maybe before the screen has a chance to come up  in devices that don't have one,  or even under what temperature it comes on anyway?  So, I've got a handi-graph here for you guys.  This is the iPhone operating temperature, as taken from the Apple website,  plotted against two climates in North America,  one here in Las Vegas and one in Montreal, Canada.  Right now, since it's August, we are at the top of that blue curve.  If you notice, it's well above the maximum iPhone operating temperature of 95 degrees.  If you've used your iPhone outside today, congratulations,  you've been violating its operating requirements.  So, next cause of bit errors, electrical problems.  This slide is actually very apt when I found the picture.  The caption for it was that this is the backup power supply  for a group of computers in rural India.  We are all accustomed to always-on, very good AC power in the western world,  but this isn't true for a lot of parts.  Sometimes, your power is extremely unreliable, intermittent, or both,  and sometimes, your backups or car batteries.  When you have extremely unreliable input voltage,  odds are that extremely unreliable effects may propagate through your electronics.  Sometimes, though, it's the electronics on cells that are faulty.  Picture here is a pirate capacitor.  There's actually entire websites on the Internet dedicated to identifying faulty capacitors  and common motherboards.  Their list is a lot higher than you would think.  So, whenever they bid components out to the lowest bidder,  sometimes they get exactly what they pay for.  Capacitors also aren't the only electronic components that are pirated.  There's knockoffs of all kinds of things sold in the black market,  and sometimes, to a skimpa buck or maybe pocket the difference,  people making their electronics might not use the best ones.  Even if they do use the very best components,  as we saw earlier in the case of the Intel Drams and the Sun Ultra Spark,  sometimes, you may just be radioactive contamination somewhere during manufacture.  And speaking of radiation, that brings us back to the last,  but certainly not least, cause of bid errors,  and that is cosmic rays.  Yes, I'm serious.  And I specifically mean the intergalactic kind, not the solar kind.  From all the research I've been able to do,  the solar kind are generally not energetic enough to penetrate the upper atmosphere,  but the intergalactic one certainly are.  Potentially far from being a remote nuisance,  there are some studies that indicate that cosmic rays are actually the number one source of bid errors at ground level.  This is a graph taken directly from the IBM Journal of Research and Development,  Volume 40, number one, page 13, for those who are interested.  And what it's plotting here is altitude versus cosmic ray flux,  which go hand in hand as the higher up you go,  the more cosmic rays there are since there is less atmosphere.  And if you notice these circles on the triangles,  those are actually experimentally observed errors in cache and main memory.  If you notice, they align exactly with the prediction for the cosmic ray flux.  Now, this IBM study ran from 1978 to 1994,  so it's entirely possible newer generations of RAM are differently affected,  but cosmic rays is definitely something you want to consider.  So, what's the distribution of various causes of bid errors that I see in the wild?  Honestly, I don't really know.  I can't go half way around the world and see what was wrong with somebody's iPhone,  and it's entirely possible to cause a didn't consider.  What is interesting to know is that these bid errors do happen, and they're real.  We have mentioned DRAM for a bit,  and I'm going to go into a little more in-depth discussion about DRAM.  DRAM is the source of really great information density for bid errors to happen.  It's hard to cool. The components are always cheap,  and it happens to be where the previous majority of bid error studies have focused.  So, I'll start off with some really good news.  And the good news is that all errors in DRAM can be fixed by use of what is called ECC or error-correcting codes,  and ECC can detect and fix all single-bit errors.  There's actually forms of ECC that will detect all one, two, three, and four-bit errors.  But ECC only works if you actually use it.  A lot of you in the audience probably manage extensive server farms,  and those typically have ECC memory,  since hardware manufacturers know that bid errors do happen, and especially high-end ones.  But have you thought about all the RAM in your server?  I'm going to go with no.  This is a hard drive pulled from one of these enterprise-class servers with ECC memory  that chip there, highlighted in yellow, is 128-megabit DRAM.  It does not have ECC.  And this drive is actually a few years old.  It only has 16 megabytes of cache, newer drives have 32 or even 64 megabytes of cache,  and enterprise servers typically have five to eight of these drives.  So the data in your enterprise-class server may be going through a lot of non-ECC memory.  Let's look at some DRAM failure rates.  Now that we've established there's probably a little bit of it in your server somewhere.  This slide summarizes two different studies,  one from a Terrazan semiconductor and one from Schroeder at the University of Toronto  in association with some engineers from Google.  And the first thing you notice is that the scale varies very widely.  This is also a logarithmic scale.  The lowest error rate is about 50, and the highest error rate is about 100,000 failures in test.  And the failure in test is about one error in one billion operating hours.  Another interesting thing to note here is if you see the manufacturer one to manufacturer six columns,  those are from the Schroeder study,  and those were bit error rates measured in actual servers in Google data centers.  One of their conclusions was also that the vast majority of bit errors could be attributed to specific DIMS,  counteracting the IBM study, and in fact suggesting that maybe manufacturing defects  are in fact the number one cause of DRAM failures.  But if you don't typically think in terms of one failure in one billion operating hours,  so let's put this in a more usable perspective.  If you go to Dell.com, the cheapest PC you can buy will have 4 gigabytes of RAM.  Assuming the worst case scenario from the previous slide,  that PC will encounter approximately 3 bit errors per hour.  Assuming the best case scenario, it'll encounter approximately 3 bit errors per month.  But also, it's not great to think of just a single PC.  What we want to see is the emergent effect of all the DRAM on the Internet.  And there are several studies that say that there are approximately 5 billion devices  that are connected to the Internet in 2010.  Assuming each of these devices has 128 megabytes of RAM,  and now this assumption isn't really based on scientific fact,  I felt it was a very fair compromise between the servers that have multiple, multiple gigabytes  and your phone which may have, you know, 6 to 20.  You will get approximately 600 petabytes of DRAM that is connected to the Internet.  And using the lower end error estimates from the previous slide,  that's approximately 600,000 bit errors that occur daily in all the world's Internet connected DRAM.  Now, how many of those errors actually happen somewhere that is interesting?  Well, I set up an experiment to find out.  And this experiment is in three parts.  Part one, register domain names.  This list includes actual domain names that I registered.  They are one bit away from certain very popular domain names.  By one bit away, I mean is you take the domain name,  then you put it in its ASCII representation, you expand it out as a binary string,  change ones to zeros and zeros to ones.  If it's still a valid domain name, when you put it back to ASCII, you register it.  And the domain names they pick tended to be those of popular websites  and more crucially advertising and content delivery networks.  And the reason they pick those is because nobody ever types those addresses in,  but you certainly look them up an extremely large amount of time.  Experiment step two is you have to properly answer DNS.  And this is actually very important, and I'm going to go through this via an example.  So let's say somebody out there is trying to resolve a domain name you registered.  Let's say it's mic20soft.com, one bit away from Microsoft.  So you're going to get an A record request, and of course you will answer it.  But the trick here is that we think that a bit error happened somewhere  on that server that asked you for the domain name.  Therefore, we will also send it back a second reply for the original domain we expected it to be.  And the reason we do this is because if it's expecting a reply for microsoft.com,  it will discard the reply for mic20soft.com, but silently accept the Microsoft one.  If it did indeed query mic20soft.com, it will accept that reply,  but discard the Microsoft reply.  In an overview, for every domain, for every DNS request you receive,  you have to send back two responses.  And this isn't just A records.  This is also other types of records such as NS requests.  Assuming your bit squatting was successful,  next thing that's going to happen is you will get an HTTP request.  So you set up an HTTP listener, and you log the connection.  And in this case, I chose to return HTTP 404 not found for every single request I received,  since I wanted to avoid causing any damage to any of the requesting computers.  Once again, that's you get a request, you log the request,  you send it back a 404, and you close the connection.  Then this is how I set up my experiment.  And the first thing that really surprised me is that people actually show up.  This is the traffic volume of raw HTTP requests for a six month period  from the end of September to the beginning of May.  As you can see, there is a steady background stream of requests,  punctuated by several extreme spikes,  the biggest which was approximately 3,500 HTTP requests per day.  But raw requests isn't necessarily a fair comparison,  since maybe some machines out there get in a loop  and you have one guy requesting the same resource over and over again.  So here instead is the traffic volume by unique IP address per day.  Some of the peaks disappear, but others still remain.  Aside from the steady stream of background noise,  there's three major events labeled here as A, B, and C.  Each of these caused by bit squatting,  and I will get into detail of these in the next three slides.  So what caused event A that affected more than 1,600 unique IPs on the Internet?  And that critical application happens to be Farmville.  Yes, I'm serious.  The reason this says 1,300 IPs is because it could only attribute 1,300 of those directly to Farmville,  but the other 300 are also of similar causes.  So how exactly does this happen?  Well, let's diagram this out.  Let's pretend you're a user somewhere and you want to go play some Farmville.  Then you request some stuff from Facebook,  and a bit error happens in either the Facebook or the Farmville servers,  and profile.aka.fbcdn.net changes to pbo file.aka.fbbdn.net.  I happen to own fbbdn.net,  and this bit error happens to happen in the URL of an ad server,  and this URL gets cached and then served up to the 1,300 people who keep requesting that resource.  Instead of requesting ads from Farmville, they're requesting ads from me.  I could have sent them anything I wanted, but I chose the 404.  Once again, an overview.  You're doing nothing wrong going to play some Farmville.  A bit error happens somewhere outside of your control in either Facebook or the Farmville servers.  This bit error gets cached, served up to 1,300 people,  and those 1,300 people request ads from me instead of from Farmville.  That's event A, and event B was 456 unique IPs,  and the cause of that was also Farmville.  The reasoning behind it was actually also pretty much the same,  except the bit error here was different.  You would play Farmville, bit error changes fbbcdn.net to fbbgdn.net.  Once again, this bit error gets cached somewhere in the Farmville cache,  gets served up to 130 different people who request ads from me.  And of course, you don't have to send them ads.  I chose the 404s, but there's no reason somebody malicious  couldn't send them some choice JavaScript.  That's it for event B.  Event C is actually the most interesting one of all,  and I promise it's actually not Farmville,  and it affected 246 unique IPs.  What's interesting about event C is that it's an actual case of DNS poisoning  caused by random bit errors.  After looking through the logs for the days of event C,  I noticed that all of the requests for those few days were one from the same slash 24,  and two, they were all for the same server.  And here is approximately what happened.  So you're someone in that slash 24.  You request your ISP to resolve s0.2mdn.net.  A bit error occurs somewhere in your ISP's recursive domain server.  Instead of requesting s0.2mdn.net,  you request to resolve s0.2-dn.net, which I happen to own.  If you recall from before, we always send two DNS replies.  One of the replies we're going to send back is for s0.2mdn.net.  This reply is going to, one, get cached in the DNS server,  and two, get propagated to the original requestor,  who will then request an ad from me instead of froma2mdn.  And I will send them a 404, but of course, you can be more creative.  As a full overview of the entire process,  you are browsing some website, you request an ad.  Your local ISP's DNS server cache happens to be empty.  It queries instead s0.2-dn.net.  I own that, I answer DNS authoritatively for it,  and I say, hey, here's the IP address for s0.2mdn.net.  That gets propagated, that gets cached,  propagated to the original requestor,  and now everybody in that slash 24, when they're requesting s0.2mdn.net,  will instead request, will instead get my IP instead of the original one,  until the DNS cache expires.  So that concludes the three outlier events.  And if you look at the traffic without outliers,  you see that it's generally just a random trickle of requests.  But even this, you can see by the blue line,  that there's an average of 59 requests.  This is 59 requests with only 32 domains.  This can easily be linearly scaled up by any sort of organized person.  Next thing I wanted to do after measuring the traffic volume,  was to see the volume per hour.  My intuition here was that there would be more bit errors  when it's hotter outside during the day.  Unfortunately, it also turns out that most people use their computers during the day,  so it's impossible for me to separate the causes due to heat  from simply more traffic use.  But it is very interesting that this graph  approximately mirrors North American internet traffic.  And this only includes the traffic from those IPs  that were geo-located within the United States.  There is a steady start of traffic about 8 Eastern.  It goes and levels off at about 2 p.m.  and stays steady up until midnight where it rapidly drops off,  only to resume again the next morning.  Next thing I was curious about is,  what operating system are all of these users using?  So I have their user agent header,  which conveniently tells me browser and operating system.  So I decided to compare the operating system  of people visiting my BitSquad domains  to the people visiting Wikipedia for March of 2011.  I'll start off with the commonalities.  So there's a giant common share of Windows boxes,  which is to be expected.  Windows is the most popular OS.  Then there's about 3% iPhones,  1% Linux users,  and 1% Android.  Now, the difference is what's really striking.  First, for some reason,  only 2% of the visitors to my BitSquad domains  are users using Apple OS X,  whereas 8% of the visitors to Wikipedia do.  I do not have a conclusive explanation for this.  My thoughts think from a potentially better build quality  to maybe the aluminum casing being a better cosmic ray shield.  Not really sure.  And the crucial thing here is that other field,  the other field for BitSquads is 5%,  whereas the other field for Wikipedia is 2%.  So I looked at the user agents of these others,  and this is all kinds of handheld mobile devices  and gaming platforms.  Things I saw were Wii's, PlayStation 3's,  PSP's, Sony Ericsson phones,  Samsung phones, and other devices.  And a lot of these phones also really like telling you  what carrier they're on for some reason.  Not sure of the logic behind that.  Next, I wanted to know,  so where are these people coming from?  At first, I graphed this for all of the visitors,  but I chose to limit it to Microsoft.com  since some of the sites at BitSquad  are disproportionately popular in the United States.  I figured Microsoft would be a good target  since the vast majority of DNS lookups  would in fact be from automated Windows machines.  The results here are actually extremely surprising.  They do not correspond to population.  They do not correspond to number of internet devices,  and they do not correspond to number of internet users.  I don't have a solid explanation for this.  My only guesses include, potentially,  that as we saw from before, not all BitSquads are equal.  Sometimes you win the BitSquad lottery  and get some server in Farmville.  Sometimes you just BitSquad somebody's iPhone.  It's entirely possible that it just happened  to a BitSquad more useful places in China and Brazil.  But this definitely warrants further research  to see exactly what the issue is.  Next, what I looked at was,  which domain are these people looking up?  And this includes outliers,  so of course Facebook is by far and away the crowd favorite,  and followed by BitSquads of Microsoft,  followed by various content delivery  and advertising domains.  If you see there highlighted in yellow is MSN.com.  If you were to look at the list of domains that I BitSquad'd,  MSN.com wasn't actually on that list.  So, how did MSN.com make it into the top 25 most popular domains,  despite the fact that I didn't BitSquad it?  Well, I'm going to explain it,  but first I want to explain the places where BitEros can happen.  There's two different places.  One of these is the DNS path,  and this happens during name resolution,  and one of these is the content path,  which occurs before DNS ever has a chance to work.  We'll start off with the DNS path,  and this is best illustrated by example.  So, you request FBCDN.net from your ISP.  A bit error occurs in your ISP's DNS server,  and instead it requests FBBDN.net.  I own FBBDN.net.  I send two DNS replies.  One of these is for the original domain,  and this domain reply gets propagated back to the original requester.  Then, this is crucial.  The original requester will make an HTTP request to me.  I don't know how many of you are familiar with the HTTP11 protocol,  but HTTP11 requires that you use the host header,  and the host header contains the domain that you are actually  you think you're connecting to.  So, in the case of bit errors during DNS,  I will see a host header of the original domain in my HTTP logs.  And of course, then you can send them whatever you want back.  Once again as an overview, you request FBCDN.net.  A bit error occurs somewhere in the DNS resolution path,  and what ends up being requested is FBBDN.net.  The bad reply gets propagated to the original requester,  who then makes an HTTP connection,  and crucially, in their host header, uses FBCDN.net,  the original domain.  Now, on to bit errors in the content path.  And the content path is the farmville type bit errors.  So, you're somebody browsing something like Facebook.  A bit error happens somewhere in the extensive Facebook memory  caching infrastructure, and let's say it's, you know,  for a JavaScript, you're about to pull from it,  and the domain changes from FBCDN.net to FBBDN.net.  Then, you will connect to my BitSquad server,  and in your host header, you will say FBBDN.net,  because the bit error occurred before you ever looked the domain name up.  You are bound to connect to FBBDN.net  because of the bit error happened in the actual content.  And now, this content didn't actually have to get corrupted  somewhere on the server end.  It could have entirely gotten corrupted in, let's say,  the memory of your iPhone.  Afterwards, I send them back a reply,  and as an overview, you're browsing Facebook.  A bit error happens somewhere in the content,  either on the cache, or maybe somewhere in your memory,  or maybe when you're parsing HTML.  And crucially, when you make the HTTP request,  your host header has the BitSquad domain and not the original domain.  So, what's the actual breakdown of these that we see?  96% of the time, and this includes the outliers,  since they were actually Cosby bit errors,  96% of the time, the host header that I see is the BitSquad host header.  That means that all of the security research that you've been doing  for DNS would not fix it.  What we need is research on ensuring content integrity.  The other 4% of the time, the error happens along the DNS path.  And if you look, 1% of the domains aren't the BitSquad domain,  they're not the original domain, they're, in fact, the other domain,  such as the MSN.com that we saw earlier.  And the reason this occurs is because of CNAME chains.  This is an actual example that I observed.  In a CNAME chain, when you want to resolve a domain,  the domain is actually says, hey, I'm a canonical name for this other domain,  and that domain is a canonical name for yet another one.  And you follow this chain until you finally resolve a domain to an IP.  If a bit error occurs anywhere following the CNAME chain,  you will get redirected to a BitSquad domain instead of the original domain.  And that's how I was able to get requests for Microsoft  and this guy for ax.init.itunes.apple.com.  Despite the fact that I did not BitSquad those domains.  So, speaking of other domains, it's time for a series of real-life examples.  I apologize if this is really small, but I couldn't think of a way to better convey it,  so sorry for those of you in the back.  The very top request is, of course, for ax.init.itunes.apple.com.  And I believe that person is actually trying to activate their iPhone.  I can only assume they were unsuccessful.  There's a few of these for AdMob and there's a few for MSN.  And I want to note that this is not an exhaustive list of the ones I saw.  Quite a bit more of these, these are just the ones I chose to include.  Next up is people browsing Facebook.  These are people requesting JavaScripts from me while they're logged into and browsing their Facebook sessions.  It doesn't take a lot of thinking to figure out that you can extremely easily steal their Facebook session cookies,  send them some phishing pages, or do other really malicious activity.  Next up is people requesting Windows updates.  Some of these are for the initial Windows Update self-updater,  but if you see that bottom one is somebody is actually requesting an exe from my server instead of the Windows Update server.  I really hope they verify those signatures.  Next up, people browsing their web mail and requesting ads from me while they're logged into their web mail session.  This is also not an exhaustive list, but I hope you'll recognize the dangers of this.  If you have JavaScript running when you're logged into your web mail session,  I can potentially steal your web mail credentials.  That's not a good thing.  Also, the two examples here from live.com, I don't want to pick on them.  I got lots of requests from various web mail sessions.  These are just the ones that I have to find first and put in.  Next example, Dr. Watson crash reports.  So one of the biggest criticisms I got during this entire thing was that,  hey, these things can't possibly be legitimate because you're going to,  whenever a machine encounters bit errors, it's just going to crash and it'll die before you ever see anything useful.  Well, I'm sure that certainly happens a very large percentage of the time,  but some of the time the machine crashes and you can get something useful out of it.  Interestingly enough, I don't know if you're familiar with Windows Air Reporting,  but the server on the other end can actually potentially request a full memory dump from your machine.  So if this happened to you, I could have potentially requested you to send me the contents of your RAM.  My favorite is actually that second one.  It's a Watson report from notepad.exe.  We all know how unreliable that process is.  So now that we've seen that these things happen, that they're very serious,  let's talk about some mitigations.  We'll start with mitigation number one, and that is ECC on everything.  If you're in this room and you're in the charge of a bill of materials for the next mobile device,  the next laptop, desktop, the next server, please make sure you use ECC memory everywhere.  That includes things such as your drive and your Nick and your Nick and maybe your keyboard controller.  Next mitigation, pre-register domains.  This is actually the easiest you can do since bit squatting affects a very small percentage of all domain lookups.  If you own a really, really popular domain, you also have the most money to register potential bit squats of that domain.  There's actually a quick upper bound you can place on this.  If you're only looking at single bit errors, the most possible bit squats that can exist is six times the amount of letters in your domain.  That's only for single bit errors, though.  The great thing about pre-registering is, one, you can do it right now.  Two, it'll help all your users, even your users running in some really hot climate  in really terrible power supplies with a really bad computer.  And mitigation number three, trust but verify your data.  As we noticed earlier, 96% of these bit errors occur during the content path.  If you or somebody here responsible for building a really large memory caching infrastructure,  you should check that what you put in your cache is actually what comes out of the cache when somebody requests it.  Please include something like a CRC32 with every cache element.  Modern CPUs actually have a CRC32 instruction, so performing this should actually be extremely quick.  And you're probably going to be bound by network delay anyway.  Another place where you should consider doing this is if you're developing mobile devices  or something else that's going to work in high stress environments,  please be sure to verify things like the integrity of your outgoing DNS queries.  Some room for future research.  Previously, it's only been possible to bit squat second level domain names,  but ICANN has approved generic TLDs.  It'd be entirely possible for somebody to out of know, register.con for conferences,  and perhaps you would get a nice slice of the traffic for.com.  I was actually talking to somebody in Black Hat, and apparently there's a 300 page guide of rules  you have to follow to get one of these things, and they try to preclude similarities,  but still you want to be sure.  Another possible issue is punicode domains.  I have not looked into what happens at bit errors in punicode domains.  For those unfamiliar, punicode is how you would use internationalized characters and domain lookups,  but it's quite possible that a bit error in a punicode domain in one language  would actually be a domain in a completely different language,  making the attempted use of trademark laws to get it back extremely difficult.  I would like to give a special thanks to a few people,  notably Robert Edmonds of ISC, who first noticed DNS bit errors in SAE data.  Another person is Paula Royal, who helped me immensely when creating the white paper for this.  Erin Lamasters for acting as the adversarial researcher.  The entire Raytheon Roslin office for their support in helping me with many multiple reviews.  My other patient and supportive reviewers, whom I begged to review my slides in my white paper.  The DEF CON 19 staff for helping me actually present this to you guys.  And to everybody who licenses your photography in a creative comments format,  without you this presentation would not have been possible.  And of course, to all of you guys who came to see my talk, I greatly appreciate it.  And finally, I'd like to say if you want a quick tool to identify which bit squats of your domain are available,  you can get a Python script at dinoburg.org.  Thank you.
DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_0_119.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_120_203.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_204_287.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_288_1571.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_1572_2111.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_2112_2639.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_2640_3107.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_3108_3167.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_3168_3251.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_3252_4067.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_4068_5711.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_5712_6359.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_6360_6815.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_6816_7235.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_7236_7511.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_7512_8003.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_8004_8747.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_8748_10667.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_10668_12131.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_12132_12371.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_12372_12827.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_12828_13235.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_13236_14795.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_14796_15959.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_15960_16187.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_16188_16763.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_16764_17183.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_17184_19079.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_19080_20591.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_20592_21251.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_21252_22619.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_22620_23147.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_23148_23747.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_23748_24803.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_24804_25883.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_25884_27587.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_27588_28295.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_28296_29243.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_29244_29615.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_29616_29843.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_29844_30923.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_30924_31055.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_31056_31427.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_31428_32807.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_32808_33695.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_33696_34535.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_34536_35447.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_35448_35975.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_35976_36839.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_36840_38063.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_38064_38267.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_38268_39311.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_39312_39947.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_39948_40223.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_40224_42323.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_42324_43139.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_43140_44375.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_44376_46991.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_46992_48551.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_48552_49523.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_49524_49907.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_49908_50039.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_50040_50183.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_50184_50399.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_50400_52031.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_52032_52727.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_52728_53411.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_53412_54035.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_54036_55067.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_55068_56315.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_56316_59423.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_59424_61223.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_61224_61895.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_61896_63215.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_63216_64703.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_64704_67439.png DEF_CON_19_-_Artem_Dinaburg_-_Bit-squatting__DNS_Hijacking_Without_Exploitation_9WcHsT97suU_1_67440_67842.png