Defeating a Nmap decoy scan using statistics

[Brandon Enright]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fellow developers and port scanning geeks,

I've been giving some thought to how to detect the real scanning host in
a sea of decoys.  Up until I think it has been generally accepted that
if the attacker does everything "right" there isn't a way to determine
the real attacker.

By right I mean that the scan doesn't leak any addition information
because it doesn't do DNS, service or OS fingerprinting, etc.

For example, this scan shouldn't leak information:

# nmap <victim> -sS -n -v -P0 -T5 -p <ports> -D fake1,fake2,ME,fake3...

Of course, this assumes that all the decoys actually reach the target.
This would not be the case with RPF (reverse-path-forwarding) or
quality egress filtering.

So lets break a simplified version of this where Nmap uses the same TTL
on all the IP packets it sends.  In this setup, Nmap scans <victim>
with itself and one <decoy> and all the IP packets start with a TTL of
10.  Nmap is 5 hops away from <victim> and <decoy> is some other number
of hops away from <victim>, say, 7.

Breaking this is somewhat trivial -- <victim> can look at the packets
from the real scanner and from <decoy> and see that they all arrive
with a TTL of 5.  Since <victim> has the source code to Nmap and knows
that all packets started with a TTL of 10, <victim> knows the real
attacker is 5 hops away.  <victim> can now probe each of the potential
attackers to determine which is 5 hops away (there are several ways to
do this and it can't be prevented in general).

An attackers sending decoys has no generic way to prevent such
information disclosure.  The attackers can't (in general) determine how
many hops the victim is away from the decoys and can't prevent the TTL
from decrementing uniformly for all the decoy probes.

The obvious approach to solving this problem is to randomize the
initial TTL so that the victim gets random TTLs.  Nmap does this but it
does it too uniformly and the simplified attack discussed above can be
extended to break how Nmap currently sends decoys.

The heart of the problem is with this code:

/* Time to live */
if (ttl == -1) {
  myttl = (get_random_uint() % 23) + 37;
} else {
  myttl = ttl;
}

Nmap chooses a random TTL for each probe uniformly in the range
[37, 59].  Instead of the victim receiving packets with the same TTL,
the packets have randomized TTLs.  Statistically though we know that
Nmap sent a TTL of 48 _on_average_.  All the victim has to do now is
compute the average TTL for incoming packets.  48 - <computed average>
is the distance the attacker is away from the victim.  With even just a
few dozen probes the average will fall very close to an integer offset
from 48.  Now that the victim knows the attacker's distance they can
probe hosts to determine which of the scanning machines has that
distance.

The reason this attack works is that the initial random TTL is chosen
uniformly across different decoy hosts.  If each decoy host had a
slightly different range of TTLs, it would not be possible to find the
"correct" average and the victim would not be able to determine how
many hops the real attacker is away.

So how do we "fix" this so that decoys don't leak information about the
attacker?  This is what I propose:

For each decoy, we generate a decoy-specific TTL offset.  We then
change the TTL generation code to look like this:

/* Time to live */
if (ttl == -1) {
  myttl = (get_random_uint() % 23) + 37 + decoy_offset;
} else {
  myttl = ttl;
}

At the very startup of Nmap, we generate a random decoy_offset for each
decoy host that persists for the remainder of the scan.  I propose a
random decoy offset range of [0,16) which should be good enough unless
you pick decoys that are more than 15 hops different to the victim --
something that is very unlikely on the current Internet.

Note that the above system can also be broken but it would require that
the attacker scanned the victim with the same set of decoys many times
until the victim could average the decoy_offset per host to be 7.5 --
no stealthy Nmap user would do this...

Comments welcome.

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkh72fMACgkQqaGPzAsl94KfSgCfb7nFMYPv/sBymyZwAiDLcNrs
qkIAoK3WOpMVywjPMxEEuCyJEGqIUNoO
=PDcO
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[Kris Katterjohn-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brandon Enright wrote:
> Fellow developers and port scanning geeks,
>
> I've been giving some thought to how to detect the real scanning host in
> a sea of decoys.

Cool stuff.

Like a lot of things, I find statistics to be fascinating, but unfortunately I
know very little beyond what can be considered common knowledge.  So you'll
have to bare with me :)

> So how do we "fix" this so that decoys don't leak information about the
> attacker?  This is what I propose:
>
> For each decoy, we generate a decoy-specific TTL offset.  We then
> change the TTL generation code to look like this:
>
> /* Time to live */
> if (ttl == -1) {
>   myttl = (get_random_uint() % 23) + 37 + decoy_offset;
> } else {
>   myttl = ttl;
> }
>
> At the very startup of Nmap, we generate a random decoy_offset for each
> decoy host that persists for the remainder of the scan.  I propose a
> random decoy offset range of [0,16) which should be good enough unless
> you pick decoys that are more than 15 hops different to the victim --
> something that is very unlikely on the current Internet.
>
> Note that the above system can also be broken but it would require that
> the attacker scanned the victim with the same set of decoys many times
> until the victim could average the decoy_offset per host to be 7.5 --
> no stealthy Nmap user would do this...
>

Does adding another number from a uniform range really affect the ability to
find the attacker in the decoys?  You'll have to forgive me for my lack of
knowledge in this area, but it seems like you're just making a bigger range to
work with: instead of [37, 59], you have [37, 74].  Is this not the case?

If not, and I'm wrong about the exact behavior of the range, does the offset
really need to be persistent for the decoys?  If you're just adding another
number from a range, why not keep it mixing up and change the code to just add
get_random_uint()%16 instead of the persistent decoy_offset?

Or what about even something like this:

tmp1 = 24 + (get_random_uint() % 12)
tmp2 = get_random_uint() % tmp1
myttl = tmp1 + tmp2

I just picked semi-arbitrary numbers, but you get the general idea.

> Comments welcome.
>

Interesting! :)

