 So, this is weaponizing the web, more attacks on user-generated content. I'm Nathan Hamill. I'm a senior consultant for ID Information Security. I'm also an associate professor at UAT, which I saw some of my students here running around at one point. I also founded the Hexagon Security Group and apparently as of a couple days ago I became a 23rd degree Mason and I'm a lava rolling enthusiast. More on that later. More later. And yeah, Sean Moyer. I work for a company called Fishnet Security. Often described as the douchebag with the microphone. In this case I'm actually the other douchebag with the microphone. So we have kind of a, you know, binaural kind of thing going on. Self-styled wikipedia and shot a man in Reno just to watch him die. That's good. So yeah, just kind of an overview of sort of where we're headed. And I guess I would say kind of bear with this. Some of the things that we're talking about, I have to set up a little bit. But yeah, just kind of the first part of the talk is just kind of some overall observations about sort of what is wrong on the internet today, you know, and such. And sort of talking about user-generated content in the democratization of misinformation, right? So, you know, if you think about it like 10 years ago, you know, you could only be misinformed by your local newspaper or your TV news and now anyone has the ability to misinform somebody else, you know. So that's kind of the beauty of the internet, right? And sort of... What we're starting to see on the web is there's really not that many one-way conversations on the web anymore. So long gone are the days of visiting somebody's GeoCities page, which I don't know why you'd want to go there anyway. I believe Jason Scott has an archive. So if you really, you know, just need to have that fixed. So there's a lot of two-way communication. And in this two-way communication everything is communicating with each other and becoming this more social animal. So you end up having aggregation points and feeds and you end up integrating other people's content into your application and allowing other people to integrate your stuff into their stuff. Yeah, and sort of also, you know, and we've mentioned this a lot, you know, there's sort of a features arms race that, you know, so everybody's scrambling to add, you know, new functionality to their sites and that kind of creates some sort of emerging attack surface that are a little bit different, you know, in terms of the web today. Actual information and content, you know. So, you know, again, so kind of the first part will be a little ranty, but then we'll kind of get to that stuff. So, you know, we're sort of talking about what we think is kind of a different approach to an old bug that's relatively well understood, which is, as most people, I think probably know it at this point, is cross-site request forgery. And we sort of are looking at some approaches to get around the typical mitigation measures that people put in place. For preventing that. So, and being the nice people we are, some of these new sorts of attacks on cross-site request forgery, we've released a nice little nifty tool that helps you do it much easier. And that, you know, that also kind of relates to some of the demos that we'll run through. Yeah, so we prove that the tool works because all the demos were done with the tool. It worked for us, yeah. It did work for us. You're doing something wrong. Yeah. And don't knock my coding skills, man. Please do. Yeah, and sort of, yeah, again, you know, some observations about sort of multi-site APIs and silly things that are out there in terms of some of the APIs that you're seeing across a lot of different sites. Yeah, imagine that. When you expose yourself, there may be vulnerabilities there. I saw that last night, somewhere. Yeah, but yeah, you kind of have to listen to the rants first. So we'll kind of run through some of that and then we'll get to the rest. So kind of, again, sort of the overall topic here is user-generated content. This is, you know, basically just the concept of sites where the content is driven by the user base. And at one point, you know, that might apply to a specific subset of sites, but what we're finding is more and more there's just sort of, you know, all of that kind of functionality across the board. But yeah, things like blogs, wikis, social networks, web communities in general. Again, increasingly kind of bolted on to older sites. And so there's sort of this kind of functionality is getting integrated sort of everywhere. And by user-generated content, the user doesn't have to be like an end user. I mean, this could be a developer as well. So in a lot of these applications, the developers are actually the users as well. So their small apps that they build are actually user-generated content. We kind of got into this a little bit. Aggregation points. So you may have, you know, accounts on multiple pages, and you want a way to aggregate those so you only update once and you aggregate too many. Who would have thought there'd be vulnerabilities there, right? Increasing client-side logic. So sharing more of that logic on the client side can lead to greater vulnerabilities, more information leakage, and we have screenshots. Yeah, so actually, you know, kind of part of what got me contemplating some of these things was Marble Cake also, the game. So I'm kind of looking around the room, and you don't have to raise your hand, but is everybody sort of familiar with that particular turn of phrase and its relevance? You know? Yes, I would think, some people here might be very familiar with it, you know, presumably. The Black Hat audience was not so sure, you know. I think we're the first people to mention Fortune. You got one woo anyway. I did get a woo. But, you know, the thing that's kind of interesting about that, so the story is, for those that don't know, is that Moot from Fortune was actually nominated for Time's Person of the Year poll that they do every year. So they do this, you know, sort of the most influential persons on the Internet or something along that line. And so that gathered the attention of that community, and so what kind of became interesting about that was, the first plan was just to have Moot win, right? Just to get him to the top. And so that was done with, you know, some auto-voting scripts and things like that, and then people decided that that wasn't challenging enough. So they decided to have all of the votes spell an acrostic in order that spelled the phrase Marble Cake also the game. For the Time Person of the Year poll. So the way that that was done was through a whole bunch of different logic that went through and prioritized different people who had the appropriate letter for their first name and watched, you know, how the score, you know, how many votes went where, and went through and set that up. And then it got kind of interesting because at one point, you know, Time Magazine tried all these different ways to circumvent, so they added CAPTCHA, and they added what they thought was a tokenization method for the voting process and all of that. And they actually ended up, all the people that were working on that found out, you know, a way around sort of everything that they put in. I think the end totals here was like 12,939,000 votes for Moot. Yeah, and then 1.6 million for Atwar Ibrahim, who just happened to have, you know, an A in the name. But yeah, the sort of the larger point of this, though, is what I thought was really nifty was that Time's response to that was, oh, well, you know, Internet polls aren't true. And so, you know, that just happens. You know, you don't need to worry about that. But, you know, they predict the, you know, presidential race, which way it's going to go from online polls and things like that. So, you know, everything on the Internet isn't true, I guess, was their answer to that. Well, it's a good thing the polls for the presidential election weren't hooked into 4chan. What about a different election there, I don't know? So, yeah, and kind of related to that, when, you know, after Michael, and some people here know this, after Michael Jackson's death, there were sort of a series of these kind of copycat hoaxes of other celebrity deaths. It was like Britney Spears and Jeff Goldbloom and some of those things. And, you know, this one, which was, you know, Rick Astley. I'm sorry. No, I think that's just wishful thinking because everybody wants Rick Astley dead. So, yeah. So, but what's kind of nifty about that is that one of the reasons that that was so successful, you know, in recent months, for that kind of misinformation to propagate it is because CNN and then, you know, as a copycat offering Fox News have created this thing called iReport and then Fox's is youReport. We decide, you report, but we decide that basically allows just random people on the Internet to, you know, post their news stories. And it's been really useful. It's also done things like break, actually the riots in Iran and all the post-election stuff and a couple of other things. But it's also been used to just, you know, seemingly believable hoaxes that have been able to propagate a lot more because of that. And so, actually, this graphic down here on this slide is the star, which is, I guess, a magazine in India that picked up the Rick Astley story and ran with it, as if it were actual information. So... What was he doing in Berlin? He wasn't Rick Rowling in Berlin. Well, his age was 43, I thought. I thought the Germans hated Rick Astley, too. Yeah, Hasselhoff, now there would be people crying in the streets. And then also just sort of another point to that, please stop Rick Rowling. Just stop. It's not funny. 18 months ago, it was funny. Okay, I mean, we said it died last year at DEF CON. So, you know, hopefully it is completely dead. And we suggest it's an alternative lava rolling. And you'll see what that is here if you're not familiar. Which I'm sure is half of you probably are. Really, the entire goal of this talk is just to propagate that. So, last year, I have... Okay, I might just have to show the picture. We were talking about... Yeah, sort of talking about last year related to social networks about people's information that gets exposed in ways that they don't expect. I was talking with my coworker and I said, hey, we're doing some hacking on social networks. And I said, hey, do you have a MySpace page? He's like, yeah. So, he gives me his MySpace page. He adds me as a friend. And, you know, I didn't even think about it. You know, I didn't go look at his pictures or anything. I mean, I see the guy every day, you know. So, about a month later, I met Sean's house and we're working through some of this stuff. I'm like, yeah, you know, my coworker, you know, added me on MySpace. And I start looking through the pictures. And I see... Oh, his face isn't covered up. The... That animation gets me every time. It's like, oh, yeah. So, there's this picture of him with this caption that says, does this dress make me look fat? And I could not quit laughing. And I'm like, oh, I'm so putting that in the presentation. And then I thought about asking him about it. And I'm like, nah, it's easier. It's better to ask for forgiveness than for permission. And I just never told him about it, right? So, I never told him. And about a month later, you know how you use MySpace. And it says... And it shows your photos. And it shows photos tagged of you. And this one came up. And as I moused over the picture, the crotch area said Nathan Hamill on it. I'm like, oh, my God. I'm like, what the hell? So, I talked to him. He's like, oh, yeah. My friend said, hey, I saw that picture of you in drag. He's like, yeah, I have it on MySpace. He's like, no, I saw it at DefCon. And he's like... So, he decided to silently tag his crotch area with my name, which that kind of leads to some of the bigger things, too. I mean, tags, the correctness of data, all of that is user-generated content. And he had the ability to make me look like an ass. So, I had the ability to put this picture back in our presentation. So, another kind of nifty thing with aggregation and integration and things like this, I don't know if anybody's sort of familiar with this, but about maybe about three, four months ago, there was a HTML injection problem. So, HTML injection versus sort of XSS, it was like dumber than XSS. You could put any tag, anything that you wanted into a rebate form on the McAfee website because security companies rock. And so, it was actually getting used to propagate some malware, so that was awkward. But... What, McAfee didn't catch malware? What? With the next dat, they will detect it, yes, actually. And also disable Win32. Ooh, rocking. So, what was cool about that, besides McAfee looking dumb, what was cool about that was that there was this article on ReadWriteWeb, which is this sort of Web 2.0 auto-philatio website where people talk about how nifty the internet is or something. But anyway, they had a tutorial on HTML injection where they explained sort of what it was. And they had these snippets in there, and if people didn't know sort of Web stuff, if you want to put a code example or something on a Web page, you need to escape out sort of the tags. So, it's like and LT, semicolon, and stuff, right? To show that code example, but not have it actually be the code. But it's like, here's what URL injection would look like. If you were to do this, then this would happen. It would redirect you over to this site, right? So, the New York Times carried that story by syndication. So, they had an RSS feed to ReadWriteWeb. And some developers handling of, you know, some XML parser, you know, gone horribly wrong somewhere, parsed those tags and actually then the HTML injection example on the article about HTML injection did HTML injection. So, everyone who read that article, when you went to the New York Times, it then had a pop-up that went to the ReadWriteWeb story about it. So, what's kind of interesting? They probably thought it was a feature. Yeah, there was a pretty cool, you know, little pop-up ad for them. But sort of the larger point of that is, and there's been some stories about, I don't know if people know the BeTwittered application. It's like a Google gadget. I don't use that stuff. But it's a Google gadget that goes on your, like, I Google page. And there was an XSS in the app itself, right? And it didn't work on the app. So, it was like if you changed your Twitter name to script alert foo, right? It didn't work in Twitter, and it didn't work, you know, if you went to some other client site. But in iGoogle it did. So, it XSSed you, you know, in your iGoogle. So, the point of that is all of this integration then creates the shared exposure. And sometimes the way input gets handled on one site, when it gets aggregated over, it might be handled completely differently. So, even if you're not exposed, you might still be exposing somebody else. Speaking of which, the shared exposure? Yeah. So, is everybody starting to get a good idea of just the broad scope of user-generated content? Because, typically, if you ask somebody about user-generated content, they're going to think of photos, maybe uploading some music. But it's really a much larger issue and a much larger problem. Homemade amateur porn, as well. That does qualify the record. If it's shared on the internet only. Otherwise it's not. So, what we're getting into is this big social creature called the web. We all share a bunch of information. So, the web is really becoming a collection of user-generated content. So, with many sites aggregating their functionality, it's all about attack or return on investment. So, if you have... You don't necessarily need remote code execution to attain your attack. So, if there is a goal that you have and there is a shorter distance to that goal, then it really doesn't matter if you have brilliant vulnerability that you exploit that took you 10 months in and you've just been banging away on it and then you get pissed off because somebody patches something and then you have to go back to the drawing board. So, some of this stuff is much easier than that. So, on attack or return on investment, the point of that, what I think about is if I want to propagate malware, links, URLs and stuff, that's a lot of the game. You're going to put it in a Rick Astley video? That's a good place for it. That'll teach people to Rick Roll? Only flash to the other day. But friend feed and all of these aggregation feeds that people use to annoy the living shit out of everybody else who follows them on Twitter and Facebook by publishing the last 15 websites they went to or whatever. Your credentials are shared across five, six sites. That's the most efficient way to propagate links and URLs. Sort of along the same line on Twitter, they recently added the trending topics section so you can kind of see what, I don't know, Britney Spears, whatever it is that everybody else is putting a hashtag around. You're actually seeing people use that then to propagate malware and do SEO kind of things because they just ride on top of that tag knowing that a bunch of other people are going to click on that. So, it then gives them an ROI. So, we'll get into some more of the technical details of attacking APIs and what you can do since the web is becoming this more social animal, we're kind of conditioning everybody to think of legitimate software as kind of having malware tendencies. So, in the past, malware was the only stuff that kind of phoned home and stole information from you and everything else. Now, it just doesn't even ask your permission. It just says, hey, I need to go check this license file or hey, I will help you out by letting you know when there's an update. So, we're kind of conditioned to this behavior of thinking of legitimate software as taking advantage of malware tendencies. And on the web, with everything becoming more social, the kind of blended threats. So, using a social mechanism to implement a technical attack is much easier now. Oh, I guess I got a little bit of... No, that's okay. I was wondering where that slide was. It was like, I hope it's sort of right there. Yeah, sort of along that point is things like Google APIs and Amazon Web Services. Those are basically this giant JavaScript sandbox that half of the sites you visit sort of run in, which again becomes kind of interesting. You can't log in or do like half of the functionality on a lot of sites anymore without allowing, you know, GoogleAPIs.com, right? Unless you want to know how many characters you have left on your Twitter. If you've got Google APIs, you won't be able to see that. I can't unfollow anybody on Twitter, which is very important to me, unless I can get to GoogleAPIs.com, right? And the idea of that, again, is that those in the Amazon Web Services and all these other shared site APIs then become this kind of conduit through everything. It's kind of interesting. Okay, let's talk about your portal into the Web world. Browsers have become more than browsers. They're not just for browsing content anymore. Let me show you something really scary. This is Opera Unite. Has anybody ever heard of it? Does anybody here use Opera? One person, that's about what we thought. How many of those people also work for Opera? Yeah. You can't actually nominate yourself. So this is Opera Unite. And it is more than a browser. And, you know, the thing about this is, I was like, oh, maybe you just came out. I'm like, this is time to find some really cool vaults. Unfortunately, the damn thing wouldn't work in any operating system that I tried it on. But if you look, there's this thing called The Fridge. The Fridge, a fun place for people to leave notes on your computer. There is no fun place on my computer where you can drive by and leave me notes. Send me an email, please. So you have file sharing functionality as well, because people are really great at determining what on their system should be shared. Hence the location of Obama's safe house, ending up on LimeWire. And also, too, it has an embedded Web server, because we've never had problems with Web servers before. Yeah, so you know what this Web browser really needs is it needs some peer-to-peer file sharing in a Web server. That's probably coming in 2.0. That's the only thing it's really missing, right? And again, sort of the point of that, too, is so much of what we do is in a Web browser, and so the response to that is to build all of this other kind of functionality that's then increasing sort of attack surface, right? So how many people here use Firefox? That's about what I expected. We love you. Out of all of you people, who has heard of Jetpack? Do you work for Mozilla? Well, I know Greg does, because he's seen this talk already. So Jetpack is an addition, is something that's coming out from Mozilla Labs, is something that they're working on. And kind of in the description, it says making extensions for your browser as easy as writing HTML. So now we're going to give all of these morons that can't get it in the first place, on your browser. That's exactly the kind of thinking that gets us into problems in the first place. No word yet on whether blink tag support will exist. So you can have like blink tags that then integrate with some plug-in on your browser. Yes, and after seeing that, I saw a Twitter message come by, somebody I wasn't following, and just said, hey man, these guys are bagging on Jetpack, man. It's not even out of development yet. It doesn't have to be out of development to be scary. It can be scary in development. It's really scary in production. How many people here use Safari? You probably shouldn't, but okay. Stop it, stop it right now. If you're going to use Safari, please don't use top sites unless you may potentially want to be attacked. So this is Safari top sites, and somebody told me that it doesn't send headers. That's actually incorrect. So whenever you do a control T or whenever you open up a new browser window, what ends up happening is it sends a bunch of requests to refresh all this content, and I'm sure Apple started thinking ahead and they're like, wow, this could be really bad, so let's block Flash and let's block JavaScript. But that kind of assumes that that's in your strategy. Since it sends headers, it means it also sends off data back to the application. So as you can see, if there is a method to get a malicious page, even a social method, right, to get a malicious page on your top sites, you can have more top sites than these. So it makes you ripe for cross site request forgery, which is really bad once you see the monkey fist tool, so you might not want to do that anymore. So if you're going to use Safari, please don't use top sites until they fix the header problem, if they're going to. How many people here use adult friend finder? This is kind of an example of kind of bolting on problems. And yes, and every time I talk about this, everybody's like, wow, you know a lot about adult friend finder. Well, when you spend 10 hours a day on a website, you become really familiar with it. So it's hard to see in the screenshots, but what this is is an error message that popped up that gives you the name of the admin site, where all the admin functions come from on adult friend finder. I had to find the videos that I tried to find, I tried to find ones without people in them, because the ones, some of them were very bad. On the other side here, they had kind of bolted on this chat infrastructure. So it allowed you to do instant messaging and chatting and everything else. Well, when I started taking a closer look at it, I realized it was just jabber. So I opened up iChat, and I started trying to chat with people. And what I found was, is that you can actually run a chat bot from this. Because if you wait, it's just a jabber client, you could script your responses, and that's what a lot of people are doing. Like a lot of people are trying to get you to go different places and whatnot. And that's why they don't contact you first. They create like this profile of this smoking hot woman and they wait for you to connect to them and then they start this conversation. So moving on before this gets any more awkward for Nathan. So like the, yeah, kind of the larger point here too is again, a lot of times where these exposures come in on different sites is from bolting on kind of new functionality on top of something. There's also, I think, a live journal and a couple other sites have added chat functionality and bolted it on in some kind of way. Well, they use a flash client. Flash chat, that sounds super. Not going to have any problems there at all. Well, flash chat on an adult friend finder. What they do is they set a policy through flash that allows you to restrict how many characters and everything you use. If you just connect to the service, you can bypass all that. You can bypass all of their little security stuff. So the exposure continues and we have many different ways to expose site functionality. Everybody probably Google is the most popular right now. Yahoo has Yahoo OpenStructure or Yahoo OpenSite and there's many others. Google has some new stuff coming out that haven't really had a chance to take a look at yet, but they're kind of pushing OpenSocial to be more than just for social web applications. They're pushing it more to be a total site API. Your bookmark can now friend my bookmark and that's... And that is just hot. It's awesome. Speaking of hot, this is the new way to consume services. So every site that goes up that wants to maintain any kind of popularity cannot just survive on its own anymore. It needs to have integration. It needs to allow you to be able to consume services on other pages. So pretty much every single site out there now has APIs. Oh, another thing about a lot of the way these companies are implementing APIs, they're kind of separating themselves on a different canvas, which that's not really a good idea because they're putting everybody, even though it's off the main domain, they're putting everybody in a separate subdomain, which means that if you make an application for any kind of site, it doesn't have to be a social network site. If you make an application and push it, you can call built-ins in other people's applications. So for some weird reason, somebody was setting a cookie in a social network application or any other type of application, you could just call that same value. Yeah, like I say, we've hit on this pretty hard, but anytime you're able to get into that same sandbox, by definition you can get anything else running in that sandbox, any of that functionality, with the exception really of people filter inside their APIs certain calls, but that's kind of like the input filtering game with cross-site scripting, there's always going to be some input that's been missed. So API stacking, at any given point in this structure, you can have vulnerabilities. So a lot of times, you may have an aggregator that also exposes an API, so you have to assume, if you open yourself up for an API to have your site services be consumed, you have to understand that everybody can consume those services now, because you can't really stop another site from opening up an API and then allowing them to consume your services and the endpoint be by proxy. Here's an example of kind of anonymizing an attack through APIs. So we have a lot of APIs that call functions that allow you to get past browser security restrictions. How do we know this? It's documented. So if you just read the API documentation, it'll say this function allows you to get past browser security mechanisms, because they don't let you make calls for content off of a domain. Well, there's a reason they don't do that. Gosh darn you, same origin. I'm going to find a way around you so I can make this application work. So kind of messing around as much as possible. And this is kind of an open social thing. You can call the proxy function directly with absolutely no credentials. So for as long as you can make that URL, whatever, however much length you can do, as long as it's properly encoded, it will make the call for you as long as the request is proper. So in the example of MonkeyFist, which we'll get to here in a little bit, you could put your ID on a chain of these open social proxies and go right through them, and the endpoint has no idea where the request really came from. So, continuing on the open social path, apparently nobody ever thought that filtering out 127.001 on any API proxy call might be a good idea. What this is here, this is Hi5's open social implementation, and that page right there is the homepage of the developer box. So, and this works for whatever port number you want to throw in there, and I will let your imagination fly with that one. And I wrote a tool in like 10 lines of Python to enumerate this, and that will not be coming up today. Another thing you can do with these is you can get one site to attack another site or something like that. So, there's protection mechanisms, and I talk about open social a lot because that's just kind of, I didn't have to go anywhere else to look for examples of this, they kind of had everything really needed. So, is there anybody who works for Google in here? Thank God. Oh, you're just not admitting it, that's cool. So, Google did think that it was a bad idea to continuously go redirects forever because that would be dumb, right? You'd have this big loop. So, they're like, you can't follow more than seven redirects because that would be bad. However, if you call the API itself, so if you did 127001 and then called the request again, it would just continue to go and go and go and go and go because it was a new request each time. It only followed one redirect. The same thing can be done for something like a triangle of death attack. It's a super sensational term for something that could be like, oh, that's just kind of okay. But, we've been in the security industry for a while. So, we're working on a jacking name for this. This is triangle jacking. API redirect jacking. So, you could potentially get one site to attack another site and so on and so forth and hit a redirect and start the loop all over again. So, it would look like a new request each time. So, each time it's called, it would look like a new request. You could light off the more resources you consume and so on and so forth. So, essentially, my space is API attacking High 5's API, which is then attacking LiveJournal's API. Dude, why are you attacking me, bro? Where's the love, man? Okay, and now let's break some stuff. So, how many people here are familiar with cross-site request forgery? Okay. How many people here think it's bad? How many people who don't know about it but still think it's bad? Thanks. I think people think it's super and awesome. Okay. Now, if we make cross-site request forgery even more dangerous, how many people would think that was awesome? Okay, thank you. Sorry, now we're just being good. It's early in the morning and we're trying to keep you awake. So, I mean, kind of the larger point of this, this is sort of like this old vulnerability. I mean, this has been understood since, really, actually, the Pete Watkins actually, it's just a post-debug track, but that was kind of the first person to really just nail it down on what it is and it's not actually the confused deputy and if you know what that is, that's actually about mainframe stuff, so there, because everybody always says it's that. And if you even care about that, then you're a dork like me. We don't care about history, we just want to break stuff, man. But sort of the larger point of this is kind of where we're headed with this is that it's very tough to audit for, you know, usually sort of automated applications. It's very tough to identify there, so we think it's fun because we can actually sit and find things that are new and nifty. The guys that have the talk after us, I think they have like what, like 97 CVE IDs from the last year or so, for different C-SERF bugs. So it's a lot of fun to look for. Kind of our point is that it's typically described as sort of a static attack where it's like well-known values, known parameters, and we did a lot of stuff last year. People have been doing that since the early 90s of action equals logout on some website or send funds with your PayPal account number, whatever it might be. Usually, when people think of being able to do cross-site request forgery on a per-user basis, so it's sort of something that the parameters that you're C-Surfing are specific to that individual request, that's usually something you think of as being just for the payload for an XSS. One of the classic examples of that is the SAMI worm. The way that SAMI propagated, it was sort of combined, actually a bunch of things. People are still trying to figure out what the hell to call it, but a big part of that was it was XSS that then used the JavaScript to enumerate people's usernames that were on their top heroes list or whatever it was so that it would know where to insert itself. And so that's kind of a dynamic way of doing C-Surf. That's typically only part of cross-site scripting is the way most people sort of think of it. Yeah, it's really a silly attack. I broke a Motorola router and I never got a CVE for it because I said it was dumb, but Motorola does not have a sense of humor. Neither does AT&T. And sort of with a silly bad or really, really bad, obviously Grossman and a number of other people have spotted bugs in things like Gmail using this, the ability to reset people's passwords, disabled firewall rulesets. I think somebody here at Defconn, I don't know if it's been today or if it's yesterday about doing a talk about the two-wire modems, the AT&T modems and there was actually one of the largest sort of mass C-Surfs that happened there was a bunch of people in Mexico via phishing email that then changed their DNS settings so that they would go through malware sites and stuff like that. And again, just be a C-Serve. So anything with a web server can be attacked, whether that's the local host, local network, or websites and applications. And we're just going to go past this because we want to show you something cool. This is Newsweek.com and I'm going to go back for a second. This is Newsweek.com and this is still live so be nice, please. And we used MonkeyFist to pull this attack off and we'll talk about that in a second. I want to say one thing because I thought really hard about that, Link, and it doesn't show up in the video long enough is sort of our example scenario here is you'll see there's an article that somebody logs in a Newsweek and then clicks on it and the article title which I thought was pretty nifty. Yeah, you thought it was nifty because you wrote it. Exactly. It was funny. It was an article, Link, that went to like Bitly or IsGood or something, Link, and it said, Sarah Palin Resignation, Link to Nude Photos, question mark. So that's kind of the our bait in this scenario. So here we go. This is Newsweek.com and as you can see, we're about to log in and we have Bob logging in with a password of old password. I am so smoking on the laptop, man. Just fast. So we're going to log in and we're authenticated. So here's the link on Reddit with Palin Nude Photos and of course what? Are you watching Benny Lava? Did we just get Lava rolled? We're trying. Last time we bring it up, I promise. So what happened was there was when that was clicked on, a dynamic page was created with a hidden post. The post contained the password reset to a value of our choice and now we get to see Benny Lava walking up. Prabhu Deva actually is your guy's name. So we'll go back and try to log in again with the old password. We're going to hurry it up a little bit because we want to explain some of the more complex scenarios. But it makes no difference. As you can see, the login failed. So now we're going to log in with Epic Fail and that's full of win. So that works. So now let's talk about something called dynamic cross-site request forgery. So there's a certain amount of cross-domain referral leakage that happens, especially when you put tokens in the URL or you have these sort of disjoint tokens from sessions, right? So there's a certain amount of those things. Lots of complex examples get ignored when you're talking about standard cross-site request forgery. And we have diagrams of this. So if you're leaking what you can do is repackage that token value up into a valid payload. So something that was thought of as protected against can now be exploited again. And if you're crazy enough to think that the session ID is random, so why not use that? That's really bad because that means you can make any request on your page if you can pull the full session data. Yeah, and sort of the larger point is just there's a lot of CSERF out there that's not sort of these static values. It may not even be that there are CSERF tokens which are sort of these dynamic values that are around it. It might be things like the username as part of the request that you're trying to forge. And you can't get that without, you know, dynamically sort of constructing requests on the fly for each of these. Yeah, some things may be, you know, may require extra bits of information that an attacker may not have. And now they have the ability to get that. So typically thought of a higher bar. And for us like a big part of this was that when we would talk to developers and point out like those kind of bugs, the standard answer that people would say was, oh well, you could really only do that if you had like an XSS. Right, so that would be harder to do. How else could you do that? And sort of our point is there's a lot of other ways to obtain those values besides just via XSS. You might be able to log into the site and use the same token for different users. You might just be able to enumerate those values, like we said, from the referer if there's a link to offsite content. And so yeah, we sort of wanted to automate the process of these complicated C-SURFs that were a little tricky. And also kind of related to that if people that follow the sort of Web Security world about just a couple of weeks ago somebody did a proof of concept of brute forcing C-SURF tokens as well. We sort of think of that again as being kind of a dynamic attack. So in that case what they're doing is running a piece of JavaScript code that sort of runs through your history your browser history to try to guess your tokens and then those can then be used to replay an attack. So here's kind of a simple example of a dynamic C-SURF. It's basically a really complicated example. It could be really complicated, but basically it's one payload to rule them all. So you can do you can run one basically attack site and handle attacks for multiple domains. Go ahead. Enter monkey fist. It was never meant to be what it became, so don't beat me up too bad on the code changes. Basically it's a tool that helps you pull off dynamic C-SURF attacks and all of the scenarios that we talk about are implemented in the tool. The most complicated is the fixation attack which actually makes requests and fixates data on to a user's session and we will get to that. But it hides attacks through hidden posts redirects and it refreshes to a legitimate destination. So kind of how you saw we clicked on the link earlier and we ended up on a legitimate, you know, YouTube page. That's kind of how it works. So there's like this series of different you know security douche bag sphere, you know, a set of opinions about URL shortening services and I don't know that they're bad in and of themselves but they do condition us to be really stupid about clicking on things that we don't know exactly where they're going to go. And Twitter's a fall for that. I fully believe Twitter. So I mean I recommend using, there's like a lot of different Firefox plugins that will do things like expand those shortened URLs. What we think is kind of a neat payload is to use a, you can use URL shorting service. We can do C-Serve in the middle of that and then again so we take you to a YouTube video or something it looks like it's performing as design and that's that one little request runs you know in, you know, one second while you're in the middle of clicking on the link and you're not, it's not typically something people are going to spot. And it's live right now so if you go to Hexhick.com for Slash Labs you'll see the stuff from Monkey Fist. And it will it will steal any session data you want it to do that may end up in the refer and repackage it into a valid payload. I'm just going to go through some of the, this is some of the options. Yeah and so essentially so you set up the site that you're going to target. You set up the destination URL you want to send to and then you can define these different values that you want to pull out. Yeah the site basically is what it's going to match where the refer is coming from so it knows which payload to pull out of the file. There's a default payload which kind of makes it a little sneaky so if you're trying to hide and attack or requesting spacer.gif and somebody gets wise and they just point their browser to your domain and ask for spacer.gif they're going to get spacer. a real spacer.gif so they may not be able to know exactly what's going on there. And that's because they're sort of the refer is the trigger for the payload so unless you see a specific refer it's just going to respond with the default. And the destination for the meta refresh so here's an example what the XML file would look like and in case there's some confusion about that I got a couple of blog posts coming up and the link's in here and you can read about how to set it up and get it going. So a couple of examples. This is a dynamic redirect attack so the user would make a request for content somewhere on whatever page they're on makes a request back to another site that is hosting MonkeyFist. It will take all of the kind of tokenization whatever data you told it to take out of the refer send back a redirect with a 302 the user's browser will then send the payload that you sent it back to the legitimate site. So it's a very simple example. They get more complicated. And really the larger point is just again these are per request forgery so each time it's sort of constructing that forgery based on data that's getting from the client request. So here's a post construct so basically in case there was some confusion about this when we talked about it before the user request content. So if you're leaking full session data in cross domain fashion like say you put J session ID in the URL that then hits something on the page which sends data to the tool. The tool says okay I have a payload that tells me to construct a post and the tool will actually construct a post request with all of the session data and send it back to the site without the user's browser interaction so that's how we can create header values. So if we wanted to add our own cookies and stuff like that we could. And actually kind of what's nifty is it's sort of a quasi same origin bypass because the tool especially like the token stealing scenario where it's going out and pulling stuff down, it doesn't really care because it's not doing JavaScript. It has you do a post with the data that it gets. The funny thing is this is exactly how the APIs that were exploited earlier were doing it. So okay so here's the dynamic page. Apparently we blabbed too long. Something that we thought was kind of cool is I would look at the freaking Wikipedia article on C-Surf all the time and it would piss me off because it was just really dumb because it talks about just image tags and things like that. Like I said, and the things we're talking about have been understood by a lot of people in web security for a while but it's all the papers and everything else sort of defined it as that. So it just kind of piss me off. So we decided to edit the C-Surf article on Wikipedia via C-Surf so that would be kind of cool. So here we're going through Wikipedia as you can see forging requests and then you see prevention mechanisms. So we're on the page and we want to go buy a truck. So we're on Craigslist. Craigslist St. Louis in the Jefferson County section if anybody's from St. Louis, you'll know. So here we go, we're going to click on the truck and it says... $100 truck man! There's a shortened URL right there so when you click on it some magic happens and here we are at what? What? So we have some more Benny Lava to explain what happened. We'll refresh this first and show you the payload. As you can see it's been edited, there's been a new section that says other approaches to C-Surf. So we kind of figured this is the best way to add data about this. And this was also the most complex... Thanks! This is also the most complex example of using the tool because there was many things that had to happen behind the scenes so what we did was take something extremely complicated to pull off and make it really easy. Yeah, and so to explain, in the case of that C-Surf what's funny is there's a CBE ID for this. It's already out there but they sort of fixed it for authenticated users but not for anonymous ones and so the thing about it is there's all these different values in the post if you do a post to Wikipedia and you look at it there's all these different token values that you need and all this other stuff. It's mainly not there as a mechanism but it does kind of thwart some of the attacks because you have to have those values for the request to be valid. It is funny. We watched it about 80 times in the past week. So what we had to do was request that data on our own without the user's interaction and then package that up into a payload and that's kind of the problem of all these disjoined session values. Like the tokens aren't joined with the session IDs that are issued by the site. So when that happens and it happens in many different places you can go look for it yourself. You can create valid payloads by just requesting the data, getting it back parsing it, putting it into the request and sending it onto the user's browser. I just wanted to put out something kind of nifty with that is that the church of Scientology has been banned for making edits to Wikipedia because they've been inserting bias into it but the way that they did that ban was just sort of their IP ranges so essentially if they put like a little link on their website that went somewhere, they could sort of have billions of anonymous people over the internet to do their edits for them. So no consulting fee required. You can cleanse me of Tatens or something later. So here's what the payloads file looked like for that attack. We really don't have time to get into it but as you can see it by adding a couple of values it made the attack really easy which would have been really hard before. The one point we would make about that is this is how to fix it. You don't want to care about fix it. Go look it up. This is usually when everybody gets up and leaves a talk and here's how you fix the problem and then everybody just gets up and leaves. Don't worry, we're not going to bore you with fixes. But yeah, the mitigations for CSERF are well understood. Really like the things we're talking about it's not sort of a bypass that OMG we broke the internet. We'll try null string terminators in it and see if that works. The thing is that in order to mitigate for CSERF you have to do a whole bunch of stuff right and most people do like most of it but not all of it. So you look at one site and maybe they check refer. You look at another site and maybe they map tokens to one token could be reused against multiple users not mapped to sessions. It only takes once. If you leak that token in one spot it's game over. Yeah, and again if you're issuing tokens and CSERF protections in JavaScript don't assume that same origin is going to help you. Thanks for listening. Yes, and bug fixes. My blog is neohaxer.org so if you want to have some examples they'll be up soon. MonkeyFist is on Hexec.com and our talk will be uploaded there shortly. Thanks. Thank you.