Security Incidents mailing list archives
Re: mystery SF scan tool = Idlescan correlation
From: "Stephen P. Berry" <spb () MESHUGGENEH NET>
Date: Wed, 15 Nov 2000 16:34:10 -0800
-----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-----
Current thread:
- mystery SF scan tool = Idlescan correlation Bidwell, Teri K (Nov 14)
- Re: mystery SF scan tool = Idlescan correlation Stephen P. Berry (Nov 17)
- Re: mystery SF scan tool = Idlescan correlation George Bakos (Nov 24)
- Re: mystery SF scan tool = Idlescan correlation LiquidK (Nov 18)
- <Possible follow-ups>
- Re: mystery SF scan tool = Idlescan correlation Joe Stewart (Nov 21)
- Re: mystery SF scan tool = Idlescan correlation Stephen P. Berry (Nov 17)