 My name is Artem Dynaberg. 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 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 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 some resource constraint. Like 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, two per day, that's three. So while bit squatters are going after the three domains that you type in, typo 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. Whenever 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 used vacuum tubes for memory storage and computation. And these vacuum tubes failed and they failed a lot. Whenever one of these tubes would fail, 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 brand board from the Mits Altair 8800. The Mits 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 SRAM 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 Mits Altair Basic, an alpha particle would get emitted. It would shift some ones to zeros 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 that 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 as 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 wear 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 the 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 TV 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 to 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 is 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 a user 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 and 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 your 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 it's a cause I didn't consider. What is interesting to know is that these bid errors do happen, and they're real. We have mentioned DRM for a bit, and I'm going to go into a little more in-depth discussion about DRM. DRM 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 DRM 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 DRM. It does not have ECC. And this drive is actually a few years old. It only has 16 megabytes of cash. Newer drives have 32 or even 64 megabytes of cash. 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 DRM failure rates. Now that we've established there's probably a little bit of error 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 a 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 DRM 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 three bit errors per hour. Assuming the best case scenario, it'll encounter approximately three 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 DRM on the internet. And there are several studies that say that there are approximately five 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 six to twenty. You will get approximately 600 petabytes of DRM that is connected to the internet. And using the lower end error estimates from the previous slide, that's approximately 600 thousand bit errors that occur daily in all the world's internet connected DRM. 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 picked 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 misc20soft.com, one bit away from Microsoft. So, you're going to get an A record request. And of course, you'll 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 misc20soft.com but silently accept the Microsoft one. If it did indeed query misc20soft.com, it'll 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 requests in 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's 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 was which was approximately 3,500 HTTP requests per day. But raw requests isn't necessarily a fair comparison since, you know, maybe some machines out there get in a loop when you have one guy requesting the same resource over and over again. So here instead is the traffic volume by unique AP 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 few slides. So what caused event A that affected more than 1,600 unique APs on the internet? And that critical application happens to be Farmville. Yes, I'm serious. The reason this says 1,300 APs 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.ak.fbcdn.net changes to pbofile.ak.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, in 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. And 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 FBCDN.net to FBGDN.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 it on 404s, but there's no reason somebody malicious couldn't send them some choice JavaScript. And that's it for event B. And 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. And 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 dash 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 from 2mdn? 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 dash 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 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 is 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 those, the traffic from those IPs that are geolocated within the United States. There is a steady start of traffic about 8 Eastern. It goes and levels off at about 2 PM 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 is 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 differences is what's really striking. First, for some reason, only 2% of the visitors to my BitSquad domains use Apple OSX, 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 that other field, the other field for BitSquads is 5%, whereas the other field for Wikipedia is 2%. So I looked at the user agent 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 in 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 a number of internet devices, and they do not correspond to a 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 warns 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 BitSquadded, 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 wanna explain the places where bit errors 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 your 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 farm bill 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 don't 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, there's one for AdMob and there's a few for MSN. And I wanna note that this is not an exhaustive list of the ones they saw, I saw quite a bit more of these, either just the ones they 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. 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 wanna pick on them, I got lots of requests from various web mail sessions. These are just the ones that happened 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, the next 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 four single bit errors, though. And 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 and 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 occurred 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 gonna 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, I don't 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 wanna be sure. Another possible issue is punicode domains. I have not looked into what happens at bit errors in punicode domains. For those unfamiliar punicodes, how you would use internationalized characters in 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 and helping me with many multiple reviews. My other patient and supported 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 Commons 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.