I thought I'd dig this post up which was sent to firewalls ~ 2.5 years ago by myself. The "RST" problem was known then but getting free Unix people to fix it has not been easy (yes, they can and will argue over anything and everything to the point where some things just don't get done, be it due to lack of concenous or otherwise). And vendors are supposed to be bad in responsiveness... Anyway, for those that didn't see this then and haven't seen it since, have a read. For those that look for a way to say "SPF's are bad", those which let through arbitrary ACK's might be susceptible to the scanning technique described below - I don't know as I haven't tried that yet. Darren In some mail from Darren Reed, sie said: > From firewalls-ownerat_private Tue Dec 5 00:34:27 EDT 1995 > Message-Id: <199512041259.EAA21992at_private> > From: Darren Reed <avalonat_private> > Subject: port scanning. > To: Firewallsat_private (Firewalls Mailing List) > Date: Tue, 5 Dec 1995 00:00:27 +1100 (EDT) > X-Mailer: ELM [version 2.4 PL23] > Content-Type: text > Sender: firewalls-ownerat_private > Precedence: bulk > > (hopefully this is far enough from being an actual exploit to be > suitable for the firewalls list. Whilst not directly relevant to > firewalls, I believe some of the details herein will be of interest > to its readers). > > "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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:14:11 PDT