Naomi, which is probably most of you. My name is Weasel. I'm a member of the Nomad Mobile Research Center.
It's an international group of hackers that's been around for, oh, seven, eight years? Something like that?
Yeah, and we've just, you know, had thousands of projects that we all worked on,
and probably maybe 1% of them have actually been finished and made it to fruition.
Hopefully we've got a few here that might impress a few people,
if anything, maybe inspire them to take them and do something useful with them,
instead of them just sitting on our file server.
Okay, I don't know, am I supposed to read these things? No, okay.
These are a few quotes, feel free to read.
Let me go ahead and introduce a few of the members.
Most of you know Simple Nomad. He started the group. I think he's known for his goat porn, and Pandora.
So if anybody has any support questions with Pandora, that's thenome at nmrc.org.
Anyway, next to him is Jay Random. He's another long-term member, and probably his claim for fame is...
I won't embarrass you. He was the maintainer of the Hack Fact for many years,
and if we actually have time at the end of our presentation, he'll go over what's happened with that,
and why it's not as up-to-date as it probably should be, or if it even should be up-to-date.
And then over there is Mad Hat. If there are any single ladies in the audience, he will buy you a car.
So, speak to him afterwards. I'll let you introduce your personal life. It's Mad Hat.
He's recently joined the group, and he's coming up with some really exciting projects. And that's who we are.
Okay, we'll go on to the where section and see what tools we've been going over here. And this is yours.
First off, a tool that I had worked on previously called Encrypt. And I've talked about it previously at other conferences,
so I'm not going to go into a whole lot of detail on it. It's a symmetrical crypto tool.
The one thing, and it also had some file wiping features that came with it, and it was kind of nice.
It included AES and Serpent and TwoFish. Included in that, Todd McDermott, who's contributed code to the project.
I don't know if Todd is here. Is Todd McDermott in the audience anywhere? I was going to have him stand up.
Anyway, he's contributed a lot of code to the project, and it's out on SourceForge if you're looking for it.
But anyway, I'm hoping to get up... Todd wrote a drop-in replacement for RM called NRM, which does basically secure wiping of a file where it does multi-passes.
And it forks off into the background and kind of runs and does all the passes so you get your prompt back.
And that's the main thing that we've added into that. The other thing is, believe it or not, we put in...
We had a lot of people asking for integration for the Encrypt tool into scripts, where they actually...
And this was requested, say, we want to be able to pass the password on the command line or from a text file, which is horrid.
However, they're wanting to do it for encrypting log files before transmitting them from one machine to the other.
I'm not exactly sure... I don't use that feature, but I had enough people do it.
I put it in there, and it's in the man pages. It says it's highly dangerous.
But nonetheless, it's in there in case you want to assume that the box that was broken into makes sure that those log files that they get across there in a secure fashion.
Anyway, next, Mad Hat. Why don't you come and talk about that?
Alright, so, actually this is three different tools I wrote a while back.
This is designed for short people, it's not my fault.
Alright, can everybody hear me now?
I'll take that as a yes.
Alright, so these are actually three different tools.
I had a project where I had to scan a large number of IPs on a daily basis and figure out what exactly was changing, what was going on.
I love nmap and all the work that Fyodor has done on that.
Unfortunately, it wasn't quite fast enough for what I needed, so I wrote the nmap wrapper.
And what that does is it runs a bunch of nmap processes in parallel.
Stores all of it to flat files right now using the graphical output.
The other two tools work off of those databases.
nmap report basically allows you to go in and specify what you want to see.
So, show me all the hosts that are windows.
Show me all the hosts that are nmap 480 open.
nmap diff allows you to specify two specific dates and give you the diff on all the hosts or any particular host.
The whole idea is being able to monitor large networks for changes.
By default it only shows you new things are added, but you can also show whenever things go away a whole new host that comes up.
And it just makes it a whole lot easier than trying to look at something that you only see a snapshot once every week or something of that nature.
It shows you daily changes.
Oh yeah, so I was...
For this particular project, I was scanning around 150,000 IPs a day.
And I had it down to around 10 hours to scan all 150,000 IPs, so I could have done it twice a day if necessary.
From a single box, 3BSD box, sitting in a DMZ, scanning hosts worldwide.
This was not like a single location.
This was boxes all around the world, trying to deal with network latencies, you know, and well, the speed of light, things such as that.
So it came in extremely handy.
Alright, so for those of you who are at Black Hat, we went over this at Black Hat.
The idea is single packet authentication.
This was really a project just to see if it could be done.
I run the local DC group in Dallas, which is DC214.
And we started discussing a year and a half or so ago, you know, after Port Knocking came out.
Is there a better way of doing this?
You know, do we really need to send multiple packets?
Can we do it with a single packet and make it not replayable and make it, you know, secure and actually do more than just open a port?
You know, can we run commands?
Can we do things like, say, reverse shell?
Do we have to have any ports actually listening?
So this is what we came up with.
It's a simple protocol.
It allows a remote user to authenticate the system.
There's nothing listening.
It sniffs all the packets that are coming in.
We use PGP or GPG to encrypt the data.
And whenever you do that, if you just use raw encryption, what is it, eight bytes in?
Eight bytes in, there are four bytes that are the GPG ID of the key that can decrypt it.
So basically, we look for that, we see that, we pass it on to the processing engine.
Of course, it's free.
Why not?
Well...
And of course, one of the issues we wanted to deal with was working across NAT because we always hated, you know, having somebody call us up.
Hey, I need to be able to check my mail on such and such host.
Okay, what IP are you on?
I'm on 192.168.
No, no, no, no, no.
What IP are you going to be coming from?
Well, it says 192.
Oh, Jesus.
So, they can send, you know, with the client, they can send a single packet and it looks at the source address and says, oh, okay, so we'll open it up for that IP.
And then, of course, it monitors the traffic and after a certain timeout, it will automatically close the port.
We're also, you know, working with the idea of doing a reverse shell, so you send a single packet and it connects back to you.
And then we can also have it to where, in our sample code, where you can run arbitrary commands.
And the commands are specified in the config file, so it's not like anybody who has access to it can run any command.
You have a comma-separated list of the commands that are allowed to be run by that particular user.
This is a visual representation of basically how it works.
So, over on the left-hand side, you have the client with, you know, its GPG ID.
It encrypts all the data, which includes, you know, an ID, session keys, timestamp, and then the command and control data for the application that's using this fault protocol.
It's encrypted and signed, you know, encrypted for security and signed for authenticity.
And then it can be, you know, it's a data packet. So, I mean, it can be TCP, UDP, ICMP, anything like that.
We've implemented TCP and UDP in our sample code.
And then, of course, you know, it encrypts it with the server's key.
The server gets it, verifies that it's, you know, encrypted data, passes it on.
It's kind of an idea of how it's laid out.
I'm a Perl hacker, so the parts that I worked on are in Perl.
The client right now, you know, can be on whatever host.
Sends the data.
SPA-D is basically a simple sniffer.
Nomad Spark written in C.
Once it verifies, you know, what it's looking for, sends it on to the SPA engine, which then calls GPG as necessary to decrypt.
Checks the user config to verify, you know, whatever they're asking to do can be done.
And it also keeps track of firewall states.
So, for some reason, the daemon, you have to restart the daemon, and it's going to know what ports were already open and still keep track of them and close them as necessary.
And a whole new one.
And we will have time for questions a little bit later.
Alright, so, at the job where I was mentioning where I wrote the nmap tool, my primary responsibility was scanning and monitoring of large groups of hosts.
A whole lot of web servers and Unix boxes.
At the time, whenever I first started on this particular project, there wasn't a lot out there to be able to scan all those same IPs on a daily basis, you know, for basic misconfigurations.
Vulnerabilities, things such as that.
So, I wrote, I started off writing a very simple HTTP scanner, and it kept growing and growing and growing.
Works off command line, or it has a web-based GUI.
You know, same script, just depends on how you call it.
The configs are all in XML, so it's really easy to add and remove things or expand them.
Lots of command line options to specify exactly what you want to scan for, how you want to scan it.
Runs a whole bunch of processes in parallel, according to, you know, whatever your system can handle, so it's fairly quick.
I added in, I started adding in some other features, like FTP to look for anonymous access, look for writable directories, things such as that.
The SQL stuff was added because, you know, I happened to be working on parts of it whenever, you know, the whole SQL Clamor thing came around, so it was easy to add in other features.
There was also some SMTP stuff, but, you know.
It is extremely fast, that was the whole idea.
You know, once again, I was scanning a large number of hosts.
Needed to get it done, you know, in a short amount of time.
The way the output works, there are multiple outputs.
You know, there's a verbose output that would actually tell you, here's the vulnerability and here's the fix, and, you know, standard stuff for a scanner.
But it also, another thing was, it was written so that I could export the data, import it into a database very easily.
Also worked a whole lot of time on false positives.
For anybody who's done any, you know, constant monitoring of hosts, the big thing is, oh look, there's a Apache vulnerability running on an IIS box.
Yeah, that makes sense.
So, I spent a whole lot of time making sure that there were as few false positives as possible, looking for a whole bunch of different things.
You know, looking for custom 404s, you know, things that, it's starting to become a little bit more common in scanners, but at the time...
And of course, once again, it's free.
Hey, I'm gonna stand up here for a while.
Alright, so here's another one.
Once again, in Perl.
This one, the idea is ICMP packets are sent out with a forged source address.
The whole idea was, on the corporate network, we wanted to check to see if people had DSL lines or modems, you know, something,
or even misconfigured network devices, so that things were being sent out the wrong direction.
I wrote a small Perl module that allows for looping, so all of these actually use the same Perl module,
so you can actually specify ranges of hosts in, you know, almost any format.
Makes it really easy to run.
So, what this does is it forges an ICMP echo request.
The data contains the IP that it was supposed to be sent to, as well as a signed key,
which is just using MD5 and a shared secret.
The server snips those on that forged address.
Whenever it comes in, it looks to see if the source, where it was being, where the echo appliance is coming from,
is the same as within the data portion.
Because the nice thing about ICMP is, whatever you send it in the data portion, it sends back in the data portion.
So it made it very easy to be able to do this.
So I was able to find DSL hooked up to a corporate network.
Somebody had gotten a DSL line run to their desk.
How? I don't know. I wasn't involved in that part.
But basically, their default route went out to SBC.
So I'm sitting here spewing packets to the 192 space, and all of a sudden I'm seeing data coming back from SBC,
and that's not a good thing.
And of course, my favorite was the networking devices that had odd routes added for no apparent reason.
Of course, the networking guys denied that it was on purpose or anything like that,
but it got changed rather quickly after you find it.
Once again, fast, simple, very specific problem to solve.
Okay, here's another contribution of mine.
This is NPC, Nearly Perfect Crypto.
And I'm so glad you're sitting right there in front of me. I really am.
What this does is it's mainly meant as an academic tool, okay?
Fuck you. I got mud up here causing shit for me.
It really is meant as an academic tool, and I'll tell you why.
I mean, there's a lot of people that don't understand how one-time pads work.
What this is is an implementation of a one-time pad, okay?
And the reason I say it's Nearly Perfect Crypto is because it is perfect,
but it is as only reliable as Isaac, the pseudorandom number generator that I've got in there.
And it is only as perfect as your key management, which is actually kind of the bad thing.
So if I'm going to send, let's say, goat porn to Mudge, because...
It wouldn't be the first time.
No, it wouldn't be the first time.
Then what I would do is I'd say, hmm, well this file is 30 meg in size,
so then I'd need to generate a 30 meg key to make it happen.
And then the trick is, is me getting that key to him,
and then us never ever using that key ever again for anything.
Destroying the key after it's done.
I mean, literally, if I put it on a CD and hand it to him,
and then we're done with it, we need to destroy the key.
Perhaps with that NRM file that I had previously,
or we throw the CDs into a vat of acid,
or however you manage your paranoia with your CDs at home.
However that happens.
Anyway, because you're doing something which is like a one-time pad,
it makes the crypto part, really it's not very complicated.
You're just doing a simple XOR.
So it is very fast, very simple, it's really nice to do.
Like I said, if you can manage the key exchange,
you're getting damn close to having pretty good crypto.
Anyway, just to show you why this thing is so fast and secure,
here's the main, and I have it in quotes there,
crypto loop, because it's hardly a loop.
And if you look right down here, toward the bottom,
oh my god, I know why he showed up.
You'll know in a minute.
Where it says, wicked crypto, because we are XORing.
And you can see that massively intense one line of code there
that kicks so much ass.
So anyway, we have this tool there to kind of play with this.
And I'll tell you the truth, the main reason,
actually, truthfully, the main reason I wrote this tool
is because there's a friend of mine
who we would like to really, really have some deep, serious conversations with.
And we were talking about, well, how in the world
could we actually do this in a secure fashion?
Well, okay, we have a smartass up front who thinks he knows something.
But nonetheless, we just kind of went over various scenarios and everything.
So I've come up with this thing.
By the way, this and all the tools, we're going to have a spot out there
on the NMRC website.
We'll put something up on the front page.
Hopefully I'll get it done tonight.
And we'll have pointers to all the tools, all the presentations.
Please, all questions at the end, please.
And, oh, well, see, now it's at time for Q&A.
Now, this is the thing we're going to do.
For the Q&A, because this is kind of a dry kind of tool talk,
so what we're going to do, something different from the Q&A,
is during the Q&A portion of this,
we're going to go ahead and spank audience members
who want to be spanked.
Now, the thing that we're going to do is,
the first thing is, if you're coming up here,
I mean, obviously there's no female members,
although I think we may be able to recruit some females
that we happen to know to come up here to help spank.
Lily, come on up.
So you're going to have a choice of, you know,
not only being spanked by a guy,
but you can be spanked by a chick.
Okay, now the thing is, if you want to be spanked,
we do have a release form you do have to sign.
If anyone has been reading on Full Disclosure,
we did post a link to the release form,
so if you filled out one previously,
that you printed off and filled out,
feel free to go ahead and bring it up.
Let me get out the stuff that you're going to be spanked with.
Hold on just a second.
Alright, the first thing that we're going to spank people with
is a ShmooCon, this is from the Shmoo group.
When I was at ShmooCon, all the speakers got these
because they handed out Shmoo balls to throw at speakers
that weren't behaving well, or being stupid, or causing shit.
So they gave the speakers something to fight back with,
so we have a Shmoo group paddle that you can be spanked with.
You can also be spanked via a nice firm hand.
And the final thing to be spanked with
is a copy of the third edition of Hacking Exposed.
And just to show how it's going to work,
I want to bring Mudge up here and spank him.
Let's get Mudge up here.
You guys should have seen the rehearsals.
I would have to look at the code specifically.
I stole some code from Todd McDermott
because we worked on entropy stuff.
Part of it is we're using processor timing speeds
and we're throwing in some... I forget the exact call.
It's one where you're saying,
slow down, I'm relinquishing the processor,
and so I get a random time.
And so that gives me...
between that and some other stuff thrown in,
like the times and stuff.
Okay, there you go.
Okay, thank you.
Anyone else? Anyone else want to...
Comments instead of questions?
Yeah, go ahead. You got a comment?
Two comments, go ahead.
All right.
You want to get spanked while you're getting your comments?
Who do you want to spank you?
Sign the release form.
He signed it.
Woo!
Jesus.
Notice he didn't read it first.
Give him a mic.
Okay, so my first comment is your single packet authentication thing.
Talk about using it behind a NAT
so that you could open up a service and so forth.
Aren't you opening...
You're opening up that service for everything behind that NAT
and everyone behind that NAT.
Isn't that kind of insecure?
Yes.
Using the Internet is known to be insecure.
Yes, of course it's insecure.
Okay, just a comment on that.
Really what this is,
it's not considered true authentication on there.
All you're doing is you're opening up the port.
Obviously, you'd be opening up the port
and then some other process
would handle the authentication.
So the tool's misnamed.
No, we are authenticating.
You actually are authenticating.
You're saying, I am who I say I am
if you trust PGP.
And then if you trust PGP
and it says, okay, I've signed that key,
then yes, I know who you are, so I will at least open up the port.
Now you've got to go ahead and provide credentials
to get access to the box.
So it's considered a layer.
Okay, so the second comment is
your tool where you used spoofed ICMP
in order to try to map network topology.
The fact that your client
has not implemented anti-spoofing measures
on his network all the way down to layer 2,
the fact that the tool is allowed to work on the network
means that you need to recommend to your client
that he implement the anti-spoofing technology
so that your tool won't work.
Because it's best practice not to allow spoofed traffic
to traverse your network or egress from it.
You're assuming this is for business.
I think it's for any kind of IP.
Don't forget, you're going to come up here spanking.
Which did you want?
Alright, next question.
Next question. We've got to keep things moving.
Come on, there's got to be more questions than this.
And there's got to be more people than this.
Alright, who just wants to be spanked?
Come on up, we're not shy.
I see people that are like looking and thinking about it.
Come on, let's get some... I'm serious, I'm looking at people.
Oh my god, we've got people coming up.
Yeah, yeah, yeah, come on, alright.
Alright, sign a release form and get your ass spanked.
He's going to read it first.
There's check boxes on there.
Oh, like to who you want to be...
Yeah, like I would like to be spanked by.
Check all that apply.
Oh, we need a beer up here too.
If someone could bring Helen back a beer.
Yes, he has a heavy thing to drink in three minutes.
Please.
Also, the names that you want to be called
during the spanking,
such as, you can check all that apply,
like Biatch, Script Kitty,
Scene Whore, Russ Cooper,
a number of different ones.
Oh, there, we've got a beer.
We've got a beer for you.
Any other questions while we're at it,
while we're getting some people ready to be spanked?
This guy's already signed.
Who do you want to spank you?
Alright, there we go.
Alright, who do you want to have spank you?
Me?
What instrument?
Ah, USAP.
Alright, anyone else got any...
I want to bring Jay Random over here
and talk about why the hack pack
hadn't been updated in ages.
Basically, it's all your fault.
So, I think we were here
maybe two years ago?
Was that the last panel?
Yeah, so two years ago,
I spent maybe a good few months
taking the hack pack as
Nomite had left it,
updating the HTML so it was all valid,
updating all the URLs so they weren't broken,
updating a good amount of the content
so that it was relevant to today.
You know, stuff that had been documented back then
but wasn't known at the time.
And so we basically came to people
and said, we've redone everything.
All we need is your input.
We need more questions,
more frequently asked questions
that we can get documented in the pack
so we can improve general knowledge
in the community.
And we just got spam.
That's all we got.
Penis enlargements,
credit card bills,
so yeah,
the pack's pretty much dead.
We're going to keep it online,
but clearly no one's really interested
in adding to it,
so we'll just keep it as a kind of
historical record, I guess.
Alright, I think we're right
back toward the end
of the presentation.
I wanted to go ahead and actually finish up
with a couple of specific announcements.
The girl in the picture, yes,
she is wearing an NMRC t-shirt.
And yes, I have the world's
most understanding wife
because I actually paid for the model
and paid for the photo session
to get these pictures, in particular,
just for DEF CON.
And we will make sure that
some of the artwork is available
on the NMRC website
so that you can use it for
backgrounds on your computers.
And got a few shoutouts in there.
CAU,
they're represented over here.
There's some green guy, that if you see
the green guy, then you know that
CAU, they've been very supportive
for us. Obviously,
all the DC 214 people, because
a lot of the talks and stuff
that we give, we try them out on our local
DC Groups thing.
Also, Mad Hat's going to be participating
in the DC
Groups panel that's on later this evening.
John Kallis, I saw him at Black Hat.
He had some ideas for
SPA that actually were pretty good, that we had put
in there, and shoutout to him.
Of course, the rest of the NMRC people that aren't here.
Mike Rash, who is
somewhere out here in the audience. There he is, right
there. F.W. Knopf,
which actually was
here last year,
actually is very similar. He's very
similar to SPA, so we've been talking with him
and everything.
And I just want you guys to know
that we're trying, we're going to be
actually, our first planning session
for DEF CON 14
is going to take place later tonight.
And we
promise that we're going to have something
really big
and fantastic for you guys.
We really appreciate
all the support that you guys have given us
over this
wondrous
time that we've been having.
So, really do appreciate all
the support from everyone. We'll try to
do our best to give back
as much as we can
to everyone here. So,
if we have nothing else,
just want to say thanks.
Oh, we have something over here, yes.
The rumor
is what now?
There are,
yes, of course there are rumors that it's not going to
be here at Alexis Park
next year. I don't know
because there was those same
rumors last year
as well.
I know there's rumors floating around at ShmooCon
for example that it might not
be here this year, but in fact it
was. So, I
don't know. I mean,
as much as I
can, I try to slide my tongue down the
back of Jeff Moss's
trousers, but he really doesn't tell me
much as an exchange
for kissing his ass.
So, I don't know. Take that up with Jeff
actually. Another question.
Okay.
Suggestions for the hack pack, we'll take...
we'll get on that
right away. Okay.
No, and again,
all the code and stuff that we're talking about, we will
have links up to that stuff. I'll make sure that stuff gets
put up tonight.
So you can pull it down, play with it,
break it.
A number of us have been writing code.
We don't profess to be coders.
So, if you come up with...
In fact, for example, SPA
had a remotely
exploitable heap overflow in it
until I found that and corrected it.
Okay.
Anything you guys can do to help add
to it.
And if you come up with some better idea
than what we've got,
then that's even better.
That means we've inspired someone
to come up with something that's actually
encoded by real coders.
Instead of just hacker types.
Okay.
Do what now?
Oh, yeah.
And if you find
any zero days in any of the
code that we release, we recommend that you go ahead
and turn it into iDefense because they need
the help. Okay.
They really do.
Alright, so, that's it.
We will see you guys next year
and at cons in between.
So, thanks a lot.