 Hey, welcome to XAB version 2.0. XAB stands for Cross-Site Scripting Anonymous Browser. And essentially, that is a tool and a framework that allows one to tunnel HTTP requests over sites that are vulnerable to Cross-Site scripting attacks. The prerequisites for this are, number one, you've got to understand what Cross-Site scripting already is. We're not going to explain it during this talk in the limited time we have. You need to know basic HTML and basic JavaScript. My name is Jeffius Trumskis. I'm in a CISO role for a SAS provider. This is my 10th DEF CON and first time presenting. So long-time listener, first-time caller. All right, and I'm Matt Flick, principal with firm associates. And we're an information assurance consulting company focusing on AppSec a little bit, which is pretty relevant. And I apologize for the sound of my voice. It's related to bullet point number three. So what's the agenda for today? So first, I'm going to go through a little bit of history. This is version 2.0. The initial one was back in February, or the initial release was back in February. I'll talk about what it is, what kind of high level, how the idea came about, and things like that. And then Jeff will get into the details of it, as many details as we can fit into a 20-minute talk. And then, actually, we do have a live demo, which worked in the green room, had a little trouble, but it's up and running. So assuming everything goes well, you get to see a live demo. Otherwise, we'll play a video of one and put some music to it or something. And then we'll just wrap it up. So how did the idea come about? Last year, I was just reading articles on tour and attacks against tour. And then, luckily for us, one of my buddies hit me up with a question on cross-site scripting he was dealing with at his job. And so I just kind of put the ideas in my head. And so I started thinking about, OK, well, tour's out there. It's a great tool. I love it. I use it all the time. What if we try and do something else, something different? The same idea, do anonymous browsing or anonymous things on the internet. But what if we try to use cross-site scripting in order to do that? So we threw a bunch of ideas around, actually threw together a presentation submitted to Blackhead DC and presented it there back in February to a few people. It's a little bit more crowded today, thank God. But we actually did have a working demo there too and then released the code, proof of concept code is out there. It's at the firm site. So what is XAB? As we've said a bunch of times, cross-site scripting anonymous browser. Basically, the idea, the basic framework is we've got proxies set up or you can set up either sites that you do a stored cross-site scripting, just store your JavaScript there. And then when people come and visit the site, it runs in their browser. Same old thing about cross-site scripting works. But basically that kicks things off. You've got these two proxies on the outside. And then you have your victims or participants that hit one of those sites, run the JavaScript code, which forces their browser to pull the next request off of your queue, goes off, makes the request, sends it through. The response comes back, they package it up. The victim, the participant packages it up and sends it back to you, the attacker. It's fairly simple architecture. A little bit similar to Tor, a little bit different. But what's cool about it, or what we thought was really cool about it, is that instead of actually having your participants in your anonymous network install something on purpose and willingly load up the tool, you're actually just forcing people to be a part of this network. And it's pretty dynamic. The JavaScript runs in the browser, or runs by the browser. And then they do something for you and then they leave. So it's pretty cool. It's pretty dynamic, rather than being static. Although we came up with some other ideas that we were wanting to implement. Some things have, some other things haven't yet been implemented. But things like doing encryption and trying to tie together, string together multiple participants. So it's actually pretty difficult to do that. Haven't gotten that yet, working yet. But it's on the to-do list. But things like that that we presented at Black at DC, other ideas we've been wanting to try find other people to help join us and fight the good fight. But one of the things that we mentioned that we brought up and discussed at Black at DC was the use of HTML5. So if you can store your JavaScript long-term in the clients, then that becomes a lot more reliable. One of the problems with doing things with cross-site scripting is that if the JavaScript doesn't finish executing, then you're gonna miss part of your data that you're requesting. But if you can have it resident in the browser and run basically whenever the user loads up their offline Gmail and things like that, assuming they're connected, then that becomes a much more static, less dynamic, much more reliable thing. And I don't know if anyone went to Black at and saw the veiled talk, but it seems like they kind of took that idea and ran with it. So we thought that was pretty cool. So now let's get into the nitty gritty as to how all of this works. There's three primary components. The first is XAB attacker. This is the core of everything. This is what handles receiving new requests for data. This is what delivers the JavaScript payload and the commands that we wish to execute and the request that we wish to execute on the victims or participants. HTTP ProxyB is a simple HTTP proxy. This is used by the attacker to seamlessly browse the web through the XAB framework anonymously. All requests if one chooses to participate in the framework would be going through this HTTP ProxyB proxy. It's a seamless proxy. It'll seem like it's a standard browsing experience for the user. I'll be a little bit slower. And CD Proxy is a cross-domain proxy that allows us to get around the cross-domain sandbox of the inability to make an XML HTTP request to another site. So the cross-domain proxy is what allows us to be able to do that. So let's just go through this process flow. There's a lot of steps here, a lot of things at play. And we do have a limited amount of time. So if you have any questions about any of these, please hit me up afterwards. Every step here is important and is necessary for a request to go from beginning to the end. So the first thing we're gonna do is we're gonna run the proxy on a predefined IP address and port. That proxy is then going to listen for incoming traffic from the attacker. The attacker simply sets his web browser to the IP and port of this proxy. And when the attacker makes a request, so say for example they go to www.target.xab. The HTTP ProxyB is then going to insert that request into a queue, which is then going to be picked up by the XAB attacker, which I'll get to in a second. So, but actually before that, we've gotta go back to the human process flow here, is the attacker needs to actually put that payload of XAB attacker on a site that's vulnerable to HTML injection. Ideally, that would be stored. So multiple users can hit it. However, it does work in a reflected HTML injection attack as well, but stored works a little bit better for forums because you're gonna have more users hitting it. Every time a user hits that payload, they're gonna download one more, they're gonna make one more HTTP request for you and send it through the network to the attacker. So the XAB attacker, this is that core piece. It receives that payload request from the participant. It's simply a JavaScript source equals and then the location of the XAB attacker script. Very simple. What's gonna happen is it's gonna look at its internal queue file that HTTP proxy B has updated and it's gonna look to see what needs to be executed. I was gonna remove that request from the queue and then respond to that to the client, aka the victim or participant with some JavaScript that sets some other things that makes the actual request to the cross-domain proxy. So now we've got the client or the victim or participant making that request to the cross-domain proxy. It's also gonna set some other JavaScript functions to handle the data coming in. Don't need to know about that too much, but if you really want to, you can look at the code. And once a participant makes that request to the cross-domain proxy, we're gonna hit step four now. So step four is really simple. They make the request to the cross-domain proxy. The cross-domain proxy makes the request to the target site that the attacker all the way at the top of the chain wants to browse and then it goes all the way back to the cross-domain proxy to the participant who's gonna make image requests with that data in it. Because remember, we could change image requests with and we can append whatever we want to those image requests and it's to make those calls to the XAB attacker, Perl script or CGI. All that data is gonna be base 64 encoded and it's gonna be split up based on how much, based on how you configure it. So I mean, you can only send what 2000 something characters in an IE URL. So you wanna set that a little bit below that in the max data size that the cross-domain proxy or excuse me, the participant sends to the XAB attacker to receive this data is always gonna be under, it's gonna be in chunks under the maximum for that browser. So once XAB attacker receives all this data, it's gonna write it to a file and it's gonna send, so for each of these image requests, it's gonna send them back a one by one GIF image that's transparent so there's nothing funny in their browser and once it receives all of those segments, it's going to combine all that and base 64 decode that and place it in the dump directory. Finally, the HTTP proxy B is going to scan that dump directory. If it sees the file request it's looking for, it's gonna send it back to the attacker, the attacker's gonna view the webpage. So before we get into the live demo, this is what the setup looks like. I don't know if you could read the little boxes but vonsight.xab, this is simply the site that is vulnerable to HTML injection with the attacker's payload. Target.xab is the site that the attacker wishes to browse through this anonymous network. Attacker.xab is the site that is owned by the attacker that runs that XAB attacker tool that's the core of everything and freehost.xab is where we're hosting the cross-domain proxy. On the client side, this is on the hostOS on the actual laptop outside of the VM, we have two web browser instances. We have the victim who has no proxy. He's gonna browse to vulnerable site, vonsight.xab with that payload on there and then we've got the attacker client. The attacker client is gonna go to target.xab through the HTTP proxy proxy. So I'm gonna launch one Firefox instance for the victim user, okay? Sure. So this guy's gonna go to vonsight.xab. You could see that there's not too much time if there's time I'll show you what the payload actually looks like and this is the attacker browser instance. This is the one that is going to be retrieving the files that are on target.xab. So I'm gonna minimize this a little bit so you can kind of see multiple things going on at the same time here. Over here, we're going to run the HTTP proxy.xab and that's gonna listen on 8293 and you can see this guy's reloading over here when I minimize him. Right here, I'm gonna go to www.target.xab and I'm gonna go here and reload. This guy's reloading, he's parsing it and now we got the text part of the page. He's gonna hit that site again. Now this could be another user hitting that vonsight. What's the left? We've got three images here. So there's one more image. He just hit it again. Let's get this last one. But wait, there's more. We've got the favicon.ico up here. Let's see if it'll grab that one for us, too. Sure enough it did. Thank you. Thank you. So what's new since February? Well, we ran into this big issue with the HTTP refer problem and smart folks in here may have already figured out that we're passing the refer from the vulnerable site to the cross-domain proxy. All right, so by doing that, the owner of the cross-domain proxy can look at the vulnerable site and if they look at that source code, they could see the location of the XAB attacker payload and machine. So that's kind of an issue. So there's a couple of ways around this. One is to find sites that are vulnerable to HTML injection that are always SSL. The RFC2616 says that browsers should not pass the refer when the connection is secured with SSL. That is the case for IE and Firefox, the most recent ones. So that's one option that will get rid of the refer. Another option is to use local files. Local files will also not pass the refer. So it's another possibility. Thirdly, there's using iframes. What if we created an iframe that has its source set to another site that's vulnerable to HTML injection but from a reflected standpoint. So it reflects back the URL parameters and then we put our payload in there to the request of cross-domain proxy in there. So then the refers from the site that has the reflected cross-site scripting attack capable on it. And so now we're what? Three subpoenas away from the attacker. So more people you add in there, the more anonymous it can get. And then finally, the last way around the refer problem is random browser bugs that pop up and get fixed pretty quickly. So least favorable approach, but there are approaches to it. Since then we've also added improved content handling. The content handling instead of using file magic to figure out what type of file it was and then send the appropriate content type to the attacker. We just take the content type coming straight from the cross-domain proxy and pass that all the way with the string with the data that's going in. So we're always gonna have the right content type. So in theory, you should be able to hit movies, should be able to hit MP3s, PDFs, any type of content. We actually didn't get any applause or anything at Black Hat DC, so I appreciate that. Worked beautifully then too. So anyways, our time is close to being up. It was pretty quick. So basically again, the idea is that we wanna build something that allows anonymity or some level of anonymity. There are problems like the refer header and other things that may limit the ability to have it anonymous, but as we keep working on it and building in new things and more functionality and stuff like that, it seems like an exciting thing that we wanna keep working on. We could probably make it better and better. So anyways, if you wanna learn more about it, you can download the code from firmassociates.com. Feel free to hit us up after the talk, of course. And if you wanna beer or anything like that, I'm all drunk out today, so I'll goodbye you one, but not myself. Any questions? We actually have a few minutes. No technical questions. Way too tired for that. Yeah, in the back. Incorporating URL redirection. Did we think about that? Yeah. We did. I can't remember. So are you talking about to get rid of the referral issue? If I heard that right, can you speak up? The answer is no, we haven't. Sorry. Good idea. We got a minute. All right, thanks a lot, guys.