> Brandon
>

Thanks,
Kris Katterjohn


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSHv+Vf9K37xXYl36AQIUvRAAq4gyUpug2gcx3BNxrtdZrVN4sAhcrafm
sfvFIPOKCsmbpYlcPT4ra1a+dxMllZvqjHG3rdPQ1XBCb/fyDVglpZvF1UsXp8BF
SY82MbvCWfxJ3ZppFYrdH+85CGt8o/QV1hdjcFkDEpebRyMyR8IeawdztuqNoQL/
71Juk6OwCJqlpzIOodNsJRRBk7DwK7GGjvVFHtyv2sF5D2D48Ty4E7e8NqwTfUSL
pJH8hMlgPlv6KMZM0VmnCfhouEfi2Oy00L50xJrRGaFJ8S6Q9fqx7nNEtm1o9nb4
0GhV/2C5IoYJfiJIrrAw0qIyKN0GnqQdNEtiNPH2YPJp/85v2AyiMuMek7O2sRL3
2Yv7xs18chNmI/PynjmD7m4CtHHhR0/ug7JrJWa+E7xL+DFKcxb1GugrJUgAk/0O
Xi6TgUKb6sB9KYpI8nBl8rb1ZjWkutMGJL4i4UsUJhA7lPc8GcY4yX//f27wtVdM
R+3Tbpc8e9kgoH6hIGpYdSKSc5bcIq8gvVQ0i6VAAEcJFNLrImjrigY/wx++muXM
/pHy2K9dI4cKi4xbD3W3tBjfn3AOj2MqytmmWVyO5Uz5e4VuVD6BstRNliFH+Laj
UCEIEcieT7ZdyajjDOLwLHZROD+tP8r0vDnOGMPtHg0wA2TPgFP5saD5X10ZaTa3
cjhASGo456M=
=T7/b
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[Fyodor]

On Mon, Jul 14, 2008 at 10:57:48PM +0000, Brandon Enright wrote:


> Up until I think it has been generally accepted that
> if the attacker does everything "right" there isn't a way to determine
> the real attacker.

Well, I wouldn't make a claim that strong.  The Nmap man page says of
decoys: "while this can be defeated through router path tracing,
response-dropping, and other active mechanisms, it is generally an
effective technique for hiding your IP address."

