 Greetings everyone. My name is Russ McCree. Thanks for coming, sticking around. Mike Bailey on my right. We are unfortunately for some of you guys who are already here talking about CSERF very specifically and very targeted attacks against multiple platforms. There's certainly some crossover from the fine performance you saw just prior to us, so we apologize for that, but our mission with this discussion is more to point out how very specifically this attack can be used across so many interfaces, so many platforms, so many places, and how incredibly inherent it is to most web apps. So there is some repeat. I apologize for that, but I think you'll find it. We'll try to skim over those parts. Yeah, exactly. We won't tell you how to fix it, we promise. We won't tell you our employers, but in case you know, please don't attribute any of this to them. Carry on. All right. Basically the gist of this talk is that CSERF is bad stuff. It's a very underappreciated vulnerability, and it's all over the place. Because it usually gets rated as a pretty minimal issue, it almost never gets fixed, and that means that we have these kinds of holes all over. Spacebar. Spacebar. Okay. I'm not very good at this computer thing. All right. So in case you didn't know, in case you weren't at the last talk, basically a cross-site request forgery is making a user do something that he didn't intend to do, usually against another site. Okay, always against another site. Well, all right. If that user is an authenticated user on that other website that you're attacking, you can use it to escalate privileges and perform actions that he didn't intend to do. There are other attacks you can use that don't really have anything to do with the session or the authenticated user, but we'll get into that later. Yeah, one of the key concerns again is that, you know, okay, surprise, surprise, 90 plus percent of websites have vulnerabilities. Yes, we know. The reality is, though, certain things that can be fixed, certain things that can be done to prevent are so rarely done, and when the impact, in particular, to CSERF attacks is so high, we believe that it really actually borders on negligence, and while that may be somewhat counterintuitive, we think that there's a responsibility here in site coders and providers that really, for reasons of millions and millions of people at risk, we think should be fixed, and Mike, in particular, has got some very, shall we say, some exemplars to prove that point. So we have, I would argue, it's never ending. We're going to try to limit what we talk about here today. There are some things that we can't talk about that will be coming out, say, next four months, probably about accurate. Well, I won't even describe what they are, but suffice it to say, the impacts are larger than imagined with regard to anything we're going to show you today, but nonetheless, I think this stuff proves the point, particularly when it comes to wormable stuff and or just flat out, in essence, compromise of a system right up to admin. Alright, let's roll this move along. Okay, cross that request for a drink. It still works. Alright, we're going to show you how to prevent it. We'll breeze through that because that's not interesting here, but first of all, we're going to show you what you can break with it. Alright. We get this one all the time when we try to report stuff, and it's like, well, look, it doesn't matter because somebody has to do something stupid. Well, yes, but if somebody does something stupid in the context of your application, you'll feel your problem, and they obviously don't care. So everyone clicks links, yes, we know. Mike can tell you in particular to the extent that somebody obviously clicked a link, i.e., the CEO of Strong Webmail, and it cost him $10,000, which Mike paid for this trip with. Explain, that's probably worthwhile. It's worth a beer, too. I have beer. Thank you, Trey Ford. So my mom's going to watch this video later, and she's going to be pissed. Mike's additional skill is that he actually brewed this beer. Alright, so Strong Webmail. This is a fun story. I was just sitting on my computer one day, and on Twitter, some people were passing this link around to StrongWebmail.com. They were having this contest that if you can hack into our Webmail, you get $10,000. And a couple of us were just passing the link around joking about it, like, yeah, that's not going to go well. Then Lance James, if you're on Twitter, he's XSS Exploits, he says, you know, let's go ahead and do this. Let's sign up for an account and win this money. And I'm like, okay. So Lance bankrolls it. He pays the $5 to set up an account. Thank you, Lance. Yeah, and once we set up an account and logged in, within the first minute, we found a cross-site scripting holes. Where were they going? Alright. Once we had the cross-site scripting holes, it was just a matter of coding a payload and figuring out how to get it to execute. We weren't sure if the CEO of the company actually checked this email account. We figured it was probably just a dummy account set up because we didn't really think they were playing on paying. And so we sent in the cross-site scripting hole we found that it involved injecting HTML into the subject line of an email. And when he'd view it in the email web mail client, it would execute and own his account. We had to figure out how to get him to look at this email because we didn't think he actually logged in. So what we did, we set the subject to that email to, we said, hey, we think we've won. Who could resist clicking on that? So we're watching the logs as soon as he hits that, the payload executes, and we got all the information we needed to win our 10 grand. So while that's not really a cross-site request forgery story, it's a fun story, and it demonstrates our next point here. Quick tools, the thing about tools is you can do this either manually, whatever you want, any kind of proxy mechanism. I prefer tamper data. You like SAC bar, for IE heads, there's Fiddler, all the same thing. See the parameter, break the app. Like the McAfee Secure app. Sorry, James. McAfee Secure, this is one that hit, it was in the news I think in May. I published some cross-site request forgery holes in the McAfee, actually it's McAfee I found out last night. You pronounce it McAfee. But I found some cross-site request forgery holes in their McAfee Secure application, which you use to scan websites and find vulnerabilities in websites. So I was using this application actually, and I noticed that it wasn't, we'll get into the protections a little bit later, we'll go through that quickly, but I noticed it wasn't protecting against this stuff. So I coded it in a payload and I set up an exploit so that if you hit my evil website and you're logged into their account, I add myself as an administrative user to your account and then I can scan your website for vulnerabilities. And so it's just kind of ironic having that in the McAfee Secure portal. I actually have screenshots from it. Basically I just described what happens though. Every user set up on this account, you hit my website, has an iframe, I've got the URL there, the basic idea is add user dot whatever. It loads that up in an iframe, adds my user, and shoots me an email with my temporary password. So this is completely blind and zero knowledge attack. If you're logged in, I get an email with an account password. All right. Obviously the McAfee implications are many and scan whomever, whenever. However, it gives you another subset of vulnerabilities to play with. Linksys, this one was something that I stumbled on because I actually have this device at the house. No, it's not available to the internet. And ultimately when reporting it in a brand new WRT-160N internal device, Linksys said, and I quote, I apologize if you guys are here anywhere, I can't reasonably prevent CSERVS without bogging down our code. The compromise we made here is to have a timeout on the web interface so users are logged out after 10 minutes of inactivity. We also advise users not to click on suspicious links while logged into the web interface or close the web interface as soon as they're finished completing the router. They claim this language is on the site, I've not seen it, I did go looking for it. And obviously none of these mitigations are particularly useful when it comes to breaking things, which I will show you. So, here's logging in with my known good account. Hope you guys can see this within reason. You can see that my current password is, I'm a doofus. And of course we'll let me in. And there we are. So in classic attack form, well first the form itself, it will ultimately force the account to change its passwords to really doofus. And we'll do that through the classic social engineering attempt. From your friends at Linksys, please log into your router and upgrade now, which inevitably somebody will always click. And you'll find that in fact, now if I log back in as if I were the attacker, I'll be doing so with the account that the CSERF script forced. Which isn't again really doofus. Now this is an attack on one network device, one router. When we started looking at this kind of thing, we found out that almost every web application we look at has these kinds of holes, especially the ones that are sitting on your internal network. And everybody thinks my internal network's safe, nobody else can get to that, except for your browser can get to it. So, I think we have a few more examples, other devices that sit on your internal network that are vulnerable to this kind of attack. Netgear on my, I know, much on HATES blogs, I understand. On my blog, just prior to DefCon, I did a Netgear attack. I won't bother you with it here, but it's very much the same thing where we were able to force the remote management interface on where typically it's off by default and immediately change the access port as well in a fashion that had made it somewhat visible, not only to me, but to any bots going by. So, somewhat interesting. Other infrastructure devices though, I mean think about it off the grid. It's not just stuff that's available to the internet, right? Think about it from an intranet perspective and the, shall we say, you know, evil attacker on the inside. Who uses Ubuntu? How many of you use transmission for your BitTorrent client? How many of you would tell me if you did? This has actually been fixed in the current version. I don't know if it's been fixed in the current version in the Ubuntu archives or in there. But I was talking about this a little while back on my blog. For some reason, transmission has a web interface built into it, the latest version of it does. It just came out recently. And this web interface is enabled by default, but only accessible to the local user. So I honestly don't know why this is even needed because the local user obviously has access to the regular application. But at any rate, the local user can access this web interface. This interface is vulnerable to cross-site request forgery. So if you hit my website, I can force you to create requests to your own application on 127.0.0.1. And it will change, I can change the directory, you're downloading all your files to, and then I can force you to download a file of my choice. So I actually was, while I was testing this, I accidentally changed the directory to my main root directory, and I downloaded a file that overwrote the whole thing. So it works. It works really well. And I'm glad I have backups. Self-surf. All right. This is a fun one. ESPN.com. I think that it's a very highly ranked traffic site. I think it's like number 14. I don't know if it's in the U.S. or overall, but is that overall? Okay. Until recently, they were vulnerable to both HTML injection and cross-site request forgery. This makes this little perfect storm for an exploit, that you can have a site performing cross-site request forgery against itself. So it's not really cross-site, but same principle. And what you can do here is you can actually worm this thing without any client-side scripting at all. So if you think no script is going to save you from this kind of attack, you're dead wrong. Basically, by creating these requests back to this site itself, we can add this HTML code to any profile of any user who views my profile, and we can propagate this payload across the entire site. So this one's someone interesting. It's not that broadly used in application, but where it's used is kind of what's fascinating, because it includes things like MCI. It's very European in nature. Securitas, Red Cross France. And in case you wanted to know anything about the missile defenses of the Bilgin Defense Agency, this is one way you could actually lift the data. They have missiles, apparently. They do have two missiles in Belgium. That's right. Case one broke. So... So just a calendar. They use it as a learning portal for folks to go get training inherent to the organization. But what's rather amazing is that it's vulnerable to CSERF, but it's also vulnerable to script injection as well, so you can then drop all kinds of evilware in there if you wish. Kudos to our friends at XSS.org. I promised I might say hi. And at the end of the day, it's very simple. There's nothing to it other than pushing a frame, pushing whatever content you want into the calendar, and then anybody coming along in the general context of a session, they do not need to be authenticated, can be instantly owned as needed. So obviously, not much good. And then OSCommerce, this one... Okay, so surprise, surprise. Web apps that are feeding customers and websites, particularly for shopping carts, etc., are broken. This is obviously a well-known, perhaps quite obvious, statement. The issue we took with it is the fact that OSCommerce alone, and this is not an exaggeration, we figured current installs is about nine million and change. Unfortunately, again, discovered while picking on McAfee Secure, because literally two-thirds of these sites are branded McAfee Secure. Indicating, in fact, that they might not be. I'm checking Twitter right now. Yeah. Sorry, guys. So this one's interesting, and particularly because of credit card, we're going to work on the admin account. I'm logged in as admin currently, and I will fall victim to an attack. One of the things I want you to see first and foremost is the fact that Fred Flintstone's account does, in fact, include his credit card. Nice. In case you're having a difficult time funding this little adventure, that's a real number. Kidding. So we trick Fred into stepping on board and adding an admin user. Frank is now an admin user thanks to the script we've thrown at him. I log in, as Frank, with my handy-dandy account. I go back to Fred Flintstone's account, which is now visible to me, and I, as the attacker, now own his credit card. So, again, all through very fundamentally simple C-Serve attacks. The thing that's frustrating here is, and I believe Sean in the last talk, is that we walked in with saying this, is that everyone assumes C-Serve's about get, right? These are all post-attacks. These are all circumstances. So when we talked about that, and Mike and I were chatting, we discovered that, oh, no, that means there's another problem. Zencart was forked off of OS Commerce a while back. It's basically the same code. Well, it's been changed a lot since then, but it's built off the same code base. So we found out that it's vulnerable to the same thing. And that gives us another 7,330,000 sites that are vulnerable, which gives us a grand total of 16 million some websites that are taking credit cards and storing data, and vulnerable to the cross-set request forgery. And this isn't a minor vulnerability. I mean, you can add admin users to any of these sites. That's a big deal. An even bigger deal, in my opinion, is C-Panel. C-Panel, if you don't know it, it's an administrative web interface for mass-hosted servers. Let's ask the question. How many people here have a website? Come on. How many people here probably use a website with C-Panel and a hosted provider? You're all lying. Look at you. There's so many more of you out here. What's the problem? All right. The WHM interface, the web hosting manager, it's vulnerable to cross-set request forgery. If you're logged in as an administrator or as root on this server, which people do, because apparently you need to manage your web server through a web interface, if you're logged in as root and you hit my website, or you hit any website I control, I can do anything I want. I can reset your root password. I can upgrade software. I can modify any setting I want. I can suspend, unsuspend accounts, through the WHM interface. That's scary, and that's bad. What's even more scary was the response that I got from C-Panel. Do we have that here? We have a video. We like video. The response that I got from C-Panel was we can't fix this because it's a feature. Apparently they're worried it's going to break integration with third-party billing software, so they can't fix this vulnerability. And so we have literally millions and millions of web servers that are sitting there ready to be rooted, and C-Panel won't fix it. They do have a cross-site request forager protection feature. It doesn't do much. It checks the refers. This is actually, I can't pause it. What it does is it checks the refers of the request that's made to the server, and it makes sure that either comes from its own server, so you can't do it across sites, or unfortunately a lot of people don't send refers. In fact, there's an RSC that states that if you're on an SSL server, you don't send refers. So they have to obviously accept requests that don't have any refer at all in the browser, in the request header. If you're using C-Panel without SSL, you're a fucking moron. You want your video? Yes. Now, there's plenty of other ways to strip of refers if you are worried about this, but the easiest way is just to bounce somebody through an SSL encrypted site. And that's easy enough because there's plenty of SSL encrypted sites that have open redirects on them. There's plenty of them that have other issues. So cross-site scripting, anything I want, I can make this request to your web server and root your SSL server. And in this case, I'm actually throwing a cross-site scripting thing, but that's actually a different demo. That's a different talk. But that was just me getting root access on that server. Before we get into the misconceptions, why don't you cover some of the smaller, more annoying things that were on your mind earlier? Which ones? There's a lot of annoying things on my mind. I know. Amazon, eBay. Oh, boy. A lot of people aren't thinking about it. The classic example of the cross-site request forgery is either, you know, owning somebody's bank account, transferring money to your account, or doing the privilege escalation through an administrator who's got access to something. But there's a lot of sites that just they just take any request you send them and they do things with it. And it turns out you can actually do a lot of things that they don't want you to do. An example of this. Amazon.com Whenever you're browsing through the products on Amazon and you come back to the site later, you'll see all the products you've recently viewed, or a few of them, and they're there to try and sell you more products or try and sell you something you already bought. But if I can make you use that site using, or not view it, but request the site with the cross-site request forgery, next time you come back to Amazon.com, you're going to see any product that I want sitting in that recently viewed items box. And that may not make a whole lot of sense. But with the money that people spend for advertising, putting something on the front page of Amazon, that seems like that would be a big deal. It also works with eBay. There's a recently viewed items box there. If you're using, I'm trying to remember what it was, there's actually a handful of them, but there's a handful of major e-commerce portals where I can actually stuff items into your shopping cart using cross-site request forgery. So if you're looking through your shopping cart and you're wondering why you've got these products sitting in there, you may click on them, you may look at them, and you may buy them later. I mean, if you're looking through your shopping cart, and you may buy them later. Either way, it's good advertising. It's getting the product right in front of your eyes. But there's also the issue, then, of forcing somebody's history to change. If I can manipulate your search history, think of all the fun things I can do with that. Again, I can use it for spamming, or I can stuff your search history full of links to whatever product it is I'm trying to sell. What if it's worse than product? I mean, there's legal implications here, too. That's kind of what we're trying to drive at. If you think about the ability to force somebody's history to basically contain people have been prosecuted based on their search history before. That's exactly right. So if you want to really hose somebody, and something is in particular, certain search engines are vulnerable to the ability to force that. This is a side note, and Russ doesn't know I'm going to talk about this, but he works for an evil corporation. He happens to have your search history displayed whenever you go to their major search portal that just apparently came out a little while ago. It has a search history, and I can stuff it full of links to whatever product I want to sell, or whatever malware I want to sell. I mean, if you want to buy malware, or just download it. Don't know what you're talking about. I will. Misconceptions. So Mr. Sullivan over at Black Hat, is talking about URL rewriting as an option to fix this. I would by no means disrespectfully disagree, but to some extent we take issue with that. Obviously, the majority of the things that people think should fix this issue don't. Thoughts there real fast? We've gone amazingly fast, which is unfortunate. Well, we could just talk later. Where are we going? Where are we going with this? Just basically. Some things that actually do work to protect against cross-site request forgery, and I said I'd get into this later, but a captcha is basically forcing the user to manually do something and do it on purpose in order to make a request. Another... You go ahead and take this one. I'm not thinking straight. You okay? I'm a little bit wired. I had a lot of coffee this morning. The issues around captchas, of course, is that they're most often broken, number one, and often they're two. A captcha itself might be based on a token, and if that token is repeatable, obviously you pass it once, you pass it again, and you're through. It's a very simple, shall we say, bypass and doesn't really work. The most important fix of all is a unique token. But again, how strong a unique token are you using, number one, and are there now, all of a sudden, magically in the last four weeks, attacks that will even compromise you there through CSS history? Do you want to clarify that one? I can clarify that one. Are you clear headed enough for that? Okay, so this is an attack that came out just a lot... I think about two weeks ago. Well, the CSS history hack is a well-known hack in security industry. Basically what it does is it uses CSS to find out what links you've visited before. So it colors a link blue, and then it checks the link to see what color it is. And if you visit it, it'll be a different color than if you haven't visited it before. And theoretically, it's not all theory. You can use this to compromise a cross-site request forgery protection token by just brute-forcing that token and see... You just generate a whole bunch of different options and you see which one works. It doesn't work so well if the token is not hard to predict, if it's long, and if it's randomly generated, it doesn't work very well. So the point I'm trying to make is to make sure that your CSRF validation tokens are cryptographically secure. The final thought on it, too, is that even there, particularly as a DDWRT, that router, no protection in the world was even implemented on it, but ultimately at the end of the day, you didn't even have to be logged into the device because the checks were so insecure. So ultimately, you could via ICSRF attack own the device without any mitigation in place at all. So a lot of it comes back to secure development practices, which we're not going to get into here. And unfortunately, we flew through this thing, so that's kind of it. We can open up to Q&A if you want here. I can have Mike go on forever. But really, it's up to you guys, sir. The reality is unless better development practices are put in place, say again. I'm sorry, you're right, absolutely. So the gentleman said that in particular with regard to things like do-not-call lists for marketing, that the more prevalent web applications become as services for marketing, services for tracking, services for analytics, etc. If they're in fact not coded properly, mitigated properly that then attacks against privacy, you're going to be even more and more stringent. I think really the thing to look at for us is too, what does it mean in the now cloud or SaaS? I mean, there's so many buzzwords now where they're putting everything out in the internet or in the world. And again, I find so often that they're not protected, so it really is an issue. There's a mic over here, so can you pop that mic on, boys? There you go. Good. In inserting browser histories, forcing browser histories into unsuspecting users we have people in this country being prosecuted criminally for the contents of their browser history in part. Mike, would you care to comment about what type of forensic trails you're believing when you're injecting someone else's browser, well, false browser history into an unsuspecting end user? The really tricky thing about this attack is that it really can be completely anonymized. I can inject these cross-site request forgeries any website that I can put any HTML or a deep-linked image in, MySpace. I can put a link in MySpace to an image on another domain. There's no way you're going to track that back to me personally. You may possibly be able to track it back to MySpace, but who doesn't browse MySpace? Nobody does anymore. From a forensic perspective, it's very difficult. In the context he's talking about, it's one of those things where, you know a user executed something and it's attributable then to that user, but if that's not the actual user who did it, because he was forced, the only forensic trail you might have is if the back-end of the, shall we say, the system he's using, the social engineering site, pick it, if they're tracking IP access, but even that's not going to get him anything because it's coming through. So you really have almost no mitigation whatsoever. Another really interesting attack that I actually was going to talk about, but I didn't is using cross-site request forgeries to make other people perform attacks for you. If you want to DDOS a site, you just put a whole bunch of cross-site request for you tokens into a high, or not tokens, put a whole bunch of deep-linked images that point to a really high, a high resource, whatever I'm saying. Yeah. You make it so that it, you know, lock up the server by just pulling a huge database query, something like that. If you have, oh, if you have file injection holes, which are really still pretty common in web applications, but you don't want them to see that, you know, I don't want somebody to see that it's me making these requests, that's fine. I can just put links to it in MySpace, somebody else will own the site for me. I can inject scripts, I can perform all these attacks, I can do SQL injection, I can do it all through cross-site request forgery, have somebody else take care of the dirty work for me. Again, none of which attributable or victim, so. From the standpoint of forensics, you modify the search history, you're not placing the data from those locations, so I would have a hole from something that I actually went to, search history to data that's not on the drive, so it might be the essence of data being missing, cache data being missing that I might look at, is that true, or is modifying the search history placing those, the actual, your access of those you are making the requests with cross-site request forgery. Your browser, I mean, it actually visits the site. It visits the site, if I load this page up in an iframe, you make the request and you'll load any images inside the site, so it looks like completely legitimate browsing as far as the user side goes. Although in the case of the browser history attack, if you force something into somebody's browser history, that they may not have visited, is that a fair analogy? In that case, if they haven't visited it. That's what I was talking about. One of the points there is that the trail may stop at the history file that says it, but if you truly are a good forensic investigator and you haven't dug in... My index.dat would tell me... I went there, my cache would tell me there's this hole. That's right, and so there are theoretically some gaps, but again, it's the quality of the investigator doing it and certainly would be enough to cause you significant problems, but yes, a good... Russ is the one with the forensic background, so... Oh, absolutely, yeah. I mean, if you do it through any of the known anonymizers, it's the worst. I mean, theoretically, you've compromised somebody's box and you make requests through their box via C-Serve. I mean, it's on and on, so... Sir. Hi, I was a little bit late. I don't know if I missed this, but did you mention any client-side protections that people in this audience might use to generally protect themselves? That's a good question, actually. As far as client-side protection goes, there's not a whole lot right now. There's some really cool stuff coming, though. NoScript just added some... Everybody here uses NoScript, right? Yeah. NoScript just added what I believe is called the ABE, the Application Boundary Enforcer. It's a feature that forces... It basically protects different zones on your web... on your web browser. So I can't... My application can't make requests to your local internet zone or to your local machine. It's very good. It's not quite 100% yet, but it's coming, and I really like it. Another thing that's coming up, Mozilla just announced that they're putting together... It's... I'm forgetting all the abbreviations for things, but I think content... Just tell them what it does. Framework, policy, something or other. Basically, it's a feature that it does the same thing, only way better. You're... This is all opt-in, so if my website... If I send a header back saying protect my website, don't let any cross-site request forgeries happen. Your browser won't make any request to any outside domains at all, and that is what... It's exactly what we need. The problem is that it's opt-in, and if it wasn't opt-in, it would break the entire internet. But it's the single protection. It's something you get, but again, if you believe it such that it's opt-in, it's something you don't have to use in Dustball Victim. Right, thanks. I appreciate the mention of NoScript's ABE, but I have to... Because you didn't plug this for me, I figured I should mention I'm actually the author of a Firefox extension called Request Policy. I don't know if you've heard of that one, but that one... I owe you a beer. That one would actually protect against just about everything you mention, across-site. That's a different issue in that sense. But other than that, of course, this means someone has to install the extension, be running Firefox. This is not something that you could propagate and have developers use on their website to protect users everywhere, but for those in the audience, that's something. Definitely look it up, because it's good stuff. That's Request Policy? I was asked to repeat it, yes. So, dude, come see us. I apologize for not knowing of it, but I'd love to talk about it. No, no, it's pretty new, actually. I just wanted to see if you could do that. No, good. Come up later. Another question? Have you done any Cross-site Request forgery jumping out of a sandbox, like using multiple browsers, or if I have IE and Mozilla open and I'm doing my open surfing on IE, but I'm doing my quote-unquote secure surfing in Mozilla? Cross-site Request forgery... I mean, by nature, using a browser and exploiting the browser. I have some ideas. There may be stuff coming. We'll see what works. So, I do have some stuff I've been meaning to work on there. It's walking by. Anyone else? Alright, we'll give you some time back. We appreciate you guys coming out, everybody. Thanks.