 Okay, we're going to go ahead and get started. This is biting the hand that feeds you. My name is Billy Rios of the Dunk Tank fame and other things that I will not mention to happen this weekend. And this is Nate McFeeders. So the first thing that we're going to do is we're going to go over an agenda. And the agenda basically consists of domain names and trusts. Initially, we're just going to talk a little bit how domain names and trusts are kind of built into each other. Maybe some ways that various pieces of client-side technology try to protect us by using various domain names. And then we're going to look at some ways on how we abuse that trust. I'm going to give you some really simple examples that you can either take and learn from and develop your own examples from. Or you can just kind of sit here and take that in and say, yeah, that's really cool, that really sucked. But I'm going to give you the examples either way. And at the very, very end, we're going to go over some things that are related to URI use and abuse. And the reason that we're going to do that is because a lot of people have been asking myself and Nate a lot of questions about the recent Firefox zero days that we released a couple weeks ago that were just recently patched with Firefox 2.0.0.5 and 2.0.0.6. And then there's also another zero day that we had put out for trillion. And then there's one back in the day that we had put out for Microsoft that's actually considered a Windows URI resource handling vulnerability that was patched in MS07035. And so if the Krillin Studios crew is here or the Firefox, uh, Missile Security team would just like to say what's up and see how everything's going. And if you have any other further questions, you can maybe address this at the end and hopefully if you cancel it out someplace, we'll answer those for you. The first thing is, every time you surf the internet, there's something, whenever I'm on the World Wide Web, I always ask myself a question. You know, who do I trust? And I think there's two different schools of thought as far as browser content-based interaction with your browser and the World Wide Web. I think one camp goes, hey, anything running inside the browser, you're basically running untrusted code inside the browser. So you need to be really careful. And I think the other school of thought is, hey, you know what, I've got these client-side protections and these different ways of protecting myself. I'm going to go ahead and use my browser and my client-side application to protect me from whatever it is that's out there on the internet. If we look at some of those protection methods, well, I think, you know, there's some people that are on the far left, some people are on the far right, but I think most of the people kind of, you know, come to a happy medium someplace in the center, they go, yeah, a lot of stuff out there is pretty crazy. A lot of the stuff I can't really trust. I'm not going to fully rely on the browser or the application to protect me, but at the same time, I'm going to try to make some common sense judgment. I'm going to try to see whether or not I should trust this content that's being served or rendered to my browser or my client-side application. So if we take a look at some of the protections that are offered to us, I think the first line of protection are browser restrictions. So if you look at these browser restrictions in the way the browsers try to protect us, it's basically based on domain names. And so if you look at various things like, you know, cross-site request forgery and cross-site scripting and malicious JavaScript and such and such and such, a lot of times the biggest thing that they're trying to overcome is something that's called the same origin policy. And the same origin policy just kind of dictates that, hey, you know, content from one domain cannot interact with content from another domain or scripts from one domain cannot interact with scripts from a different domain. And they do that for our protection. And so all these different attacks that we're trying to, you know, that we're seeing, especially with related to cross-site request forgery and cross-site scripting, kind of try to take advantage of that, skirt that, get around it, whatever. But what it basically boils down to is the browser is taking a look at where that content's coming from, but the only thing it can really discern from that content is the domain name. That's the only thing. Things like cross-site scripting, they can't determine who actually who actually wrote the content that it's serving, can never determine that. The only thing it can determine is where is this coming from as far as a domain name standpoint goes. If we take a look at another security measure that's put into place, like SSL certificates, SSL certificates, I think, you know, are a really, really good thing. They help prevent people like me from getting man in the middle out here on DEF CON's network, which is extremely dangerous. But, you know, a piece of that is actually a domain name, a host name match, right? Does the name on the SSL certificate match the name that the content's being served from or the server that's serving the content? And if you think about it, that's really the only thing that it can really kind of base its judgment on, right? That's why you get the certificate error that says, hey, something's funny, the name doesn't match, blah, blah, blah. Let's take another step back and say, hey, you know, what are the browser manufacturers trying to do to protect me and Joe Schmo when I surf the Internet from getting my credit card stolen or going to a site that I really shouldn't be going to? And a lot of the new browsers have implemented some type of phishing filter. And so basically what these phishing filters are are just lists of domain names, right? And they just say, hey, you know what? You should never trust content from these domain names. I'm not even going to let you see content from these domain names. I'm going to go ahead and block any content from these domain names. And I'm not going to let you get taken by the website or the content or whatever is getting served from this domain name because we know it's evil. So the browser is trying to protect me in that way. But in reality, all it really is is just a list of domain names. Domain names and IP addresses saying, just don't trust these guys. They're known bad guys. They're owned by people like Nate McFeeters and Billy Rios. Don't ever trust the content, right? And then the last piece, and this is probably the most important piece, this is the piece that I use most often, is human trust. So, you know, I'm a pretty paranoid guy, but at the same time, I've got business that I have to take care of. So I've got to check things like email. I've got to pay my bills online because I travel a lot and all that sort of stuff. So a lot of times what I'll do is whenever I'm asked to perform some kind of sensitive transaction, whenever I'm asked to do something that I think is kind of, you know, maybe I should think about this, I always take another look at that domain name just to make sure that, you know, that domain name is Bank of America and not Bank of America is with an S or some weird stuff like that. Whenever I get an email with a link or anything like that, I always take a look at what domain it's actually going to and then I do some other stuff to protect myself. But it's kind of a human decision-making process that I go through and basically at the very end of the day I ask myself, can I trust that domain? Can I trust the content that's coming from that domain? Can I trust the request that my browser is making? So, I just gave you protections from the browser. I just gave you some SSL protections that are done via SSL. I just gave you how phishing filters kind of protect users against phishing websites and I just told you about, you know, a little bit about the human decision-making factor that goes in when you're taking content from the internet, which is a really dangerous place. And if you didn't get it, everything really boils down to the domain name. That's actually the only piece of information that you can really base any kind of trust off of when you're surfing the internet is the domain name. What else can you base a trust on? What else can you base trust on? You can either not trust or you can trust a domain name. And so, with that in mind, any attacks against the integrity or any attacks that abuse someone else's domain name, a trusted domain name, it's going to be a pretty serious deal on the World Wide Web. And so, we're just going to give you an example of a couple little abuses here. But like I said, I think it's just an indication of some things that can be taken in a step further, a couple steps further and get really dangerous. But we're not going to show this today. And then Nate's going to talk about some URI stuff that's really, really cool and he'll get into that one thing at a time. So, before we start abusing domain names, I'm just going to talk really briefly about something called cross-site request forgery. And everyone should already know how cross-site request forgery works. But I'm just going to go over a very, very, very basic example. So, Nate has some compromising piece of information about me about something I did a couple of weekends ago. And he says, hey, you know what? I'm going to put this out on the internet. And I'm going to do it unless you give me $1. So I say, okay, I'll give Nate a dollar. But Nate's like, hey, you know what? I don't trust you. I don't want to meet you anywhere. It could be a setup. I want you to go onto bigcutting.com and I want you to transfer $1 from your account to my account. And so I say, hey, okay, no problem. So I log into bigcutting.com and I transfer $1 from my account to Nate's account. And being, you know, the guy that I am, I log every single request that my browser is making. And I notice, I notice that it makes a request, a get request, and it has Nate's name in one of the parameters and it has an amount in the other parameter. And I'm like, wow, you know, it's pretty good. And I take another look at it and I realize that it's doing a really good, you know, really good, it's a really good effort of tying the cookie my session to my account. So there's no, my account number or my account name is not getting passed in any parameter. The application just knows to associate my session ID with my account. So I transfer $1 to Nate. Being a very, very stingy guy, I don't like giving Nate a dollar. So I'm trying to scheme away to get my money back. And so what I understand is there's two parameters that get passed in a cross-sector cross-forgery attack against this application. One of them's the account. The other one's the amount. And then the rest is basically just writing off the session that's getting passed back and forth. So what I do is I craft, made an email saying, hey, you know what, dog, you need to log into your account and check your balance because I just sent you a dollar. But inside the email that I send them, because I know that Nate uses an HTML web client that renders anything that's in there, I put an image source tag in there and I say, hey, I'm going to make this thing one pixel by one pixel. It's going to have no borders. It's going to be really difficult to see. And whenever that image request gets made, it's going to make the get request. So instead of having the two account to Nate, it's going to have the two account to Billy. And then instead of the amount being a dollar, it's going to be $10,000. So if he has an active session, he browsers the email or whatever that the contact gets rendered. That's going to get executed in the context of his session. He's going to transfer $10,000 to my account. So this is a very, very, very classic, very, very, very simple example of how cross-site request forgery works. And if you want more information, you can just go to this website called Google and type in cross-site request forgery. And it'll give you tons of references on cross-site request forgery. Okay, now, I think cross-site request forgery is kind of cool. And so when I was in Amsterdam, at Blackhead Amsterdam, I actually gave a presentation where I used classic cross-site request forgery, but I put a little twist in there. And so basically what I did was I understood what cross-site request forgery could do. And I thought it was pretty cool. So I crafted up some nasty JavaScript code, which I'm going to show you in a second here. And that did some really, really weird stuff. What it really did was it used a cross-site scripting exploit. So now I control the content of a certain page coming from a certain domain. And it basically used that cross-site scripting exploit to write an invisible iframe. And what it did for that iframe is it actually posted a form to that iframe. That was the target of the iframe, or the target of the form post that I made. It was the invisible iframe. And what I actually did was I had all this nasty JavaScript code, but the most important piece of that JavaScript code were these two arrays. And the two arrays contained the first array contained usernames and the second array contained passwords. And if you look at that, that's actually the array that I used right there, the username list and the password list. So what I had it do was I had it use that invisible iframe and it basically made posts to some internal network management console and cycle through the different username and passwords. So those people who are really good with cross-site request forgery who have already been to Google and typed in cross-site request forgery know that a lot of times cross-site request forgery is just one way, which it is. So the way I determined which username and password credentials worked was I followed each cross-site request forgery request with a request for a cross-site scripting exploit that was available only to authenticated users. And so if one set of credentials didn't work, the cross-site scripting request that came immediately after it would just fail and no one would know the better. But as soon as I hit that username and password combination that did work, the cross-site scripting request that came after it would work. And that cross-site scripting request would actually send me a ping back saying, hey, I got a valid set of credentials. These are what the credentials are. I'm now logged into this machine. And now not only do you have control of the victims' browser from the domain that it's coming from, you now have control of the victims' browser from this new domain or this new machine that you've just cross-site scripted. I think some people call this exponential cross-site scripting. There's a lot of fucking weird names for it. Right, yeah, but what I'm going to do is it's kind of a weird concept to understand. So I've got a really simple demo I'm going to show you and just kind of walk you through and show you how it works here. Okay, at this point, what's happened here is you see two things, right? You see one iframe that you can actually see. And the attack that I did, it was actually invisible. You couldn't see that iframe. But for demonstration purposes, it's a lot nicer and it's a lot easier to understand when you can actually see the iframe. So what the iframe does is it actually loads the network management console that's someplace on someone's internal network. And all the content or all the post requests and all the forms and such are being controlled from the big frame. And in the attack, the big frame was actually the cross-site scripted, the original cross-site scripting exploit, but I pulled off against some victim. And so what's going to happen here, I'm going to go ahead and hit play. And what you'll see is you'll see some activity in the iframe that's in the top left-hand corner. Okay, like I said, in the real attack, that was invisible. But what you see that's happening right there is the JavaScript that's in the bigger page is actually rewriting a form, an HTML form, and posting that to the iframe. And it's cycling through that username-password list that I had in those two arrays. And so it's going to keep going, it's going to keep going, it's going to keep going. After every cross-site request forgery request that's made, I follow it up with a cross-site scripting request. The only way that cross-site scripting request is going to execute is if the session gets forced and the user becomes authenticated. So eventually, I'm going to go through those two arrays and I'm going to hit one combination where the username-password combination works and the cross-site scripting will fire. And we'll see that through an alert box because that's the easiest way to demonstrate when a cross-site scripting exploit is successful. And there it is right there. So now I basically jump the domain right there. It was a really cool demo. Jumping the domains is not really a concept that we're going to talk about here. If you want to learn more about it, look up the talk I did at Blackhead Amsterdam or just go to the website, access-sniper.com and you can read as much about it as you want. The important part that you just saw right there was the fact that that network management HTML console would allow me to do cross-site request forgery against the login page. And actually to tell you the truth, every single web application I've looked at and I've looked at tons and tons and tons of them because I do it for a living basically, I have not come across one web application that does protection against the web application authentication piece. It will allow any person to post credentials to the web application as long as they know which post parameters or which get parameters to pass. So what I just showed you there against the What's Up Gold IP switch network management console, which is a commercial piece of software, is probably valid for every single web application that you've ever come across. And the next time you come across a web application authentication page, check to see if there's any kind of cross-site request forgery protection against it. And the reason I think there isn't very much cross-site request forgery protection is because no one's really used cross-site request forgery protection or cross-site request forgery attacks for some people if they think about it, it doesn't make sense, right? What can you do with that, right? So we're going to show you what you can do with that, but we're going to set this up and we're going to show you the cross-site request forgery attacks against the authentication page and some other stuff against webmail. The reason we choose webmail, there's four reasons. Number one, today's webmail servers allow for a ridiculous amount of storage. So I'm going to go ahead and use a file storage functionality and show you how to store malicious content on a webmail server. The reason I pick the webmail server is because I can store, like, two gigs on most webmail servers. And then if I run out, I can just find another one. So the storage space is just ridiculous. Almost anything I want to store on there, I can store on there. The second thing is anonymity, right? So I come across this webmail server and I want an account. Basically, all I have to do is just type, you know, garbage into the login or to the registration form and it grants me a username and password and I have a webmail account. I don't know how much anyone can create a webmail account from anywhere in the world. That's one of the greatest things about webmail but at the same time that's one thing that makes it a little bit dangerous. The last thing is the speed. So I've known some people who've hosted ware servers in their life and they've had a lot of content on there, a lot of real good content. But, you know, after a while the speed of the server just becomes really bogged down because there's a lot of people downloading stuff off of there, a lot of people downloading content, a lot of bandwidth, that's not really an issue anymore. So if you're trying to transfer a big file from one place to another speed really isn't a problem. And the last piece, the most important piece is because people trust those domains. For some reason they see those domains that are recognizable and they trust those domains for some reason. It's like an implicit trust. They go, hey, I go to this server every day anyway. There's no way that malicious content can be coming from this web server. So that's why we're focusing on webmail but like I said before, pretty much any application that exhibits a certain amount of characteristics, you can do these attacks against and other more nasty attacks, right? So the first thing that we're going to do is we're going to bite the hand that feeds me and we're going to bite Yahoo, right? So I'm going to walk you through a couple different things and then show you how this works. The first thing is I'm going to go really quick over the Yahoo sign in process because it's really easy. And then I'm going to show you some protection measures that Yahoo actually has against these kind of things. But then I'm going to show you how trivial they are because they have a little protection measure against this. It's so trivial, it's almost ridiculous. And then the last thing is how to store the content on there and how to serve the content. So that's it right there. That's the only thing that's standing between you and having your own Yahoo mail account. That form right there. And the thing is that this form is really not designed against people registering accounts anonymously. It's more designed to prevent people or prevent bots from registering an account anonymously. So as a person, pretty much anyone can go and just register an account on Yahoo, which is the same for most webmail servers. I'm sure you, everyone's seeing something like this, really easy. Where do I live? What's your name? What's your gender? You know, select the username and password. So let's say I go ahead and I create this anonymous account. I'm going to go ahead and call it a throwaway account because that's all I'm going to use it for. I'm going to use it maybe once or twice and then I'm going to throw it away. I created it. Now I have an account on Yahoo. So what I'm going to do is I'm going to go ahead and upload a file to Yahoo. So in this screenshot right here I show you, I uploaded a file called pwdump.exe. Now there's supposed to be some antivirus protections and scanning such that goes on onto the applications when they get uploaded to the server. Every file that I've tried to upload to servers, it's just been accepted. I don't know what the antivirus scanning is, and I'm sure PWDump is the greatest. There's no virus threat in PWDump, right? Right, no way. PWDump is totally not malicious, right? So if anyone's getting served PWDump, it's always for good. So when you see this sort of thing right here, you've got attachment that says, hey, the following file has been attached, and guess what, no virus threat has been detected. If you want to attach more files, just click here. I think the most important piece, once again, scanned. So once again, the most important piece of this whole thing is that little button right there that says download attachment. So when you click that button, download attachment, what it actually does is it makes a get request. And so now we go back to that original classic cross-site request forgery that we had in place where we have a get request, and there's certain parameters that are getting passed, and the application is relying on the fact that you have a good session to pull up that file. And so that's part of the get request that's being made when I click download attachment for PWDump. So if I just make a copy of that URL, that get request, and I have the right session, I should be able to download that file. I should be able to serve that file to somebody. So that's what I do. I create a JavaScript, right, let's say I cross-site script somebody, and it's some kind of phishing page, and I want to serve them a file, but I don't want to serve them a file from my server, because if I'm serving bad files from my server, someone could come and kick down my door and take my server away from me. I'd rather serve from someone else's server, right? So you create the JavaScript. If something happens, cross-site scripting or whatever, you can actually create the form like I showed you in that example for the what's up gold switch. Create the invisible iframe. Go ahead and have that posted to that invisible iframe, and then the next request that you make is the HTTP get request for the file that you want to serve. So this is what they would see right here. They would say, hey, this server is trying to serve you pwdump.exe, but hey, guess what? It's from mail.yahoo.com. This is where we're going to get into one of the protections. If you actually take a really good look at this screenshot right here, you'll see that the get request is not actually from us.f57.mail.yahoo.com, which is where they serve their mail from, which is a little bit more trusted than the other server that they're serving from. They're actually trying to serve it from a server called attach.re.mail.yahoo.com. And this is something that I... I think I've ever heard this concept before, but this is something that I call domain switching. I think the guys at Yahoo are pretty smart and they're like, we don't want to serve this from our mail server. We want to serve this from some other server. So we're going to serve it from an attachment server, right? And so that's what they did, but there's one big problem. A lot of times the attachment server where the content's actually coming from is in reality the same server as the mail server. So they've got a different domain name, but the request is still going to the same mail server. So you see that area that I've highlighted right there? That's the full get request, but if you take that little piece out right there and just make the request to usf574.mail.yahoo.com, the content in the file will still get served anyway, but it'll get served from a different file. It's supposedly a different domain, but it's the same server. And that's the example that you see right here. If you take a look at where it's from, it's actually from us.f574.mail.yahoo.com. And it gets even crazier. You can actually par that down some. So in the next screenshot that I show you, I've actually just taken out the us.whatever, whatever. And guess what? You can actually par it down a little further if you want. And there's other protections to do that. There's other protections against that. I'm not going to show you how to bypass those, but I'm just letting you know that they're very, very, very trivial. So I'll show you the yahoo demo. It's really... I'll tell you the truth, this is kind of ghetto. And the only reason it's kind of ghetto is because I'm definitely afraid of connecting the DEF CONS network, because it's the nicest network in the world. But if you see this here, that's all that it takes. Let me pause this guy right here. That's all that it takes. A JavaScript that has an iframe that you can't see and then posts the credentials to that iframe, forces the authenticated session with yahoo, then makes the appropriate get request, then serves the content from yahoo server. So the victim in this case doesn't have to type anything, they don't have to do anything. If they think that they're on a page that's affiliated with yahoo, I can serve them content that appears to be coming from yahoo. I'm going to abuse yahoo's domain name right here, because when they look at the file download and such, it says it's actually coming from yahoo.com. And like I said once again, you can actually parse this down further and make it, you know, get served from almost, almost the root of yahoo.com. Pretty close. That's left for an exercise. Right, exactly. So this is just a blank page. Yeah, you know, someone goes to a blank page, whatever. But, you know, in reality, it would probably be pulled off on something like this, right, where you've got this page and it's like, hey, download the latest version of, you know, such and such toolbar, blah, blah, blah, blah. And in this case, it's really easy to spot the fake, because, you know, I'm assuming that the yahoo toolbar is not called command.exe, but you can actually name that to whatever file that you want, you know. It can be an executable. You can use this to serve your JavaScript content for cross-site scripting attacks. You can use this to serve wares or whatever. So, but it's not served from my server. It's served from their server, right? Let's go ahead and finish this up and this will be closed. Okay, so, I mean, how bonehead of yahoo, right? I mean, what were they thinking? You know, so we took a look at some other Webmail servers to see if they were vulnerable to this kind of stuff and guess what? I mean, they all, oh my gosh, right? So the next example that we're going to show you is Gmail and we're not trying to pick on yahoo and Gmail here. We're just showing you that these are two very, very well-respected Webmail servers who are pretty good about security. They're very good about security, actually. And if these two Webmail servers are vulnerable to this kind of stuff, I mean, imagine who else would be. Any kind of application that exhibits characteristics like this, vulnerable. So once again, the sign-up process, there it is. That's the only thing standing between you and a Gmail account. I'm sure everyone here has a Gmail account, some sort, or other. In-protection against bots as opposed to human beings, right? So you sign up for your account. But you know what? Gmail has protections as well. So not only do they do domain switching in certain cases, they also don't allow certain pieces of content to be served from their domain. Smart, smart idea, right? So if you actually upload command.exe and try to email it to someone else in a Gmail account, even if it's to yourself, Gmail will give you a warning. They'll say, hey, you know what? EXEs, no way. There's a lot of other files that it won't take as well. So, but let's say I try to upload a file called command.exe to Gmail. The first thing that I'll see is something like this, where it'll say, hey, you know, a little paperclip, and it'll say there's a file called c-windows-system32-command.exe, right? If you wait three or four seconds, what happens is that actually changes to a link. So at that point, although Gmail will not allow you to serve it to someone else via their email service, it's already been uploaded to their server. And what, right, right. So, the dangerous piece of that is that, you know, it's uploaded to their server. A lot of people don't understand this concept is that they've taken ownership of my content. That's the big thing to take away here. They have taken ownership of my content. So now when someone downloads that, dude, that's not my content. I don't know where that came from. That thing came from that other server over there. They've taken ownership of my content. And so in order to get the location, in order to get the get request from my content, all you do is right click on the link and say copy shortcut, and it's going to give you the whole link right there. Once again, back to those two simple, simple demos that I showed you. Create the invisible iframe. Use the cross-site scripting exploit to write the form. Use the form to post to the invisible iframe. You already know the creds. You signed up for it. It's a throwaway account. Who cares if someone compromises it two seconds after you compromise someone else with it? You can just create another one. After that, you know what the get request is to get the content off of there. Now you're serving it from their content or now you're serving it from their domain. So we'll show you the Gmail demo as well. It's pretty much the same thing though. Here's a page right here. There's just a simple link. Someone clicks the link. There's some JavaScript that goes on in the background. And there you go. Command.exe for mail.google.com, right? It could easily be Google Desktop from mail.google.com. Or it could easily be Google Desktop from some other domain that allows domain switching. Someplace else on the Google whole scheme of things, right? Because they own a lot of different domains. So... And although I'm not really big on phishing, I think if someone were to pull off like a phishing type thing on here, it would just be the same thing. You know, hey, download Google Desktop. You know, click this link. It's yours. Where's this file coming from? It's coming from mail.google.com or some other Google.com domain, whichever one that you want to pick. And there it is up there. So... Now, when I first saw that, I was like, man, I could probably really abuse this because a lot of people really trust those names, right? So there's a lot of different ways you could abuse this. Maybe it's not just to serve command.exe to your friend. Maybe it's not just to try to get your friend to download your version of the Google Desktop so they can install it on their machine. And nice things will happen. Maybe you can use it to serve malware, which we just kind of showed you. But maybe you could use it to serve wares, right? So you have these wear servers. These email addresses are constantly forwarding, attachments, and forwarding other emails to different places. And now you know the username and credits for all those email addresses. And so when someone wants to download something from your wares site, instead of hosting the wares on your server at home in the basement where mom and dad always come down and go, what do you have on those servers? You can go, hey, I don't have any servers. I don't got any software or nothing illegal on my stuff. All I do is hand out JavaScript to people who want it, right? So... Exactly, exactly. File sharing. There's actually another little twist that someone sent me about file sharing was there's some guy, a non-techie guy, who just said, you know what? He tried to steal my presentation now. It was kind of pissed. But it was in Esquire, and instead of actually serving this stuff up like via JavaScript and that sort of thing, he actually just created an email account, uploaded like 150 MP3s on it, and just sent out the username and password to all his friends, which then sent out their username and password to all their friends, blah, blah, blah, blah. So that's kind of cool, but I think the way I do it's a little bit cooler. But he's still there. Good concept, right? Good concept. And then last is covert channels. You can just pass messages. Never have to have those messages on your machine. And then maybe you can take a step away from the browser. Who says you have to implement all this stuff from the browser? You can actually have a full-blown application. Someone could write a P2P application that could abuse this type of functionality, never pass creds in the open or anything like that, just pass sessions, and just take advantage of the functionality that these places are offering you. Maybe we're already adding peer software. Maybe someone's running peer-to-peer software to do this already. So, but it doesn't stop there. I'm going to show you one other attack that basically abuses domain name protections and show you why, hey, you know what, maybe someone doesn't want to serve wares. Maybe someone actually wants to attack you and read some of your stuff. Maybe someone who actually wants to break some of the domain name protections that's offered by different client-side pieces of technology. And this is with Flash. So I don't know how much you know about Flash, but I'm just going to give you a quick, quick primer on how Flash works, especially with cross-domain requests. Well, Flash doesn't allow cross-domain requests like it shouldn't. Well, it kind of doesn't allow cross-domain requests, right? What it actually does is, it has something that's called a cross-domain.xml file, and all you Flash gurus should probably know what the cross-domain.xml file is. It's the thing that's going to allow you to do cross-domain requests. And now there's a new piece of functionality in Flash, I think of it as a Flash 7 called Load Policy File, which will also make your life a lot easier as a developer to do cross-domain requests to servers. So the cross-domain.xml file, there's an example of the cross-domain.xml file. If anyone here wants to put a cross-domain.xml file on their web server, this is the way to do it. Just go ahead and say, allow access from domain and put a star in there. That's the most secure way to do it, okay? Take this screenshot, take this screenshot, paste it into an xml file, and throw it on your server. You're really, really good. In reality, that's not the best way to do it. Basically what this is saying is, when Flash makes a cross-domain request to some server, let's say Flash makes a cross-domain request to Gmail, mail.google.com. If it finds a cross-domain.xml file on there, and that cross-domain.xml file says, allow access from star, that means any domain on the Internet can make a cross-domain request to mail.google.com, if it finds this file. Now typically, cross-domain.xml can only be located in one place, and that's the web root. But if you look at some of the security policies written by Adobe and Macro Media, they have a couple different ways to do it. So if you look at the documentation, the documentation for something called system.security.loadPolicy file allows administrators of web servers to write the cross-domain.xml file and put it into their web server. Now when a Flash object tries to make a cross-domain request to that web server, it's going to first check the web root. If the file doesn't exist in the web root, it's not going to allow you to do a cross-domain request to that web server. However, if the Flash applet that you're loading uses the loadPolicy file, system.security.loadPolicy file, because it's really secure, right? And you can specify your own location for the cross-domain.xml file, and the Flash player makes that request and finds the cross-domain.xml file there. It'll allow you to do the cross-domain.xml files. So this language right here is taken straight from the security documents, and this API was introduced in Flash Player 7. 7.0.19.0 to be exact. From 7.0.19.0, you can specify the location for the cross-domain.xml file. So, as you've seen before, all you need to do is, once again, create the invisible iframe, use the cross-site scripting exploit, load the Flash Player, tell the Flash Player exactly where to find the cross-domain.xml file, which is demonstrated in this screenshot right here. You can take a look at the slides later. You can specify the exact request that the Flash Player needs to find the cross-domain.xml file, and once it's made that request and found it, the Flash Player can now do cross-domain requests to whatever server it is that's hosting that file, which you put there that owns your content. So, if you've attacked someone and you want to maybe follow their Google search habits, or maybe if you want to wait and see if they're going to log into their email after they've been attacked by cross-site scripting, you can just wait, and as soon as they do that, the Flash Player that you would instantiate on their machine is now capable of making cross-domain requests to that web server because you put your content there, and they owned it. They took ownership of that. The example I gave right here, it says mail.google.com. slash mail, and then there's a request after it, the parameters. But once again, with the domain switching, there's a lot of play that you can do. So those people who know how the load policy file works really, really well knows that it'll only allow you to go back to the web folder that's specified in the request, in the load policy request. So if it's slash mail, then you'll only be able to go to slash mail and above. But once again, with the domain switching stuff, you can basically take away that last slash, and it'll appear as if it's being served almost from the root. So, very dangerous. Okay, we're going to talk a little about defending. We have time. Okay. If you need to know about how to protect yourself against this sort of stuff, you can catch up with me later. I'm done drinking beer for right now, but I'll be drinking water someplace trying to hydrate. But we can talk about some protections on this, because I really want to let Nate talk about some of the URI stuff that we've been working on lately. Alright, so onto the O-days, I guess. It's good to see so many people here after a long week of drinking and having fun here in Vegas. It's a good thing. A lot of people have been asking us a lot of questions about this URI use and abuse that Billy and I have been talking about for the past, I don't know, a couple weeks. There's been a couple O-days we've released on this for some of the major browsers. So I think one of the things people want to know are what are these URIs? So you've got them all over your machine. You know the common ones, you know, HTTP, FTP, but what other ones do you not know about, right? Did you know that there's an AIM URI on your system? Did you know that there's a Firefox URL on your system? PICASA? I mean, all these things are being registered by developers, and any developer who wants to code an application, they can register their own URI that they can determine how it interacts with that application on the back end of your system. So what's crazy about this? Well, anybody knows a URI is able to be put into an HTML webpage and accessed. So if you cross-site script someone, you're now able to access that URI through that cross-site scripting exposure and through, you know, transitive property or whatever we are here. You're going to be able to also interact with the commands that the URI is going to be passed to you on the back end. So it's really dangerous. I mean, cross-site scripting exposure is now going not just to the browser, but to the back end applications. You might want to know what's registered on your own personal machine. A good friend of ours, Eric Cabatis, I'm sure probably several people here know him, helped us with writing a tool called DAH. It's Dump URL Handlers. Pretty simple. It searches through the registry, finds the appropriate entries, and it then pulls out the relevant information. You can see a screenshot here. It looks terribly blurry. We're sorry about that. You can go to our website later. The gist of it is that you could see there's an Acrobat URI that's tied to the AcroRead program. And it will accept certain parameters that are passed on the URI. There's also the AIM URI handler here, same type of deal, and there's several others. I'm sure you'll be hugely surprised by what's all registered on your system yourself. You can download this tool. The link to Eric Cabatis' site is on our website. We'll tell you that later. So what's vulnerable so far? What have we been doing the last several weeks of our lives, until 5 in the morning drinking? Cross-browser scripting is the big one that we started with. And the whole premise here is that IE is ponying Firefox and Netscape Navigator 9 through URLs that they've registered into the Windows registry, that being the Firefox URL and the Navigator URL. So IE or Firefox and Netscape Navigator 9 depending on which side of the political debate you're on, they're having difficulty sanitizing double quotes that are passed in the URIs. So what happens here is during the call to Firefox.exe or Navigator.exe, respectively depending on which URL you used, it's possible to use a double quote to close out of the current command line argument you're in and insert another command line argument. In this case we're going to inject the Chrome argument which allows us to use some fancy code like this courtesy of Billy here which is going to actually actually this is based off of the core lahom safari thing. Should give credit where credit's due here, so. But this is going to use the JavaScript within the Chrome argument to actually kick off a command.exe window. So pretty, you know, you can run whatever command you want here. The next type of attack we've been looking at is cross application scripting. Is what we're calling this now. This example we're going to give here and keep in mind there's many examples of these. This has been like the last four weeks of our lives, five weeks of our lives, so it's pushed out completely yet. The whole idea here is that IE is now pony trillion through the A and URL handler. And so what's happening? We've got two types of attacks here. One's a stack overflow and one's a command injection. So I'm going to get into examples of those. Obviously, you know, that's a pretty long string here, we're passing to the A and URL handler. Again, this could be done through a cross-site scripting. It could be done through, you know, phishing attacks, whatever you want, right? It's not hard to see, but if you look down at the bottom, you'll see that we have control over pointer to next SEH record and the SE handler. So obviously at this point it becomes an exercise and can you shell code on XP Service Pack 2. So you guys can go ahead and do that from the proof of concept code we've got out there. Example number two, this is going to be the command injection. Real strange. I mean, this is a really strange flaw. You can see here the first thing to notice in the URL that we're passing, the A and URL that we're passing. Notice the first double quote right after calc.exe. That's where our command injection occurs and we're closing off the current command line argument that we're on, which is actually the URL command line argument, and we're inserting another argument which is the space INI. For whatever reason Trillian takes this INI argument and it takes a file for that argument and whatever file you give it, it will then write content to that file. That's the location you want. In this case we're interested in writing it to the startup folder as a batch file for some obvious reasons. The other interesting thing to notice about it is that it actually takes the previous portion of our URI and dumps that into the file that we've just told it to write where we want it to write and will allow us to put whatever content we want in there. So that's the first part of the URL where you see the amp for sand secon slash windows system32 calc.exe. Now you can notice the two screenshots I'm showing the pwn.bat file in my startup folder. So that's going to run the next time I turn my computer on and you can see probably barely the content that is stored within there, which actually has our amp for sand secon slash windows system32 calc.exe. If you can't figure out what this is doing, I'll save you the drama. Next time you restart your computer, it's going to load calc.exe. You can put any command in here you want. So it's pretty much game over at this point. What else is available? This has been a big one in the last couple weeks here, I guess. Remote command execution in firefox, nescape navigator 9, mozilla, any other gecko based browser or browser like system you can probably imagine. Cmonkey, nivu, whatever else. This is a quote from the mozilla security blog. I think they explained it probably better than we could in this case. The idea is that if we put in a null character for sent zero zero and coded null character in the url for these url schemes that we're discovering, for some reason firefox when running on a windows system with ie7 installed will actually misinterpret how it should handle this and instead of using the url protocol handler, it uses the file type handler. So let's show you I mean to me that's just I'm not exactly sure all the details or whatever we don't care. We want to see the demo, right? So here's the demo. This is the mail to url. There's several of these. There's mail to, news, snews, nntp all kinds of things, right? The idea we got the double encoded nulls right there and you can see at the very end the blah dot bat what's a bat file? It's a batch file, right? It's going to be run by the command prompt, right? So what ends up happening is the url the way it gets handled is it goes to the file type handler now and it kicks off command .exe and if you notice the dot dot dot slash windows system 32 calc.exe that's actually the command that command.exe is going to run so you could see it's kicking off calc here. It's kind of hard to see from the example that's basically just a hard-coded web page with a link. That's the red box right there. When you click that it's going to pop up on calc.exe. There's great proof of concepts on our website xs-sniper.com. You guys can go and pull in yourselves. Have a good time with it. We're not going to do any live demos. Obviously the defcon network is as shady as we are so we're going to try to avoid that. I think this is actually patched in the latest version of Firefox, right? But I think there's some other Mozilla-based browsers that haven't rolled out their patches. Yeah, actually Netscape Navigator 9, I think the Mozilla browser is still vulnerable and this is our last checking so they're out there and hopefully those teams will work together to try to fix this issue as well. They put that out really fast by the way. They put it out in my portfolio. They put us to Firefox Navigator. I think people are asking a lot of questions about the blame game. Whose fault is it? I think Rios and I have stood pretty strong that it's everybody's fault. Because what we're looking at here are some very simple examples of just stupid things like stack overflows, command injections, things that people just forgot about, right? But this isn't touching at all the functionality issues that these URIs are allowing you to interact with. I mean think about the Pocasa URI. You guys use Pocasa for editing your photos. I love it. I think it's great. But what can you do with the Pocasa URI? I don't know. We'll have to figure that out I guess in the next couple months. I think everybody is at fault. Everybody needs to take a strong look at what they're doing with this and try to fix it. So what's next? I think I touched on it a little bit. You got your functionality attacks I think are going to be the big thing. Can I send messages as you like from your browser? Once I cross that scripted you through your chat programs? I think so. Probably. Can I upload pictures, download your pictures, send you nasty pictures to the Pocasa URI? It's possible. Probably. And then what about Nix? I think no one's really talked about Nix and the big reason is, well Windows has this registry, right? And this registry's great and it keeps all these URL handlers. Linux actually has some registry-like things as well especially for Nome and KDE. So we'll be seeing where those take us to as well. Definitely. So any questions for us? We'll take any and all questions. But no guys without teacher signs. Yeah, keep your t-shirts on. Anybody? I can't really see because the lights are real bright. Alright, cool.