"Stealth Scanning": etcp

Well since newscan is available, I don't see too much harm in making this
tool available (I was unaware that it existed, previously).  There are
"bugs" here for everyone...:-((  Hassle your vendor if you find your
machines susceptible to some of the stranger things below.

This document describes the behaviour of etcp and thus explains to a fair
extent how Stealth Scanning works, how to take advantage of buggy firewalls
which don't send back replies and points out some bugs in TCP.

etcp is the precursor to ipsend (which has diverged from the role of doing
TCP port scans).  It ONLY works over Ethernet.  It's primary role was to
exercise the short-TCP packet bug, but became a bit more flexible.  It will
ONLY run on SunOS4 (NIT or BPF) and 4BSD boxes with BPF.  The command line
looks something like this:

etcp [-d device] [-f fragflags] [-g gateway] [-m mtu] [-p min] [-P max]
     [-s src] [-S source-port] [-t port] dest flags

Device is obvious (which device you want the packet to go out from).
(defaults to le0)

The "fragflags" field is there to niggle another bug observed in packet
filters (mainly setting the highest bit -ONLY- and sending a packet with
this field as 0x8000, even though it wasn't a fragment).

The gateway allows it to send packets through to another network.

The mtu paramter.  This did "most of the damage".  The key value for this
field is 28 - enough to put port numbers in one packet and TCP flags in
the next.

The min and max parameters specify the minimum and maximum ports for the
scan.  Default is 0 and 1023.

Source allows for a different source address to be specified - almost useless
unless you don't want to see the replies.

Source port sets the given field in the TCP header.

If the port number is given, with the -t option, it will try to make a TCP
connection and then send data across without using in-kernel TCP.  This option
work best with an MTU of 28 against a packet screen'd firewall which doesn't
return any ICMP/TCP packets in response to blocked packets.  Why ?  Because
it relies on the screen remaining silent and not giving the kernel any cause
to close the TCP connection.  So, if that bug was available, it'd call
connect(), expect the SYN packet to be dropped, send across a SYN split in
two which would hopefully make it through, assume an answer, and then send
across an ACK (using a system call) with actual data, doing a kernel lookup
to get the sequence/ack numbers from the TCP PCB.  Sometimes not sending a
reply is more dangerous than sending one :-)

Destination is the destination IP address.

Flags is any combination of TCP flags (SAFRPU).

This table shows the packets returned to those sent.  The target machines
were an Ultrix 4.3 box and a FreeBSD 2.0.5 box.  Hopefully two different
`poles' of BSD TCP.

L - Listening, I - Inuse, U - unused
S - SYN, A - ACK, F - FIN, R - RST
All packets should be considered to have bad sequence/ack numbers.

Sent	State	Received	Window*
S	L	SA		!=0
S	I	-		-
S	U	RA		0
SA	L	RA/R#		!=0
SA	I	A/-		!=0/-#
SA	U	R		0
F	L	A/-		!=0/-
F	I	-		-
F	U	RA/R		0
FA	L	R/-		!=0/-
FA	I	A/-		!=0/-
FA	U	RA		0
FS	L	RA/SA		!=0	&
FS	I	-		-
FS	U	RA		0
R	L	R/-		!=0/-
R	I	RA/-		!=0/-	+
R	U	-		-
RA	L	RA/-		!=0/-
RA	I	RA		!=0	+
RA	U	-		-

* - on Solaris 2, RST packets always have a window of 0.
+ - On some Unixes, where a reply is shown as received, this can close the
    connection a la ICMP destination unreachable `nukes' - hassle vendor!
# - FreeBSD 2.0.5 reponses, where different
& - it appears that 4.4BSD treats FS as a S.

When kernels based on BSD networking are targetted, a non-zero window is
returned for sockets which are listening.  This is due to them (a) having a
non-zero window in the listening state and (b) a pointer, tp, being non-null
when passed to tcp_close() to send the RST.  In case (b), tp points to the
listening socket.

Looking at the above table, we can scan for active listening ports quite
successfully, so long as we know what to expect back.  In particular,
using a SYN-ACK instead of a SYN seems particularly fruitful.

It can be found at:

ftp://coombs.anu.edu.au/pub/misc/etcp.tar.Z

darren

p.s. between this and ipsend, I've found `bugs' in TCP/IP on Solaris2.4,
     4.4BSDs, Linux, SunOS4, Ultrix 4.3...so there are probably some in
     the others too!  Some bugs are more benign than others, and at least
     two can be made to crash/panic and not reboot.