Tip:
Highlight text to annotate it
X
>> 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 ***," 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 ***." 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
***. 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.
(Applause)