Re: Defeating a Nmap decoy scan using statistics

[Kris Katterjohn <katterjohn () gmail com>]

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

Brandon Enright wrote:
> Comments inline.
>
> On Sun, 20 Jul 2008 17:22:40 -0500
> Kris Katterjohn <katterjohn () gmail com> 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