 Okay. We got a ton of stuff to get through, so I'm going to kind of kick off. Just a quick disclaimer up front. We kind of cut this talk down from 140 slides and a 75-minute talk at Black Hat to 50 minutes and a lot less slides. So everything is going to be up on our site. If you catch our blog, we'll link to our research portal and we'll have the full content up as well as this. Just a quick overview of where we're going to go. We're going to give a quick introduction to the talk, kind of background on where some of our things are going. We'll talk about some drawbacks when you're dealing with cloud computing. And then we're going to look at some specific people. So the ones we looked at were salesforce.com, Amazon's AWS and Apple's Mobile Me, and then a quick wrap up. Just very quickly again about us. So SensePost as a company we're a dedicated security services company out of South Africa. Been around for about nine years. We've spoken at Black Hat and Defcon for the last eight to those years. We do a ton of research, a lot of training, put out some papers, kind of put out some books, not going to hop on us. So really quickly, the moment you talk about cloud computing, the question has to come up why we're even bothering. At the moment cloud is a real headline stealer. You just have to say cloud and a whole bunch of people are listening. But we've been doing talks for quite a bit. We've spoken at Black Hat, Defcon for quite a while. And we're not famous for doing talks just because they headline Stealy. In fact, some of our talks have some of the most boring demos known to men. We've got probably the slowest port scanner, probably the slowest tunneling tool ever released on the interwebs. And the reason I'm saying that is we wouldn't choose a talk just because of its fashion appeal. Okay, we think there's something important going on here and we think it's important that people start noticing it. So there are a few people talking cloud. But the moment cloud is spoken, you get people splintering into different groups. There's a group of people who immediately go, that's nothing new, cloud, cloud, cloud. It's the same old thing. Schneier's gone on record a few times saying it's the same old computing paradigms that we've done. What's interesting to note is that he said that multiple times in multiple interviews. Okay, so clearly something new is happening here. Something's coming up. There's also something that we'll touch on later on during our talk. And that's lots of attacks that we previously thought were uncool and unsexy. Suddenly start to take on a different tinge with the new paradigm. And the bottom line there is that at this point with attacking the stuff, with testing the stuff, we really don't want to waste time splitting hairs. Okay, this is not the time for us to be deciding whether Web 2.0 is or isn't new, whether JavaScript is or isn't an attack, a cool attack vector. What we're interested in is what we can do with it and to make sure we're prepared for these attacks. So why would we want to attack the cloud? Why would we want to try and find things to break? Well, as much hype as it is, a lot of people are actually moving there. A lot of businesses are going and outsourcing functions and putting things up in the cloud so that they can then abstract that infrastructure and not have that responsibility. It's also fairly insidious, right? So even as a technical person, you could be fighting that and saying, look, we don't want to give away those things, but the decision is made above you at a business level because that's what's happening, right? And that's where those calls are made. So everybody in one way or another is kind of moving into the cloud, which makes it a really, really attractive target for us. And interestingly enough, if you consider the nature of the thing, it's out there, right? It's a web app that you're accessing things through. Clearly, we haven't got web apps right since the dark ages. I mean, we're very prone to making those same mistakes again and again. But the truth is we don't have to make those same mistakes if we tackle the stuff up front. So if we look at some of the drawbacks of cloud computing, there are a couple of issues that we face as testers or as people that are putting their data out in the cloud. And the first major one is transparency. Anybody who remembers a couple of weeks ago, the Amazon debacle, they got really attacked pretty hard about their transparency on that. Felton came out and said that they need to really step up to the plate and make sure that there's more insight into what they're doing, otherwise they're going to lose the user's trust. Privacy is a big deal as well. So on a small scale, you could be saying, look, I'm concerned about giving my email to Google. But on a bigger scale, what happens when you're outsourcing core business functions or your core data, like sales-related data, whatever it is? That thing goes further when you look at the legalities that are involved. So in essence, what's happening is you're losing your fourth amendment right to a warrant being searched before you get your data. So what actually happens is with the law at this stage in time, your cloud provider can be told to give up your data. And you don't even have to necessarily be notified about that. Never mind, have a warrant to give consent, which obviously is a big deal for a lot of people. One of the other big things is compliance. We don't necessarily know how to handle compliance in the cloud at the moment. So some people are doing some work around it, the cloud security guys. But compliance in the cloud is still a big deal, because ultimately, even though your data is somewhere else, you're responsible for that data. Vendor locking is another one. So consider now that you're giving your data to somebody specific, what happens if all of a sudden they go out of business, or if they're acquired by a competitor of yours, how do you then get guarantees that you'll get that data back and you'll get it back in the form that you had? Or if you make a massive investment into a specific platform, how portable does that become? The big one as well is availability. So availability is one of the major promises from the cloud. It's always up. There's massive kind of scalable infrastructure. You can always get access to your data. So from a browser, from a mobile device, whatever it is. But a lot of people are failing in that space, even though that's one of the major selling points. So you look at somebody like cloud files, for example. I want to access my files. I want to write stuff up. But at the moment, it's in read-only mode, because they're having issues with their data center. All right, that's less than ideal. You could also look at someone like SugarSync, who promises to have all your data in your contacts and whatever it is synced at the same time. I want to try and access that data because that's why I'm paying for the service, but they're down for maintenance. That stuff doesn't scale very well. I mean, it's not the smaller guys. The big guys are vulnerable to that as well. Google App Engine had a really big issue recently. So if you're thinking about availability, one of the things you'd need to keep in mind is that it's not just about uptime. So when we were looking at this talk, we were pretty much browsing around looking for cloud providers to attack. And one of the first guys to come up is for disk storage was Usa. Go to their page and it turns out they don't exist anymore. Okay, how they handled people getting their data back is questionable. If you go to Tech Crunch, Tech Crunch lists a whole bunch of online storage guys you should be using or could be using. And what you almost see highlighted down there, almost see highlighted down there is them recommending Omnidrive. You go to Omnidrive and this pops up. Omnidrive is no longer available. We now recommend Nomadisk. Okay, so it's a big problem. It's something that needs to be considered. But as an attacker or as an auditor, something else that pops up is that it's not just stuff that's out of your control like this. What happens suddenly is somebody locking you out of your account starts to become a very real attack. If someone locks you out of your account when you're using a cloud provider, you've now got to provide your identity somehow and you're basically just sitting in a queue hoping that they'll bring your account back. The other big issue that comes up is that by default if you're giving things away and you're outsourcing functions, you're automatically extending your attack surface. So it's one thing to protect your systems when they're in-house, but once that stuff is out there, other people can get at it. Even more so, a lot of things that are now out of your control can affect your security posture. So consider the case with a traditional phishing attack. Right, your users get phished, maybe they lose some email, maybe you give up some creds, whatever it is. If your provider gets phished now and they look in after your entire infrastructure, all of a sudden your data and your infrastructure is out there on a risk that you can't even control. If anybody thinks that's not a big deal, we can talk about how effective user education is after the talk. I'm sure everybody's dealt with users and seen the phishing attacks. It's happened to some of the bigger guys, so everybody knows about the Twitter stuff. It's happened to some of the other big players as well. While we're on the phishing attack, all of a sudden now, again, like I said, you're not dealing with a loss of somebody's credentials or giving up some email, suddenly you can get phished and your entire data center gets given up because you've got one username and password for Amazon to buy books, and that same username and password grants you access to your entire data center. So it's a slightly bigger deal for what we'd potentially consider a lame attack. Trust is a big deal too, right? So the question we say is, why would we give our data to these guys? If we want to outsource this function, it's because we trust those guys, because they're specialists at what they do and we're trusting them to control their data. But there have been a couple of fails there as well, and a quick Google for cloud fails will give you tons of hits coming back on how those things have gone wrong. So interestingly enough, on IRC recently, I was speaking to someone who was talking about how much cost years, cloud break stuff. So for those of you who haven't seen it, it's a really, really elegant exploit that allows you to escape from VMware, and he was talking about how scary this attack is. And what keeps coming up is the point that while the attack is scary, and cost years clearly got more brains than some small countries, that actually that type of attack, we've got no reason to not fear that attack natively from Amazon, right? If you're running in Amazon's data center, you don't know that Amazon don't have a Trojan hypervisor already. All the hypervisor has to do is give them access to stuff that they want men to, and actually you've got no way of knowing it. So sometimes we tend to focus on the wrong threats. So if you take the popular phrase trust but verify, you'll find that one of the problems you have with the cloud is your inability to verify. So to some extent, reverse engineers keep Microsoft honest. If you remember back in like 1992 or 93, people found NSAID at DLL in Windows, and everyone went nuts because we thought there was something wrong going on, that stuff's almost impossible to do in the cloud. Even if you verified somehow that Amazon didn't have an evil hypervisor on your system today, you don't know that that's the same hypervisor that you're on tomorrow, okay? And it's just one of those things that you give up the moment you enter the cloud. So like I said, the problem is, even if they're not evil today, how do you know that they're not evil in the future? One of the things that you need to ponder, so I'm not sure how many of you remember, but a little while back or a long while back, the story of Swiss AG came up. Swiss AG was the Swiss company selling crypto to about 140 countries, and it turned out later on that Swiss AG was just a front for the NSA. So all these countries that were buying crypto were actually buying specifically weakened crypto so that the NSA could have access to it. I'm not saying any of this about any of the current cloud providers. I'm just saying that if they are doing it, you don't know, and you probably wouldn't find out. So another interesting angle is not attacking the cloud itself, but using the cloud for things that are interesting and taking advantage of the extra resources that we get. And a couple of researchers were kind of quick off the mark on this. So if anybody remembers back to the Debbie and Weak Keys debacle, Dino D'Iservi picked up on that really quickly and used Amazon EC2 instances to brute force keys. There was another case where Ben Nagy at his syscan talk, spoke about how he'd used parallelized resources for when he was building his metafuzz harness for attacking office. And some of the guys like Dave Molnar and Dynamics are also using it for things like malware analysis and fuzzing. So you get this ton of resources and it's kind of more cheaply available and you can really, really scale your attacks and speed things up. So with a background and some of the drawbacks out of the way, let's dig into some of the specific providers that we looked at. And the first one is Salesforce.com. We figured we'd look at Salesforce because they're the leader in the industry and pretty much everyone who's anyone is using them. So we figured they'd be an attractive target. Salesforce also gives you two things. So on the one hand, you've got platform as a service where they give you a development platform in the cloud and you can start to build your own apps or extend functionality, but they also give you the full software as a service stack. So you get things like you can outsource your entire sales management or CRM and they really got a mature offering. So we took a look at them and we kind of started out probing them for traditional web app vulnerabilities. Again, we had limited time and we were kind of working at that stage without a mandate. So we were really, really careful about what we were doing so we only did cursory testing. But again, they hold up really, really well against that stuff and fully props to them for the work they've done. Ultimately though, what you're dealing with is a web application, accessing the stuff over the web. And everyone knows over the years that nobody makes web app mistakes anymore. So you've got a fundamental problem now where we suck at web apps as an industry. Now we tying the cloud to the web and things can go horribly wrong. If you look at the statistics on web app vulnerabilities pretty much from any source you come across, that stuff looks terrible. Nobody can argue that that stuff is good. And we've had a couple of high profile examples. So from Sammy in the early days on MySpace, through to multiple cross-site scripting worms of the same deal earlier this year against Twitter. Right? And if you think about Twitter... I need to interrupt you. Yep. I'm sorry, folks. You've got news. The good news is I will keep it short. In the last 24 hours, we've had a serious outbreak of the stupid from you people. I'm sorry, I'm very upset right now. The slide on the screen is very apropos. In the last 24 hours, we've had a serious outbreak of the case of the stupid by a lot of people here. Police yourselves. If you see someone about to do something stupid, don't laugh at them. Stop them. The staff is flashing back to DEFCON 9, which was our worst DEFCON ever. You guys are better than this. Is there anybody here who doesn't like the hotel? Who doesn't like coming to DEFCON here? Would you raise your hand? Good. We like it here, too. Keep doing what you're doing. We won't be here. Do not bungee jump off the roof. Do not go to the roof. Carrying a concealed weapon in a casino is a big deal. Even if you have a permit for it elsewhere. Basically, don't be an asshole. If you see someone being an asshole, stop them. We're supposed to be in the top 10% in terms of IQ in the United States, if not worldwide. You're acting like a bunch of 13-year-olds. Knock it off. I'm sorry. That's going to be a really hard act to follow. I'm going to leave you with the idea that if we're talking about web app security, look at somebody like Twitter. They've been owned so many times. All they're doing is they're putting out 140-character strings. If they're not getting that stuff right, what hope do we have for the more complex stuff? We decided to just demo a quick attack. It's a fairly overhyped attack, so I'm not going to go into... Everybody knows about the click-jacking bug. I didn't discover it. I don't want to take credit for it. But if we fire up a video clip very quickly, what you'll see on the screen is you've got... Kind of in the app, you've got tasks that can get assigned to a user in Salesforce.com. And to close that task, they kind of get listed like that. And if you just go through the motions, you hit the X button and you can kind of go in. You can check out the task. You can hit Save to carry on. So I'm going to skip ahead a little... Skip ahead in that guy. What we can do is if we fire up a malicious page on our site and we get a user to brass to it, essentially we can load that page as a frame in the background. And you can see it's kind of semi-transparent. So we did it like that for the demo. You could make that thing completely transparent or you could put up a punch the dancing pigs or the lolcats or whatever it is and force the user to click where you want them to click. But what you've got is within the page, you've got JS that will follow the user's mouse clicks. So what we can do is we can force them to click wherever we want them to. So in this case, we get the user to save their task. We do a refresh in the app and the task is gone. Simple click-jacking just shows that even some of the guys who are doing everything right can still be vulnerable to some of the smaller web app vulnerabilities. So for the Mike Myers fans out there, allow myself to introduce myself. My name is Mark from Sense Post. So we didn't get the intro right at the beginning. This is Haroon. This is Nick. So just if you need to figure out in your head who to give the credit to, it's probably to those two, Haroon and Nicholas. Okay, so I'm going to carry on talking about Salesforce for a little bit. I focused on Salesforce as Nick pointed out because they actually managed to split the software as a service and platform as a service quite nicely. So what they do as their core business is provide web-based CRM software for their clients and they've got a lot of clients and they're a big company. But they also expose that infrastructure and that platform to developers for third-party applications. So essentially they've got a system kind of like the App Store for Apple whereby developers can code their own apps and sell them to customers. So they've got massive infrastructure spread out across the world. But what's awesome for us, we're South African, we're kind of cheap. So they do provide us with free accounts to test with. They provide you with free dev account. And so we played with that to see what we could get. Our goal here wasn't to, well, while looking for exploits is fun, when you don't have mandate, it becomes a really, really gray area as we'll chat about later. So in this case, we're looking to find ways to abuse rather than exploit. Their platform. So if one wants to develop on their platform, basically they're three main components. The one is to write front-end. Front-end pages are written in a language called Visual Force. It's a HTML-like templating language. So you might be able to read that. You might not. You'll see that they've got custom tags embedded there with HTML. But that's less interesting for us. They also support business logic language that's kind of got sort of Java-like called Apex. But it is their own language there. And Apex is quite interesting for a number of reasons. What you'll find is that it supports interesting APIs. So for instance, you can make web requests from within Apex. You can also code web service endpoints from within Apex. So in other words, you can have business logic that runs when someone hits a page on your Salesforce site. And likewise for email. So you can send email and you can also have Apex that runs on the receipt of email. And then the third part of their platform is the data store. Obviously it's kind of an embedded database that they have. So when you're dev for force.com, you're either in Eclipse with a plugin or they've got this web-based dev environment, which is kind of cool. But the big thing here is that it's a multi-tenant system. So you share infrastructure with other people. So you need to quite carefully protect instance or organizations or accounts within Salesforce from one another. You can imagine if one account monopolizes the resources on the platform, everyone else suffers. So in order to protect users from each other, they've got a piece of technology called, right, so they've got a piece of technology called the governor. And the governor is, so it's built into their platform and it enforces all of the execution limits. So essentially any script that ever executes is subject to a whole number of limits. And once your limits are exceeded, they kill your script, okay. Limits vary dependent on how and where your code executes, but your code at all times is subject to limits. The type of limits you'll see are things like the number of script lines that get executed, number of database queries, the size of the result sets from database queries, number of call outs, number of sent mails and so on, and those are all published. But they're also, of course, a number of unpublished limits that we bumped into along the way, which points to good thinking on their part. So things, the kind of unpublished limits you'll hit are a number of received mails as well as running time of scripts. But this language called Apex comes with a number of limitations. It's not a general purpose language. It's a business logic language. So you'll find that there are a number of primitives you'd like from other languages that just aren't present here. So things like, you don't have locks, explicit locks. You can't pause execution, they aren't real threads. There's no explicit shared memory and so on. I mean, you'll also find that the order in which you make API calls is quite important, just because of the way their system has been built. So this is less interesting. Basically, we came up with a bunch of workarounds. So in order to pause execution, there are a whole bunch of floating-point operations. They don't count, well, so they only count script lines rather than the size of the expression on each line. So in this slide, basically what we're showing is you can chain about 200 odd cube roots to pause execution, and that just counts as one line of script. So, but you'll agree, I'm sure that that's quite a horrible-looking hack. We also managed to figure out ways to do locks and synchronization. They do support one implicit lock mechanism. It's less important. Shared memory you get by default with the data store. You just have to write it as such. You also get access to triggers. So within the data store on certain actions, you can set triggers that'll fire and the triggers can do things like make other updates into the data store, send emails, send web requests and so on. And so we focused on trying to bypass the governor, because if you can bypass the governor, then you get access to a lot more computing power than was intended. And with their platform that's spread out across the world that equals both computing time as well as bandwidth. We really don't have a lot of that back home. So any bandwidth that we can get is gratefully accepted donations. No? Okay. So what we wanted to do there was to create a way to fire off a lot of actions, more actions than should be allowed, based on a single user interaction. So in other words, normally a user hits a script, it executes its subject to limits. What we wanted to do is to find a way by which we can hit a script, it executes and we get a lot more processing time, processing power than was intended. And so what we focused on doing was to create event loops. So essentially chaining together multiple execution steps of a single script. And the first way that we tried, which didn't work, but it's worth reporting on failures, I suppose, gives us time to talk here, was to create a web service endpoint that called itself. But that gets detected on their side. So the next thing that we thought of, but discarded fairly soon after that, was to have a third party. In other words, you sitting with your browser to just have your browser repeatedly call their Apex script sitting on their server. But that involves a third party, so we did clear that. So what we finally decided on was to go with email. So essentially you can create email loops. You can imagine how that works. We send an email to a Salesforce address. It does a small part of the job that we're interested in and it then fires off another email to itself, carries on with the job, sends off an email once the limit approaches for that script, and so on. The loop continues. And so that gave us, gives you about 1,500 rounds of execution in a day. You still hit an unpublished limit eventually, but it gives you more processing time than was originally intended. And of course, whatever job gets executed is then up to the user's imagination. We don't have much imagination. So what we came up with was SIFTO, which is essentially a port of the Nectar web scanning tool onto the cloud. So I'm sure most of you are aware, but Nectar basically scans a website for vulnerabilities based on a database that it has. And so we ported that, as I say, into Salesforce. So our little app will basically add your target website into the allowed endpoints. If you're a developer on Salesforce, you'll know what that means. And then it kicks off this event loop. And in each iteration of the event loop, you'll get results for 10 of the Nectar tests. And then you'll get an email coming through every time hits received. Of course, the question you're going to ask me is why would you want to do this? And as I say, this is a proof of concept for utilizing the cloud or a cloud platform or as an attack platform. You can fire up EC2 instances and scan the world if you want, but this is actually using a programming language within the cloud to also perform security testing. So for one, it's free. So as I said, you get access to a whole lot of infrastructure that we just don't have. You get a degree of anonymity, but of course they definitely do monitor as we found out. Okay, so I'm going to show you a little video of this thing in action. Okay, so this is us just doing the setup. I lied to you, I want to play this faster. Okay, so this is just to show you you're required or you're required to have a bunch of custom Apex classes as well as a bunch of custom Apex objects. So all of this is now done through their web interface. We have an alert email that gets sent when a record is updated. So that's our trigger, which will help us kick off the event loop, and then the email address which receives the trigger mail is that. So as you can see, it's kind of a randomly generated email address that they provide you with. Less important. Okay, so what we've got then is a little shell script that wraps up all our calls to the site. In the one console, we're going to tail the victim's web log, and on the other side, we're actually going to kick off the scan. So you'll see that the request starts to come through on that console. There we kick off the scan, and now we start to see requests coming through in the web logs. So essentially, we perform one user action, and that's caused our scanning tool on Salesforce to kick off. So we bypass the governor limits. At that point, we can make a lot more web callouts than were originally intended. But I'm afraid there's no shells to be popped yet. Okay. So what we see then at the end is basically as results are found, they come through via email. At the end, we get all of our results via email. And I guess for us, the more interesting thing here is just that little slide that says, we started at 105, we ended at 116, total scan time, 11 minutes, which if we had to do from a single machine on the bandwidth that we have would take a lot longer than that. Okay. All right, so then we're gonna talk just a few pros and cons of the approach. As I say, this thing is a proof of concept just to get an idea of what can be done in on custom cloud platforms. It is free, you get lots more bandwidth. Of course, the question about denial of service does come up here. We're not gonna talk about it too much. There are a few cons that are listed there. So the one thing that's immediately obvious is to say, look, you only had 1500 possible iterations, now what? Well, that's true, but the converse is also, well, not the converse, but there's an alternate approach which says that a cancel is zero cost. So actually we can register one account that will perform 1500 iterations. We can register a second one which we'll carry on with the next one. We can register a third one which we'll carry on with the next 1500 iterations. Okay, so we can spread it out horizontally instead of having one account responsible for all execution. And of course they can communicate via email. So for this, we needed to have a whole bunch of accounts so we needed to auto-register. There's a problem. The registration page is protected by Captcha, not a particularly strong one, but it's there. However, we found when we pulled the Captcha, actually just on the command line, they had a unfortunate print R at the end of their Captcha script which just dumped out the text of the object. So actually it was there. Ready? Okay. To their immense credit though, they fixed that within 15 minutes. So I think that also probably deserves a round of applause. Okay, so at this point we now have 200 accounts. They spread out around the world. And so at this point you can then do that horizontal scaling. Yeah. So some of the things that we figure should be pointed at are basically, Cyfto is really basic, but it does hint at the possibilities for attacks from within the cloud. Their platform is developing rapidly. They're already on API version 16. And so we'll be monitoring that as new features become available. I think the third last point there is of most interest in the sense that we now have the security for an organization is transferred to your Salesforce administrator. And in many cases that's actually a C level executive. And this is the guy who's getting fished on a daily basis. He's not, and fair enough, he's not a security guy. This isn't something that he should have loads of knowledge about. But if he gets fished, they go all your customer data. So something to keep in mind. Yeah, one last thing there. Salesforce was really positive with the interaction with us. So we just wanted to acknowledge that they fixed the bugs and they've actually been quite cool to work with. So that ends my Salesforce stuff. I'm gonna hand over to Haroon to talk to you about Amazon. Okay. Okay, so we've got Amazon, Amazon and straight after that mobile me coming up. So really quickly, Amazon Web Services. We have to say right at the start is cleanly one of the coolest things we've worked on for a long time. The ability for a shell script to fire up 20 boxes and some data center somewhere, do some work and then send you back some results is really cool and well worth fiddling with. The pieces that we'll touch during this talk, we're gonna look at EC2, which is the elastic compute cloud. S3 will touch on SQS, which is their queuing service and dev pay. We're not gonna look at a whole bunch of others right now, although we're doing some of that testing back home, we're not ready to talk about some of it. So EC2 really quickly, if you break it down into its simplest form, you hit a webpage, if you want to, you can do it from the command line. You pick a machine, you boot the machine, it gives you an IP address and you've now got a machine sitting in Amazon's data center somewhere. Okay, it's got a whole bunch of other functionality which we're not gonna need right now. S3, it's simple storage service, relatively easy to understand, it's storage in the cloud and it works with a bucket model. Okay, for all of the services, Amazon's trying to get support, their pricing's really good, really attractive. Some people differ on the EC2 costs, but for lots of uses, you'll find it's a really quick, really reasonable way to get machine time. If we look at S3, there's a Firefox plugin called S3 Organizer, so it gives you pretty much an explorer type view that allows you to drag and drop files around. Its usage is increasing, January 08, it was storing 14 billion objects. Okay, and something that's gonna come up in a little while to bite them is the fact that it's pretty much got a flat name space. Okay, which means you get to choose your bucket and if you grab your bucket early enough, then that bucket is yours. Okay, so nothing stops me right now from grabbing a bucket called Defcon and going into the future, nobody else gets to store something as top level Defcon on S3. This doesn't sound so bad, but we'll be able to use it for fun and profit shortly. Okay, so one of the quick things that come up when you look at AWS is its feature for auto-scaling. Okay, it's a really big promise. Well, it's a really big promise with the cloud and basically it means you don't have to plan for peak usage anymore. You can basically have your app rise and fall as it's needed. Okay, of course you can probably see where this is going to start going wrong. If you take Amazon's SimpleDB, SimpleDB gives the site the opportunity to charge depending on SimpleDB usage, which basically means that you, with your little WGet script, can start adding cost to the guy who's using SimpleDB in the background. Okay, now the immediate response is we've bumped into this problem before. It's the same thing that happens with click fraud and with ads, except that with ads, the system self-regulates somewhat. If you get a bazillion clicks and only three of them convert, the price you're willing to pay for your ads go down. Okay, in the case of SimpleDB, you paying a price based on number of hits, whether those people actually buy from you or not. Okay, so there's actually less incentive for that problem to be fixed. Google have to fix click fraud because if they do it, if they don't, it devalues their ads. If there's the equivalent of click fraud happening on SimpleDB, you get poorer and Amazon gets richer. Okay, so we were looking at what we could do with AWS and we didn't have ideas initially or I didn't have ideas and probably a safe thing to do in any such situation is to copy Marco. So what we were trying to do was just see if we could steal resources from Amazon. Okay, they put the stuff up, let's see what we can steal from them. Turns out we can or we could. So if we take a really quick look at how this works, what you're seeing there is the page that comes up when you log in to the AWS interface and you now want to boot up some machine. Okay, what's interesting to note is what you should see at the time that screenshot was taken, that there's 2,800 just about machine images that you can fire up. Now interestingly enough, only 47 of these images were built by Amazon. Okay, all the rest are user contributed in some way or fashion. Okay, so you should be starting to get worried already. Now with these shared AMIs, what's interesting is people basically take an Amazon AMI or build one from scratch, bundle it together, then upload it to S3 and share it with the world. Okay, so the first question is, how many of these people are doing it right? Before you even wonder about how many of them are evil, just the question of how many of them are making mistakes. So if you troll Amazon's forum pages, you'll find a whole bunch of forum posts from people who are claiming or complaining that they can't get something to work right. And if you actually look through at the cause of their problem, you find that they've actually uploaded their secret Amazon credentials to the Amazon instances and then given these instances away. Okay, now all that means is you've got to boot that image, take those credentials, and now you transact as those people when you're transacting inside of Amazon. There's also the question, and Amazon's taken some heat for this, that they provide kernel images and how quickly they can keep up with the vulnerabilities that seem to be coming out quite often in kernels today. Okay, one of the problems that you've got here is you can't just scan machines in the cloud. Even though Amazon say, so officially Amazon say no scanning in the cloud, it transgresses their EULA. And unofficially the word is, as long as there's no complaint, you won't get kicked out. But one of them is a legal document and the other one is something that Amazon said. Okay, so right now scanning in the cloud is dangerous. So we needed a quick alternative cause remember the intention is we're trying to find other people's credentials so that we can use it. And so what we hacked together really quickly was a really ghetto scanner. And what the scanner does is it goes out, gets a list of all the AMIs and builds an SQS list with it, SQS queue with it. So SQS is just a normal queue except you keep it in the cloud and Amazon pay charge you a little bit of money to use their queue. They handle synchronization and all of that cool stuff. So we get this list of AMIs. We then fire up 10 images. Okay, each of those images go to the queue, pull down one of the images that's listed. It then fires up that image and then proceeds to scan that image. Okay, and in this case, we're doing really simple scanning. We're doing a NASA scan. We SSH'ing in and trying to steal stuff that looks interesting from their file system. Okay, so what we're looking for there is keys, passwords, bash histories, MySQL histories, stuff like that. We then dump the results to S3 so that we can grab them offline later. Okay, so the first thing is we were really surprised because we thought we'd find some stuff, but it turns out you actually find quite a bit. So just on the NASA scans, you end up with 1,200 highs, whole bunch of criticals. Only marginally interesting, what's more interesting is those are all user credentials that were left on these images. Okay, so these are all Amazon.pems or Amazon passwords, and they either left clean on the system or people have left them in their bash histories while they were doing stuff. Okay, what you're seeing there are certificates and key pairs, okay, all just left on those machines. So at this point, they ours and we can be them on Amazon. So while we're stealing stuff, the quick question becomes, can we steal licenses? Also turns out to be yes. So if you go to Amazon, you get to boot Windows images. We then use the Super Elite Magical Jelly Bean. So it's just a utility to steal, to recover licenses from your own machine. At this point, we're taking Windows Server 2003 license, which it gives us. We then take this back to our house in South Africa. We put it on our own Windows 2003 server and it happily registers for us. Those machines even allowed the past genuine advantage, so they even allowed to install updates from Microsoft. So we now run Windows machines also. So if we stealing stuff, we decide not to stop there. Amazon also provides something called DevPay. So with DevPay, someone gets to put up a machine and then gets to register it with Amazon saying that they wanna charge for its use. Someone comes along and wants to use it, they pay the guy, they get a product code, they then get to boot this machine. Okay, I'm gonna quickly try to show you a video. So DevPay is really cool. Essentially, they're offloading a whole bunch of work that you no longer have to do. So if we look at it, and I'm gonna speed through lots of those videos because outstandingly, we shortened time again. So what you see here is if you hit Amazon, what you should see down there is a product code that I then pay for. We pay for this, we then fire up that machine and what happens is every time we fire up this machine, the original guy gets paid for it. Okay, so Amazon handle that separately and we don't particularly care about it. If you see down here, if I describe this instance of mine that's running, what you should see up here is there's a product code attached to it. Okay, essentially this just means that I'm getting charged extra while this runs. So what we do here is we quickly bundle this image which is a normal functionality on an AMI and once we've bundled this image, we upload this back into S3. Okay, so essentially I've paid for it once, I've then made a copy. What I'm gonna do for demonstration here is make two copies, imaginatively called copy one and copy two and we're uploading this to Amazon. Okay, once this is uploaded, we then go back to S3 and pull down that machine's image manifest. Okay, so the image manifest basically says this is what makes up the machine and if you look through the manifest, you see here it's got an ancestry. Okay, which basically tells it that this machine was once Nick's machine which we paid for. So at this point we're feeling quite proud of ourselves. We remove the manifest, we remove the ancestry, we upload it back to Amazon and we try to register it. Unfortunately Amazon come back and say that's an invalid signature, this is not gonna be allowed. Okay, it turns out there's not a lot more needed so we grab it again, we remove the ancestry again and then we use the tools that Amazon give you for bundling machines and we re-sign the now modified request, we upload that to S3 and this time it allows us to register so effectively we can now run that machine from now on and there's no tie to the original image which we should have paid for. Okay, so I'll kill that really quickly, go back to the presentation just because there's a lot of it and we're running out of time. So if that's Nick's deal, the other thing that needs to be considered really quickly is even though the cloud provides us with a lot of stability and high availability, Amazon itself becomes your single point of failure. Okay, and the normal response to this is it's Amazon. If anyone can handle DOS, they can. If you read Amazon's docs, they talk about DDoS prevention and how they're willing to stay up despite DDoS attacks but attackers are not DDoSing you like it's 1992 anymore. Okay, nobody's sin flooding to take people down and if they go down for that, they deserve it. So what Amazon does is they prevent you from firing up more than 20 machines. Okay, so if you're a first timer, you get to fire up 20 machines because if a whole bunch of people fire up 1,000 machines, you can see it causing them some problems. Okay, so what we did, what we did, sorry. Okay, so I'll skip the video just because Marco says so. But effectively what we do here is it turns out you can sign up Amazon accounts without any capture or without anything stopping you. Okay, so a really quick tool script allows you to register hundreds of users. So really simply what we do is we take one script and that script creates 20 users and each of those 20 users go ahead and get 20 machines and each of those fire up 20 machines. And what you look at if you look at the graph of how that grows is by the ninth iteration, you're gonna be firing up close to 800 billion machines. Okay, and this is gonna cause them some problems. So thank you very much. So we want one more way to steal machine time and it comes from Amazon and that's basically when you get a machine, you don't know that that machine wasn't pre-owned before you got it. Amazon give you the six point bullet list but six points is not enough to know that your machine hasn't been owned. Okay, so what we do is we want to take an image, upload it and get someone to run it. The first time we do this, it turns out that we register our image, we upload it but it shows up really low on Amazon's list of machines. So I'm gonna skip through the videos and talk you through them for the most part but basically your image shows up like on page 200 and nobody's gonna run it. So what we do is we wrap that in a little script that registers the machine, checks the AMI ID that it gets. If the AMI ID is too high, it deregisters it and registers it again because those things are assigned to you randomly. The first time we ran it, we ran it overnight and by morning we'd gotten an AMI ID that now showed up in the top 10 which now means that when people go to the page, your image bubbles right to the top. Okay, the second time we ran it, we got a top five hit in under two hours so you can race it but that's not all. Because it turns out that, you remember I spoke about the name grab thing. Okay, because you can grab names as you want them, you can also make your image more attractive by naming it better. So what we do is we try to create something called Fedora. Fedora's unfortunately taken. Eventually you find names that work for you, underscores are cool. So Fedora underscore core underscore 11 gives you a nice name and you manage to promote it to a top five hit. Okay, so that thing bubbles to the top really quickly. At the time we did this, we did it at home or I did it at the office. By the time I drove home, two people had already booted our machine. Okay, and this is now our machine running in the cloud that we don't care about anymore. Amazon also don't do any outbound firewalling. People ask about it on the forums. People actually reply saying, but why would you want outbound firewalling? Okay, so welcome to 1990. So really quickly, I'm gonna touch on MobileMe. A long time ago, people figured out that MobileMe disclosed usernames. And basically if you go to the MobileMe page as Bob the cat, everyone on MobileMe gets a public page. Bob the cat gets told no such page. Fundavolt gets no such page. Shell Fundavolt, you get a public page. Okay, so we now know Shell exists on the system. You can now take all of Apple execs and start looking to see who actually uses MobileMe. You see Steve Jobs has an account which should mean you can mail him at stevejobsatme.com. But it turns out that one's not used. Notice that if you go to Steve, you actually see one with a 75 gig option and you can't buy a 75 gig option on MobileMe. Okay, so account password resets really hard problem to solve in the cloud because essentially someone who doesn't know you has to trust who you are. And so what we, it turns out MobileMe is quite silly about this. So I'll go to my last demo quickly. It turns out that MobileMe is quite silly about this and they handle, say if you go to Nick, okay. So if you go to MobileMe what you'll find is they have a password reset scheme that's basically based on secret questions. Okay, so once we find out that Nick exists, you hit his secret questions and so initially all it needs is his me at me at me.com address. Okay, so you don't even have to know the guy's real address, you just know his name. It then also gives you confirmation of his private email address. So you can confirm that it's the right guy you wanna attack. Okay, it then gives you secret questions. The first one is his birth date which almost everyone gives away free on Facebook on the Amazon wish list. Okay, and then it asks you a secret question and those things fall pretty quickly. So once we've got access to Nick's MobileMe, the question is what else we can do with it? Okay, because we can reset his password but shortly Nick's gonna come back and change his password. So what we wanted was permanent access to Nick's account and we found it in the stolen iPhone thing. Okay, we've gotta go. Basically what we do is we take an iPhone, sync it with his account except we also go into, we also go into iTunes and rename my phone script alert high so we rename my phone malicious JavaScript. My phone now syncs with his, we've gotta do some JavaScript taxery to get it right but essentially once we've gotten over those hurdles every time that Nick goes into his MobileMe page as long as my phone's there, my JavaScript runs in Nick's browser and when Nick tries to do a who am I he essentially runs our script and we own his MobileMe forever. Okay, so while doing this, we actually tested and found Steve Wozniak's account logged in to his mail just to show him how it worked. Turned out he was really cool about the whole thing. We've got conclusions which you can read off the slides. We in the room for questions. Room 103 for questions. We wanna say again, Apple were really quick to fix their stuff. So were AWS, so we only told AWS about it yesterday. They've already put in fixes for some of the stuff. Salesforce.com ready with their fixes. Other than that, you can get the stuff from our website. We should write up more of the stuff. Thanks for your time.