They are generally effective, but there are some weaknesses.  The
biggest is perhaps that the true Nmap host still calculates timing and
retransmission information, while of course the decoys don't.  So if
you're in the process of being scanned by 5 IPs and want to know which
ones are decoys, you could try firewalling off one of them, then the
next, and so on.  When you get the right one, it will likely slow down
and increase retransmissions because it is not getting responses any
more.

>From a pcap file of a 65K port scan, you also might be able to figure
out which one is the true scanner if you carefully analyze drops and
timing very carefully.

Nmap could ignore drops and timing for scans with decoys, but that
would slow things down dramatically.

> The heart of the problem is with this code:
>
> /* Time to live */
> if (ttl == -1) {
>   myttl = (get_random_uint() % 23) + 37;
> } else {
>   myttl = ttl;
> }
[...]
> Statistically though we know that
> Nmap sent a TTL of 48 _on_average_.  All the victim has to do now is
> compute the average TTL for incoming packets.  48 - <computed average>
> is the distance the attacker is away from the victim.

That's a good point.  One option would be for Nmap to just select a
ttl once per run and always use that.  I haven't thought mouch about
whether that would have any disadvantages to Nmap.  It would be
trivial to implement and might help performance, but probably not in
any material way.

If you pick your own --ttl when you launch the scan, that might
resolve the random ttl issue.

Alternatively, we could make the numbers 37 above more random (and
then keep it the same throughout the scan).  Then you don't know what
number to subtract in order to get the real hop number.

Cheers,
-F

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[Brandon Enright]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Comments inline.

On Sun, 20 Jul 2008 17:22:40 -0500
Kris Katterjohn <katterjohn@...> wrote:

>
> Brandon Enright wrote:
> > Hi Kris.  I don't have time for a detailed response right now
> > because I'm hacking some book chapters but I'll send you a much
> > more detailed response when the book deadline isn't so pressing.
> >
>
> I've been waiting for a response on -dev, but I can't resist
> continuing on a bit more :) Feel free to quote this email and reply
> on -dev (I'd prefer it to keep the discussion open).

Sorry about not sending a response out earlier.  I prefer open
discussion too so thanks for this note.

>
> > The main point to having a persistent offset that is unique for each
> > host is that each host will average out to a different TTL.
> >
>
> But if you're just adding a value to it, does it really need to be
> persistent? It seems like adding a different random value every time
> has more of an effect on the outcome (but see by concern below about
> both of these options).

Okay, ignoring Fyodor's excellent insight on this for a moment, the
fundamental problem is that if you are able to determine the real
hop-distance of the attacker then you can figure out which decoy is the
real attacker.

Okay so how do we prevent one from learning the hop distance?

We have discussed 2 ways to do that:

1) Add a random value to the TTL to each outgoing packet you send.
Nmap currently does this.

2) Add a random value to *all* TTLs that persist for the entire scan
duration.

We know we can "factor out" randomness by collecting enough data and
then averaging.  So the question then becomes how much data do we have
to collect before an average produces reasonably accurate results?

For "1" we are adding a random value to the TTL for every packet that
is sent.  If you use more than a few decoy hosts or scan more than a
few ports you should the victim should have _a_lot_ of data to average
out to determine the real hop distance.

For "2" the randomness was picked at the start of the scan.  That means
that it doesn't matter if you scan 10 ports or 10,000 ports, you aren't
providing more useful data to average with.  To factor out this
randomness the attacker has to scan you multiple times before you can
start to average out the randomness.

To recap: with technique "1" every probe helps you average.  With
technique "2" every whole scan helps you average.

>
> > That is, without the offset, if you are 5 hops away the average TTL
> > for all the hosts comes to 43.  If you have a different offset for
> > each host, the average for one host may be 45 while another host
> > could be 51.
> >
> > Because each host has a different average, you know know how far the
> > attacker is away because you don't know the expected original
> > average TTL.
> >
>
> I understand the point; however, the concern I expressed here:
>
> >> Does adding another number from a uniform range really affect the
> >> ability to find the attacker in the decoys?  You'll have to forgive
> >> me for my lack of knowledge in this area, but it seems like you're
> >> just making a bigger range to work with: instead of [37, 59], you
> >> have [37, 74].  Is this not the case?

