GREGORY PICKETT: This is "Let's screw
with nmap," fingerprinting prevention through packet normalization.
I am Gregory Pickett with Hellfire Security a quick plug there.
Here is an overview of today's talk.
We will start with "nosey bastards," then "all
about packet normalization" followed by "working it out," and then "putting it
into practice," and finally "finishing up," final thoughts, that sort of thing.
So let's start with "Those nosey bastards."
We see scans and probes of our network every single day
from the outside, the inside, everybody is targeting us,
identifying our assets.
So how do they do it?
Network stack implementation is highly discretionary.
DIPs identify the operating system type and version,
along with attackers, to identify targets
by patch matching target headers to known system implementations.
If your target has a TTL or "time to live" of 128, and if it uses
the following options, maximum segment size
of 1460 followed by a single NOP Windows scale of zero,
followed by two NOPs, and ends in a sec or select vac, the target
is likely a Windows 2003 server.
Implications.
If they identify your assets, they know the weaknesses, and how
to attack them successfully without triggering your sensors,
so basically precision.
Anyone experience this recently?
I am sure more of you will actually experience this going
home when you see the DEF CON T shirt.
It is a fact of life.
But does it have to be?
I say, no!
Why don't we remove the differences to remove their advantage, strip them
of their ability to fingerprint to significantly reduce their chance
of success?
My answer: Packet normalization.
So okay, but what is packet normalization?
The concept isn't entirely developed yet.
There are many expressions, but most are incomplete or what I call
"confused" and do not involve what I have in mind.
I will start off by differentiating between normalization and scrubbing.
Scrubbing is "to do away with" or cancel.
Normalization is to make normal, causing to conform
to a standard or norm.
Most of the time they are used interchangeably,
which I believe is a mistake.
Scrubbing or removing parts really makes a packet less of itself;
it doesn't really move it toward a standard.
In order to do that, I believe you have to reorganize its structure, not
unlike what is done in databases.
Both of these are seen in varying degrees, an often times
in the same solution, illustrating the confusion out there.
We will start off with scrubbing, PF, PF accepts, Net Filter they have
the option to randomize the IP ID, clear the IP "do not fragment" field.
In addition, Net Filter allows you to set the type of service and TTL,
and all three solutions there is an army approaching, I see.
(Applause) Our speaker is not a first time DEF CON speaker.
We may invite him to have a shot, but we are here
for a special reason tonight.
We've got Sarah.
Come on down.
My God, Sarah, you are moving like you are on The Price is Right.
Everybody, this is Sarah who has been running
the camera.
We have a cameraguy back here.
Too bad you're not gettin' any.
Even though this isn't your first time speaking, you did not get your shot two
years ago at your the first one.
GREGORY PICKETT: I did not, and I made the mistake
of mentioning that earlier.
So you are owed.
Okay, everybody, here is to Sarah.
(Applause) We got calls for a double.
There is an extra shot, so the one on the stage gets the double!
For all of you who buy the sync view DVD, it will be all wiggly.
Here is to Sarah!
Cheers!
(Applause) Thank you for coming.
Rookie!
GREGORY PICKETT: I am glad this is not SHOT CON.
Net Filter allows you to set the IP type service and time to live.
All three solutions will do IP fragment reassembly,
but like all firewalls, policy violations and abnormal packets
and flows are the concern.
Some scrubbing with some normalizations happens,
but not enough, nor is the right kind of normalization effective
for fingerprinting prevention, lacking the ability to cover
the entire network.
Then there are networking devices like Cisco Ace and SA, throwing
in other scrubbing options randomizing TPC sequence number and clearing
the reserve and urge fields, clearing TPC options and enforcing
a minimum IP time to live, as well as fragment reassembly.
With regard to other solutions, the concern is policy violations
and abnormal flows and keeping the bad things out.
As the others, the scrubbing with some normalization,
but not enough for the right kind of normalization, not effective
for fingerprinting prevention either.
They are primitive devices, but they are not practical
because they lack the ability to cover the entire network.
This brings us to the first real totally normalization
only solution used by IPS and IDS devices.
These sorts of devices, their main job in this space is IP fragment reassembly,
and doing some checks on the TTL to make sure there
is no evasion happening.
The first solution that is truly there, just doing the normalization.
The primary concern is detecting attacks,
detecting evasions, but it is normalized and not enough or
the right kind of normalization, not effective
for fingerprinting prevention, nor practical, lacking the ability
to cover the entire network.
For those in the "know," it is worth mentioning masquerading.
Some examples are IP personality, morph and IP morph.
Because this solution does begin looking at this, but it
is a modification to the stack, the idea is for the host to pretend
to be something else, like a printer.
The way I look at it, it may be a little dangerous, playing
with those values.
I don't want to degrade or break my connection,
and speaking of degrading, we are of course speaking of performance;
that kind of thing doesn't really sit very well with me.
And then of course, it is a "host only" solution.
Through all the research I did prior to submitting my application,
I had not even heard of these solutions, so I am probably not
the only person who sees it this way, as far as seeing
the dangerous aspect and not looking at this as a broader solution.
But it is worth mentioning because people have talked
about this sort of thing before.
How about outgoing normalization?
Have we seen anything like that?
Not really.
Outgoing transit normalization really hasn't been discussed before,
and there certainly isn't anything out there that is talking
about protecting the fingerprinting.
When you look to prevent the fingerprints, it is important
to look at that fingerprinting process.
As nmap is a major theme to the talk, and this is where I
will show you where I began, looking at nmap and its process
for fingerprinting targets.
Nmap will send out TCP and UDC and ICNP probes which have
responses, and nmap will compile the results, the responses
into a fingerprint.
It is composed of response attributes, response categories that are looking
to categorize some responses, as well as recording the structure
into something like you see here.
What it does, it compares this fingerprint
against a database of previously enumerated operating
systems, attempting to identify the target by finding a matching entry
in the database.
It compares the target fingerprint, and how closely it matches, that
is basically where you get the number of 89 or 90 or
a hundred percent.
It doesn't happen very often, but it does happen, and that
is where I started, the nmap database.
There is a lot there.
It is very complex, and ultimately it is too much trouble; I didn't want
to work that hard to unwrap, given that complexity.
Of course there are the other fingerprinting tools that aren't
so famous, X probe II, quite old, NF SNP and Nexus and other scanners.
Looking at these sorts of tools, it really isn't a good idea
to begin chasing after every tool and its techniques.
It is ultimately best to just try to disrupt any existing pattern,
and that is what I look to do with the normalization.
The algorithm I developed to disrupt the pattern does start
off with some scrubbing.
The idea is to leave behind as little as possible for that print;
don't give them an inch, as it were.
You clear those necessary values out, like the IP type service, IP ECN,
to see the urge flag and pointer.
The nice thing about doing this, nmap uses reflection probes
to inject values into the probe, looking for those values to be returned.
This is a somewhat unusual and often obscure operating system
that will mirror values, receiving
a packet and mirroring back the value in the response.
An nmap is able to identify some operating system just
from that, clearing it out and taking care
of that reflection probe.
Next, you want to randomize anything you can,
like the IP ID, because nmap and tools like it do algorithm analysis.
We didn't want to try to allow them to reverse engineer
with an algorithm previously enumerated, so this left me
with the IP time to live and TCP options.
In this case, scrubbing or clearing out or randomizing wouldn't work,
so a new technique would be needed.
This is where I apply the normalization, and this is what I came
up with: Outgoing normalization and true packet normalization
to the rescue!
The algorithm to normalize the IP time
to live makes some assumptions that the starting TPC was originally
a well known value, and you can look it up on the Internet;
there is a list.
As the bracket traversed the network, it would be decremented only, and
the packet would travel less than 32 hops, and these assumptions are
reasonable, given the expectations out there.
It's true for 99% of the packets out there, so it turns
out they're pretty sound assumptions.
Now with the algorithm, it takes the current TTL and backs into one
of those well known values to estimate the number
of hops traveled.
It then recalibrates the current TTC by taking
a new standardized starting TTL of 255, subtracting the hops, to come
up with a recalibrated standardized version of the calculation to arrive
with a brand new recalibrated current TTL.
Then it puts that in the packet, which is the process, the overall flow
of the algorithm's steps.
This is a more logical view.
The algorithm starts with the lowest well known TTL,
first making sure the most likely TTL gets selected first.
Then it moves to the next and the next one, and assumes
at the bottom that it's already close to 55.
There are actually several exceptions to this normalization to keep
a number of layer three mechanisms
from breaking, which we will talk about momentarily.
Then there is the algorithm to normalize the TCP options.
It also starts with some assumptions.
There are only a few well known options that
are needed.
Ultimately, order was not important.
The requirement I imposed was that the values not be changed;
I did not want to degrade or even possibly disrupt that socket.
The algorithm, with those assumptions and operating
under that requirement, it reads the necessary options
and discards the rest.
It rewrites the options in the proper order or the order I select,
and then it fills out the remaining space
with NOPs hitting the right 32 bit boundaries,
so checks can be calculated without further problems.
These are the options and their order: Maximum segment size, window scale,
selective AK and MD5 past and present.
So after processing, an options list would look like this.
So that's pretty simple.
It is really nice on paper, but it's even better when put
into action, putting it all together and making all packets look
the same with the proof of concept idguard.
To put this on hardware, I wanted to select a suitable platform,
suitable hardware.
The first thing I wanted to be sure of was that it was already modified
by others, as I didn't want to reinvent
the wheel so that I can spend normalization time.
I wanted plenty of documentation available.
So for the hardware, I used router boards,
specifically this one, as well as identifying
a suitable operating system with an available space to put
into VM to spend time developing proof of concept.
I also wanted to make sure that it had a rival
or editable filing system so that I could make quick changes.
For the OS, I pick Open WRT.
This is a very, very, very abbreviated list
of the steps involved.
I started out with the Open WRT site.
There is page after page of instructions.
A lot of it is not specific.
There are things missing, as well as errors.
From this, I condensed it into a clear and concise set
of instructions.
I will be posting this on the project site after the talk,
so that way, you can avoid my pain
from putting this together yourself.
So that will be up there.
Now putting it on the hardware.
What worked?
I know we are getting tired of those nosey bastards.
We will start with what didn't work so well
by itself: Type of service, clearing, ECN clearing, urge flag or point
of clearing, IPI randomization not due to fragment flag clearing,
and the scrubbing.
I say it didn't work so well alone, but what really did help
out and which made the rest of the algorithm possible that would be
the IP ID randomization, doing a good job of contributing
to the algorithm and putting it together nicely.
The others I may ultimately remove because of the possibility even
a remote possibility that the socket could be disrupted,
especially on an internal network with that type of service.
So I may end up removing them, but for now they are there.
So what do the IP ID randomizations help,
the synergy of what worked?
The time to live standardizing and TCP option standardizing,
the normalization.
I can talk about this all day and just say it
is really wonderful, but it is better to show you the results.
We will start here, and then show you a demo
in a few minutes.
Windows 7 target, unprotected.
Wow, surprise, a Windows 7 host.
A Windows server 2003 target, unprotected, looks
like a Windows 2003 host.
And then an Abuntu desktop, not protected, looks likes
a Lennox host.
And then a Red Hat Enterprise target, unprotected, looks
like a Lennox host running the 2.6.X or 3.X kernel.
It does a pretty good job of identifying these and what they are,
so I shouldn't say "unprotected."
Now Windows 7 protected by ID Guard.
Looks like an Allied Telesyn router.
Windows 2003 server protected by idguard, looks like the same router.
This desktop looks like a Cisco router running IOS 12.6;
not so bad.
And Red Hat Enterprise target protected by idguard.
Looks like a device running in an embedded D link.
Yes, they are looking all the same, like routers.
Not so bad unless you are that router, and then I guess it's not so great.
In addition to those fantastic results, there are some other effects.
Nmap does report a negative distance number,
a little strange, but ultimately completely harmless.
How about those other printing tools?
X probe, grandpa there.
Syn FP.
Turns out for Nessus, at least on the operating system identification
for the network and transport layer, those mechanisms are
equally confused.
They see either nothing at all, or they have a completely wildly off view.
Then, of course, the other tools we use to monitor
and troubleshoot, the network like ping and tray shot,
two good examples which are able to operate normally
with no problems whatsoever.
I did talk about the demonstration, so here we go.
It is always good to show you.
I am going to first make sure idguard is not running, so that you get
a good look at what these things look like without it.
Nothing is "fixed" here.
There we go.
It will scan.
It's just taking a few seconds.
It takes a varying amount of time.
I have the scanning machine here, router here.
Over here is the targets.
This is taking an unusually long amount of time.
Over here we have the targets.
Four VMs are running.
For some reason, it is a little slow.
Keep in mind, this is without idguard.
So whatever is going on, it is on its own.
I have some time to fill.
So this is performing the normal activity, and I put
a "dash O" but you can do a "dash A" but you can see it
is sometimes a little squirrely, so no use putting more things
in the way to go wrong.
The first target is identified as Lennox host running 2.6.X
or 3.X kernel.
It looks like it far felled the second one.
It was looking like it was having problems.
The third target is a Microsoft Windows 2003 host.
Sounds like disco music over there; it's a party.
So the fourth target is identified as Lennox host running this kernel,
so what we expected, accurate identification.
All right.
There we go.
I will run it again.
Hopefully it won't be as squirrely as it was a moment ago.
Running this, the performance is fine.
It runs the exact same speed.
That is what it was supposed to look like the first time.
When you run the scan with idguard in place, the time is the same,
no degradation of network performance.
The first target looks likes Tran Map; looks like the device is running
in an embedded D link.
The second target looks like an Allied Telesyn router
and I had never heard of these people until I actually did this.
The third target looks like the same router; fantastic.
And the fourth target, to nmap it looks
like a Cisco router running IOS 12.X; fantastic.
(Applause) Thank you.
I hope the network continues to operate as it is supposed to.
It is going around a tracer route.
There we go.
It functions normally.
We want to make sure that not only the network is running as it should
with idguard in place, but the hosts are also functioning
normal and are able to carry out the given tasks.
As we saw earlier, SSH works fine, not interrupted in any way.
Then we have a web server running over there.
We want to make sure the web server is available, that we can browse
to the website.
There are four VMs running over there.
And then, of course, it is IIS so there is a little delay.
So the network is working great, and I think I might have the time
to run Sen FP real quick on one of the targets.
Has anyone here used Sen FP before?
I threw it in there because it is more recent than
like two years ago when they had an update.
It isn't quite as old as X probe.
So we saw some fantastic results.
There are some challenges like authorized activity,
and other identification like banner and query and identification
through Layer 7.
The first challenge, authorized activity.
Scanners manage their platforms.
Idguard excludes the resolution to that challenge.
You can load it with an exclusion to allow that sort
of authorized activity to occur unhindered.
By loading idguard with the exclusion, it tells idguard
to basically leave alone the traffic and perform no transformations
on that traffic, so the challenge is overcome.
The second challenge, banners and direct query.
There is network available.
Application layer query and OS detail are returned in the reply.
The resolution is split into two parts.
On the perimeter network, those protocols are generally not
available, should not be, just leaving us
with the internal network.
Those application layer queries and replies will have
to be normalized as well, in order to provide an additional fingerprinting
prevention capability.
So a challenge that is existing now and ultimately it won't be,
but there are also some concerns with upstream and downstream
fragmentation or what I am calling TTL attenuation.
That may not be not very accurately described, but you will understand.
TTL special uses.
As we saw before, the trace route and TCP option sensitivity,
and then how about link loading protocols,
especially RIP.
First, upstream fragmentation.
The IP ID is randomized at some point, at work traversing the network.
Idguard randomized the ID.
Another router sees it, can't fragment.
It sends a message back to the host, which is confused
because it never sent a bracket with the IP ID; it keeps sending
the original packet.
The resolution, idguard clears the fragment field,
which breaks MTU path discovery.
I haven't so far had a problem with that, but you may.
That is something I will continue to look into.
If you run into this problem, you can all add an exclusion
for that particular host, so problem solved.
Then there is the second concern of downstream fragmentation.
Each fragment is given a different IP ID.
Therefore, the destination can't reassemble
the original.
The resolution, access switch placement, go ahead
and have the IP ID randomize before the packet might encounter
a router that would need to fragment.
And then of course, Idguard excludes fragments,
just in case.
The host actually does the fragmentation.
So both those together mean the problem is solved.
Then what I call TTL attenuation, when a packet travels
more than 32 hops which aren't all accounted for, so TTL
is continually extended.
It got 66 hops and recalibrated with 2, so it would have more available hops
before expiration.
If it happens again, routing may occur.
The resolution is access switch placement so that
the change to the TTL occurs before any routing activity begins,
and then after when it is already at the destination
and no longer matters.
So problem solved.
Then there is the concern of TTL special uses.
The TTL is recalibrated.
1 becomes 254, and 2 becomes 253.
The TTL time to live never runs out.
Therefore, no intermediate hop reports; trail fails.
Resolution idguard excludes echo request from the TTL transformation,
and then idguard excludes the DUDB trace route range
from all TTL transformations.
Problem solved.
Then link local writing protocols.
The packet has a TTL of 1.
TTL of 255 is abnormal; bracket is malformed.
Resolution, idguard excludes write in protocols.
This concern which always lingers, issues with performance that it might
break something, point of code application and who knows
what else.
It is a concern, but at some point in time we have to begin
to hold our developers and vendors accountable.
So while it is a concern, for the most part my idea
is maybe we should begin getting them to fix these things and not continue
to propagate poorly coded software.
So it is there, we need to be aware of it, but I'm not as worried about it myself.
That is what testing is for.
So we have some concerns and challenges.
For the most part, so far it's really not a big deal.
So what are the benefits for putting this in place
on our network?
It shields the network from casual attackers.
The script KD, they have a new exploit.
They are aware of a weakened configuration.
They will go looking for that particular host.
These hosts are generally popular, ultimately common, and
they won't find those sorts of targets.
They will move on and look for something that matches what
they are looking to attack, automated assaults
with classification going on, scanning and looking
for those targets that match an exploit they have.
So they categorize it, the matching exploit.
The targets will be less likely to fall under one of these categories,
so the software on the server, this BO, it really won't believe it has anything
to launch against this target; it will move on.
And then oblique threats.
If somebody makes a toe hold, they won't have the target
they made for the preferable next step of where
they like to go when moving laterally.
So it does a good shielding job for the network from these threats,
and it helps protect unmanaged and unpatched devices,
because as it moves beyond these targets, the fact that
the target is unmanaged, unpatched and unhardened,
it becomes less of an issue.
Also, helping to defeat canned exploits.
If there is an identification, it makes it much more difficult.
If they know it is Windows, without the exact version
and service pack, they will have to launch the exploit can.
Exploits, to be most effective, need that context.
Without that context, it will lower their chances
of overall success.
So fantastic results, great benefits network wide.
So what is next, now that we have the solution to getting this
out there in place?
First, more platforms, open source router firmware DD WRT,
and then switches where it ultimately belongs.
There are some native Lennox switches.
Matrotek has one, and I believe Aureus is the name.
There are Lennox versions of extreme switches,
and Cisco switches in particular, to try to get some sort
of modification there, and of course they require permission.
We want to take these switches and put them in some sort of trial
out there, starting in a test environment.
Is anyone interested in running a trial?
If you are, contact me after the talk.
From there, with those switches in place, talking to the vendors,
because I want to get it out there as a feature on the switches,
like IGMP and DHCP snooping.
I think it would add benefit to that access switch post.
So if you are a vendor, I would like to speak with you
after the presentation to begin that path.
This is a summary.
Accurate target identification is key to a successful attack,
identification that is way too easy to perform.
So let's change that with fingerprint prevention.
I have proven it can be done.
Now we just need to make it happen.
Proof of concept will be available this afternoon.
There is Version .5.
It is a POC.
It has the IPV for support right now.
Version .6 will be out in about a month.
I am still working out some kinks with the IV6 support.
And application layer queries, they will be dealt with.
There will be a version right after that to handle that.
There is the hash.
I tried 256, but it was too big.
That is where the POC will be available momentarily.
It will be sourced, and I am giving this one away,
so I have to make myself a new router.
It will be a perfect opportunity to test the package, so that will be
up there too.
And here are some links to provide some context to today's talk.
Should I back up for the hash?
Are we good?
And this is the special time of the talk, special thanks to a couple people.
This person helped me work out the many problems in the abstract,
as well as Kenny, Kevin, Kathy and Nick.
This is the last one which will conclude my talk, but I want
to make sure I have everyone's attention.
I promised Nick Pruitt I would get him face on a slide at DEF CON.
Here he is in all his glory.
He sent me many pictures.
This is the one I wanted to use.
This is probably how he would prefer to be remembered.
In fact, there he is, just so that he is properly embarrassed.
So that's it.
Thank you.