This is Let's Screw with NMAP, fingerprinting prevention through packet normalization.
My name is Gregory Pickett with Hellfire Security, quick plug.
An overview of today's talk, we'll start with nosy bastards.
Next is all about packet normalization, followed by working it out and then putting it into
practice and then finally finishing up, final thoughts, that sort of thing.
So let's start off with those nosy bastards.
As network defenders, we see scans and probes of our network.
Every single day, from the outside, from the inside, everybody is targeting us, identifying
our assets.
How do they do it?
Network stack implementation is highly discretionary.
Differences identify the operating system type and version, allowing attackers to identify
their targets by matching the headers of their target to known operating systems.
If your target has a TTL or time to live of 128 and uses the following options, maximum
segment size of 1460, followed by a single NAP, that's actually or should be a window
scale of zero, followed by two NAPs and ends in a SAC or selective ACK.
Then your 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.
Precision, basically.
So anyone experience this recently?
I'm sure more of you will actually experience this going home when they see that DEF CON
T-shirt.
It's a fact of life.
But does it have to be?
No.
I say no.
Why can'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.
Okay.
But what is packet normalization?
It's not an entirely developed concept.
There are many expressions but most incomplete or what I call confused.
And nothing involved what I had in mind.
I'm going to start off by differentiating between normalization and scrubbing.
Scrubbing is to do away with.
Cancel.
Normalization is to make normal.
Especially to cause to conform to a standard or norm.
They are often most of the time used interchangeably and I believe this is a mistake.
Scrubbing, removing parts, really just make a packet less of itself.
It doesn't really move it toward a standard.
In order to move something toward a standard.
I believe that you have to reorganize its structure.
Not unlike what it is done in databases.
Now both of these are seen in varying degrees.
Often times in the same solution illustrating the confusion that is out there.
We'll start off with scrubbing.
PF, PF sense, net filter.
All firewalls.
They randomize the IPID or the IP address.
They have the option to randomize the IPID, clear the IP, do not fragment field.
In addition, net filter allows you to set the IP type of service and the TTL.
And all three solutions, there's an army approaching.
Our speaker is not a first-time speaker at DefCon.
Not a first-time.
No, we may invite him to have a shot.
But we are here for a very special reason.
Tonight on a very special blossom.
Sarah!
Come on down.
We got Sarah.
Come on Sarah.
Round of applause for Sarah.
Ah!
Sarah, my god, you are moving like you're on The Price is Right.
That's awesome.
Come on down.
Come on down.
Everybody loved Sarah.
everybody, this is Sarah. Sarah has been running the camera. Thank you. We've got a camera
guy back here. All right. Too bad you're not getting any. No way, but even though this
is not your first time speaking, you did not get shot two years ago at your first one,
right? I did not. So you are owed. I made the mistake of mentioning that earlier. Yeah.
All right, everybody. Here's to Sarah. We got calls for a double and there is an extra
shot, so who on the stage gets the double? Sarah! Sarah! Okay. All right. All right.
So for all of you buying the Sync View DVD, it will be like ooooh.
Cheers. All right. Here's to Sarah. Cheers.
Thank you for coming. Thank you.
That was aGRUiK gooD job. That was a solid high five.
Sarah? Yeah, thank you so much.
All I can say is I'm glad this is not ThoughtCon.
It's getting there.
You want to be a first‑time speaker.
So NetFilter allows you to set the IP type of service and the time to live.
All three solutions will do IP fragment reassembly.
Now, the primary concern, though, is like all firewalls, policy violations, abnormal
packets and abnormal flows, okay?
There is some scrubbing with some normalization, but not enough, nor the right kind of normalization,
not effective for fingerprinting prevention, and not really practical, lacking the ability
to cover the entire network.
Then there are a variety of networking devices such as the Cisco ACE and Cisco ASA.
Throw in some other scrubbing options, randomizing the TCP sequence number, clearing the TCP
reserved field and urge fields, clearing some TCP options and enforcing a minimum IP time
to live.
And also some fragment reassembly as well.
As the other solutions.
The primary concern is policy violations, abnormal packets and abnormal flows, keeping
the bad things, obviously bad things, out.
And as the others, there's the scrubbing with some normalization, but not enough,
nor the right kind of normalization.
Not effective for fingerprinting prevention either, and not practical.
They're primitive devices for the most part.
Therefore they are not practical because they lack the ability to cover the entire network.
This brings us to the first real, you know, totally, you know, normalization-only solution
used by IPS and IDS devices, these sorts of devices.
Main job, you know, as far as NIST space is concerned, is IP fragment reassembly and
doing some checks on the TTL to make sure that the IP fragment reassembly is in place.
That there is no evasion going on.
The first solution that is truly there, just doing that normalization.
Primary concern, detecting attacks, detecting evasions.
But it's a normalization-only solution, and once again, not enough, nor the right
kind of normalization, not effective for fingerprinting prevention, nor practical, lacking the ability
to cover the entire network.
Okay.
Now.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . and you want to know, all right, it's worth mentioning masquerading.
Examples, IP personality, morph, IP morph.
This solution, because it is a solution that, you know, it does begin to take a look at
this, but what it is doing is it's a modification to this stack, and the idea is for your host
to pretend to be something else.
Like a printer.
All right.
. . . Now, that's, a la, the way I look at it, is it may be a little bit dangerous.
playing with those values. I don't want to degrade or break my connection. Speaking of
degrading, we're talking about performance, of course. So that kind of thing doesn't sit
really well with me. And then, of course, it's a host-only solution.
Through all the research that I did prior to submitting my application, I actually hadn't
even heard of these solutions. So I'm probably not the only person who sees it this way as
far as being the dangerous aspect and just 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
or transit normalization hasn't really been discussed before as a solution. There's certainly
nothing out there, even if there was, talking about, you know, printing fingerprinting.
So when you look to prevent the fingerprints, it's important to take a look at that fingerprinting
process. And, of course, as NMAP is a major theme to the talk, this is where I will show
you where I began, which is looking at NMAP and its process for fingerprinting targets.
NMAP will send out TCP, UDP, and ICMP probes. The probes, they have responses. And they
will compile the results, the responses, into a fingerprint. It's composed of response
attributes, response categories. It looks to categorize some of those responses. And
then it also will record the structure into something like you see here.
Now what it does, it takes this fingerprint and it compares it against a database of previously
enumerated operating systems. And it identifies or attempts to identify the target by the
finding a matching entry in this database. So it takes that target fingerprint, compares
it against the database, and how closely it matches an entry in that database, basically
that's where you get that number. It's 89%, 90%, 100%. It doesn't happen very often, but
it does. Okay? So that's where I started. All right? The NMAP fingerprint database.
And if you just look at that just for a second, there's a lot there. It's very complex. It's
complex. And ultimately, too much trouble. I didn't want to work that hard, really, to
unwrap, given that complexity. And then, of course, there are the other fingerprinting
tools, not so famous. Xprobe 2, which is actually quite old. A newer one, SynFP. And
then, of course, Nessus and the others, the vulnerability scanners.
Well, you know, looking at these sorts of tools, it's really just not a good idea to
begin with.
I'm chasing after every tool and its techniques. Ultimately, it's best just to try to disrupt
any existing pattern. And so that's what I look to do with the normalization.
Okay? Now, the algorithm that I developed to disrupt that pattern, it does start off
with some scrubbing. The idea is to leave as little behind as possible for that fingerprint.
Don't give them an inch, as it were. All right?
So you clear those necessary values out, like the IP type of service, IP ECN, TCP urge,
flag and urge pointer. The nice thing about doing this is that NMAP also uses some reflection
probes. It will inject values into the probe and look for those values to be returned.
There are some unusual, often obscure operating systems that will mirror values. They'll receive
a packet and actually mirror the value back in the response. And you can see that there's
NMAP that's able to identify some operating systems just by that. So you clear that out
and it takes care of that reflection probe.
Next thing is you want to go ahead and randomize anything you can, like the IP ID, because
NMAP and other tools like it do algorithm analysis. So we did not want to give them
an opportunity to try to reverse engineer or just, you know, match it with an algorithm
that they had previously enumerated and put into NMAP.
And then this left me with the NMAP.
The IP time to live and the TCP options. Now in this case, scrubbing, clearing things
out, randomizing wouldn't work. A new technique was going to be needed and this is where I
applied the normalization. And this is what I came up with. Outgoing normalization. True
packet normalization, as I say, to the rescue. Now, the algorithm to normalize the IP time
time to live, make some assumptions that the starting TTL was originally a well‑known
value.
You can look that up on the Internet.
There's a list that as the packet traversed the network, it would be decremented only.
And that the packet, you know, travels or would travel less than 32 hops.
These are reasonable assumptions to make given the expectations that we have out there.
It's true for 99% of the packets out there.
So it turns out they're pretty sound assumptions.
Now what the algorithm does is it takes that current TTL and backs into one of those well‑known
values to estimate the number of hops traveled.
Then it recalibrates the current TTL by taking a new standardized starting TTL of 255 and
subtracting the hops to come up with a recalibrated standardized version of that calculation to
arrive ‑‑
It starts with a brand‑new recalibrated current TTL and then it puts that in the packet.
That's the process of the overall flow of the algorithm, the steps that it takes.
This is a more logical view.
The algorithm starts with the lowest well‑known TTL first, making sure that the most likely
TTL gets selected first.
Then it moves on to the next one, the next one, and then just assumes, you know, it's
at the bottom.
It's going to be good.
It's going to assume it's already pretty much close to 255.
All right.
So there are actually several exceptions to this normalization to keep a number of layer
three mechanisms from breaking, which we'll talk about momentarily.
Then there is the algorithm to normalize the TCP options.
Starts out with some assumptions as well.
There are only a few well‑known options that are needed.
Order was ultimately, though, unimportant.
Okay.
So the requirement that I imposed on this was that the values not be changed.
I did not want to degrade or even possibly disrupt that socket.
The algorithm then, with those assumptions operating under that requirement, reads the
necessary options and then discards the rest, rewrites then the options in the proper order
or the order that I've selected, and then fills out the remaining space with naps to
make sure it hits the right 16‑bit, 32‑bit boundaries.
So that, first of all, I want to make sure that I've got all the options in the right
First off, the packet is not displaced in memory in any way, and the checksum could
be calculated without any sort of problems.
These are the options that I selected and their order.
Maximum segment size, the window scale, selective ACK, and then MD5 hash if present.
So after processing, an options list would look like this.
Okay.
Okay.
Okay.
Okay.
Okay.
Pretty simple.
All right.
But it's really nice on paper, but even better when you actually put it into action, so putting
it all together, making every one, all the packets look the same with the proof of concept
ID guard.
Now to put this on a piece of hardware, I wanted to make sure I selected a suitable
platform.
Suitable hardware, the first thing that I wanted to make sure was that it was already
already modified by others. I didn't want to reinvent the wheel. I didn't want to break
new ground in the area. I wanted to spend the time with the normalization. I want to
make sure there's plenty of documentation available. So for the hardware I chose the
MicroTik router boards, the MicroTik RB450G specifically, right there. Also identified
a suitable operating system with an available base that I could then put in a VM and spend
most of my time developing the proof of concept there. And it also ‑‑ I wanted to make
sure that it had a writable filing system, a writable file system so that I could make
quick changes. For the OS, I picked OpenWRT. Now, this is a very, very, very abbreviated
list of the steps that are involved. I started out with the OpenWRT site. They
are page after page of instructions. A lot of it is not specific. There are things missing.
There are errors. Now, from this, I condensed it into a very clear and concise set of instructions.
Well, I call it clear and concise because I wrote it. You may feel otherwise. I'm going
to be posting this on the project site after the talk so that you ‑‑ we can avoid
my pain putting this together. All right? Mm‑hmm. So that will be up there. Isn't
there? Okay. Now I want to talk about putting this on the hardware, you know, what worked.
Because I know we are getting really tired of those nosy bastards. Well, we're going
to start off with what didn't work or what didn't work so well by itself. The type of
service clearing, the ECN clearing, the IP ID randomization, the fragment flag clearing
and the scrubbing. Now I say it didn't work so well alone. What really did at least help
out, which made the rest of the algorithm possible, that would be the IP ID randomization.
That did a good job of contributing to the rest of the algorithm, putting everything
together and making it work real nice.
The others I might ultimately remove because there's a possibility, even a remote possibility,
that the SOC could be disrupted, especially on an internal network with a type of service.
So I might end up removing those later. But right now they're there.
So what did the IP ID randomization help out? What did it, you know, that synergy,
what worked? Well, the time to live standardizing and the TCP option standardizing.
Now, of course, I can talk about this all day and just say, this is really wonderful,
but it's better to just show you the results. We'll start off here and show you a demo
in just a few minutes. A Windows 7 target. Unprotected. Looks like ‑‑ wow, surprise.
A Windows 7 host. A Windows Server 2003 target. Unprotected. Looks like a Windows 2003. No,
host. And then an Ubuntu desktop, unprotected, looks like a Linux host running the 2.6.X
or 3.X kernel. And a Red Hat Enterprise target, unprotected, looks like a Linux host running
the 2.6.X or 3.X kernel. I shouldn't say looks like, I should say identified because it does
a pretty good job of identifying these and figuring out what they actually are.
Now, Windows 7, protected by ID guard, looks like an allied telecom router. A Windows
server 2003 target, protected by ID guard, looks like an allied telecom router. The Ubuntu
desktop, protected by ID guard, looks like a Cisco router running a Windows server 2003.
And a Red Hat Enterprise target, protected by ID guard, looks like a device running embedded
D-Link. Yes, they are looking all the same. They're all looking like routers. Not so bad.
Unless you are that router, then I guess it's not so great. All right. So, in addition
to those results, fantastic results, I would say, there are some other effects. Nmap does
report a negative distance number. A little strange, but ultimately completely harmless.
How about those other fingerprinting tools? The X probe. Grandpa there. SYNFP, Nessus.
It turns out that, well, for Nessus, at least on the operating system identification for
the network and the transport layer, those mechanisms. They're confused. Equally confused.
They see either nothing at all or have a completely wildly off exactly like Nmap is. And then,
of course, there are those other tools. The tools we use to monitor and troubleshoot the
network. Ping, Trayshot, two good examples. They're able to operate normally without any
problems whatsoever.
whatsoever. Now I did talk about doing a demonstration. So here we go. Because it's always good to
just not talk about it but just show you. Okay. I'm going to make sure first off the
ID guard is not running so that you get a good look at what these things look like without
it. I don't ‑‑ nothing is fixed here. There we go. I'm just going to scan. It will
take a few seconds there. Got a lot of VMs. There we go. Nope. Okay. Takes a varied amount
of time. Got the scanning machine here. The router is right here.
Okay.
And over here is all the targets. It's taken unusually long amount of time. And over here
we have the targets. There are four VMs running. Okay. A little slow for some reason. Keep
in mind this is without ID guard. So whatever is going on, it's on its own. Oh, okay. I
have some time to fill. All right there. Okay. So this is performing the normal activity.
I put a dash O, even though ‑‑ I mean, you can do a dash A. But, you know, as you
can see, sometimes it's a little squirrely. So there's no use kind of putting more things
in the way to go wrong. Okay. So the first target has identified the
target as a Linux host running the 2.6.X or 3.X kernel. I hope everyone can see that.
It looks like it far-folded the second one. As I said, it was looking like it was having
some problems. These are VMs, anyway. So the third target is identified as a Microsoft
Windows 2003 host. Sounds like disco music over there. Okay. Okay. So now we're going
It's a party.
So the fourth target is identified as a Linux host running the 2.6.x or 3.x kernel.
So this is exactly what we expected, accurate identification.
We'll run that again, hopefully it's not as squirrelly as it was just a moment ago.
Now we're running this.
The
performance is fine, runs the exact same speed, there we go, see?
That's what it was supposed to look like the first time.
When you run the scan with IDGuard in place, the time is the same.
There is no degradation of network performance.
So the first target looks like trend map, looks like a device running embedded D-Link.
The second target looks like an allied router.
I had actually never even heard of these people until I did this.
The third target looks like an allied router.
Fantastic.
And the fourth target looks like to end map.
like a Cisco router running iOS 12.X. Fantastic. Thank you. And now we want to go ahead, and
I'm hoping the network continues to operate as it's supposed to. Let's go ahead and run
a trace route. There we go. Functions normally. Because we want to make sure that not only
is the network running well, as it should be running, with ID guard in place, but the
hosts are also operating functionally. Are they able to carry out the tasks that they've
been given? Well, as we see, as we saw earlier, the ‑‑ here we go. SSH works fine. Okay.
Not interrupted in any way. And then we actually have ‑‑
Okay.
A web server running over there. We want to make sure that that web server is available,
that we can browse to that web site. There's four VMs running over there. And, of course,
it is IIS. So there's a little delay. All right. So network's working great. All right.
Well, I think ‑‑ I might have the time just to run a real quick. I'm one of the
targets. Okay. Has anyone here used CFP before? Do you use it? No? Okay. There we go. So
unknown OS. I threw that in there because it is a little bit more recent than I know
Like last year, two years ago, two years ago, they had an update to it.
It's not quite as old as Xprobe.
Okay.
So we saw some fantastic results.
There are some challenges like authorized activity and other methods of identification
like banners and direct query and identification through layer 7.
The first challenge, authorized activity, scanners, management platforms, the resolution
to that sort of challenge, ID Guard excludes them.
You can load ID Guard with an exclusion to allow that sort of authorized activity to
occur unhindered.
So by loading ID Guard with exclusion, it tells
ID Guard to basically leave that traffic alone, do not perform any normalizations,
any transformations on that traffic.
So the challenge is overcome.
The second challenge, banners and direct query.
There's Windows networking available, so we have a Windows host.
There's an application layer query.
And the OS details are returned in the reply.
The resolution is split into two parts.
On the perimeter network, those protocols are generalized.
Generally not available, should not be available.
So that just leaves us with the internal network.
Those sorts of application layer queries and specifically those application layer replies
will have to be normalized as well to provide an additional fingerprinting prevention capability.
So while a challenge now, ultimately it won't be.
Okay.
Okay.
Then there are also some concerns.
Up-stream and down-stream fragmentation, TTL attenuation, that's just what I'm calling
it, probably not accurately described, but you'll understand what I'm talking about
in just a second.
TTL special uses, as we saw before, the trace route.
And TCP option sensitivity.
And how about link local routing protocols.
Especially RIP.
First concern, up-stream fragmentation.
The IP ID.
ID is randomized at some point, packet is traversing the network, ID guard is there,
it randomizes the IP ID. After that, another router sees it, needs to fragment it, can't,
sends a message back to the original host. The host is a bit confused because it never
sent a packet with that IP ID. It just keeps sending that original packet. The resolution
is, ID guard excludes, I'm sorry, ID guard clears the do not fragment field. This does
break MTU path discovery. I have not had a problem with that so far. You may have a problem,
so it's something I will be continuing to look into. If you run into this sort of problem,
you can always add an exclusion. That particular host, okay? 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. All right. Go ahead and have that IP ID randomized before it might, you know,
encounter, the packet might encounter a router that would need to fragment.
fragment. And then, of course, ID guard excludes fragments just in case. The host actually
does the fragmentation. So both of those together means the problem is solved.
Then there is a concern of TTL attenuation. That's what I'm calling it. Packet travels
more than 32 hops. Not all these hops are accounted for. And therefore the packet TTL
is continually extended. You know, it traveled 66 hops and it's basically only recalibrated
with two. So it would have more available hops to make before it expired. If this happens
more than one time, then there's a possibility that a routing loop could occur.
The resolution to that? Access switch placement. So that the change to the TTL occurs before
any routing activity begins.
And then?
After. When it's already the destination when it doesn't matter anymore.
So problem solved.
Then there is the concern of TTL special uses. The TTL is recalibrated. You know, one becomes
254, two becomes 253. The TTL time to live never runs out. Therefore no intermediate
hop reports and trace route fails. The resolution? ID guard excludes ICMP echo requests
from the TTL transformation. And then ID guard excludes the UDB trace route range from
all TTL transformations. Problem solved.
And then link local routing protocols. The RIP packet has a TTL of one. TTL of 2 55 is
abnormal. Packet then is malformed. The resolution ID guard excludes routing protocols. I want
Okay. And then this concern, which is always lingering in any of these sorts of cases,
issues with performance, that it might break something, poorly coded application, who knows
what else. You know, it is a concern, but we have to at some point in time begin to
hold our developers, hold our vendors accountable. So while it is a concern, for the most part
my idea is that maybe we should begin, you know, getting them to fix these things and
not continue to propagate poorly coded software. So it's there. We need to be aware of it,
but I'm not as worried about it myself. And that's what testing is for.
Okay. Now, so we have some concerns and some challenges. For the most part, not really
a big deal so far. So what are our benefits for putting this in place on our network?
Well, it does shield the network from casual attackers. Casual attacker, your script kitty,
they have a new exploit. They are aware of a weak configuration. They're going to go
looking for that particular host. These hosts are generally, you know, popular, ultimately
common. They're not going to find those sorts of targets. They're going to move on,
looking for something that matches what they're looking to attack. And you have automated
assaults. You have any sort of classification going on. Scanning, looking for those targets
that match an exploit that they have. So they categorize it. Matching exploit. The targets
are going to be less likely to fall into one of these categories. Therefore, the software
on the server, this bot, is not going to really believe it has anything to launch against
this target. It's going to move on. And then oblique threats. If you have someone making
a toehold, they're not going to have that target.
This is a target that they prepared for, the preferable next step, where they like
to move when they go laterally. So it does a good job helping to shield the network from
these sorts of threats. And, of course, it helps protect unmanaged, unpatched, and
unhardened devices. Because as it moves past these targets, moves beyond them, then the
fact that the target is unmanaged, unpatched, and unhardened becomes less of an issue. And
it's going to make it much more difficult for them to get a precise, even if they know
it's Windows through other means, without that exact version, that service pack, then
they're going to have to launch the exploit canned. And as we know, exploits, in order
to be most effective, need that context. So without that context, it's going to lower
their chances of success overall. Okay. So fantastic results and great benefits, network-wide.
So what's next now that we have the solution to getting this out there in place? First
off, more platforms, open source router firmware, DDWRT, putting it there. And then switches,
where it ultimately belongs. There's some native Linux switches. Microtik has one. Aries,
I believe, is the name. There are Linux versions of the extreme switches, Cisco switches in
particular. Let's try to get that out there.
Some sort of modification there. That may require permission, of course. If I plan
to do production trials, because that's what we want to do, is we want to take these switches
and put them into some sort of trial out there, starting in the test environment, of
course, and then into production. So if there's anyone interested in running a trial, please
contact me after the talk. And then from there, with those switches in place, talking to the
vendors, because I want to get this out there as a feature on the switches, like IGMP and
DHCP storage.
I think that would really add a lot of benefit to that access space, that access switch space.
So if you're also a vendor, or just a vendor, I would love to also talk to you after the
presentation to begin that conversation, begin that path.
All right. All right. So some final thoughts. There's a couple more things after this. But
this is just like a summary. Accurate target identification is key to a successful attack.
We talk about this a lot. So I'm actually going to spend more time talking about this
And that is the idea, not the actual thing. So let's start with the key issue.
Key issue, and this is the most important key issue of the deal.
So key issue number two,這就是重副的問題。
The key issue, and it's a very key issue.
So let's talk about this a little bit, but first, let's talk about this key issue.
We want to talk about the
key issue.
Key issue number two, this is something that I know everybody is thinking about, like
This is a problem we're talking about, in any case, and I know this is not only, it's
not only, it's an issue that we've been discussing for a while.
be there. And oh, yes, application layer queries, they will be dealt with. So there will be
a version right after that to handle that. Here's the SHA-1 hash. I tried a SHA-256 hash
but it's too big. It's out of control. So we'll just do a SHA-1. And that is actually
where the POC will be available momentarily. It will be a source. And then soon ‑‑ well,
I'm giving this one away. So I've got to make myself a new router. And that will be a perfect
opportunity to test the package, open WRT package. So that will be up there, too. Okay.
And some links to provide some context to today's talk. Here we go. Should I back up
for the hash? All right. I think he's got that. All right. All right. All right. All
right. All right. All right. All right. All right. Are we good? Okay.
And then this is a special time of the talk right here. Special thanks to a couple of
people there. for working out the many, many problems in my abstract. And then
Kenny, NEC security, Kevin, and Nick Pruitt. The reason for this ‑‑ this is the last
one. So this will conclude the presentation. Thank you. Thank you all for taking a moment.
I want to make sure that I get everyone's attention for this. Nick Pruitt, I promised
him that I would get his face up on a slide at DEF CON. This is my second time around
so I thought I would get that out of the way. And here he is, in all his glory. He sent
me many pictures. This is the one that I wanted to use. This is probably how he would prefer
to be remembered. Okay. In fact, right back there, if everyone, there he is. Just so he's
properly embarrassed. There we are. Okay. So that's it. Thank you.