>
> hasn't subsided.  If you're just adding another range (0-15 or not),
> does that not just expand the possible range of TTLs and thus still
> allow for averaging? Added separately or not, the overall "pool" of
> values still seems susceptible to this (in my mind).
>
> So for this code:
>
> >>> For each decoy, we generate a decoy-specific TTL offset.  We then
> >>> change the TTL generation code to look like this:
> >>>
> >>> /* Time to live */
> >>> if (ttl == -1) {
> >>>   myttl = (get_random_uint() % 23) + 37 + decoy_offset;
> >>> } else {
> >>>   myttl = ttl;
> >>> }
>
> Does the outcome not come out to simply a larger range to choose from?
>
> (37->59):
> |-----------------------|
>
> (0->15):
> |---------------|
>
> (37->59) + (0->15)
> |--------------------------------------|
>
> The same averaging operations hold true for the larger range as for
> the smaller (original) one, doesn't it?

Actually, even a non-uniform distribution (Gaussian, Poisson, etc) will
allow factoring out the randomness given enough data.

The point is that one must collect enough data before they can factor
out the distribution.

So we have two ranges, 37->59 + 0->15

That isn't directly 37->64 even though it may seem like it at first.
It would look more like this:

         <range 1>               <range2>
|--------------------------| + |----------|


Where range1 is determined randomly with _each_packet_ and range2 is
determined randomly for _each_scan_.  You can average out both but not
at the same time.  Each scan will allow you to fully average out range1
while it will take several scans before you can average out range2.

>
> > You're response though brought up a good point.  The per-host range
> > should be increased from 0-15 to give it more variance for small
> > samples.
> >
> > More later or hit me up on AIM.
> >
> > Brandon
> >
>
> Thanks,
> Kris Katterjohn
>

Good discussion.  My proposal is somewhat more complicated than it
really needs to be though.  Fyodor had a few great points and a simpler
way to fix this problem with decoys.  I'll respond to his note in a
moment.

Brandon


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiFC5oACgkQqaGPzAsl94J/BwCeKD087wggk+uKR3trbTHGwQn+
OikAoJ8OR8AFhMZtvsMIZKGWxLDcxMct
=p+uq
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[Brandon Enright]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry for letting this sit for so long.  Comments are inline.

On Mon, 14 Jul 2008 19:48:07 -0700
Fyodor <fyodor@...> wrote:

> On Mon, Jul 14, 2008 at 10:57:48PM +0000, Brandon Enright wrote:
>
>
> > Up until I think it has been generally accepted that
> > if the attacker does everything "right" there isn't a way to
> > determine the real attacker.
>
> Well, I wouldn't make a claim that strong.  The Nmap man page says of
> decoys: "while this can be defeated through router path tracing,
> response-dropping, and other active mechanisms, it is generally an
> effective technique for hiding your IP address."

You right.  It's dangerous to make such broad claims.

>
> They are generally effective, but there are some weaknesses.  The
> biggest is perhaps that the true Nmap host still calculates timing and
> retransmission information, while of course the decoys don't.  So if
> you're in the process of being scanned by 5 IPs and want to know which
> ones are decoys, you could try firewalling off one of them, then the
> next, and so on.  When you get the right one, it will likely slow down
> and increase retransmissions because it is not getting responses any
> more.
>
> From a pcap file of a 65K port scan, you also might be able to figure
> out which one is the true scanner if you carefully analyze drops and
> timing very carefully.
>
> Nmap could ignore drops and timing for scans with decoys, but that
> would slow things down dramatically.

For the TTL averaging technique I was assuming that the victim would
only have access to logs after-the-fact.  That is, maybe netflow,
syslog, or other firewall logs.  The resolution of such logs is often
much lower that the actual packet data and so estimating drops and
retransmissions could be very hard.

Also, analyzing logs after the scan precludes active detection like
firewalling hosts in sequence.

All very good points though.

