Bugtraq mailing list archives
port scanning. (fwd)
From: avalon () COOMBS ANU EDU AU (Darren Reed)
Date: Mon, 31 Aug 1998 21:20:14 +1000
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-owner () GreatCircle COM Tue Dec 5 00:34:27 EDT 1995 Message-Id: <199512041259.EAA21992 () miles greatcircle com> From: Darren Reed <avalon () coombs anu edu au> Subject: port scanning. To: Firewalls () GreatCircle COM (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-owner () GreatCircle COM 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.
Current thread:
- Buffer overflows in Minicom 1.80.1, (continued)
- Buffer overflows in Minicom 1.80.1 Eduardo Navarro (Aug 29)
- Re: Buffer overflows in Minicom 1.80.1 Alan Brown (Aug 29)
- Re: Buffer overflows in Minicom 1.80.1 M.C.Mar (Aug 31)
- Re: Buffer overflows in Minicom 1.80.1 Wichert Akkerman (Aug 31)
- buffer overflow in nslookup? Peter van Dijk (Aug 29)
- Re: buffer overflow in nslookup? Brandon Reynolds (Aug 29)
- Re: buffer overflow in nslookup? Peter van Dijk (Aug 30)
- FreeBSD's RST validation Tristan Horn (Aug 30)
- Re: FreeBSD's RST validation James Snow (Aug 30)
- Re: FreeBSD's RST validation Tristan Horn (Aug 30)
- port scanning. (fwd) Darren Reed (Aug 31)
- Re: FreeBSD's RST validation Andrey Alekseyev (Aug 31)
- Re: FreeBSD's RST validation Diane Bruce (Aug 30)
- Re: FreeBSD's RST validation Oliver Friedrichs (Aug 31)
- SEYON vulnerability in TurboLinux 2.0 Scott Stone (Aug 30)
- Re: buffer overflow in nslookup? www.devoid.net (Aug 30)
- Re: buffer overflow in nslookup? Benjamin J Stassart (Aug 30)
- Re: buffer overflow in nslookup? Theo de Raadt (Aug 31)
- Re: buffer overflow in nslookup? Uwe Ohse (Aug 31)
- Hole in Oracle Server/Developer 2000 - authentication protocol. Yaron Yanay (Aug 31)
- Re: buffer overflow in nslookup? Willy TARREAU (Aug 31)