Re: mystery SF scan tool = Idlescan correlation

["Stephen P. Berry" <spb () MESHUGGENEH NET>]

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


Bidwell, Teri K writes:

> For a year or so the scan tool has been unidentified and referred to by one
> Bugtaq poster as "mystery tool number 11".

That's me, athough it was on the incidents mailing list, not bugtraq.


> I decided to tackle finding the tool as a research project for GIAC
> certification, and I now believe the tool being used is a slight
> variant of Idlescan.

First off, I'd like to say that I think that this is pretty cool.  Does
everyone pursuing GIAC certification have to do such a project, and
if so what sort of cajoling would it take to get the others to make
their results publically available?  Maybe it's just a result of my
prior experience working for academic institutions, but you show
me a group of individuals seeking education, and I see a mass of raw
manpower[0].

That being said, I'm afraid I must remain agnostic about your
conclusion.  More below.


> I have been able to produce network traces identical to those posted on GIAC
> and Bugtraq by editing Idlescan's send_syn() in packet.c and 1) changing
> the source port from 1500 to the "destport" variable, 2)  changing the
> IP ID field to 39426, 3) changing the window size to 1028, and
> 4) adding TH_FIN flag, then recompiling.  The results were then confirmed
> with nmap.  I have not found the exact tool using IP ID 39426  in the wild,
> so I am surmising the distribution is either extremely limited or we're
> even dealing  with a single instance (that you, liquidK?).  Of course, I
> could just be looking in the wrong places. :-)    I felt that the
> simplicity of the diffs between Idlescan and this tool that recreates
> the mystery detects warranted the posting of this correlation.   It seems
> likely someone has taken Idlescan and made the improvements
> on liquidK's todo list in the source code.

This doesn't sound particularly persuasive to me.  I'd have no problem
believing that the tool being used to generate the traffic in question
is a variant of some other tool (there seems to be very, very little
original code out there).  But the fact that you can edit the
source to produce the traffic we've seen doesn't suggest that someone
else already has---you could produce the pattern we're talking about by
editing -any- code[1].

Also, I don't believe that it's all that isolated, and certainly not
a single perpetrator.  I can't say that it's impossible---but I've recorded
close to a hundred instances of this pattern across different networks,
with dozens of scans across some of the same subnets.


> (If this turns out to be wrong, please don't flame me.  If it's correct
> and you wrote the code, stand up and be recognized for eluding that many IDS
> guys for so long!)

I'm not sure I understand your use of `eluded' above.  The traffic has
been independently identified as a recognisable pattern by several
individuals, and identified as suspicious traffic by many more who
haven't actually identified the pattern.  As has been noted elsewhere,
almost all NIDS sensors will flag anything matching (tcp[13]&3 != 0).


Anyway, while I won't say that you're wrong in your analysis,
I remain skeptical.  Before I'd be willing to consider the issue settled,
I'd like to see something like:

        -Recovery of binaries compiled with your changes (presumably
         off compromised machines)
        -Disovery of a source distribution containing your changes
        -Traffic (captured in the wild) from one of the Idlescan sensors
         showing the pattern we've observed, coupled with the stimulus
         traffic from the host controlling the scan

...or something along those lines.





- -Steve

- -----
0     Speaking of academic institutions, does anyone on the list know
      of anyone besides GIAC that is involved in teaching security in
      general, or network security in particular?  I've often thought
      that being an instructor in such a program would be interesting,
      but don't know of any programmes that aren't specifically targeted
      at certification.
1     Although if you started with, say, the nethack(6) source, there'd
      be very little left of the original.  I understand your point about
      the required diffs being small.  I just think that requiring any
      changes at all, regardless of their complexity, makes your case
      far less compelling.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6Eyt6G3kIaxeRZl8RAhTvAKCHLUJKbT2D5+IngjgCdrDdsiPziwCgtp6Q
aVmQT/MkGPhWNfCqnVGM3/Q=
=4kur
-----END PGP SIGNATURE-----