>
> > The heart of the problem is with this code:
> >
> > /* Time to live */
> > if (ttl == -1) {
> >   myttl = (get_random_uint() % 23) + 37;
> > } else {
> >   myttl = ttl;
> > }
> [...]
> > Statistically though we know that
> > Nmap sent a TTL of 48 _on_average_.  All the victim has to do now is
> > compute the average TTL for incoming packets.  48 - <computed
> > average> is the distance the attacker is away from the victim.
>
> That's a good point.  One option would be for Nmap to just select a
> ttl once per run and always use that.  I haven't thought mouch about
> whether that would have any disadvantages to Nmap.  It would be
> trivial to implement and might help performance, but probably not in
> any material way.

I like this idea a lot more than mine.  It is basically the same
suggestion I came up with but it eliminates the confusion of the other
randomness which doesn't help much anyways.  The new PRNG is so fast
that the performance change wouldn't even be measurable.

>
> If you pick your own --ttl when you launch the scan, that might
> resolve the random ttl issue.

Probably.  As long as you pick a "random" initial TTL I can't think of
a way to use the TTL to find the right attacker in the decoys.

>
> Alternatively, we could make the numbers 37 above more random (and
> then keep it the same throughout the scan).  Then you don't know what
> number to subtract in order to get the real hop number.

Sure.  This is just "pick your own --ttl" only Nmap does it for you and
in a good range.  The only problem I see with this is that if people
know what range Nmap uses than if Nmap gets unlucky and picks a TTL
at the top of the range it will place a maximum on the distance.

Suppose the range is now 50-200.  If you get TTLs from a host with a
value of 195 then you know the host can't be farther than 5 hops away
(or the attacker used --ttl >200).

>
> Cheers,
> -F

Overall I think we can reduce this "ttl problem" down to almost zero
but we can't make decoy's perfect.  I'd like decoys to be nearly
perfect from a netflow/firewall log perspective but we'll never get
them perfect when the victim can interact with the scan as it happens.

Brandon


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiFHHoACgkQqaGPzAsl94IlXACfRIAqAXdpndYxfASgTmxcUx/S
RnMAoLGwGP8Ut1yDz7TiGU4yi7SVyDIf
=lAko
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[Kris Katterjohn-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brandon Enright wrote:

> Comments inline.
>
> On Sun, 20 Jul 2008 17:22:40 -0500
> Kris Katterjohn <katterjohn@...> wrote:
>
>> Brandon Enright wrote:
>>> Hi Kris.  I don't have time for a detailed response right now
>>> because I'm hacking some book chapters but I'll send you a much
>>> more detailed response when the book deadline isn't so pressing.
>>>
>> I've been waiting for a response on -dev, but I can't resist
>> continuing on a bit more :) Feel free to quote this email and reply
>> on -dev (I'd prefer it to keep the discussion open).
>
> Sorry about not sending a response out earlier.  I prefer open
> discussion too so thanks for this note.
>

Great.

>>> The main point to having a persistent offset that is unique for each
>>> host is that each host will average out to a different TTL.
>>>
>> But if you're just adding a value to it, does it really need to be
>> persistent? It seems like adding a different random value every time
>> has more of an effect on the outcome (but see by concern below about
>> both of these options).
>
> Okay, ignoring Fyodor's excellent insight on this for a moment, the

Yes, I wasn't trying to imply that Fyodor's suggestions were for naught, just
that I had a difficult time grasping the effectiveness of your technique.  I'm
not sure if that's exactly how it came across, it's just that I was interested
in continuing/forking the discussion based on your ideas.

> fundamental problem is that if you are able to determine the real
> hop-distance of the attacker then you can figure out which decoy is the
> real attacker.
>
> Okay so how do we prevent one from learning the hop distance?
>
> We have discussed 2 ways to do that:
>
> 1) Add a random value to the TTL to each outgoing packet you send.
> Nmap currently does this.
>
> 2) Add a random value to *all* TTLs that persist for the entire scan
> duration.
>
> We know we can "factor out" randomness by collecting enough data and
> then averaging.  So the question then becomes how much data do we have
> to collect before an average produces reasonably accurate results?
>
> For "1" we are adding a random value to the TTL for every packet that
> is sent.  If you use more than a few decoy hosts or scan more than a
> few ports you should the victim should have _a_lot_ of data to average
> out to determine the real hop distance.
>
> For "2" the randomness was picked at the start of the scan.  That means
> that it doesn't matter if you scan 10 ports or 10,000 ports, you aren't
> providing more useful data to average with.  To factor out this
> randomness the attacker has to scan you multiple times before you can
> start to average out the randomness.
>
> To recap: with technique "1" every probe helps you average.  With
> technique "2" every whole scan helps you average.
>

