 So I'm Sam Bown, this is Matthew Prince, and we're going to talk about DOS attacks and defenses. I'm the attack side, which in my opinion is the most fun, but the least practical. He's the guy that can actually save you from all this garbage. I just make trouble. And I'm hoping to have a few minutes at the end to show you something new about cookie reuse, hacking into American Express and Chase. So I do not appear to be able to proceed to the next slide, so I'm going to make this smaller and see if that works. All right. So I'm Sam Bown. I teach at City College of San Francisco. There's Matthew Prince from Cloudflare. You can't see, the slides are gone? Aha. No, but that doesn't matter. Does it come up now? That's what I thought. They had a problem with this before. Guys, I've got no video again. I'll try pulling the plug out and putting it in again. But that's what I thought. Yeah, by the way, I'm going to need your help when you tell me when the video dies because I have to move to another machine later, and the system here appears to have some defects. You see anything yet? Right. Well, I can tell you a story while they get the video going. I'm in contact with a lot of criminals now, which is really great because I'm on Twitter, and they often tell me interesting information. In fact, I recently hired a felon, although he's not that criminal, but anyway. So I gave a talk two years ago at Matthew here about denial of service attacks, and I gave some similar talks, and a criminal someplace saw those, and he said, hey, I was checking out your stuff, and in the first place, why don't you teach backtrack? That stuff is garbage. What do you lame? And in the second place, where's sock stress? Sock stress is a great attack, and you don't cover it. And I said, I thought backtrack is fine, and I thought sock stress didn't even exist. You may not even remember this. Like five years ago, there was a podcast, and they said there was this new scary attack that would kill anything that used TCP, routers, and servers, and everything. We thought it was the end of the world, and then nothing. I had it for the source code. I couldn't find anything that worked. I thought that was just vaporware. Well, what happened is it was real, but the man that wrote it died before he could go to the cons and make a dog and pony show like I proposed to do, and show everybody how it works. And a black cat, some of them knew, and this guy knew. And you can totally take down servers with sock stress, and you can take them down permanently with sock stress is a claim I've seen many people make. And I think I understand what that means. You could not take down a professional company. Do I have the slides now? Thank you. All right. So let me talk about how this works. If you have... Here's how TCP works. TCP... What? Okay. All right. So TCP. You have... TCP lets the receiver control the flow of information. So first you have the handshake to make sure that the person is really there. They send a SIN up to the server, the server sends you a SIN act, then you send an act. Then the server starts sending you data. It sends you some packets of data, and it waits for you to acknowledge them. So if your client is slow, it can control the rate of flow. So that's one form of flow control. It's good, right? It's not... It died again? Oh. Well, anyway, I'm going to have to keep going. Hopefully, if someone noticed in doing something about it, perhaps. Anyway, so there's another form of flow control in TCP, which is not commonly used, but it exists. You can send a packet with a window size of zero. And what that means is I can only accept zero more bytes. You have to stop sending me whatever you're sending me and wait for me to get it working. And that is available so your client can say, I have a buffer and my buffer is full. Stop sending me whatever you're sending me until I can clear that out. But you can use it as an attack, and that's what Sockstress does. All you do is the TCP handshake. You send a send to the server. The server sends you a SINAC. You send an AC, but the AC has a window size of zero. And that means the server will start a process and prepare some memory to send you something and then wait. And in practice, it will wait for a really long time. So all you have to do is make a lot of those connections and use up all the RAM on the server. If you keep it up for about 20 minutes in practice from real attackers against real servers, it will damage the server so much that it freezes and you cannot shut it down normally. You have to just pull the plug. And I think this is why the black hats tell me that this will kill servers and they're gone forever. Now, you couldn't kill Yahoo with a nuclear bomb. You blow up a whole data center. They have backups. They have other servers. So a professional place cannot be taken down by any kind of attack like this. But with an amateur site, we're on a shared hosting, you could kill it. So we're trying again for the video here, which would be nice because I have definitely asked some demos to show you to slide you're more expendable than the demos. Anyway, let me get down here and see. All right. That's the joy of Soxure. Yeah, I can start to show this way, but that's a bunch of, it's still no projector, right? Well, life is tough. So I don't think it's me. Oh, it's up. You got it. You did? Okay. They fixed something. Good. Great. Thank you. All right. Just leave it like that. That'll do. All right. So you can see it now. Life is really good. All right. So anyway, I still cannot move from one slide to the next, though. Let's see. Can you see it now? Okay. Good. Then we will keep going. All right. So the only thing I'm glad I brought up the slide to remind me of this, you have to use an old version of Slackware to make this thing really go. And it took me a lot of tries, and I kept saying, this is garbage, and the black hat kept taunting me saying, no, it's not garbage. You're just stupid. And he was right. So with enough work, I eventually got it working. So let me show you this thing in all its glory. I've got some virtual machines here, and not that, but this here, okay. And so here's my attacker, and here's my target. So yeah, yeah, I don't have a dog. So all right. Now let me tell you something about this attack. There are two parts to this attack, and that is one of the reasons why I had just trouble doing it, because some of the software written by the people that designed this attack didn't work for me. I had to write it myself and escape you. This is art poisoning of a very simple kind. Your target, to get the effect that's really cool where you kill a target dead, the target has to be listening on many ports, and you have to attack it from a whole bot net worth of IP addresses. But you can simulate it for testing vulnerability on a land this way. You run an art poisoning script here, which will just tell anybody that asks that any IP address is me. So I can pretend to be 127 IP addresses, and it will just believe they're on this machine. That's important. This is the bot net, and the attackers over here, and this is just going to send a lot of those handshakes I described. It's a normal handshake, except it ends with a window size of zero, but it sends it from 126 possible IP addresses and two about a dozen ports, so it can really make a lot of connections. So let me get my target here, and this looks good. This is a Windows 2012 server, the latest version, 64-bit, and it's got one gig, and as you can see, it's using about a third of a gig right now, and almost no CPU, because it's just sitting there. So when I start this attack, let me get to my right window, okay, let's have these as visible as possible, okay, the attack is here, okay, now you see this number of connections per second being made going up to 2,000, and I've seen it get up to maybe 3,000 or 4,000, which you will never see unless you use a slack ware, and there is the effect. It just starts chewing up all the available memory, and you can run it against the server with 4 gigs I've tried, and I don't think there is any limit. You can run it against as many gigs as you want, and it will just use up all the RAM. And when the attack stops, that RAM does not come back any time soon. It just stays consumed, and if you wait until the RAM is all gone and just let it keep going for another 10 or 20 minutes, the server becomes completely unresponsive, and the only thing you can do is pull out the plug, and this works over the internet. It's a layer 4 attack. So that's why it's really scary. That's the first one I wanted to show you, and you can see under these conditions, it's not taken very long to use up all the RAM I've got available. So I'm going to go back to my slides, and we'll give this one to you before where I'd fill it up. I'd stop the attack, and as you can see, the memory doesn't become available again. So it seems to me that this is a design flaw in the operating systems, that they could have some kind of garbage collection process going on. But anyway, almost every device that uses TCP is vulnerable because nobody ever did popularize this attack, and we all, as far as everybody I knew, thought it wasn't real. So that's one thing you should know about. It is in current use by criminals to take down servers right now, and I'm not aware of anybody paying much attention to how to stop it. It seems to me like there are reasonable mitigations available. You could just block packets with small window sizes at your firewall. That might be fine. You could patch your operating systems in various ways, but it's time for people to pay some attention to it, and I made a version of it that runs on Kali, or I found it pretty easily do that now. It runs at one-third the speed, so it's not as dramatic, but it is enough to test defense tools. So I'd like to see people pay attention to it. Anyway, the other thing I wanted to show you is the latest IPv6 attack, which is good, clean, fun. As we all know, we ran out of IP addresses a while ago. It's a non-renewable resource in about a year. North America will run out, and then more people should notice. Projected error in exhaustion data is here, April of 2014. Now, IPv6 address, it won't last a long time. I made an IPv6 countdown counter, and as you can see, we got enough of them for a little while. So that's why we're trying to move forward on this. That's live on my website, by the way. You can watch it count down. So I talked about this two years ago. This has been around for a while. This is the old-fashioned attack, all the way from 2011. So in IP version four, if you want an IP address, you boot up a laptop. It asks the router for an IP. It gets an IP, and that's the end of the game. But in IPv6, you send router advertisements from the router, and they are sent multicast to all nodes, which is what a normal person would call broadcast, if they were just a little bit sloppy. And every thing that receives that packet has to create an IP address and join the network, which amounts to the same thing under normal conditions. But if you send a lot of router advertisements, the clients are all burdened by making up a lot of addresses and joining a lot of networks, which burdens them far more than any sensible person would think. I would think making up a number is only a few clock cycles, but Windows can only do five of these per second without using up 100% CPU. And that is also true of one of the BSD versions. So the router advertisement packet is just an IPv6 packet going to ff02, colon, colon, one, and it's got a prefix in there telling it what network to join. So if you run this flood for a while, then your Windows machine will join all these networks and make a lot of IP addresses, and it'll use up a lot of CPU. And that was the old attack in 2011. Now, that drives Windows to 100% CPU and had no effect on Linux or Mac, which just ignored all the advertising after the first 10 addresses or so. And Microsoft, all right, that was the old flood. And so then Microsoft came out with Windows 8 in survey 2012, and the Chaos Communication Congress in Germany came out with a new version of this attack tool. But the person that wrote the tool told Microsoft that Windows Server 2008 and Server 2012 were much more resistant to the flood. And this is something I only found out because I have a student who's kind of nuts who set up a real IPv6 lab and a lot of real equipment and would not stop until you had everything really going the way it really is to use it. And we found things that only happen under those conditions. So now, this is the new version of the tool. Each router advertisement packet can advertise more than one router. I don't know why, but they allow it. So now it allows, it now advertises 17 routes and 18 prefixes in every packet. So every one of those packet is like 35 of the previous ones. And if you send a lot of those in, it's really quite dramatic. But if you just turn on that flood alone and send it at Windows 8 and Windows Server 2012, it doesn't do much. There is some kind of defense built into them, but it doesn't work if you're actually using IPv6. So let me just demonstrate this thing. It's good, clean, fun. You can do this one from Backtrack. Let me get rid of these unnecessary machines. And this one. All right, here's good old Backtrack. And I've got a target here. I'm gonna show you the attacker and then I'm gonna move the cable over to the target and Lord only knows what's gonna happen to the video. I will need your help to tell me if the video dies. All right, so I'm, I've got a cable here. I'm gonna pull this on. This is very important, by the way. This attack will kill the Mac. It will kill the host underneath my VMs. Now that kind of interferes with my testing. So the solution is to use USB-NIC. When you plug in the USB-NIC, you get this happy message popping up. Or so I would like to see. Asking me where it goes. You get out to my Mac and plug it in again. And if it continues to annoy me, there we are. It's asking me where to send it. I can send the USB directly to Kali Linux, which is a really good idea because the traffic that passes through the Mac operating system will not be Ethernet. It'll be USB and therefore it won't kill the Mac. If it was using VMware networking and passing the networking through the host, it would kill the host. All right, so now that I've got networking in my virtual machine, let's see what I have. IP address show. IF config is deprecated. I'm attempting to learn to quit using it. Okay, IP address show, eth1. This is my connection to this Windows Server 2012 machine. So, to make this attack work, you have to send some packets first. I'm gonna put a zero here. I've got def CO30 here. So now I'm advertising a network starting with DEF CO30. And let me show you what happens to the target. Okay, so hopefully, let's see, this might work. Yeah, hopefully you are now seeing a Windows Server 2012 desktop. Is it happening? It's of course not happening. I don't think it's necessary, but I'll give it a try. It's not a five on this one. Windows, it's Windows P. Now there, there it's there, Control P, Windows P, duplicate, all right. How about now? Oh, good, all right. That's good, I appreciate your help. Now, so I go to my glorious PowerShell window, which is the replacement for Command Prompt and do IP config, which is not deprecated, thank God. If I can only spell, okay. All right, and now I have joined a network called DEF CO30. So this machine is receiving IPv6 router advertisements and obeying them. And now, let me turn this thing around so it faces you because the next part is fun. It is, that's looking pretty good, thank you. All right, and it is not subtle. So even if you're seeing that thing from the back row, the point should be clear. So now I have joined a network and I'm sending some router advertisements and now I just send a flood, which is as many packets as it can possibly send of those new router advertisements that advertise 35 routes and prefixes each. And what happens is, in about 30 seconds, this thing should die a gruesome death. Okay, seven, eight. I can't see it. I'm gonna move this thing around. All right, there's not, by the way, let me just check it. Okay, in about 15 seconds, now the mouse moves, but I cannot change what window's in the front anymore. I click and nothing happens. Pretty soon the mouse won't even move and then it dies a horrible blue screen of death. So anyway, that's what I wanted to show you. Those are two scary attacks. This one means, oh good, thank you. Oh, I'm glad it worked. So that's kind of rude and so my point is, Microsoft has to go back to the drawing board. They put out an update, but the update only works for Windows 7 and Windows Server 2008 R2. They did not put the IPv6 readiness update on Server 2012 or Windows 8 because they thought it was not vulnerable, but it is under the right conditions. Which I really owe that to a student. I was just going out of my mind. It would work sometimes. I'd try to record a YouTube video. It didn't work. Then it would work. I said, what's going on here? And he said, it only worked with the real routers on the network. And that's true. Anyway, so that's what happens. I've tested it against a lot of things like Android phones and the Windows Service RT. And it kills pretty much everything, this IPv6 attack, including the Mac. Ubuntu sales right through, like nothing's happening at all. So it is possible to fix it. Apple and Microsoft and Google and everybody could fix their junk and be like Ubuntu Linux. It's possible to survive this attack. You just ignore all the router advertisements after the first 10 or so. All right, and I got a bunch of videos showing you how to do it. And if you want to mitigate it, of course you could turn off IPv6, but that's not very practical anymore. And you could filter this with your switch or your router or your firewall, only let router advertisements come through from trusted sources. I should mention that the existing mitigations in the industry like RA Guard and Cisco switches are effective, but very weak. It is trivial to get past them. All you have to do is put some extension headers on the router advertisement packets and the switch will not recognize them anymore and let them go right through. So that's true of almost the first generation of every security device. It's very flimsy. Anyway, so I think that's enough of this and I'm going to pass it on to Matthew to tell you about defense and hopefully have a few minutes to talk about cookies at the end. Thank you, Sam. Let's see if I can get a video. Give me one second. How's that? No? Yeah, okay, let's try it one more time. Apologize for this. Any better? Nope. I'm going to try changing the screen resolution. Just have to select, scare it into behaving. Okay, so I gave this talk at Black Hat which was lessons from surviving a 300 gigabit denial of service attack. And I don't know about all of you, but Black Hat's kind of a dull conference. So I wanted to sort of retool it and Sam has been telling me that it's a lot more fun to attack than defend. So in that spirit, I thought I would teach you how to break the internet. So you don't have to be as smart as Sam is to do this, it turns out. And we actually went through a practice run of this a little while ago. So back from March 18th to March 25th, I had a series of really bad days. There was a series of very high volume denial of service attacks targeting one of our customers. This was fairly well publicized in the media. And it was a little organization called Spam House, which we have a sort of love-hate relationship with. But they do a lot of good things and actually once upon a time I used to be their lawyer. So when on Monday, March 18th, this was what their website looked like because they pissed off the wrong person, they called us and signed up for Cloudflare and Cloudflare is good at stopping some of these attacks. And so from March 18th to March 21st, we saw a lot of what we call annoyance attacks and annoyance attacks for us or anything that sets off an alarm within our system, which takes about 10 gigs. We got about 156 of those last week. We're pretty good at stopping attacks at this size. But to give you some scale, big DDoS attacks that knocked the US banks offline last fall were around 60 gigs. So these are not trivial attacks, but they're, that's pretty big. This is what it looks like. This is a couple of ports on our network. The blue line represents egress traffic out of our network. It should always, because we're a caching proxy, it should always be higher than the green line. The green line is ingress traffic, this traffic coming into our network. And this is what a 75 gigabit DDoS attack looks like. There's no real software that we have to, we write lots of cool software and do lots of things, but these are simply volume-based attacks. And so they are simply filling the pipe. You're dead at layer three under one of these attacks and we do a lot of things to stop it, but it's not cleverness that stops it. It's actually the size of the pipe that you have. And unfortunately that means it's really hard to patch. And so then it got real. So from March 24th to March 25th, this is traffic coming into our network that got up to about the peak, about 309 gigabits per second. That probably is not all of the traffic that was hitting our network because some of it was actually congesting upstream and causing problems. And so those are UTC time. On March 23rd, I was on a date, a little restaurant on Folsom Street in San Francisco. And I should have actually brought the woman that I was on a date with to tell you how much dinner that night sucked. But it sucked in a lot of different ways. It sucked because our team was calling us. It sucked because our upstream providers were calling us saying, you have a problem, it's starting to become our problem. And it sucked because I just spent the entire time writing emails and talking on the phone. And as I'll explain later, talking to lawyers, which makes any dinner suck. One of my, I'm a recovering lawyer so I can say that. One of my favorite emails from that period of time came from a network engineer at Google who I'm friends with. And he wrote the following. He said, I've often said we don't have to prepare for the largest possible attack. We just have to prepare for the largest attack or the internet can send without causing massive collateral damage to the others. It looks like you've reached that point, so congratulations. This, by the way, if I ever call you and I'm freaking out, is not a comforting message. So, you know, again, since I think that we've decided that we're gonna be the bad guys, not the good guys, and it's fun to destroy things, not create them, I wanted to tell you exactly what you need to launch this attack because all of you can do it probably from here. What you don't need are botnets because they're sort of a pain in the ass to build. You don't need a lot of people, you know, coordinated anonymous attacks are relatively trivial compared with some of the things we see. You also don't need a ton of technical skill in order to launch this. Instead, what you need is a list of open DNS resolvers and this has become something that is actually fairly easy to find these days. And then you need some servers running on networks that allow IP address spoofing and as you'll see, you don't actually need very many of these servers. So let me describe what these two things are just so, again, I know a lot of you in the audience have a sense of how this works but I wanna just make sure that everyone is on the same page. So what is an open DNS resolver? This is not like open DNS, the company, they're a great company, they have great limits and things in place. This is not like Google DNS. This is misconfigured DNS resolvers which are running on the network and Google DNS has great limits so you can't abuse it in this way but Google should be slightly ashamed of the fact that how do you create an open DNS resolver? If you have an Android phone in your pocket and you turn it on to Wi-Fi as a Wi-Fi sharing point, it by default becomes an open DNS resolver. So if you have a publicly routable IP address, you have just contributed one more ingredient to helping create these kinds of attacks. There are a number of home Wi-Fi devices that have these things and then people who say, wow, it'd be really fun to install Bind but don't set it up correctly can create all kinds of problems. So these are these misconfigured DNS servers that are running on the internet. I think of them as slutty DNS servers. They respond to anyone and anything that you send to them. And the effect of this, what you really need if you're going to take down the internet is you need amplification because you only have certain resources and you need to make those resources significantly better. So here's how it works with open DNS resolver. So that IP address 63.217.84.76 as of noon today was an open DNS resolver running on PCCW's network. There are a lot of these, they're not hard to find. This is just a DNS query for those of you who are Windows people in the audience. One, I'm sorry. And two, this is sort of the equivalent of NS Lookup. And so what this returns is, it returns all of the resources. And so dissecting this query, any says return any of the DNS records that's there. E DNS equals zero means give me all of the things like DNS sec and everything else. Not TCP says send it all over UDP and then set your buffer size to 4096 is the largest buffer that you can set for a UDP packet, meaning give me as much as you can. It's a 64 byte query. This is what it results in when you query it. So that's a 3,363 byte response or in other words, it's a 50x amplification factor. You send a little bit up, you get 50 times as much back at you. So the second thing that you need, I mean that's if you just wanna, if you're like Sam and you just wanna knock your own computers offline all day, then you've got everything you need at this point. If on the other hand, you wanna attack other people's networks, then what you need is a network that allows source IP address spoofing and as probably good networks, good in quotation marks, because we're on the dark side now, but good networks don't let packets that originate from IP addresses, they don't own egress out of their network. They don't let them leave it. This is something called BCP38. BCP stands for best common practice. It has been the best common practice since the early 2000s. Good for us, again, there are a lot of networks, however, that don't follow the best common practice and we'll specifically enumerate some in a second. Many networks, in other words, are naughty. And UDP has no handshake, so unlike TCP, which is really hard to spoof the source addresses of, with UDP, you simply say, the source is this and everyone goes, yeah, that's cool. And so long as the routers on the network are announcing that, then you can pretend to be anyone you want. So in other words, that's an IP address that's on Cloudflare's network spam house, again, as of noon today, sat behind, although it moves around. If you run that dig, and again, you set it to no TCP, which means UDP only, then what it's going to be is it's going to result in that response getting sent back to the source. In fact, you've reflected the attack back at your intended victim and your attack is 50 times the size of whatever volume you're able to generate. So if you can generate a gig of traffic, then that means you can generate 50 gigs of attack. This is sort of similar to the old Smurf attacks. If people remember that, that's ICMP packets that are bounced off that. The good news with the Smurf attacks is that because router vendors were relatively consolidated, they could patch them and it's really hard. You don't see many ICMP Smurf attacks anymore, but because any idiot can install bind and misconfigure it, this is a significant problem. So how common are these particular ingredients? Like is this something that's going to take a lot of exotic skill and a bunch of time and generally people are lazy so we want to make this easy? The good news is for us is that as of the time of the attack, there were about 21 million of these open resolvers running across the internet. In fact, not coincidentally on March 25th, the open resolver project was launched. It was essentially the nuclear option for the good guys which said, we've always been terrified of publishing the list of open resolvers because then the bad guys will have them over the last weekend it became completely clear the bad guys do have them so damn the torpedoes. And you would think that four straight days of New York Times coverage might get people cleaning this up and so this would be a less effective attack. What I'm happy to report is that today there are actually 28 million open resolvers. So have at it. You can also with not much, there's a little bit of protection on the open resolver project like you can only support a slash 24 at a time and all kinds of things, but if you don't want to actually query the internet because that's hard, you can actually just write a crawler to crawl the open resolver project and pull down the list of open resolvers. So there you go. The other piece and this is a little bit harder to find is that you want to see if we need to find a network that allows IP address spoofing and Comcast and big eyeball networks like you're gonna have to look around a little bit but the good news again is that almost 25% of networks AS numbers surveyed on the internet of 10% that have been surveyed so far. This is according to an MIT project do allow network spoofing. So again, talk to your neighbors, chances are one of you is running on a network that allows this to happen. So if we go back to a case study of the spam house attack and we look what was actually involved. So first of all, again, if you're fearing that you don't have the technical skills involved to launch this, this is one of the individuals that was involved with it. Not exactly a brain trust. My evidence that he wasn't a brain trust is he talked on record to the New York Times about launching a giant denial of service attack. Again, and again, this is really interesting things because at one point they stopped targeting us and they started targeting actually links the London internet exchange which counts as critical infrastructure which means targeting it is like a terrorist offense. So those eyebrows, I love them. So the spam house ingredients, how hard was it? Again, what did this brain trust do? Spam house, they generate 309 gigabits for about 28 minutes. They use 30,956 open resolver IP addresses and they only use three networks that allowed spoofing. So again, not so tough, right? So in any other words, there's one attacker with one laptop. It actually turns out it wasn't this Sven guy but I'm not allowed to tell you who it actually was which is sad because it's a great story. There were five to seven compromised servers on three networks that allowed spoofing. They sent about nine gigabits of DNS requests so they have to be kind of beefy servers to 0.1% of the open resolvers and they resulted in a 300 gigabit per second attack that was painful. You can see though how there's opportunity here. So create 0.2% and you're at 600 gigs, get up to 1% and you can send three terabits, 8% and you're at 12 terabits, which may not sound like a lot except for that the entire US internet backbone is 24 terabits. So someone may notice that and you don't need to necessarily, like we're a pain in the ass to target as they realize because we use any cast and we do a bunch of things that make it really tough. So they first, the attacks were launched against our IP addresses but because most people don't correctly configure their networks, like you can actually target internal routing infrastructure intra network so you can actually address the IPs inside someone's network, not just the edge. Like here's the London internet exchange, that's a routable IP. So you could just send the traffic directly to the choke points on the internet and it turns out that again, the biggest baddest router that Juniper Cisco buys only has 100 gig ports. So how many of those can you take offline with a 12 terabit attack? So an alternative talk, which we could give would be how to stop internet Armageddon. And again, I gave some version of this at Black Hat, implement BCP38 if you're running a network, clean up the open resolvers, work with your upstream, sign up for Cloudflare, these are all good suggestions. But frankly, blah, blah, blah, blah, blah. And so let's give something a little more def conny. So I wanna return to dinner on March 23rd, which again, sucked. And on March 23rd, I got a bunch of calls, got a call from a bunch of different people. At one point I got a call from one of the people on our systems engineering team and they said, I have a solution. And I said, oh. And they said, we could just make all the open resolvers attack each other. And so I called our lawyer. Which is, and we have a really cool lawyer. Like Sam Cote said, Cooley is pretty good. And I can't exactly tell you what his advice was. It wasn't, yeah, absolutely go for it. But it wasn't exactly no under no circumstance, you should do it. And thankfully the attack didn't get much bigger and we could stop a 300 gig attack. But if it had gotten to a terabit or something which would have started to cause a problem, it would have been interesting. And so we created this little C program called selfdestruct.c. Which, again, the lawyers who told me I can't give out the code, but here it is. It's 50 lines of C, it's nothing, right? And so, again, I don't necessarily want to actively challenge you to solve this problem yourself. But if you decide that you want to, in about 50 lines of C, you may save the internet. But, and this is kind of the beauty of it, you will break it in the meantime. So, you know, use some discretion. Anyway, thanks for having me, Sam. It's always fun to give your talks and I'm gonna let you talk a little bit more about cookie reuse. Well, good. I'm glad we're managing on the time, despite the technical difficulties, because I have another thing to show you. And I'm glad that Matthew just put something on the screen that he really shouldn't show you. Because I'm really showing you stuff I really shouldn't show you. Is it working? Let's try it. Okay, good, all right, good, all right. So, oh good, that's fine. This only takes about three minutes. I did this at B-Sides and my talk is not online yet because they're worried they need to blur it out before they can publish it. This is my Chase Manhattan credit card statement. I'm logged in for my online banking and let me just show you what happens here. So I'm logged in. This is Sam Bowen and there's stuff about my account. And I'm gonna take the cookie off of this site this is Chrome and I got an extension here that just lets you in, it's easy to get the cookies. It's called something like, get it, this cookie. There's a bunch of them. So now the cookie's in the clipboard. So now I'm gonna log off. Now there's a nice red log off button there and they would like me to click that button as if it was actually doing something. But it's not doing anything. It's just there to waste my time. I mean the only thing it does is if Matthew comes up and uses my computer he can't get in my account. But I can totally get back. So now if I try to go back to my Chase Manhattan personalized page it won't let me in. It says you have to log in which was what I wanted to accomplish by clicking that log off button. But I did not accomplish it because if I just put the cookie back in which is there and then try to go to that link I'm back in my account authenticated without my password. Now this is right on and by the way since everything's working here's American Express and the same thing is true. If I export the cookie from American Express and then I hit that log out button again just tempting me to click it as if that was gonna protect my security in some way. And then I bring the cookie back and then I go back to my personalized American Express page. Hey, whoa, that's interesting. Okay, it's just one timed out on me. And this is good because it's only fair these two credit card companies do have a 10 minute timeout on the cookies and on other log. You can't do anything for 10 minutes or trying to keep it alive down there. Then you're timed out. So that's defense in depth. They have multiple controls. One of them compensates for control that failed. But anyway, I just wanted to point this out. This is a bad idea. The point that log out button should cancel the cookie on the server. When I clicked that button my intention was that nobody should get in here again from this device without a password. So I started testing other ones. This came from a hacker news article. Everything is on my website, Sam's class.info and here's the cookie reuse stuff. So I made some videos of I gave these guys a week in secret to fix it. They promptly told me they would get back to me in 24 hours and then never did and never did anything. So I put it on YouTube and I figured and they still did nothing. So I said, well, maybe if I show it at Defcon they'll do something or maybe they'll just continue to ignore me. But anyway, I tried a lot of sites and there's a lot of bad ones and a lot of good ones. Anyway, so I told, I checked Cloudflare and they were vulnerable. So I told them and they patched it. And what I asked them to do, yeah, they do that pretty often. They're the only person that has ever moved yet from the bad side to the good side. But anyway, I'm hoping they'll write a blog explaining to these other persons of questionable efficiency how to do it. Cause it's perhaps that they don't know how to do it. I'm afraid it's more that they don't care. But anyway, there's a lot of them. And one that really surprised me, I did Gmail and Gmail was not vulnerable. So I didn't try other Google services but some other people didn't told me about it and the Chrome app store is vulnerable. And so iCloud is completely vulnerable. And by the way, Microsoft Office 365, you can log out and then change your password and wait till tomorrow and the old cookie still works. So that is really rude because you know it's easy to steal cookies. My students do it for homework, cross-size scripting and steal the cookie. And it's better to have the cookie than the password cause they can change their password. Ha, ha, ha. You just keep using the cookie. This is wrong. Anyway, so if you'd like to help, please send in more reports, test websites. Just tweet them into me at Sam Bowne. I'll put you on the list. You can gain internal fame like some other people have tested. Oh, I have a bunch of notes down here who tested it. So we might as well make a list of shame. And I should mention, of course, this is not original. It's not new. This is the same thing FireSheep did and a million other things before that. I mean, cookie reuse is just one of those endless annoying problems like plain text login that we just have to keep pounding on people until they finally knock it off. Yeah, so I got five minutes left. I think we've, I've said everything I had to say. I guess we're done. And they said, if you wanna ask questions, just meet us outside in the hall and we'll go find some place. Okay, farewell. Thank you.