 I'd like to thank everyone for attending. If you looked at the abstract on the website, you probably noticed that there was several speakers. We've had a few of them, one of them had to bow out due to political complications with his work. There was a tendency to believe that this presentation might have some information that was sensitive, that they simply violated, say, code of ethics just to talk about. But the message will be spread. We have with us today Sean Barnum, cyber security principal, and Chris Peterson from AppSec from Zynga. And so what we're going to be talking about today is the various ways in which you can abuse essentially the Facebook API through the gaming infrastructure and how this can be used to do cyber bullying, play practical jokes, but also do some serious things. The final note I'd say about it is we discovered this research I did through prowling around. And I have some families that are completely addicted to Yo-Ville and they were getting attacked. So I just started digging into it. And one thing led to another. And it turned it out to be what I thought to be a topic worthy of talking about. A couple of disclaimers, though. When we're not going to be hitting you with some brand new type of attack that's just going to blow your mind. Rather, this is more akin to if someone has skill with a man in the middle proxy that malicious intent. This will show you a wide range of things they can do. So what we're talking about is that the damage that you can do with basic skills and the malware and the structured attacks you'll see later on that will show actually originated out of the Philippines in February of this year. OK. Oh, and finally, we're not here to back to Zynga or Facebook. We're just actually showing attacks that are actually happening. And in the remediation section where we'll talk about solutions, you'll actually see some work that's been going on that's proactive to defend against the things that we're talking about. So first, I'd just like to show you on the very basic idea that down on the farm, I'm growing the good stuff. Believe me, I have a great farm and I'm growing the OG kush. So no one can touch my Farmville pad. This is actually where I grow it in my pad. But more important, the little shot you see, this is from Yovill. And Yovill has a meager population, you might say, of 8.8 million unique users per month. The total Zynga population of games that are out there 254 million unique users per month. So we're not talking about a small user population. As you can see, that's enough people that it gives an incentive for fishing and all kinds of different attacks that might prey on people who aren't cybersecurity experts who are in a position to trust what they see. And we're also going to talk about the reasons for why that trust exists in several slides. I'd really like to thank Chris for being here with us today. When we brought this matter to his attention, he was very gracious. We had several email discussions. He was already aware of it. There was already a solution in the works. The security fix has been developed by Facebook. And Sean's going to talk to you more about that toward the end. The Facebook application API can still be abused and will also tell you why and perhaps things that may happen in the future to make that more difficult. Why should you care? Do any of you out there play games on Facebook? Mafia Wars? Secret Delight? Don't want to admit it? I'll be back here. Well, here are some statistics that show you the extent of the penetration of these games. There's currently over 80,000 apps on Facebook, any number of which could be potentially malicious. Social gaming, 1.6 billion this year, projected market cap of over 15 billion by 2015, so that's pretty significant. 300 million people in July is a lot. Now, one trend to realize is it's not just people playing on their PCs, but it may be people playing at work or it may be people playing on their PDA. And all these things become new attack vectors for you. So what you're going to see is there's going to be instances where someone's mobile device is compromised because of a social gain. And this can be a huge market for the underground. On a side note, I have a friend who was basically the going value of malware on the underground related to these things. He was offered $15,000 if he would write a piece of malware for these purposes, of course. The most important point is social gaming is going on on the networks you're trying to protect. So everything you're doing, however you're locking down your infrastructure, you've probably got someone out there gardening, at least planting seeds and waiting and going to collect them later. And this is happening on your network. And so it can actually inadvertently become a way of compromising the network and getting access to the inside. So I think these are a number of reasons why you really should care what's going on. Here's the roadmap we're going to take you. This was our brief introduction. We're going to talk about client-side trust attacks within application APIs, a number of attack patterns against social network gaming. And these attack patterns are really generalized. Sham will speak more to them. And they are general patterns of attack that go beyond Facebook or any Facebook applications but can relate to any site where you have an application framework and an app within an app. Some of our impact sections, we'll use JoVille as an example. That's just one site that I was very familiar with and had family playing. And so I was sort of just focusing on that. And then lastly, most importantly, we're going to tell you how to keep your software off the stage. All right, Chris. So thank you very much for allowing me to do this with you guys. I wanted to talk a little bit about some of the reasons for these issues that they've discovered in the network. And it's easy to sort of jump to the conclusion that it's just a bad architecture and that they've made some kind of fatal flaw in how they architected the system. And that's what led to these particular issues being there. But the reality is that it's a very complicated system that's been created. And there's multiple trust domains that are interacting with each other here. You've got the trust that the user has with the application framework itself, in this case Facebook. You've got the trust that the user has with the application itself, in this case Yo-Vil. And then you've got the trust that goes on between the application and the framework. So between our Zynga applications and Facebook, for instance. And all of those various trust relationships are sort of distinct from each other. And the protocols and techniques that have been designed or are specifically designed to protect the various trust boundaries. So in some of the techniques that you're going to see later in the presentation, there are attacks going on against the man in the middle of communication between the client and the application framework. And it seems like the obvious solution would be to just have the application itself send those messages directly to the back end of the framework and eliminate this whole scenario. The problem is that the application framework is actually responsible for protecting the privileged operations that the user is doing. And so these transactions need to originate from the user so that the framework can validate that in fact this is a user operation that they've authorized. So that leads to some of these issues. Now as you'll see towards the end, they've actually done some stuff to improve this, but fundamentally the architecture's not flawed, it's just a very complicated relationship going on. Another thing that you'll see in some of these is that there's a lot of trust that's been placed in the client side of these operations between the application, say Zynga servers and the Zynga client side application. And there's a reason for that as well. As you saw earlier, our games are huge. We've got hundreds of millions of users playing every month. And in order for us to scale like that, we've got to push at least a large part of the processing of the game logic down to the client side. It's really the only way that we can scale with that size of user base. Some of the other things though that they've seen that are related to this why this threat is so large, we've got the ubiquity of this across the network. So there's hundreds of millions, by latest estimates, 500 million users using Facebook, 80,000 applications in Facebook itself. There's other social networks doing the same thing. These client side apps are everywhere. They're becoming an interesting avenue for people to look at. Our users unfortunately also have an incentive. They've got a profit incentive to go into the games and respond to requests from other users and accept invitations. And that makes them somewhat vulnerable to attack. That's one of a big area of research that we do at Zynga, which is part of the social network interaction. And then what we're seeing is that these represent an economy, a large economy, as you saw this year, virtual economy in social games is going to be on the order of $1.6 billion projected to grow 10 times that much in the next five years. And so there's a lot of people out there that see this as an opportunity for them to get a piece of that pie illegitimately. So we're seeing a lot of malicious activity. We're seeing a lot of people trying to build black market economies around the games. So that's one of the reasons why this is a big area of research that's going on. Okay, so I wanted to talk a little bit about how the actual application framework operates and what's going on. So the client app actually gets downloaded from the game servers when the user instantiates the game. It actually gets loaded, in most cases, into an iframe running inside the Facebook canvas. But that actual, in our case, flash application talks directly to our back end servers through our own API and most of our interactions are through those servers. But occasionally, when we're invoking activities that involve the social network, such as sending invitations to other users or posting messages on someone's wall or something like that, then we have to go through the actual application framework that's provided by the social network. And so our back end servers will initiate that operation through the client and the client actually sends that message through that framework interface and that's what initiates requests into the stream publishing, can access information about user profiles and friend lists and things like that. And so that's how these two APIs work. They're independent of each other, but they're also coupled. So I'll start off by apologizing for sounding like a frog. This week has been harsh on my voice. Just wanted to, before we dive into some of the attack patterns, wanted to call it explicitly some of the characteristics of this social network context and this application framework paradigm that kinda lends to it making it more susceptible to attack. So first of all is the issue of trust. There's inherent trust inside of these sort of contexts where the attacks are coming from people that are within the circle of trust you've already defined and by doing that, you're much more likely to fall for issues. You're much more likely to click on things, to understand things in a naive fashion than you would from things you would be suspect coming from the outside. The second is stealth. So all of these attacks are happening at the application logic layer. This is not your typical web attacks where you're looking at cross-site scripting and stuff and seeing scripts, seeing meta-characters. The users are just seeing interactions with the application. They don't have any view below that. So it's a lot harder for them to actually detect whether something's malicious, whether it's not malicious. And lastly is this issue of urgency. So one of the bolts on one of the slides Chris just did was the psychological conditioning that a lot of these social networking, social gaming apps do. It kinda drives the user to trust the people who are within their network and there's a temporal issue there. So sometimes when gifts go out and things go out, the user has to click on them a certain period of time where they go away or they're used up because there's a supply. So there's this conditioning to actually quickly trust and not put as much thought into it. So that sort of conditioning, once again, leads to being more susceptible to attack. And then this sort of context also brings with it certain attack perspectives. So one of those is it's very easy to do amplification attacks. Once you actually can compromise one user account, the very short hop tight nature of the social networks means that you can leverage that account to quickly affect the people within their circle of trust because then those people you can actually get to and then from those people on. So just like other amplification attacks in networks, this one's even typically faster and easier because of that tight short hop nature, excuse me. Also deception, so this whole idea of trust that's in there is absolute fertile ground for anybody doing fishing, right? So it's very easy to actually create these messages which you're gonna see some of the techniques for doing these things that look very real. They come from some of the you actually know and trust and it's very easy to get somebody to click on a link or click on a button or do something that's gonna actually take them somewhere else. In the case of some of the buttons which Tom will talk about, just like some of the Java action type buttons you see in other things, the user, the naive user, many times using these applications can't just do a mouse over and actually see where it's going to. So it's very easy to do fishing attacks with this kind of stuff. And then lastly, it's very simple to exploit. So Tom said that this is not really deep technical foo. Anybody with peros proxy and basic knowledge of how web applications communicate back and forth, it's very easy in most of these frameworks now they communicate back and forth to actually create false completely spoof content or to actually modify content on the fly and do all of these things. It's just inherent in the paradigm that's actually here. We'll talk a little bit about some of the mitigations at the end that are making this a little more difficult. But if you're either building and operating an application framework for something like this or you're building applications to work with it, it really does take careful proactive thought to think through these issues and address them at a strategic rather than just a tactical level to actually tackle this stuff. So the framework we're gonna use for talking about this stuff today is really focused around attack patterns. So attack patterns are generalizations off of certain instances of attacks. So we're not gonna be talking with here's the exact exploit code for doing something. We're taking a step back and saying, there's certain patterns that apply to these sorts of architectures, these sorts of contexts. And anybody with a basic knowledge on how to do software attack and look at these patterns and instantiate that in lots of different ways. These attack patterns actually exist at multiple levels of abstraction as well. So you'll see that the first one we've talked about here is the highest level abstraction which is API manipulation via man in the middle. So given these sorts of application framework communications, it's very easy to demand the middle inner position attack and manipulate the API traffic that's going between the application and the framework or the client and the framework. That sort of high level abstraction can get instantiated in several different ways. So you can use that same API manipulation to do content spoofing, creating stuff on the fly. You can capture stuff in transit, modify it, modify the integrity of it or you can actually do replay attacks for this sort of messaging as well which usually is for things like in-game cheating and things like that in the communications. So Tom's gonna talk just a little bit right here about content spoofing and then we'll go after that and we'll go with a few more patterns that are a little bit deeper and he'll talk about some of those as well. So given that you have the ability to basically create content from the ground up and we'll show you which API elements that you can use to do that, you can actually put something on someone's page that is completely custom. So you could create what looks like a new game or a new type of quiz and it would have a button and have it linked to, as you can see, this says one of your friends thinks you're sexy. Find out who and there's a click allow button. Now, this sort of thing could be linked to any number of different attacks. You could link it to any kind of exploit or malware or any kind of malicious website and go from there. Here's an example of just completely spoofed content that was sent out there. I put the ass of fire in circulation for a while because lonely hearts are burning up in Yeovil and you can see the button, collect the ass of fire. If some of this is hard to see, we'll make the slides available for download at some point and I'll give you a URL. Now, the important thing to note is that each element within this construct actually has a different API area where you can populate it. So here, if you sort of map it, you can see actor and then each of these. Sort of media source href is basically the link to the image that you want to put there. Then you can see that any sort of title like, ooh, the ass of fire would be in template data name and then the template data name has an href that can be manipulated. Now, also important are the action link so that when you go to collect the ass of fire, you could go somewhere else and then, of course, take the user to wherever you want them to go. So with that mechanic in place and can be exploited with something like a man in a little proxy, you can actually begin spoofing any kind of content you want and playing Mary hell with people. Ultimately, content spoofing rests on the attacker's ability to modify message content or make API calls directly to create arbitrary content within a cross application messages. Of course, and the impact can be anywhere from fishing which is a special type of fishing in this case that we'll talk about. It enables any kind of social engineering, user harassment, things of this nature. Now, this is, of course, a case of cyber bullying. It's an example of sending someone you don't want, say, a burning cross. Now, notice that I didn't change all of the underlying elements. You can see where this was actually a global element that would have populated my wall for mystery keys. But I've just taken out all of the elements, but I left the mystery keys in there so you could see portions of that API that were and weren't used. Now, here's what it looks like from a proxy view, okay? And then we'll go ahead and break this out. But this is basically the sum total of complexity that you're dealing with. You can see that it's not incredibly hard. Each of these are the Facebook API elements that you can focus in on when, say, performing content spoofing. The template data href link, the template data media href link, all of these things could point to other things. You can specify the image with the media source. Now, what's important is the action link as well, such as you go to claim it, then that can take you someplace else. Some of these you can leave unaltered so that if you're trying to create a special scenario where they only click to claim it, it takes them to someplace bad, then that's fine. That way they might not know it's illegitimate just by clicking any other links. In these cases, here is an attack execution flow that basically summarizes what was going on. And Chris talked a little bit about this. But basically, if you're starting from, say, modifying the underlying request that you found a set of keys or you found a cat in the hat hat for your apartment or for your avatar, then your client side will let what we're calling appville know, hey, I found this item. Then appville will respond, okay, this is great. What we need you to do now is to respond to the framework app and tell them that you found this so that it can publish to its own specific feeds. And then you get a stream publishing request to the framework and it goes wherever its destination is. And we'll talk about where the different types and touch points that you can attack. And then finally, of course, the message is delivered and your attack is resident. Now, in a generic sense, given that we're talking about any kind of application framework where you have a master or framework application controlling the sub-applications and there's communication, both within the sub-applications and the master, you can have things like invitations, some types of notifications, say X event has happened, these things can be tampered with. There can be user or group specific news feeds, what you would publish through the stream protocol. Individual messages, know what would this be? This would be a gift. This would be me sending you a gift, something like a Jeffrey Dahmer snack tray or if I was just trying to harass you. Or it could be something less obvious and more insidious. And then there could be some types of global alerts that go on and all these things you could tamper with as long as the client is bearing the strength of the trust in that relationship. Now, we're gonna talk about several attack patterns. Sean, do you wanna speak to any of these? Okay, basically we're gonna talk about navigation remapping and button hijackings, these two of the big ones. And in a KPEC sense, what you'll find is that exploit injection via API message manipulation and malware propagation are basically going to be hierarchically related to these. But, so really seven and eight are different types of impacts that you can pull or pivot off of five or six. And we're gonna give you some examples of those. Now, when you're talking about navigation remapping, here we're thinking of, let's say hyperlinks. And this is where you're just simply changing link destinations. I can result in any of the things we've talked about. Now, I'll show you just a simple example, a short movie of just, this is really sort of just a humorous thing, where, I got you, it's all right. Now, the user clicks on a man of the year award. I know this is hard to see, but we can make these available. And then you have Rick Astley coming right off. So, we know it's a bit overplayed, but it just gives you a sense that going directly from a content that looks authorized with on your page on Facebook that you can get to somewhere you don't really wanna be. This is all of the different API elements that were used in that. Some of them weren't renamed, but all of them, these are the very specific ones that allow you to conduct that type of attack. This is what the attack execution flow looks like. You have an event, basically the game application tells you how to respond, you modify it, send it back, and then you can get your malware or your link, whatever it is you're trying to do. All right, now with button hijacking, it's the same situation except basically the destinations are masked and you don't really know what you're clicking on when you're clicking on it. And one of the interesting things is that there is, for example, a lot of demand for, let's say, a cute puppy. And it really warms you in your heart to be able to click and save a cute puppy and no one really expects the fact that by doing that, they could actually be getting malware on their system or getting hit by a PDF exploit or something. I've highlighted within the Peristomp just some of the areas. Notice where this is labeled except, this just shows you where it would populate the button content. If you were, it would create a button that would say accept Jeffrey Dahmer snack tray. Okay, so you're actually populating what the button contains, but you won't be able to see where it leads, so. Now in terms of malware propagation through API messages, this is a little more detailed attack execution flow of what we're talking about. You have first some level of authentication that's going between the user and AppVill and then of course you have an application event and then the application event response that you're modifying. And then you're making a stream publish request. This publish request goes directly to Facebook. Facebook will respond to you and say, hey, it was successful and then it will put this to wherever the destination is that it belongs, either on the user's wall or as a message to the user and whatnot. Now, here's what it would look like and I was just gonna show a few slides and then we'll show you a movie. Here Jerry Mathers has updated his pad and the idea here is that all of his friends may wanna come and check out what he's done. Now this situation can be quite different if what's being offered is some rare item that's time sensitive and that the number of clicks determines what the lifespan of how long it takes you to claim that item. So things can get used up really quickly. So you can actually have a feeding frenzy going on for people wanting to get into these clicks. So that's why we say it's an amplification attack. Now has anyone ever, this is basically this type of warning, you can't see it, but it has broken English in it and it's actually a piece of malware that's been drifting around for quite a while. They've made several refinements on it, but this is just one example of as soon as you click the link to go see the pad, then what you get is an update that you've triggered the malware at that point. So this mask arrays itself as an antivirus. What's actually going on is it's using jQuery and Ajax and it's dynamically updating this page so it looks like what you're looking at is a view in Windows Explorer of yourself getting a virus scan and then at the end it'll offer you to download it. What's important in this case was that they had modified the malware where no matter what you do, unless you just do a hard reboot, you're going to get infected because it doesn't require you to download anything or any ascent, all of this is just a sidebar to the actual attack that's going on in the background. So actually let me back up and show you a quick movie. So once again, Jerry's updating his pad and you'll see very quickly that the malware will start hitting on Pow, okay, there's a warning that comes up no matter what you do, now he's involved and going on in the background here is it's downloading possibly through some method of like Java network load protocol or some, it fetches malware that you really have no control over seeing. So you never really know what happens. If you've closed it out, you don't even think that you've been hit. Tom just talked really, really fast and got way ahead of where he was supposed to be. So one of the cool things about Def Con is kind of the unique mix of people we have here. So at the con and probably in the room, we got everything from blackhead hackers, malware authors, botnet operators, leaps, lamers, posers, scene horrors, security researchers, vendors, but we also have some of the corporate security types, the people that actually have to build and deploy and operate this kind of software and they're worried about doing it in a secure fashion. So our goals for speaking here today was really to kind of raise awareness of how kind of fragile some of these framework, application framework, communications mechanisms are, especially within a social networking context. Some of the unique things that those bring to the game and because of the nature, the fast nature of this stuff growing because of the fast nature of how many users are out there because of some of the unique scalability issues. Many times these sorts of things are being deployed and maybe not with as deep a proactive security thought as could be there. So one of the things we wanna do is try and kind of introduce and raise some awareness for those out there who are having to build apps against these sort of frameworks or who are building these frameworks, some of the things they wanna think about from a mitigation perspective and some of the resources that might be available. So really if you're gonna build secure software, if you're gonna build software that's resilient, resistant, tolerant to attack, the first and absolute fundamental thing you have to do is understand how it's gonna be attacked. If you don't understand what the attack or how they're viewing it, what kind of techniques and things they're gonna do, there's no way you can possibly build it to be secure. And unfortunately a broad understanding of that kind of knowledge of the attacker's perspective really resides in a fairly small number of people's heads. This is not broadly known stuff that's out there and truly most of those people in the world are here this weekend. So if you look around, you might recognize them. Well unfortunately when we all leave, whether it's today, tomorrow, whenever you're going back home, you spread out, we're still greatly outnumbered by the people who are trying to build software. And so there's only so much of our brains that can go around to help them understand it. So to tackle this problem really requires some way to capture and share that sort of attacker's perspective knowledge and understanding of these sorts of things we're talking about, what sort of perspectives and approaches an attacker would take, what sort of things are vulnerable within the software, not just the vulnerability like within this specific version of Microsoft Word has a vulnerability CVE, but what is the thing that building your own software you may do to make it vulnerable to these sorts of things? So to start I wanted to, we wanted to basically introduce a couple of resources that are available for these types of people who are building and deploying this sort of software. The first one of these is called KPEC. And you heard Tom when he's ran really through, said KPEC at one point. KPEC is the Common Attack Pattern Enumeration and Classification. This is a resource developed by an international community. It's led by MITRE and it's hosted by MITRE, but it has hundreds of different people around the world involved in doing it. Basically it's a collection of attack patterns, so common approaches to attacking software. So it has a schema that describes things like a detailed attack execution flow. What an attacker does, how they do it, what sort of skill and knowledge is required, what sort of resources are required, which sort of weaknesses in software to these attack patterns to focus on and target. The other side of the equation is another resource called CVE or the Common Weakness Enumeration. Again it's an international community led by MITRE and hosted by MITRE, but involving even a much broader footprint of organizations than KPEC is. Both of these are available for free. They're available right now at the URLs that are on the screen there and they're giving me the slides. KPEC currently holds between 300 and 400 attack patterns descriptions and the CVE currently has over 800 weaknesses defined. So there's a lot of great resource knowledge, this basic fundamental yin-yang set of the attacker and the weakness perspective that form a great resource for people who are looking to build the sort of software, deploy this kind of thing, to look at the kinds of things they should be thinking about, to understand how an attacker would view their software and what sort of things they want to make sure are not there, what sort of security features and engineering they need to put in place to try and actually prevent this stuff. The different patterns that we've talked about here today, these nine different patterns, in the next release of KPEC, which we'll go out in the next couple of weeks here, we're trying to get it done before this conference, but we weren't able to get it out there, but you saw during a few of the slides actually referenced these patterns will be in the next version, so there will be a full description of these, but once again, this is just nine added on top of like 320 that are there already. The reason it's higher than 320 is there's also categories and views and things that help organize these within classification taxonomy so you can understand how they're related to each other. So beyond that, one of the things that KPEC and CW both share is they don't just describe the problem, they actually seek, strive to give prescriptive guidance. Here are the things you can do to make sure that your software's not the one being talked up here next year by not just us or anybody else, so what are the things that you can actually do? So we wanted to leave you with at least a couple of slides or a few detailed elements of prescriptive guidance to avoid the kinds of attacks we're talking about today to help secure these sorts of application frameworks and social networks a little bit. This is by no means an exhaustive list, but these things are some pretty good things that should be involved. So starting out with some guidance that are specific to this talk, so the most egregious things, the most egregious attacks that Tom was talking about really are ones where you can not only spoof or manipulate the content of messaging with things like the cyberbullying of changing an image and that kind of stuff, but really it's that ability to do phishing, the ability to actually do in-URI type exploit injection to do malware propagation to those links. Those are the really bad things. And there's been a good first step. We talked about earlier that there's been some movement from the time we proposed this talk and from the time we built the first deck. About a month ago, Facebook released a feature they call Secure Stream Publishing, which does framework side validation of user side, client side generated messaging for the URIs. So these sorts of messages that go back and forth when Tom showed you the image with the little fields in lower right that accept those kind of link fields, all of those link fields now, if an application developer uses this opt-in feature on the Facebook framework side, it will actually validate that the URIs coming through in those links are within the application-owned domain so it doesn't link off to somewhere else. So that doesn't solve all problems, but that's a pretty huge step to actually making sure this stuff doesn't go off. Now, one of the things to look out for is sometimes that might break your actual application because maybe your application goes to links that aren't inside your domain. And one of the first kind of reactions to many different developers may be, well, let's just build a general redirection. Well, now you just broke the whole feature. So the feature's there, one of the key things is it really hasn't been publicized yet all that much. We strongly encourage the people from Facebook, we're not digging them because they're working towards the right thing, but we strongly encourage them to make sure that all the application developers out there are aware of this feature and encourage them to strongly start using this as a first step towards doing this. As of today, Yovo, which is the application we'll be showing you and all the other Zynga games have actually fully implemented this feature, so all of their communications with the framework, application framework are no longer susceptible to this sort of link manipulation at least. The framework still has the ability to do image manipulation and the text manipulation of message, although that's a little bit limited to cyberbullying because Facebook does destructive transcoding all images, so there really shouldn't be a way to inject anything through that. At least there's not anything known right now, but like anything that's only today, tomorrow somebody will figure out some way to do that, but this really is a really great first step, but the key is it has to be used and right now it's not being used widely, so we strongly encourage this use. Beyond that, there are some different approaches that could actually fully secure that sort of message traffic to allow the client side can't control or manipulate or generate any of that sort of message content. One of the ways of doing this is using application generate messages with whitelists, so rather than have the client hand the content to Facebook, there's the possibility that the client can say, you know, within any application, there's typically not a valid use where the user can generate a magic message of their own, it's usually from a set of known messages, so they could actually put a request in to Facebook saying, what we want is message 24. Facebook communicate with the application vendor saying, hey, they wanted 24, and then the application vendor hands down the content and now you know that it hasn't been mucked with it's actually official content and then Facebook or the framework could publish it. Like with anything, there are some downsides to this. That can involve a significant amount of traffic between the application framework like Facebook and the application vendors, so that's the reason it's not being done today and that's a trade-off that they have decided to make. It may be a valid decision today going forward with some of the security issues that may reach the point where that isn't the case and there may be some application framework other than Facebook where maybe they're dealing with less number of apps and so they can actually deal with that sort of traffic, so this is a much more secure approach but there are some business reasons why it may or may not be the right decision today. So beyond that sort of specific to the attacks we talked about, there's also some general guidance if you're doing these sort of applications against application frameworks specifically within a social networking context that are just good rules of thumb. First of all, if you're a framework vendor, you're a framework operator, you really want to establish and enforce as the key here some clear rules for application behavior. So what kind of applications are valid? So all of these things we talked about protecting the messaging traffic are only going to protect you if you're dealing with a valid non-malicious app but the reality is you can actually publish to many of these things a malicious app and it can have completely validated that the content is coming from you but if you're doing bad things like phishing, scamming, spamming, all these sorts of things, you're still making the user vulnerable. The reality is many of the frameworks including Facebook have policies defined for these things but there's not a whole lot of really proactive enforcement of some of those rules. I will say that just this week, Facebook took a pretty significant step and they discovered one of their developers was had a repeated pattern of this sort of behavior and rather than just banning an app, they banned that developer from ever publishing anything on Facebook again. So that's a great step on that kind of thing and it's better if it's done in a consistent and wide fashion which it isn't today. Another thing is to enable granular approach to friends and trust. So right now within these social networks like Facebook there's only one level of friends, your friend or your not. And that implies all of the possible interpretations of what that trust means. So it would be actually much more effective from a security context if you can have multiple different kinds of friends or different levels of trust. This is a friend that I have on a personal nature. This is a friend I have in a business nature. This is a friend I have playing Yo-Ville. And that way if something comes to you from a friend within a certain zone of trust, maybe you're gonna put a lot less trust with somebody who's in your Yo-Ville friend list than somebody you've known for 20 years. Right now you can't distinguish that. When it comes in, you're gonna have to recognize their name and understand it. Some of us who only have a couple hundred friends, maybe that's okay. Some people have a couple thousand friends, that's just not gonna be possible really. So better granularity is gonna actually lend to supporting better security structures going forward as well. Instituting a mechanism to convey the trustability of applications. So Facebook has a basic capability of that right now where a given application on the application page, users can go and say like, I like this application. That's really the extent of the trustability right now. The reality is most people who use Facebook and they use apps, they're typically gonna click that like because they think it's a cool application, it does something fun. They're not clicking like because of its security. So that really is not all that great of something, but having mechanisms like some of the e-commerce sites like Amazon and some of those things have right now where there's a little bit more than just like, but you can actually make some security qualifications, it'd be a good idea to work some of that in so that when a user actually sees an application that they wanna use, or they see traffic from that application from one of their friends, they can make some trust decisions. Part of that also is education of the users to actually understand some of these things. Next one is employing clear and visible measures to expose measured spoofing. So right now, Facebook, and once again as the example, when a message comes through from an application, the lower left it has a little icon, a little thing that indicates that's generated at the framework level for that application, what application it is. So the user who's spoofing a message currently can't spoof that, although they can do near homographic attacks, so instead of Yo Bill, maybe they can do Yo Dashville, and you're not gonna notice, but maybe a little bit better structure to, so that a user when they glance at a message will know that it's official or not, maybe structuring a header, things like that, because right now it's pretty easy to spoof content and only an educated user or somebody who's really looking out for it is gonna notice that it's not there. Part of that once again is user education. Safe Book recently added a page on safety, Facebook safety is describing some of the stuff. You really have to be proactive and go find that, so finding ways to actually make this stuff more evident to the general user who may not be security savvy is a very good idea. Then lastly, the last one here is establishing proactive processes of vetting apps that actually get into the framework, so are they malicious or not? So this is the kind of thing that Apple gets dinged for sometimes on how restrictive they are for what goes into the application store, but they actually do think about it now, they don't test anything, but if they know things are malicious, they might keep them out. Right now, most of the social networking frameworks are fairly open game. Unless you've been banned by name like this one pencake who was done this week, typically you can throw an application in there and there's not really a proactive vetting process to know that you're a valid application just building a fun little game or you're somebody who's building some sort of a phishing page, phishing application or anything like that or any kind of malicious software downline. It could be that the flash client that's actually downloading for the application itself is full of malware. And right now it's pretty easy for anybody to actually install one of those into the Facebook framework and actually have people start using it. So we would strongly recommend a much more proactive approach to that. So I think that's all that we had for the guidance. So last little bit is, anybody wanna join a group here of the Rafflecopter Aspiration Society? You can trust us, it's perfectly safe. You can go and join it, we won't screw it to you at all. So if anybody has any questions, we're happy to take questions on any of this stuff. Any of the detailed questions for specific mitigation stuff will probably leave to Chris because he can speak from the actual vendors perspective that actually built them in. Any of the questions on some of the higher level research patterns and stuff like that, we're happy to take those either in the room or offline anytime. So thank you.