 Hi guys. So we're going to go ahead and start. This is the attacking Jboss talk. If you want the web sphere talk, that's in a different room. So just first, who am I? I work at a software security, sorry, software as a service company as a security engineer. So hence my interest in the Jboss topic. If you are into Twitter, you could follow me on it. Also, I'm really awesome at PowerPoints. So I just want to quickly just set a couple of expectations here. The first thing I wanted to mention is that most of what I'm talking about here is not really new stuff. It's stuff that's kind of out in the wild. I tried to just pull it together all into one place. The second thing is that most of, again with a couple of exceptions, the stuff that we are talking about is not like bugs that are going to get patched. These are fundamental issues in configuration or architecture. Oh, and one other thing. They had said that this was going to be a tool release. What ended up happening in the last six months or so was like the world of Jboss security kind of exploded. So there's a bunch of stuff that got released into Metasploit and I ended up releasing my own scanner into the Metasploit trunk. So if you want the tools, you find them in Metasploit. One more awesome PowerPoint transition. Yeah. Okay. So what is Jboss? How many of you are already people who use Jboss, and that's why you're interested? Wow. Okay, a bunch. How many of you use WebSphere in the wrong room? Okay, over there. Okay. So you guys already know what Jboss is, but just really quickly, Java EE application server. People like it because it's open source. It's by Jboss, which is now a division of Red Hat. And basically what any of these application servers do is abstract the infrastructure so that the developers can focus on just writing business logic. Jboss specifically is like really big and complex. There's a lot of stuff in it. You could look at it for a long time and not see everything. I think that's where some of the issues we're going to talk about come from. There aren't a lot of straightforward ways to do a lot of things. I just wanted to post this little snippet. This is from the Jboss security blog. This was in response to a talk that Chris from Spider Labs did at Black Hat Europe. It was a similar talk. And basically what the Jboss security architect said was like, well, this is how it ships and the developers will know better and they'll secure it before it goes to production. This is like late 90s style security response. I don't know about you guys, but this does not thrill me. I will say though, however, that I got a nice concerned email from Red Hat security response. They do a good job, I think. There's some kind of disconnect happening there between the Jboss side and the Red Hat side. Go read the whole blog post, by the way. You should check that out. Just to talk really quickly, most of what we're talking about here is going to be focused specifically on JMX, which is Java management extensions. Again, it's kind of complex. I feel like Java people like to make up these big like Rube Goldberg type contraptions. Are any of you guys those Java people? So what you've got at the bottom here is the instrumentation layer, the probe layer. And basically that's where M beans or management beans sit that allow you to manage the internals of your app server. And then there's an M bean server that allows you to interface with those. And the ways that you interface with them is via connectors and adapters. The difference between the two is not really important, but the point is that there are a lot of different ways that you can connect in and ultimately interface with these M beans, which as an attacker is what you want. You want to get in and remotely manage the server. So okay, so welcome to Jboss. This is the default page you get with your Jboss installation. There's some interesting things that links you to here and we're going to talk about them. So the main way that we talk about really doing Jmx on Jboss is a web application called the Jmx console. Just notice by the way that I'm looking at the slides over here when I have them on a screen in front of me. So you get a web interface to M beans or to Jmx. And things to do with the Jmx console, all kinds of interesting things. Deploying code is always nice. Shutting down the server is always fun. This is just what it looks like. So the Jmx console is installed by default with zero security. You put up your Jboss server, there's the Jmx console, no passwords, no encryption, no nothing. So Jboss does give you some recommendations for securing the Jmx console. Cool. Some of them are wrong. Some of the things they just simply don't address. So the first thing that you tend to want to do is password protect your Jmx console. Great. There's instructions out there to do that. There's a default login module which is what they recommend that you use. Well, the module doesn't provide you with some of the things that you generally expect to see like enforced password length complexity, account lockouts after too many tries. So if you find a Jmx console that happens to be password protected, brute force away. And by the way, admin, admin is the default and you will find lots of Jmx consoles out in the wild that went to the trouble of doing the password protection but left admin, admin. So okay. I would like my app sec folks to take a quick look at this and see if you see anything interesting. So this is the login config that was the default until May of this year. What's interesting about this is that these, this by the way, came from the minded security blog. I did not make this up. So thanks to those guys for finding this and posting it. So what's interesting about this is that this configuration makes the authentication apply only to get and post requests. Well, for those of you guys who are familiar with what HTTP verb tampering is, that means that I can just use a different verb that's not get or post and I can bypass your authentication, which is great. The fix for this, by the way, the fix for this is just to remove these two lines. Just take them out. And obviously again for my app sec folks, CSERF everywhere, yes, cross-site scripting everywhere, persisting and reflected, definitely. One really interesting use case for the cross-site request forgery here is that you'll find in some cases where people look at their Jboss server and they say, wow, this is really complicated to protect. What I'm going to do instead is I'm just going to use Apache or my firewall or whatever and just not allow access from outside my network to the JMAX console. So yeah, cool. So if you go to somebody's JMAX console and you see like a 403 forbidden, that's a good time to start trying to use CSERF admins. And again, no protection really against these things. This is what I just thought was interesting. Login config is the config file that says how your different applications, including your web console or JMAX console, get authenticated to. What's cool about this is that you can actually load a new login config.xml from an arbitrary URL, including one that you control. So just remove authentication if you want to or change it, add new accounts, whatever you want to do, it's fine. And this URL at the bottom is just kind of what it looks like. I mean, I think it kind of an interesting use case. I just think it's kind of cool that you can in some cases load from remote as part of the functionality. But honestly, if you're at this point where you can run this particular functionality, run something cooler like, oh, one other quick thing first. So that was the JMAX console. There's also a bunch of different services that allow you to again, interact with the MB and stuff in a variety of ways. So there's a service, RMI adapter service, so that's just a network based, it's not web based service. But it'll give you the same functionality as the JMAX console because again, if you remember the diagram at the beginning, the MBs at the bottom are all, they're all there and you're just interfacing with them in different ways. So again, different authentication mechanism, different configuration, at the point at which you go and secure every way to get into JMAX, you've probably spent at least a whole day. I want the toggle switch that turns security on, but it's not there. Jboss comes with a tool called Twiddle. It's a command line tool that allows you to easily interface with the service. So again, you will find out in the wild places that have gone through the trouble of password protecting their JMAX console, but they don't have a firewall and they've just left this service wide open. And more, again, with different configuration, different authentication mechanisms. This stuff, by the way, I highly recommend, there are links at the end, there are references, but I highly recommend that you go check out the work that Red Team pen testing has done on Jboss. They have some tools to interact with these particularly. They have a lot of good information. So exploits, let's get to the fun stuff. And unfortunately, like I said, this stuff, fortunately for all of us, but unfortunately for me particularly, this stuff all ended up in Metasploit before I could get to talking to you guys. So this one is actually in Metasploit as of February. And it just uses the built in code deployment mechanisms to allow you to, as an attacker, deploy arbitrary code. And again, this is like I said, it's not a bug. It's part of the functionality. So Jboss 4 and lower, there's a lot of cool things you can do. You can load your arbitrary code from, again, the site that you control. There's a scripting language called BeanShell. So if the web server cannot make an outbound connection to your host, you can do the send and write one of these BeanShell scripts and just have it spit out your payload to the local file system and deploy it that way. So Jboss 5 is a little bit interesting. And I spent most of my time looking at 501. So this may be quote unquote fixed at this point, but the HTTP deployer and the BeanShell deployer, the code is all there, but it doesn't seem to be quite fully implemented. So in theory, this is something you could go like open a bug in on their JIRA and maybe it'll get fixed eventually. But if you can get a file on the local file system, and again, anywhere on the file system, you can deploy that. So think about things like anonymous FTP or broken image upload mechanisms, things like that. If you can get a file there, that's game over no matter what version of Jboss you're using. And again, check this out in Metasploit. Another similar exploit, deployment file repository, allows you to upload arbitrary files, so arbitrary content, arbitrary file names. I'm sure there is some purpose for this to exist. I don't know what it is. So this was actually reported in 2006 and quote unquote fixed because it was actually reported as a directory traversal, right? So this functionality has a default directory that you deploy your code to and you could actually traverse your way back up the tree and put files wherever you want it. Well, so it turns out they fixed that by removing the directory traversal, but they did not remove the functionality that allows you to change the base directory. So if you set this to just dot, like you see in the example here, you are at the server root. Now, not the actual operating system server root, but the Jboss server root, which means that what you're probably going to do at that point is go put your jsp command shell into one of the existing web applications that lives on the system. But you can also do other cool things like overwrite config files, you know, anything like that. By the way, this is part of what we're not really talking about much the Jboss web console, not the JMX console. So if you have JMX console deployed and not web console, this won't work. And it's fun. And I like to think of Google, you know, crawling people's unprotected JMX consoles and finding server shutdown. So some other stuff that's not deploying code, what you'll find a lot of the time is people will lock down their web console, their JMX console, their RMI, whatever, and they'll leave this status server load available. So which is fine because it's just status, right? It doesn't, you can't do anything with it. Well, that depends, right? Because what are your developers doing? Well, one thing that they're doing is they are putting secret tokens into URLs. So I just pulled a couple of examples here. You've got, I don't know if you guys can read these. The first one is a software download. So, you know, you get a link to your purchased software. It's got this secret number. So you go get your purchased software. So I recommend you guys all go get yourself some free, whatever crappy app this is. I found this next one actually in the Google cache. It's a blacked out large retailer that you would have heard of. And, you know, plain text user ID and password in the URL. This third one is really broken. If you are an admin and you are in the Jboss web console and you are viewing the status page, it's going to helpfully put your session ID right here as a parameter. So all you really need to do as an attacker, if you get the status servlet, is wait for an admin to go driving around in there and grab this thing. Other interesting things, you may not need to actually own the server at all because somebody else might have already helpfully installed a command shell for you. You can also just append a parameter full equals true to the status servlet and you can get a list of the deployed applications which can sometimes be interesting. You know, just a couple of examples I found out there. Again, this one with the blacked out stuff, large retailer you would have heard of. This other one, wow, just a lot of stuff deployed and I like the idea here that somebody may be relying on somebody not being able to guess the name of their admin functionality and so I just list them. Okay, so we know some different stuff about Jboss. Now we're just going to go find it and luckily there's a lot of help for you out there. The customer list is a good place to start. Jboss sets this X powered by header that will come in one of these formats. That thing is an absolute pain in the ass to remove. I don't know why there should be a line in the XML file that I just removed and it no longer sends this header. Look for, definitely look for that. This stuff, by the way, is all in the scanner in Metasploit so just fire that up and hit whatever hosts and you'll see all this information if it exists. Error pages give by default very helpful error messages telling you about the version of Jboss stuff like that. Again, kind of a pain in the ass to fix. You guys familiar with this tool called Shodan? You guys use this one? A couple of people? Very cool. And so one search that will bring you up some Jboss servers is X powered by Jboss. The authentication realm, if it is password protected, will always be Jboss, JMX console, nobody will ever like in reality change this. I'm almost positive of that. And obviously our favorite, you can Google Dorket. So we see we've got like 550,000 results. These are probably not all unique systems but there's plenty of them out there is the point. And this actually, I should point out, means that not only did we find it but that there's no authentication on it. By defaults, if I'm seeing HTML adapter, that means it's not authenticated at all, at least at the time that Google crawled it. So you guys can go have some servers there out there. I highly recommend that you check out these references. This was a short talk, kind of an intro to what's out there. Some of this stuff goes a lot more in depth. Like I mentioned earlier, Red Team. Chris, however you say his name, from Spider Labs did a great talk and then again that's a blog post with the authentication bypass that I mentioned. And I'm just under 20 minutes, so that's good. So I guess we are going to do a Q&A if anyone's interested in the thing across the hall. So thank you guys very much.