OK... you're convincing me :)

>> So for this code:
>
>>>>> For each decoy, we generate a decoy-specific TTL offset.  We then
>>>>> change the TTL generation code to look like this:
>>>>>
>>>>> /* Time to live */
>>>>> if (ttl == -1) {
>>>>>   myttl = (get_random_uint() % 23) + 37 + decoy_offset;
>>>>> } else {
>>>>>   myttl = ttl;
>>>>> }
>> Does the outcome not come out to simply a larger range to choose from?
>
>> (37->59):
>> |-----------------------|
>
>> (0->15):
>> |---------------|
>
>> (37->59) + (0->15)
>> |--------------------------------------|
>
>> The same averaging operations hold true for the larger range as for
>> the smaller (original) one, doesn't it?
>
>
> Actually, even a non-uniform distribution (Gaussian, Poisson, etc) will
> allow factoring out the randomness given enough data.
>
> The point is that one must collect enough data before they can factor
> out the distribution.
>
> So we have two ranges, 37->59 + 0->15
>
> That isn't directly 37->64 even though it may seem like it at first.
> It would look more like this:
>
>          <range 1>               <range2>
> |--------------------------| + |----------|
>
>
> Where range1 is determined randomly with _each_packet_ and range2 is
> determined randomly for _each_scan_.  You can average out both but not
> at the same time.  Each scan will allow you to fully average out range1
> while it will take several scans before you can average out range2.
>

Thanks for the great explanation, I'm getting it now.  I'm still having the
thought of "surely there's a simpler way to calculate the average than what's
presented here," but I have yet to come up with a way :)

>
> Good discussion.  My proposal is somewhat more complicated than it
> really needs to be though.  Fyodor had a few great points and a simpler
> way to fix this problem with decoys.  I'll respond to his note in a
> moment.
>

Good stuff.

> Brandon
>

Thanks again,
Kris Katterjohn


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSIV0qf9K37xXYl36AQJMKRAAmNE2QRjoRvgDhxLFXOLSXS+HhxNwZ3a+
cardTm3fekV24qiICFff1Sjf/W0pIK12ucILN7kWLAzwiGDusKtzLOTU2n6lB6BA
yOT7RM2iMSwby7BZ/gCjVRKcJK6OG1z9FaTYiP1Bnd28XKqAxMaxbg36mPJdW79G
uurxEAHgPhIoXfH9vSD6nGqEppPdFr0fjgsZ/VU/OrydJgr0xwWR7nc3MePLG003
R1VCB9Y/354yiHYMsaRLdPMlnxgS1nbY0S+PyjWJ5+HcReDybCo80TIZ2l5uYkR1
w3r3ZIWbe/07rdpd4o0xeSBNCFaboanXWzG6ejAQtqMJtmo+5JAEXC4SYGvyk4AN
EUpoKzzSMDv5TV4zun4POS9GklhlolNQGb1AvRDSmxvm8TekMGm+KeEg8I+m78g8
nLXm37pxJaWZ2GnK6Ti+pCCsQuoIQ4BoV69A6rLKDTnlBb3zjNLiSfIHBU3M0AA8
HWqT0Kkm0Nm9ayig0RmljFclHaaB4Q+FS09Z88IsLH+r2agyj9w7wY3a5EJskF+P
OCi9d77CzPhltaTbzyVMM73Jkgn6dmxznEkuSXHIEpToySUV68NvGpJWEnd//kzt
XMk1ykp8byUG1HXi3hwRIYX2HtuLR2v82btmCXT4TTEd/WWZPfFbtYayhTuyGlwU
BTkbH0uaEaU=
=EqEy
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org