 So this is cloud computing, weapon of mass destruction. If this isn't the right talk for you, the door is that way. I'm David Bryan, technology enthusiast, hacker extraordinaire, security consultant. I also help run the network at DEF CON and do all sorts of fun things with OWASP and DEF CON groups and whatnot. How many people here are part of a DEF CON group? Yes, no. You should start one in your city. It's fun. Get together and meet and talk about things like this on a regular basis. I am Mike Anderson, and if the lack of information in my bio hasn't glued you off, I'm new. This is my first DEF CON, and I've been at a company called Netspy for just a year now. This is my company Netspy. We do a whole bunch of different stuff, but we kind of got to keep this presentation pretty short, so I'm going to breeze through it. We do all sorts of vulnerability assessment, pentesting, code reviews. Next slide. All right. Does everybody know what the cloud is? Custom server images, central storage, all sorts of fun things. No physical systems to worry about. Have anybody had problems with power in their data center? Has anybody had problems with cooling in their data center? I think we all have. This is kind of a nice environment because you don't have to worry about that. In fact, you don't have to pay minions to manage it. You just deploy machines. It has custom APIs, which you can then go in and manage your storage, manage your machines, deploy new machines, ramp up machines as your load increases, that kind of thing. Storage. It also has a queuing system where you can send a shitload of messages into it and it'll parse them out and send them to you in a nice, pretty timing format and all that fun stuff. There's more seats up in front here, by the way. There's like five seats up in the front here, and there's like ten seats over here. So keep coming up. I'm going to start a brawl, man. All right, so what can I do in the cloud? Obviously scale large. Scale and deploy large environments. Can it get rain? Maybe? Hmm? It's a cloud, right? That's what we're here to talk about. You can move your servers very quickly from the UK to Singapore or east and west across Americas. You can have large amounts of bandwidth just at your hand or at your whim. It's kind of nice. All right, so what's required? All you need to start an account with Amazon EC2, which is the environment we did our tests on, is an email address, a credit card, and you need to look at an API. There's no contact information. There's no contract. They don't try and figure out who you actually are. It's just sign up and you're good to go. I mean, there is a terms of service that you have to hit accept on. Click, right? There's no signing. There's no nothing. There's a ULA. ULA, basically. Everybody knows that ULA is a rock solid, right? All right, so our question is, is it a useful tool or a weapon of mass destruction? So in the cloud computing, weapon of mass destruction, basically this is what we're going to talk about. Sort of an outline, threat agents, attack types, defenses, and we'll also do a demo if we can try and get the presentation in before the end of the hour here. So some of the threat agents. So a threat agent can be anyone from a business rival organized crime or foreign powers, a pirate maybe as the picture would indicate. And what they're basically in this for is maybe bragging rights or money and power even. It's become a serious topic. It's no longer just a game. And here's an example of a threat agent attacking foreign money or power, Google China. They got owned for political reasons, actually. So some of the key terms that we're going to talk about in this talk is DDoS, distributed denial of service attack. How many people have heard of that? All right, good. Good. Fragmentation attacks? Yes. A few less. And our tool doesn't specifically focus on fragmentation attacks. It's mainly on SIN floods and TCP denial of service type attacks. And SIN flood, does everybody know what TCP is? TCP IP? Everybody should raise their hands. All right. Does everybody know what command and control is? So in a typical botnet, you've got a command and control network with a herder. The herder is a threat agent, a person who is actually saying to these bots or zombies, do this. It takes a long time to gather these machines. I mean, you're talking months and months of painstaking, rooting or exploiting windows based machines, trying to get them across. And you're also having to think about, you know, is antivirus enabled? Will it catch my stuff? Will I have maybe some sort of 56k least line? Or is it a modem connection that I've now basically taken over a computer that has no bandwidth? Well, that's no good to me as a herder. And what's more, once you've established a botnet, you still have to pay maintenance costs. You have to keep ahead of the antivirus researchers. You have to update it. You have to keep track of all kinds of systems or windows. So it's just sort of a diagram of what a typical command and control would look like where you've got a herder in one corner, and then you've got the machines that are actually attacking the victim. So our concept, we call thunderclap. I don't know why we came up with this. I think, you know, thinking of the cloud and all that fun stuff. But anyway, basically it's a proof of concept. We're on a DDoS attack from the cloud. We've written some modules that aren't quite fully flushed out to use social media as a herder for them. But basically the cloud environment allows you to do rapid deployment of these systems. You can say, alright, let's deploy 10 systems and boom, they're up and running. You know, there is some restrictions within the Amazon environment for how many machines you can deploy at a time. However, there's no restrictions for you to be able to go out and use more credit cards to deploy these systems. You know, email addresses, those are really hard to come by. Alright, so in our environment the herder, the command and control network is actually in the cloud with the botnet. So there's plentiful bandwidth there and they can be guided anonymously through social media or tour and it can be really hard to track because if you have these instances in EC2, for example, when you shut them down, none of your devices are actually logs. So nobody can come in and check what you were doing. It's totally gone when you're done. Alright, so the same diagram, except now think of it as all being in the cloud rather than having devices that are dispersed throughout the internet essentially. It makes it a little easier to track, maybe a little easier to shut down, but we'll talk about that later. Alright, so attack types, TCP full connection, packet fragmentation, again we didn't implement this in the proof of concept, and then TCP sin flood. You know these are really basic attack types. The full connection would use a lot more resources on our end so we try not to use that as much because we're going to have to actually open up the socket, reserve some memory for the receiving connection to come back so we can get a SINAC act, that kind of thing. TCP flood, sin flood is a little bit more dangerous and a lot more bandwidth intensive because all we're doing is we're not waiting for an act, we're just going along. So using this sort of attack we can target a website, server service doesn't really matter what it is, and it doesn't matter how many of them there are. We can target something that's been dispersed, we can target a centralized resource, and we can make money off of it. We can basically say we're going to denial of service you for an hour today, unless you pay us $5,000, and if you don't pay us, it'll be two hours tomorrow. I mean, and if that doesn't work we can try and sell this service to competing companies, like we can come to Target and say, hey, do you want us to shut down Walmart for six hours right after the release of the new PlayStation, because we'll do that, and you only have to pay us $5,000. And you can make tons of money this way probably. I mean, we haven't tested it. Baby, today we will. Anyway, so ensure your website is down for good. You know, again, blackmailing, doing all sorts of low life things. So the outcome is threat agents can hold your environment hostage quite easily, cheaply, and who's watching again? Now when I say cheaply, guess how much it cost for us to run a two-hour test against a site that was six gigabytes of traffic? $6. It was $6 for us to kill a website for two hours. That's pretty cheap. I mean, I think it cost us $30 for the machine time to get everything prepped and, you know, make sure it was up and running. Once that's up and established, it probably would have cost us all about $12 to run that whole attack. And we could potentially continue to run that day over day over day. And who's watching again? No one contacted us. Is there anybody from Amazon here? They're not going to raise their hands. Damn. We found that, you know, we generated a lot of anomalous traffic and anomalous type of situations in the cloud and no one called us and said, hey, what are you guys doing? We didn't even get an e-mail, which is how you're supposed to communicate with them, which is a little frustrating. All right, so thunder clap. So this is the tool that we built to run this test. And more or less, all you had to do to make an environment is get the credit card, sign up, and you have to make a machine image, which can take a little while. You just have to make sure that your tool doesn't deploy zombies. There's a little drop down. You can say I want to deploy 10, 20 contract or click yes, I agree again. But it wasn't a huge obstacle for us. We had to create the tools. And in the development process, I kind of went through a couple of iterations using Scapey, HPeng, and LibdNet. I settled on the last two because Scapey didn't offer me the same amount of control over setting up and destroying sockets. And you have to develop attacks. Scapey, full or send no data attack. It's just kind of fiddling with it to get the most bang for your buck that takes some time. We developed a random source IP with LibdNet as well. However, attacking from the cloud, everything's netted. And so as soon as we tried to go outbound, it would drop it because it wasn't a netted trap. It wasn't a source netted traffic that it would allow out. But you could potentially attack that point. I don't know, this 12 address is coming from our networks. How does that work? So, we're going to try and do a demo. Hopefully the demo gods will be with us. Basically, the site that we're going to try and attack today is media.defcon.org. Which I'm told has a 100 meg pipe. So we should be able to just say images. By the way, does anybody see this? No, they don't. Let me give you a window here. Oh, boy. I have to shrink this some more, I think. Stand by. Unless, of course, someone's already done it for us. Oh, wait. No, I'm just kidding. So we should be able to hit this. Basically, we've preconfigured our environment with the script. The tool is on the CD. But all I should have to do is say, launch this image. I can launch min servers, max servers. I'm going to say, let's go for 8. So we'll launch 8 servers. Hit launch. I should be able to go to instances. Has anybody seen the Katy Perry video? California Girls, right? So Minnesota Girls. Go check it out. It's our soundtrack. It's our soundtrack. We'll play it later. So these guys are starting now. Come up. Come on. Refresh. It takes a little bit. So essentially what's happening now is these machines are booting up. They go out, they pull the script off of our S3 environment, which the S3 or the cloud front environment to storage environment, pulls the script down, starts it up, and then starts a Python attack thread. And goes and grabs the targets, goes and grabs the DDoS config off of that environment, and boom, it just gets spewing packets. I don't know what's going on with my network connection here. Let's see. I think they might have. Our internet connection is goofy. Is that 100 megabit pipe shared with us? So now we got two running. So these machines are starting up sending 10,000 packets per second. Every five seconds they will send that traffic and go and check the targets file and go, all right, do I have more targets to process? Did we get the I don't know if we've done this yet, but we're going to put these images and the tool up on SourceForge and allow you guys to basically run the scheme yourself. Yeah, there's a zip file on the CD with all this stuff. All right, so now we got the instances running. Let's see if we can get to this. Hmm, it's not responding. Hmm, I think we killed it. I'm told this has a 100 megabyte or 100 megabit site link and it's not responding. Can anybody else confirm? Just go to media.defconn.org Oh, it came up. So again, you know, this is demo gods may or may not be with us, but Oh. Ah, AT&T's network. All right, we're going to launch a couple more here. We should see how many will let us bring out. That would be fun. All right, so I'm going to SSH in and just do a quick TCP dump, make sure it's going bare with us. Yeah, it's going. So if we go here, I'll show you. I don't know if anybody can see that, but so there's all the AT traffic. It's just going. Does anyone have some response times? So what we can do is we can launch more machines. I think we're about to see how many they'll let us put up at once. I don't know, it might cost us $50 today. We'll see. That's what we were told. We never had to test it. Yeah, we only had to bring up three machines actually to bring down the one site that we were doing. So now we're at 20 machines pending, hopefully, shortly. Yeah, I don't think it does. I think Jeff has it all turned off. That was specifically for our presentation. Yeah. Oh, where's my mouse? There it is. It's taken a lot longer to load, though. We're on port 80, so it's not even doing SSH. Yeah, we're just doing port 80. That should be the same instance of the server service, right? I would assume. That would probably run into the same problem where TCP full connection runs into where we'd have to encrypt and decrypt the traffic as well. All right. Let's do another 10. We'll see how many more we can go here. I hope this is the right IP. Oh. There we go. So I can only do 20 instances at a time. All right. Anybody got another credit card? I think there's a thousand of them in this room. So, all right. We'll let those go, but we can kind of continue on with our talk here. Ah, thank you, PowerPoint. Okay. So then our step three here is profit. And it's a series of tubes. So you can only fit so much through them at one time is the idea. This is the inner workings of Thunderclap. We just put in a sort of diagram here because I didn't feel like putting all the code up and explaining it. But it starts, reads a config and reads targets. Goes on to the attack phase. And here it picks the entire list of targets and spawns a thread to deal each target its specific attack type, which you can specify in the file. And it'll run that for a certain amount of time, which you can specify the amount of time, too. So you can have each round for the attack take a minute or 30 seconds or one second. So if we really wanted to, we could probably tone these VMs up and shorten their attack time and increase the amount of bandwidth they're supposed to send in that time. Then it checks to see if it's supposed to be running as a daemon. And if it is, it'll just loop. It'll keep doing that over and over until you tell it to stop. Otherwise it kills all its threads and exits gracefully. I'm trying to get it so it'll actually shut down the instance when you tell it to stop, but I have a whole bunch of other stuff on my plate, too. And then we get to the defense in which the most boring slide in this entire presentation. Does everybody have a C-cert at their company? A computer incident security response team? Yes. Everybody should. You should have an incident response, procedures, plans, policies. NIST 861 is a great document to review. I think the biggest thing that happens is if you get a DDoS attack run against you, if you don't have those policies and procedures in place to be able to respond to that and the coordination with the other groups within your company, if you're a very large enterprise, this attack may go on for hours and hours before someone is actually able to respond to it or identifies it. So that's my sort of, hey, get together, do NIST 861, or at least review it and create your own response procedures, and then make sure that all the teams coordinate. That's the biggest thing. So there are a lot of great things about cloud computing. It's fast, it's super fast. You can do what you want when you need it. And it's really cheap, super cheap. You can do what you want no matter what your budget is. And all it requires is a credit card. There's literally no barrier of entry. There are some problems with it. Unrelated to this, the government can subpoena information on the cloud. There's no monitoring a response and it allows for a quick and nimble server deployment, which is a double-edged sort, kind of when somebody starts using cloud computing for this purpose. It's a low cost, not only to run your server or your service, but also to run attacks like a denial of service. And you can use stolen credit cards or other sorts of stolen money to create your environment. And stolen email addresses? Right? Because nobody has those. All right, so I guess really that kind of what it boils down to is this environment's unmonitored and it's new territory. You know, as we come into the new territory, it's like a playing field or a walk in the park. Anybody can come along and do these attacks, run this stuff, and no one is necessarily going to be the wiser, at least from what I've seen. However, I did have a friend of mine who said, oh, you know, I was scanning for Port 25 through Amazon and I actually got a notice saying, please stop doing this. That's unauthorized. But they don't care about all the other ports that are out there. They don't care about anyone from someone saying, hey, you have spammers in your Amazon environment, stop it. Oh, okay. Right. Well, actually, you know what, so stolen credit cards aren't all the only way you can get a credit card. You can actually walk into a bank, give them cash, and they give you a credit card. Yeah, yeah. So the comment is basically, as cloud providers start to realize they're basically not going to get payment once those accounts come due, they'll start to actually patrol it and put the kibosh on that kind of activity. Absolutely. However, I mean, I could also go create legitimate contracts and have all that fun stuff in place and start to do these attacks, and they still probably wouldn't necessarily see that you're doing these attacks. Again, it's unmonitored from my perspective. I didn't get an email or get a message saying, hey, we saw a lot of anomalous TCP80 sins without any data behind it. What are you guys doing in the cloud? Or we saw you sending information from IPs that we don't own, like spoofing the source IPs. I mean, any IDS sensor in my opinion should go, okay, these are my IPs. If I start to see source IPs in the cloud that aren't mine, that's bad. That means somebody's doing something weird. So, all right. In conclusion, unmonitored, as far as a lack of IDS or IPs, it does allow for quick and nimble deployments, which is great. Being able to scale up and scale down your environment. Again, we only had to initially deploy three machines to actually DDoS the environment, but we could have ramped that up to 20 machines going really fast. And actually that HPING with the dash F, the flood works great. Just for doing a quick and dirty one. Of course, it wouldn't allow you to just turn the machines on and they start attacking, but anyway. You can reduce your server costs, reduce your operational costs. I mean, if you think about it, you don't have to have people in your data center managing your servers. However, your data can be subpoenaed without your consent, which I think is a really big thing. So, if you do use cloud environments, make sure you have a key, or make sure you encrypt the data and that your key is stored offsite at your primary business location, so that if that data is subpoenaed, they actually have to come and subpoena your company in order to get the key. Yeah, another comment, you could also keep the key at home. However, I don't know about accessing that key and monitoring of that key in a home environment. Your kid might find the key and decide to sell it off to some Russian hacker. I don't know. All right, so what about logging? As soon as these machines are powered off, there's no logs, there's no trace, there's no evidence that these machines were running, at least not from our perspective, because they're all running out of memory. That's the beauty of the cloud environment is you actually are applying an image to a base image and this allows them to reduce their storage space requirements. But with that, it's just like running a machine in a RAM disk. I don't know if anybody's aware, but as soon as you power that machine off, all the contents of that machine are gone. Unless you say, write this stuff back to a storage device somewhere. So we'll be having a Q&A session in room 112 after this, but before that, we should probably figure out how media.defcon.org is doing. Do we have time? What's our time? Well, no one's telling me so. So you can see our attack is still running in the background. Let's see here. 13 second pings. Oh, page load? Okay. Oh, I see, yeah, yeah. HTTP? We could probably do that. Well, except the Python script doesn't know how to do SSL. Yeah, we could teach it. It's not that hard. It's just that it's not configured to do SSL at this time. Future, yes, in the future. All right. So here's our DDoS config basically. I don't think so. So packets to send should be 10,000 per second. Number of threads one. Let's change the wait time. Let's go down to three seconds for these guys. And now we have to go upload this file. Where is my terminal? There it is. That can't be sending that. How's it doing? I don't think it's doing it. 100 megabits is good. Yeah. Well, we should be sending a bullet of traffic to it. But again, the demo gods may not be with us today. Yeah, yeah. All right, everybody in the room, check. So, all right, well, thank you.