TOM STEELE: Hello, everyone, welcome
to our talk Collaberative Penetration testing with Lair.
I'm Tom Steele.
I'm currently a senior consultant at Fishnet Security.
There's my Twitter.
DAN KOTTMAN: And I'm Dan Kottman, I'm a consultant.
We do pen tests and social engineering engagement and sometimes physical
security assessments as well.
TOM STEELE: So we kind of built this tool Lair that we were
having and they include lots of file and lots of data everywhere, and 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 time when you are doing a tech with multiple people, you tend
to 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 we kind of looked at the current tool sets and
they didn't really 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 that
we will be releasing today.
It's called Lair.
At its heart it's a web application.
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,
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 the reason we chose meteor.
Was a few reasons, the first one being data on the wire,
it's very, very snappy.
Very, very fast.
The originally when you load up the application, all you get
is a bunch of JavaScript and HTML templates and then JSON
back and forth to the server.
It's very fast.
And meteor is written in JavaScript and it's one language from the client
to the server and makes developing a lot better and next
is database everywhere and with meteor they have a client
in the browser.
Whether you are writing the application, it's cool to write your queries
in the client and makes things more efficient.
You can develop a realtime 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 realtime,
meaning it doesn't do any sort of Ajax pulling,
it's using web sockets on the back end and when you have
that query in the browser, whether those queries kind
of invalidate in the daily changes, everything else will update as well.
It's built to be very, very realtime and that's what we were looking for.
Of course, the web application is only useful if we can get data into it,
via, you know, all the automated tools we use
and so Dan will talk about how that happens.
DAN KOTTMAN: Yeah, the tools that we consume the data,
we call drones, they are command line tools principle
in Python that use a common API and they parse a data from some
of the tools we commonly use for our pen tests and that would be we
have drones for Nessus, Nexpose and Burp and Nmap.
We thought we would get some better community support if we wrote them
in Python rather than JavaScript because that can be difficult 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 are just sitting this 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 a you know,
something that you run in house, that maybe
the community wouldn't want.
It would be a little bit easier to kind of integrate with the framework,
if it was decoupled.
TOM STEELE: So the majority of this talk is actually going
to be a demo.
We are going to show off the app now.
All right there.
We go.
All right.
So I'm just going to create a project real quick.
So when you first create a project, you are 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 and operating name.
Everything in Lair, you can do manually.
We do a lot of manual testing.
You can enter data from many different data points but,
of course to 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 will import into that.
So do that, you grab this unique identifier here.
And you use the client side, Python drone Nmap.
And then I will bring in the first Nmap, and this is a vanilla scan,
so no scripting engine, no operating system detection.
All right.
So it actually parses on the client.
It connects to the database and inserts it.
So as you can see this automatically got repopulated.
This was no screen refresher or anything like that.
Let's take a look at the 1.2 address.
And you can see it 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 that 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 post,
with version detection.
It comes back fast enough.
You can see it automatically updated the product of that host.
There was no Ajax pulling or anything
like that it was automatically synced up with the client.
If there's something that's missing, they will add to them and that's kind
of how it that's 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 when you run a ton of Nmap scripts, you run a bunch
of different files and you have to look at them manually or parse them
out yourself.
We made the drones parse those.
So this is this next scan was a full scan of my network,
first version detection, operation detection
and script scanning enabled.
As you can see, that we get the FTP anonymous,
Nmap scripting output put in what we call
a service level node here.
This is just the service level view and 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.
We just imported Nessus.
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 killer based system.
(Applause).
Oh, my God, was that boring!
All right.
Here we go.
Somebody take that.
You guys know the drill.
These are new speakers.
All right.
Get up here.
I love that.
We walk into rooms and people have their
hands up.
It's awesome.
What do we call this, Paul?
What do we call this?
Shot the n00b.
That's right!
What is your name?
Nassem.
We have Nassem and we have our speakers, who I don't know.
Tom and Dan.
Do we have shots?
We do have shots.
I'm just trying to work.
I'm sorry.
So we've, you know, done a couple of these already today.
This hour.
Somebody Somebody pull that bottle away from him.
Do you guys drink before your talk?
No.
I'm sorry have you not been to DEF CON before?
(Laughter).
All right.
You are doing two shots!
(Laughter) Wait, wait, wait.
Thank you.
Welcome to DEF CON!
(Applause) Good man.
And I'm sorry, DEF CON has been canceled.
(Laughter).
That's the price you pay.
Just remember this.
All right.
TOM STEELE: Round of applause for Dan for taking the bullet for me.
And now look what you have done.
You have 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.
What we came one was a color coded based system.
First, I need to add Dan to my project here.
So now Dan has full view in the application and we came
up with this color coded based system that has five different colors you see
gray, blue, green, orange, blue and red and
they 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 is doing at all times and I don't want
to duplicate the things he's doing.
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 is working on that.
And then what would happen is we turn them green,
there's no serious issues.
If we turn them orange, that means we want to come back
to it later and if we return it red, that may be a foot hole
in the network or it's pwned or there's sensitive data linking
out of that thing.
That's the color coded based system that we came up with,
so that we can track exactly what we are doing and not duplicate work.
What is 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 we can really
focus on and see what hasn't been done.
And this works at every level, the port level,
the vulnerability level as well.
And we imported the Nessus scan and you can see the list
of vulnerabilities got imported in here.
You can make these manually, et cetera, and like I said,
they all have statuses as well.
The typical things that you would expect, a description, evidence,
solution, a list of hosts.
These are all linkable, everything like that.
And, you know, any notes that might be available
as well.
The next thing that we kind of want to show do you want to put
the project the client side update.
Since you know, this is the best thing about meteor,
is it allowed client side updates.
For security purposes, any time you have a database query,
it gets shipped down to the server but we do allow you
to turn that functionality on, so you can do anything
on the client what that lets you to do is create some interesting JavaScript
scripts that you can run in your browser.
I have to allow these and you are giving the security warnings telling that you
are 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 is it's kind of lengthy, but it just goes
through each host, looked to see if any of those hosts have any available
services and if they don't, it will turn them green.
Because there's nothing to test, and when you are testing thousands
of hosts, this can be efficient.
You can write one off JavaScripts to transform your data in various ways.
So if you just open up the script browser or console,
I'm sorry, and you paste this in, get so you can see.
So I not .6 and .46 don't have any queries.
They are run on the client and they are shipped on the server and
the data has been updated.
Another cool thing that's just built in is chat.
So if you are on an internal engagement
or something and you don't want to feel like getting around a firewall,
you can just use the in built chat like that.
Yeah, and that's kind of it.
There are other things, such okay.
Next thing is this service tab, a very common thing when you are
on a penetration test.
You want to get lists of hosts that have certain
services open.
You can do that here and search through these
or you can also click.
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 might be able to build
a drone that adds these in.
So they're shown here.
They are shown at the top service level view here
and then they are also given to you in kind
of its own tab here as credentials.
So that's it.
Let me bring up the slides a second here.
So the next step that we have in the project
is that we need more parsers, like we said, we only have them
for four tools.
We would like to write more tools.
I know Qualys is a big one.
We would like the community to contribute writing them as well.
One of the biggest things we are looking at doing is sinking
with the metasploit database so you can use both applications and have
the data sync simultaneously.
And another big thing is we know we need
more documentation.
When you see the GitHub site, you can see that the documentation
is pretty sparse.
We have been spending the last six months on this, trying
to make it very, very polished.
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 precompiled packages so it has
the 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 are each they are
for Linux 32 bit and 64 bit and IOS.
I will upload them.
You can follow the GitHub address and track it there.
Also if you want to hit me up on Twitter and that's my name
on freenode and that's Dan's Twitter.
We have some extra time.
Are there any questions?
Yes?
AUDIENCE MEMBER: Just quickly, why did you (Inaudible).
TOM STEELE: Yeah, so the way meteor works, as I said,
it has the database driver written on the client.
We deny all of those so the query is shipped on the server.
That security warning is basically saying, hey,
you are going to allow all of your users to modify
the database without think sort of validation.
So open the server we actually do pretty strict
validation of what end data you are putting
in so it will validate that you are putting an actual IP address on.
Those settings are only available to administrative users.
Any other questions?
Okay.
Well, thanks for coming out.