 Hi, everyone. Welcome to our talk, collaborative penetration testing with Lair. I'm Tom Steele. I'm from Seattle. I'm currently a senior consultant at Fishnet Security, and there's my Twitter if you want to follow me. And I'm Dan Koteman. I also work at Fishnet. I'm a consultant. We do pen tests and social engineering engagements, sometimes physical security assessments as well. So we kind of built this tool Lair to fix some problems that we're having on our penetration tests. And those include lots of files and lots of data everywhere. Lots of terminal windows open. Just tons of files everywhere and no real way to correlate those. The other problem we wanted to kind of fix was duplication of work. A lot of times when you're doing a attack with multiple people, you know, two or more, you tend to sometimes be looking at the same thing and it's not very efficient. The next thing we wanted to do is come up with a way to be thorough and make sure that we didn't miss anything and that we were manually investigating everything on an engagement. So what we kind of looked at the current tool sets and they didn't really focus. They all might have handled some of these issues, but none of them fixed all of our problems. So what we did is we decided to create our own tool. And that's what we're going to be releasing today. It's called Lair. And it's a web application. So it's all in browser and we think it solves all the problems that I previously mentioned. Here's an overview of the architecture in the top right corner. You see this thing called Meteor web server. So this web application is built with something called Meteor. That's a web framework built on top of Node.js which is a JavaScript runtime. The features that we, the reason we chose Meteor was a few reasons. The first being data on the wire. It's very, very snappy, very, very fast. Originally when you load up the application, all you get is a bunch of JavaScript and a bunch of HTML templates. Everything else after that is all JSON back and forth to and from the server. So it's very efficient, very quick. The next thing was Meteor is all written in JavaScript. So it's one language from the client to the server. It makes developing a lot better. Next is database everywhere. So with Meteor, you actually have a database client in the browser. So when you're writing the application, it's very, very cool to be able to write your queries actually in the client and kind of makes things more efficient. You can develop a real-time application very, very quickly. The next thing that's probably the best feature of Meteor is full stack reactivity. Everything that you build in Meteor is real-time. Meaning it doesn't do any sort of AJAX polling. It's all using web sockets on the back end. And when you have that query in the browser, when those queries invalidate in the data changes, everything else will update as well. So it's built to be very, very real-time. And that's kind of what we're looking for. Of course, the web application is only useful if we can get data into it via all the automated tools that we use. And so Dan's going to talk about how that happens. So the tools that actually consume the data, we call drones. They're command-line tools written in Python that use a common API. And they parse the data from some of the tools that we commonly use for our pen tests. And that would be we have drones for Nessus, NexBos, Nmap, and Burp, as well as a raw JSON one. And we wrote them in Python for a couple of reasons. We really thought that maybe we would get some better community support if we wrote them in Python rather than JavaScript because that can be a little bit difficult, I think, to code in, especially if you don't have any experience with it before. And we also decoupled it from the application rather than building it directly into, you know, the Meteor Node application because we didn't want to force people to upload their files to the server just to import them. You know, you're just sitting there watching your browser spin as it's importing. It's a little bit annoying. And we also wanted it decoupled so that, you know, if you develop a tool to consume data, maybe it's for, you know, something that you run in-house that maybe the community wouldn't want, it'd be a little bit easier to kind of integrate with the framework if it was decoupled. So majority of this talk is actually going to be a demo. So we're going to show off the app now. So I'm just going to create a project real quick. So when you first create a project, you're brought into this kind of centralized host view. So if we had some data in here, it would be showing you a list of all the IP addresses, their host name, their operating system, and who last modified them by. Everything in there, you can do manually. We do a lot of manual testing. And so we really need to be able to, you know, enter data randomly from many different data points. But of course, to kind of populate these initial things, you of course want to be using automated tools such as Nmap. It's a great tool. So to do that, we're going to import into the app. So do that. You grab this unique identifier here. And use the client side. Python drone dash Nmap. That's kind of the naming convention that we chose. But if you can name these things anything you want. And then I'm going to import this first Nmap file. And this is a vanilla scan of my network. So no scripting engine, no version detection, no operating system detection. All right. So it actually parses it on the client, connects to the database, and inserts it. So as you can see, this automatically got repopulated. There was no screen refresh or anything like that. Let's take a look at this .1.2 address. And yeah, you can see that it's all got populated. This is the service level view. So it kind of drills down into each service for each host. And take a look at this telnet service here. And you can see the product is set to unknown. That's because we didn't have any version detection on Nmap. So I did a second scan of just port 23 on this host with version detection. And you can see it automatically updated the product of that host. There was no AJAX polling or anything like that. It was automatically synced up with the client. So these drones are all additive. Meaning if there's something that's missing, they will actually add to them. And that's kind of how they all work. That's how the API works. The next thing I want to show off is the Nmap scripting engine is great. But what happens is when you run a ton of Nmap scripts, you end up with a bunch of different files. And you kind of have to look at them all manually in something like Vim or parse them by yourself. So what we did is we actually made the drones parse those. So this is, this next scan was a full scan of my network, both version detection, operating system detection, and script scanning enabled. See that we get the FTP anonymous Nmap scripting output put in what we call a service level note here. And this is just a service level view into each port. You can move back and forth between them. You can update and modify all of these as well. The next thing, so that kind of takes care of importing our data, right? Let me import a Nessus scan real quick. Okay, so once we just imported a Nessus scan and it again added more information such as host names identified and operating systems detected. The next thing that we wanted to work on was the collaboration effort and not duplicating work. So what we came up with was kind of this color based system. Oh my God, was that boring? All right. Here we go. You guys know the drill. These are new speakers. All right, get up there. I love that. We walk into rooms now people have their hands up. It's awesome. What do we call this ball? Yeah, what do we call this? Shot the new. That's right. And what is your name? Naseem. Naseem. We have Naseem. We have our speakers whose names I don't know. Tom. It's Tom. And Dan. Do we have shots? Oh my God, all right. So we've done a couple of these already today. Somebody pulled that bottle away from him. Did you guys drink before you talk? No. I'm sorry, have you not been to DEF CON before? We're doing two shots. All right. Welcome to DEF CON. And I'm sorry, DEF CON has been banned. All right. Round of applause for Dan for taking the bullet for me. And now look what you've done. You've locked my computer. Okay. So now I have to move really fast. But the idea here is that we didn't want to duplicate work. So we came up with this color coded based system. So first I need to add Dan to my project here. So now Dan has full view of the application. And we came up with this color coded based system. It has five different colors. So you see this at the top here. You see gray, blue, green, orange and red. And those can mean whatever you want. They mean certain things for us. In particular blue means that it's in progress. So I want to know what Dan's doing at all times. And I don't want to duplicate the things that he's doing. So all Dan needs to do is click a host. And as soon as he clicks it, it turns blue. And I can know that Dan's working on that. And then what might happen is that we turn them green, there's no serious issues. Maybe if we turn them orange, that means we want to come back to it later. And if we turn it red, that may be a foothold in the network or it's pwned or there's sensitive data leaking out of that thing or something like that. And so that's the color coded based system that we came up with so that we can track exactly what we're doing and not duplicate work. What's really neat is all of these kind of filter. So if I click that blue button, it will filter out the blue ones. If I click the green one, it will filter out the green ones. And so we can really focus on see what hasn't been done and what hasn't been done. And this works at every level, the service level, the vulnerability level as well. We imported that Nessa scan and you can see that a list of vulnerabilities got imported in here. You can create these manually, et cetera. And like I said, they all have statuses as well. The typical things that you'd expect from an application like this, description, evidence, solution, a list of hosts, these are all linkable, everything like that. And any notes that might be available as well. The next thing that we kind of want to show, I'm going to put the project update, the client site update. Since, you know, which is kind of like the best thing about Meteor is that it allows client site updates. For security purposes, we have this turned off meaning that any time you do a database query, it gets shipped down to the server. But what's very useful is we do allow you to turn that functionality on so that you can do anything on the client. And what that lets you do is kind of create some very interesting JavaScript scripts that you can run in your browser. So I have to allow these and you're given a security warning telling you that you're allowing them here. I come back to my project, load it up. Dan has graciously provided me with this script. So what this script does, it's kind of lengthy, but it just goes through each host, looks to see if any of those hosts have any available services and if they don't, it's going to turn them green because there's nothing to test. And when you're testing thousands of hosts, this can kind of be efficient. So the idea is that you can write one off JavaScript scripts to kind of transform your data in various ways. So if you just open up the JavaScript browser or console, I'm sorry, and you paste this in, you can see. So I know .6 and .46 don't have any services. So these queries are being run on the client and they're being shipped down to the server and the data has been updated. Another cool thing that's just built in is chat. So if you're on an internal engagement or something and you don't want to feel like getting around a firewall, you can just use the inbuilt chat like that. Yeah, and that's kind of it. There's other things. Okay. Next thing is the service tab. A very common thing when you're on a penetration test is you want to get lists of hosts that have certain services open. So you can do that here and search through these or you can also just click. So this is a unique list of port protocol service and product. If you click on any of these, it will reduce the search and give you just a list of the hosts with that port open. Which is very, very cool. It's just kind of a convenience thing. Another thing you might want to track during a test is credentials. So those happen at the service view. So you can add those in here or you can maybe build a drone that adds these in. So they're shown here. They're shown at the top service level view here. And then they're also given to you in kind of its own tab here as credentials. So that's it. Let me bring up the slides. So the next step that we have in the project is that we need more parsers. Like I said, we only have them for four tools. So we'd like to write more. So if you have any tools in particular like Kualas I know is a great idea. We'd like to write those or we'd also like the community to contribute writing them as well. One of the biggest things that we're looking at doing is syncing with this Metasploit database so that you can basically use both applications and have the data sync simultaneously. So we are working on that. And another big thing is we know we need more documentation. If you go to the when you see the GitHub site, you'll see that the documentation is pretty sparse. We have been spending the past six months on this trying to make it very, very polished everything works. So the code and getting it working has been our major goal here. The documentation is next. So we'll have documentation up of how you can interact with the API to build your own parsers, how you can install it from scratch, et cetera. The source code is all available on GitHub. That's the link there. We do provide you with pre-compiled packages. So it has a database, a specific version of Node, the application, all bundled up with some easy-to-use shell scripts. Those are about 100 meg each. And they're for each, they're for Linux, 32-bit, 64-bit, and OSX. I didn't have the bandwidth to upload them here at Defcon. So they will be uploaded tomorrow as soon as I get home. But you can just follow that GitHub address and track it there. Also, if you want to hit me up on Twitter, I can send you the link. And that's my IRC name on FreeNode. And that stands Twitter. So we have some extra time. Are there any questions? Yes? Yeah. So the way Meteor works is like I said, it has a database driver kind of written on the client. We deny all of those so that the query is actually shipped on the server. You can kind of do it either way. So that security warning is just basically saying, hey, you're going to allow all of your users to modify the database without any validation. So on the server, we actually do pretty strict validation on what end data you're putting in. So it will validate that you're putting an actual IP address in. That doesn't do anything of that. So you kind of have to trust what you're doing. And those settings are only available to administrative users. Any other questions? Okay. Well, thanks for coming out.