From: Bidwell, Teri K [teri.k.bidwell@XO.COM]
Sent: Monday, November 13, 2000 12:55 PM
To: VULN-DEV@SECURITYFOCUS.COM
Subject: mystery SF scan tool = Idlescan correlation

There have been several postings to security mailing lists asking about IDS
network detects
showing SYN-FIN port cans where the source port == the destination port, the
IP ID is always 39426,
and the window size is always 1028 (0x404).    The general question seems to
be
"what tool is generating these scans?"  A general example of one of the IDS
detects is below:

[**] SCAN-SYN FIN [**]
10/26-18:14:45.311283 209.1.2.102:21 -> my.host1.com:21
TCP TTL:30 TOS:0x0 ID:39426
**SF**** Seq: 0x117EB2A6 Ack: 0x2CB3E404 Win: 0x404

For a year or so the scan tool has been unidentified and referred to by one
Bugtaq poster as
"mystery tool number 11".  At least, I couldn't find any correlations that
identified it anywhere on the web.
If there have been postings about this and I just didn't find them,  then
please chalk this message up to
IDS neophyte-ness on my part.

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.  Idlescan allows a scanning host
to "spoof bounce" a port scan off
a third party "sensor" host, such that the target host network's IDS system
sees only spoofed
traffic from the third party.  The target responds to the sensor host, not
the scanning host.
The scanning host deduces the result of the scan by examining the sensor
host IP ID immediately before
and after the spoofed packet, and depends on the sensor host being quiet to
produce results.   The scanning
host remains invisible to the IDS system on both the  target and the sensor
network unless the sensor network
is looking for it.  (This is all old news, see the Bugtraq archives for
multiple postings about Idlescan).

I studied as many instances of the list postings as I could find,  and in
general, the target scan
ports are reported  to be 21, 143, 111,  53, and 199, all easily exploitable
ports.  The sensor (source) IPs
are predominantly Redhat Linux boxen but the scan works using Windows NT
sensor hosts too.
Locating the originating scan host requires examining traces from the sensor
host networks,
which has not been done.  The originating Idlescan host sends an icmp packet
to the sensor
host immediately before and after the scan is detected on the target's IDS,
so it should be
traceable directly to the scanning source by analyzing network traces on the
sensor hosts,
(unless Idlescan has been integrated with a distributed trojan.   Further
upstream correlations would
be appreciated for investigating that possibility.)

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.  (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!)

The network detects being posted on mailing lists are (possibly doomed)
attempts to make
correlations between the source IP addresses in the scans, when there are in
fact no
correlations to make other than one:  The OS's on the sensor hosts have
predictable IP IDs.

For more information on Idlescan , see liquidK's code  from 1999 at
http://superbofh.org/idlescan.
It builds on theoretical analysis by antirez in 1998 posted to Bugtraq.
(Nice work there guys.)


Teri Bidwell
Security Analyst
XO Communications