My name is Fyodor from Insecure.org.
Can you guys all hear me?
No?
Then listen up!
Alright, well...
Alright, well thank you all for coming.
DEF CON is always a blast, and it's an honor to be here
giving the opening talk to start out the conference.
This year I'm going to talk about NMAP hacking.
Basically, there are a lot of security people who use NMAP
but many of them don't understand its full power.
And NMAP deserves a lot of the blame for this
because it kind of is too helpful sometimes.
If you do a scan, such as nmap-scanme.nmap.org
you're leaving NMAP to worry about deciding on the scan type
the timing options, the output format
the target ports, the source ports and addresses, and more.
While that's helpful, reducing that complexity
in terms of making NMAP easy to use
it's also troublesome in terms of a lot of people never explore
the literally hundreds of advanced options that NMAP has
for making your scan more effective.
So in this presentation, I'm basically going to go over
three real-world common examples and scenarios
and then I'm going to demonstrate how you can use NMAP effectively
to solve them, with an emphasis on options
that are a little bit off the beaten path.
I'm also happy to be releasing a new version of NMAP
special for DEF CON.
NMAP version 3.83DC13 is available at this URL here
you definitely want to get the one on the web rather than the CD
as it's a lot newer.
It has a lot of cool features, which I'll talk about
in this presentation shortly.
Also, I'm going to give early warning now
that this presentation does use real uncensored IP addresses and host names
that's because I trust you guys not to abuse the information.
Also...
Okay, okay, but if there are any black hats in the room
who would use this information maliciously
then I'm sorry, but I'm going to have to ask you to either leave
or when the IP addresses come on the screen, just cover your eyes.
I'd appreciate that.
Before I begin, it would help me to get an idea
of how much introductory NMAP material I need to cover.
So if I could get a show of hands for anyone here who has ever used NMAP
All right, everyone.
So we'll skip NMAP for dummies
and move directly to Host Discovery.
Host Discovery covers the real common case
where you just want to look at a network
and find all the hosts on that network that are online.
Maybe you're a pen tester who just busted into a new subnet
and wanted to see what machines are on.
Or maybe you're a network administrator doing IT inventory.
Or maybe you're going to do a more intensive scan
but you want to figure out what hosts are up first
so you can focus your efforts on those.
NMAP used to only be able to send an ICMP echo request message
and later a TCP ACK to a port.
And at the time, you know, that was useful
and that's still the default
because there was a time when NMAP could send a ping request
and expect that the vast majority of hosts would respond.
Unfortunately, that time is well past.
Many hosts, you know, don't respond to a ping
even though the RFCs say that they should.
The Internet is a much more guarded and filtered place nowadays.
Fortunately, NMAP has also evolved with the times
and offers a wide variety of options
to make your host discovery more powerful.
For example, you can send SIN probes
if you want to get through a stateful firewall
that only allows SINs.
You can send ACK probes
for those stateless firewalls
that watch for SIN packets but can't tell
that the ACK is not part of an established connection.
UDP probes you can send
and all three of these types you can send to a big list of ports
in the hopes that you'll find just one of them that's responsive.
Also ICMP echo requests and pings,
timestamp requests, netmask requests,
so you have a whole lot of options there.
And you can combine those options almost arbitrarily.
But with so many options, that leaves you to the question of
well, what's going to be most effective?
And sure, I can speculate on what might be most useful
or what networks I've seen have available
but the best way to answer these questions is empirical results.
So let's start with what are the most valuable TCP ping ports to use?
I did a scan of more than 10,000 IPs
on the internet using
NMAP's random target selection option
and I took that and looked at just those hosts
that are heavily filtered because the unfiltered ones
we're going to be able to find anyway.
And of those I said, hey, which hosts,
which ports are most responsive to a SIN packet?
And this is the list starting with the most common
which is HTTP.
SMTP is also popular. SSH.
HTTPS. FTP.
Telnet's down there, but it's nice to see it below SSH.
And these are the sort of things
that you would expect to see.
If you have your firewalled host, you still have to have port 25 open
if you want to receive mail.
A lot of times they make 22 widely open
so if they're off it, but Defcon's a bad example.
But if something bad happens while you're away, you want to be able to connect in
and remotely administer.
So your best bet is to pick a variety of these.
The next question then is
what sort of TCP probes do I want to send?
There's the SIN probes and the ACK probes.
The answer is just send both.
That way if it's the stateful firewall, like Microsoft.com
your SIN will get through, but your ACK won't.
Whereas a stateless firewall, your ACK's more likely.
So send them back. All you need is one response
to tell you that the host is open. So send them both.
What about UDP ports?
Here you have a little different idea than with TCP.
With TCP, an open port is still responsive
so it tells you that the host is up.
With UDP, NMAP's blank UDP messages
are unlikely to elicit a response from an open port.
And so you don't want to hit an open one.
So your best bet is probably just to pick a high port
like 22,131 or whatever
that's less likely to be filtered.
And a little exception to the rule is you might want to try 53 as well
just because DNS is so common.
Yes, if it's open you probably won't get a response
but sometimes administrators open it for a whole section of network
and so from those machines that aren't running DNS servers
you can still get through.
For ping types, I would recommend an echo request
and then either a timestamp request or a netmask request.
The idea is that some hosts
for example Google or Insecure.org
will let you ping them.
Whereas there are other hosts that have said
hey, I'm going to block pings but they do it poorly
and they forget about the sister options like timestamp request
and netmask request.
But the ones who block the latter are likely to block them both.
So your best shot is generally to do both
or to do a ping request and then one of these others.
So let's put that all together.
Take all of these ideas and put it into one intense discovery combination.
And here's one that I would recommend.
Here we're doing an echo request, timestamp
a variety of SYN probes, ACK probes
and also setting the source port 53.
You never know when that little trick will work to get through poor configurations.
One thing to note when doing this
is that this is 13 probes rather than 2.
And host enumeration time is going to be
roughly proportional to the number of probes that you send.
And so you want to consider whether it's worth it.
But in many cases you really do want a comprehensive list
so it's worth taking a little longer.
And like I said, speculation is all well and good
but when you're deciding whether you do want to spend the extra time
or what's going to be most effective
empirical data is the best to have.
So I did a test.
I used the random target option again
to generate a list of 50,000 random IPs.
And then I ran it and mapped with the default scan types.
And it chugged away and chugged away
and eventually it said, OK, out of those 50,000 IP addresses
1,770 are up.
Alright, so now let's try it with the more intense discovery.
We use all these probes
and suddenly instead of 1,700
it gets 2,698 hosts up.
So we see a 50% improvement
just by adding these extra options.
And yes, it did take four times as long
but in many cases, if not most, it's worth it for you
because you really want to find all of the hosts.
And...
there are a couple notes that I want to make
regarding this sort of scan
and these results that we've found.
One is that it's not quite as exciting as it seems
because some of these 2,698 hosts
are going to be network artifacts.
For example, in my last DEF CON talk
I showed an example where a host that was a firewall
was spoofing reset packets
to any probe sent to port 113
on any of the hosts behind it.
And so some of these are network artifacts
and you'll have to use the sort of techniques I talked about last time
to discern which are the artifacts and which are the actual hosts.
The other thing worth noting is that
these techniques will give the most improvement
in a case like this where we're doing a worldwide scan
over the Internet against tons of firewalls
and filters and such.
If you're scanning a local LAN, the defaults may work fine.
But while we're speaking about
scanning a local Ethernet LAN
that crops up with its own big bunch of issues.
Here I do an nmap command
for a ping scan of a host on the Ethernet LAN
that's not really up.
Send IP is a new option that I'll talk about later
but for now you just need to know
that that does the same default behavior
as all of the pre-DEF CON releases.
So I run nmap and I've pasted in
some ethereal output to kind of show
what's going on under the covers.
I give the OS an IP packet.
It sends an ARP request looking for the machine immediately.
Then after one second it sends yet another ARP request
and after two seconds it sends a third ARP request
and finally it gives up and nmap ends
after just over two seconds.
And there are a couple of problems that...
Can you guys hear me better?
All right.
There are a couple problems with this two seconds.
You know it may sound, oh two seconds, big deal
but if you're scanning 10.0.0.0.8
that's 16 million hosts and two seconds is gonna add up.
Even 192.168
is still 65,000 hosts and nmap
scans these in parallel but still it's not as fast
And it's wasting time waiting for these ARP requests.
Another problem is that most operating systems, you know, they have an ARP table
and that ARP table is finite.
So when they have an incomplete entry such as this, they'll add,
that ARP table will fill up.
And sometimes NMAP has to wait, you know, as much as 4 minutes
for those ARP entries to expire.
You may have seen that if you scan a big network.
NMAP is like, hey, I can't send right now, waiting 60 seconds,
then waiting 120 seconds.
It's very frustrating.
And since scanning your own local LAN is extremely common,
that's something that's worth optimizing.
And so one of the features in the new NMAP is ARP scanning.
The idea is give NMAP full control to send those ARP packets.
That way NMAP can worry about the timing and the retransmissions.
It can skip over the ARP table for the OS entirely
and do the scan a lot faster.
Another advantage, not only is it much faster,
but it's more accurate.
You know, as we've already seen, many hosts have all sorts of filters
that can block your host discovery packets.
But if they want to communicate on the network,
they generally have to reply to ARP.
So if NMAP gets an ARP reply, it knows that it's online.
So here's a quick example I have here,
where I scan the same machine as before with the new NMAP,
and instead it sends one ARP at the beginning,
and then one ARP after a tenth of a second.
And then it gives up in two tenths of a second.
So it takes, you know, less than an eighth of the time that it took before.
I can try and do a live demonstration here,
which is always risky at a conference, but we'll give it a try.
So here I'm doing NMAP, a ping scan.
I probably have to make this bigger, don't I?
Or can you guys read it?
All right.
All right, huge we are.
So I'm going to do a...
What a mess this is.
So I'm going to do a ping scan.
PR is the new ARP feature.
And I'm going to scan the wireless network that I'm on now with aggressive timing.
And so it goes.
It starts showing you the machines that are up,
and it shows you their MAC addresses.
Right now we're only seeing one,
because I'm just scanning this short subnet.
But we see that it finished and showed that Dell guy.
Another tool that you can use to do this sort of scanning is THC Root.
How many people have used that?
It's a nice little tool by the hacker's choice.
So here I'm going to do the same scan.
And I'll make it huge again.
With THC Root.
And again, it goes through.
It finds the gateway machine.
And it thinks and it thinks.
But you can see that it's taking a bit longer.
NMAP took five seconds and it took ten.
Which is no big deal.
But on a large scan, you know, having it go faster is a lot helpful.
But it's worth noting that while NMAP may be faster,
THC Root still has a lot of great things going for it.
For example, I compiled it just recently.
And you can see all the configure screens.
And at the end, it gives you this beautiful ASCII art
of a giant monster holding a white hat severed head
who's screaming, help, help, I'm just stupid white hat.
Please don't hurt me.
So NMAP can't quite compete with their ASCII art.
Or can it?
Yes, I'm pleased to announce that the new DEF CON version...
Yes, we've got the ASCII art for you.
It's just not quite as violent.
So that's ARP scanning.
And another feature I added just for you guys is ARP spoofing.
When you've been kicked off as many networks as I have,
you start to appreciate the values of stealth and misdirection.
So say you're sitting in a conference room
and you've got the only ThinkPad.
Unlikely, I know.
And all of a sudden, a big scan starts
and everyone sees the MAC address is registered to IBM.
You know, heads will turn in your direction.
So with the new spoofing option,
I did this at the hotel last night.
I specify spoof MAC Apple
and NMAP looks through the OUI table,
finds the MAC prefix registered to the company you specify,
fills out the last three bytes randomly,
and then you can point at the Apple guy and say,
it must be him.
Thanks.
You can also specify it, you know, in other formats.
If you want to specify a specific MAC address
or just give another prefix, it'll fill in the rest.
Or just give it zero and it'll give you a fully random MAC.
And it shows you down here what MAC that it selected.
So that's basically host discovery.
As you can see, there are a lot of different options that you can do there.
A lot of different things to play with.
And by manipulating these different options,
you can get much faster and more accurate results.
Now let's look at another common scan.
And that's single host discovery.
Say a new vulnerability comes out in some product.
You want to scan your network before the bad guys can
and identify all instances of the vulnerable product.
Or maybe there's a new worm going around
and you want to scan to find infected hosts
before they can do much damage so you can quarantine them.
Or maybe you're doing forensics on a compromised host
and you find that they've left a backdoor open on some unusual port.
Well, scan your network real quick
and maybe you'll find other compromised machines
that have the same backdoor.
So here we're going to do an example of this,
which is a little bit unusual, but basically covers the idea.
Our mission statement is to locate web servers
on the playboy.com network offering free images.
The idea here is that I was thinking,
hey, you know, they charge $10 a month for their content or whatever
and I'm a cheapskate.
Maybe they have a development server or a staging server somewhere
where you can download all the images for free.
You know, it's worth a try.
So how are we going to do this?
Well, first we need the address to scan,
and that's pretty obvious.
Just do a lookup on Aaron for netblocks owned by Playboy.
The first one we get is this slash 20 of 4,096 hosts.
There are a lot more netblocks they have,
but for this example, that's enough for us.
And so let's give it an initial try.
We're going to do nmap.
We'll say don't ping because we're only scanning one port.
The ping would take longer than the scan.
The port is 80.
Save the results in grepable format
so we can easily grep out the open servers.
And then we give it the network.
And it chugs along and it completes,
but it takes 20 minutes.
You know, even for 4,096 hosts,
you know, that's longer than I want to wait.
So how can we speed that up?
One thing you can do is help
by giving nmap timing information
that it is trouble getting itself.
On a responsive network, on your local LAN or whatever,
you can usually...
nmap is able to calculate its own response times
based on the responses it's getting
and usually optimize those pretty effectively.
But when you're scanning over the Internet
on a highly filtered network,
nmap's not actually getting much responses.
And so it doesn't really have a good idea
of how long it has to wait
before it can time out and retransmit.
So the idea here is
we'll try and figure out some of that ourselves
and then we'll pass that information along to nmap.
So I look for hosts on the network.
First I try their web server
and I see that that's on a different IP,
so that's no good.
So then I look for MX servers
and we lucked out, there are two of them
that are both on the networks we're trying to scan.
Normally I might just take one host on the network,
but here, you know, we don't know a lot about
the network configuration.
And also given the names,
we can tell that this one's probably in Los Angeles
and this one's in Chicago,
so the latencies are likely to differ dramatically.
So how do we figure out the latencies?
Well, let's ping the hosts.
Well, we try that,
but they both say 100% packet loss.
They're blocking our pings.
Well, that's a bummer.
But, you know, they're mail servers,
and so they've got to have port 25 open.
So let's use HPing 2
to do a TCP ping
of those ports and see how long that takes.
So we say HPing 2,
send a SYN to port 25,
like we're opening a connection,
send five of them,
and we do it to both the Chicago
and the LA networks.
And here, the information you really want
is not the fastest time,
it's not the average time,
it's the longest time that any of those pings take.
Because you want to be a little bit conservative here.
If you try and get too aggressive,
you'll actually make the scan take longer
because Nmap will be retransmitting
when the response is in transit.
So even though the longest we saw out of these two
was 61 milliseconds,
you know, LA is a lot faster
because I was scanning from California,
we're going to pick a bit higher numbers
to be on the safe side.
So we're going to say the max
RTT timeout is 200,
so we'll wait up to a fifth of a second.
And we tell Nmap to start out with 150 milliseconds,
so that Nmap will only go up to 200
if it needs to.
And Nmap can still go faster
if it determines that it can.
Another optimization is to say
scan in bigger groups.
We're going to specify a minimum host group size
of 512.
That breaks up the 4,096 machines
into 8 groups of 512
and allows Nmap to go much faster
by more efficiently handling them in larger groups.
And the rest of the options are pretty much the same.
So how long does that take?
Nmap chugs away
and it still takes almost 15 minutes.
That's better than 20 by a long shot.
But let's be honest,
when I'm looking for these free images,
I'm not a patient guy.
This is an urgent matter.
And so I say,
how can we make it a bit faster here?
Well, think about what Nmap is doing
under the covers in this case.
Nmap, you may know,
does reverse DNS resolution by default.
And when I'm doing P0 scans, no ping,
that means that Nmap is considering
all of the hosts up.
And so it's doing a reverse DNS resolution
on every host.
And reverse DNS, I'm afraid,
is one of the few Nmap functions
that's not yet parallelized.
So that may be taking quite a lot of time.
So I do the same scan,
but this time I add hyphen N
to get rid of reverse DNS resolution.
And here we see that it only takes
about three minutes,
which is perfect,
because that's about as long as I last.
And so,
by just manipulating these different values,
we've been able to reduce the scan time
from 20 minutes to only three.
But enough about timing.
Let's look at the results.
We did that big scan of 4,000 IPs,
but we only found two that are open.
Well, that was sort of a little bit worrisome,
but you never know.
Maybe they're good ones.
Let's take a look in Firefox.
So we'll go to the first one,
which is 216.163.140.20.
And we see Microsoft Outlook Web Access.
Now, that would be really exciting
if we were trying to break into their network,
but it's not very gratifying
for our particular goal here.
What this does tell us
is that, hey, maybe the network we scanned
was the corporate network
when we really should have been scanning
the production network.
It is nice to note their cute little
Playboy mail logo up in the URL bar.
But all is not lost
because we still have one more site.
And I'm very pleased to report
that that one has gigabytes of free images
that I downloaded immediately
upon download.
In fact, I think I'll even show you.
So this one is 142.135.
And so here it chugs away.
And we see FreeBSD ISO images right over here.
We see Fedora images, lots of them.
And if you're on the kinky side of things,
they've got the whole Perl network
right around here.
So whatever your tastes,
this is a great site to download images.
And I would also like to mention
this is also named mirrors.playboy.com
and it actually is a real valuable site
that I use when I need a download.
So we can say mission accomplished on that goal.
But let's look at another quick
single-service discovery option.
And that's NMAP's version detection.
In many cases, you want to not just know
what ports open, but you want to find out
the exact service that's listening.
And so with version detection,
instead of browsing the well-known ports table,
NMAP actually interrogates the ports
and tries to figure out what's running there.
And so that way you can maybe distinguish
the vulnerable services from the invulnerable ones
or find the services even if they're listening
on a non-default port.
And NMAP now has well over a thousand
different version detection signatures
to identify all sorts of crazy things.
In this example, this is just one
that someone sent last year
when MyDoom was basically causing havoc.
Right when it was released,
he posted this to the NMAP dev.
Here's a probe you can add
so that you can identify compromised machines
or infected machines.
So I'm just showing this as an example
to show that it's actually pretty easy
to add your own custom identification
if you want to add services
that aren't in the official file.
So you just say, do a TCP probe.
We'll call it MyDoom.
These two bytes are the data that you need to send.
These are the ports that it normally listens on.
And you'll match for service MyDoom.
If you get this back in the response,
the program is MyDoom.
And for the version number,
he just put, you know,
the date it was found in the wild.
So that's a real useful thing to add.
And to add it,
all you do is add this little s, capital V,
and NMAP does the rest of the work for you.
So that's enough for single-service scanning.
Let's try something a little different
that's also common.
What if you want to defeat a firewall?
Sometimes you really want to look at
what ports are open on a machine,
but those pesky firewalls can get in the way.
And NMAP has some techniques
that can help you resolve that problem.
So we've got another mission.
This time we want to discern the open TCP ports
on docserv.caldera.com.
Now I was a little reticent about using SCO as an example
because at one time,
they were kind of considered a threat to free software.
But lately, you know,
their litigation is in shambles.
And they're pretty much a laughingstock.
And so it feels kind of like beating a dead horse.
The problem is, it's so useful
because every time I want to find
like really pathetic network configuration,
you know, I can find an example right there.
Also, they are a fun horse to beat,
so let's do it.
If we want to find the open ports,
the first thing we're going to want to do is a SIN scan.
You know, that makes sense.
It's the default.
It's often the most useful.
So we do a SIN scan against the machine.
We find port 80 open, port 5007 open,
and 113 is closed.
So did we do it?
Well, not really.
Because while we figured out the state of three ports,
the 1660 remaining ones are in the port filtered,
are in the state filtered.
So we don't know if they're open or closed.
It's worth noting that in a real scenario,
you would probably want to add hyphen P hyphen,
so that it will scan all 65,000 ports.
But just like with the Playboy example,
I'm limiting it just to be a useful example.
So we've got three,
but there's still a huge number that we've not really determined.
Those ports could be open and exploitable,
those 1660,
or they could be closed.
We just don't know.
So what do we want to try next?
Let's try a different type of scan.
Let's try the FIN scan.
That basically sends a FIN packet,
and if it receives a reset back,
the port is probably closed,
whereas if we get nothing back,
the port is either filtered or open.
And this isn't true of all machines,
since some of them aren't susceptible to this issue,
but it's true of a lot of them,
so it's worth trying.
So we try it against DocServe,
and as you can see,
we get a whole big long list of ports
that are either open or filtered,
and then the rest of them are in the state closed.
So that's very interesting.
It's limited the number of ports quite a bit here
to just a few dozen
that are either open or filtered.
And one would hope that most of those
are actually in the filtered state,
because it would be pretty pathetic
to have that many open,
but this is SCO,
so you never really know.
So how are we going to figure out,
differentiate,
because it's a very important distinction,
whether the port is open or filtered.
Well, let's try yet another type of scan against them.
This time, we're going to try an ACK scan
against DocServe.
And that sends an ACK packet,
and if it receives a reset back,
it knows that the port is unfiltered,
because it got a response,
whereas if it receives nothing back,
or an ICMP port filtered message,
it knows that it's filtered.
And so this gives us a lot more information.
Here, the vast, vast majority
are unfiltered,
but it tells us that just two of them
are filtered.
So what's an interesting thing you can do
is combine those
by looking at the last results
and comparing them with these.
For example, look at port 135.
Here it says filtered,
whereas before,
135 was open or filtered.
Well, if you kind of take the logical end of those,
you see that it's
got to be filtered.
Similarly, 1434
looks like it's really filtered.
Let's take another example.
Say you want to know about the SSH port,
22.
In this case, it says that
22 is unfiltered, because it's
one of all these other ports.
And in this case,
we see 22 is open or filtered.
So if we have open or filtered
on one scan,
and unfiltered on the other,
you know, that just leaves open.
And so, if you combine
all of these different results
from the two scans,
what the hypothesis is,
is that 135 and 1434
are filtered,
but all of these other ones
on this huge list are open.
And so,
you know, that tells you a lot.
And you can see a little bit of confirmation
in terms of the two that we know
are open to the SIN scan,
80 and 507.
You see here as well,
80 and 507 in the open or filtered.
So we have a pretty good idea
about what we're seeing.
But networks can be tricky.
It's always good to check your results,
try different things, see what's matching up.
So let's try yet another type of scan.
And that's the Windows scan,
which is a little-known scan technique.
But it's very similar to the ACK
scan, except that it noticed
a property that certain hosts have
where when you send,
when they send a reset
back from a probe to one of their
open ports, they set the window
as they would if it was
a SIN ACK for a real connection.
Whereas, when they're sending
a reset back from a closed port,
they set the window to zero.
So by looking at that window,
TCP receive window value carefully,
we can determine which of the
ports are open and which are closed.
So we do an ACK scan against this
machine, and sure enough, like
we thought, all the ports are
open except 135 is filtered
and I think
443 is the other one.
Or no, it was my MS SQL
was the other one, 1434
was filtered.
So that sort of confirms our results now.
We've tried a lot of different things,
and now we have a good idea
where they're open.
And it kind of shows the value
of taking the SIN scan and
seeing it doesn't get you all the results
that you want, so you just keep trying
different things until you meet your
goals.
So that was basically
our three missions. And so now
I'm going to just give a quick overview,
since I've got, oh, about five
minutes, of some of the new
features that I have in the DEF CON
version. There's
the ARP scanning that we've already talked
about, the MAC spoofing.
One nice new feature is
raw Ethernet packet sending,
because raw IP packets can
be a huge mess. You know, a lot of systems
screw them up, and Microsoft,
even worse, they recently banned them
with their Windows XP SP2.
So now we're saying, well, screw
you, Microsoft. We're just going to send
at a lower level, and
send the Ethernet packets directly.
And that should be a lot faster.
It also has 350
new OS fingerprints, for
a total of 1,690
from this ACC Amazon
WAN concentrator
to the Zyxel
Zywall.
250 new version detection
signatures, so there are now
1,312 of those,
covering 212 protocols,
such as SMTP, SNMP,
Kazaa, all sorts
of bizarre things. It
integrates Doug Song's excellent LibDNet,
which helps with the
raw Ethernet packets sending.
Version detection
now helps you find
OS information.
So the version detection now
can find three extra
things in many cases.
If it sees a service that only works on
Windows, or if the service responds
with a certain platform name,
it can now report, Nmap now
reports that next to the OS detection
results. The OS detection results
are this, and version detection
says it looks like this OS.
And some people would say, hey, combine
those to get just one
result. But in
reality, what you really want is to have
both, because they may be distinct.
If you're scanning a firewall
that proxies to an IIS server,
you should get
checkpoint firewall one or whatever
for the OS detection
results via TCP IP fingerprinting,
whereas it should say Windows
for the application
version detection results.
And that's pretty common. You'll get the same thing
if you're scanning someone's Linksys
network, for example, where they've
forwarded different ports to
different machines.
Version detection
also now gives device
information and host name information,
which can be valuable.
I broke the Windows support, I'm
afraid, for the moment, but
that may be fixed eventually.
And when
it is fixed, though, we'll have
the advantages of the raw packet sending.
But for the Defcon release,
I figured the priority was to get the
Unix versions out, and I've tested this
one on Linux, OSX,
Solaris, FreeBSD.
And
then there's also quite a few more features,
which you can find in the
changelog.
What's coming next? Well, I'm happy to
report that Google has sponsored
10 students to work on
Nmap for the summer. And yeah,
they're student programmers, but some of them are
serious students, like PhD students
in doing very relevant research.
And so that's
pretty exciting, and they're working on a whole lot
of projects. There were
233 applications, and
I picked the top 10,
and we worked out some pretty cool projects.
One of them is Ncat,
which is sort of a re-implementation of
Netcat, that adds a
bunch of new features that I've wanted.
You know, things like SSL,
IPv6, password protection,
there's a connection
brokering feature, so that two
hosts behind a NAT
can connect into the Netcat listener,
and then it brokers the communications
between them. You know, all sorts of
cool features. And you'll find a man
page that he's posted so far
on the Nmap dev list.
And he's working on the
implementation. New GUIs.
And GUIs sort of sometimes have
a reputation as, oh, this is just for
newbies who can't remember those hundreds
of Nmap options.
But these are more advanced user
GUIs. They're
mostly results viewers. So you've
scanned tens of thousands of machines.
These make it easier to identify
which machines have this port
open, or
compare the difference between two scans
and show me what's changed. You know, features
like that. And there are actually
two of these SOC
students writing independent
GUIs.
Potential scripting language. I'm not sure
if that's going to work out yet or not. But this
guy is working on that.
And when that is added,
we'll probably use that for host discovery
stuff. Information gathering
as opposed to, you know, trying to add a
thousand different vulnerability
detection modules. We'll
focus on, hey, have a script that does
trace route. Have a script that
checks whether a proxy is open. Have a
script for all these different things
that it can look up once Nmap
has determined the OS and
port service
version and such.
Windows performance is a
big priority. Also
I've been chugging away at my
Nmap book, which has taken a long
time, but I'm pleased to report
progress. I've
got more than 200 pages of it
here now, and I
think it's looking out to be pretty good.
Given how slow
publishing is, you know, it'll probably be six
months, but I've
added a bunch of cool network
scanning goodies and corny jokes
so it'll be great.
There's a
hyphen hyphen reason option I would like
to add, so that Nmap
can say, hey, we think this
port is closed because we received
a reset back. We think
it's filtered because we received
nothing back, or because we received an
ICMP port unreachable
or destination unreachable
message back. So that'll be useful
for more understanding
what's going on under the covers.
And then I might add proxy and sock scanning.
So that's
basically my presentation, which is good
because I'm about out of time. I'll just take
two questions here, if anyone has them.
Yes,
I'll put the slides...
Yeah.
Yes, docserv.caldera.com
No.
Right now I have
the new version of Nmap up here
at presentation slash defcon.13
and I'll put
the slides up there shortly as well.
Thank you very much.