While working on a different project back in August, we stumbled upon
a flaw in Microsoft's TCP/IP implementation. The flaw, which is present in at
least Windows 95 and Windows NT 4.0, allows an attacker to reset an existing
connection on Windows machines, as long as the attacker knows the IP address
and TCP port of the other end of the connection (and can successfully guess
the target machine's TCP port for the connection - often not too far above
1024.)
The problem arises when a packet is sent to a Microsoft machine that
generates a reset. Our example code uses a PSH ACK to generate this reset.
The resulting reset's ACK field contains the last acknowledged sequence number
across all of the target's currently established TCP connections. Armed with
this knowledge, we can then send the target machine a RST with the retrieved
ACK number as the sequence number (and 0 in the ACK field), resulting in an
abortive release of the connection. As an added bonus, since Microsoft OS's
respond with resets on ALL ports, we can retrieve the last ack'd sequence
number from any arbitrary closed port.
Of course, this has some limitations - we must know the TCP port number
and IP address of both ends of targeted connection. This is not as hard as it
may seem at first glance - if we know the type of TCP connection, we probably
know the server port. As to the target's TCP port, its probably not too far
above 1024. A significant obstacle to resetting a connection is the need to get the reset to the target before it sends another ack. To address this problem,
the brkill.c code includes the -n switch, which will cause brkill to send
the range of sequence numbers from ack to (ack + n) to the target host.
Lastly, if the target has a large number of established TCP connections,
resetting the connection can be difficult since there will be several sets
of ACK numbers, and it won't be obvious which one belongs to the connection we
want to kill.
We reported the problem to Microsoft back on September 15, and received
the boilerplate "Thanks, we'll look into it" answers back. It is now time
to release the details of the vulnerability so that Windows users can take
steps to protect themselves. The source code for brkill, a proof-of-concept
demonstration of the problem, is available here.
The source has been tested on FreeBSD, OpenBSD and Linux, and requires
the pcap library.
Implications
We consider the following types of connections to be the most vulnerable to
this attack:
Login connections: telnet, rlogin, xterm, etc. These generally involve low data
rates and have a well-known server port, making them easy targets.
MS PPTP connections. Data rates are not always low, but the connections last
long, and can generally be reset with ease.
Certain connections, even when they originate from non-Microsoft machines,
may be vulnerable to this attack if the logical connection is being relayed
b y MS Proxy Server. This assumes that MS proxy is vulnerable, which it
may or may not be. We haven't tested it.
Public chat connections such as IRC have been found to be susceptible to this
attack. These are particularly fun as you get to see them being reset (again
and again :) ).
Availability of Source Code
Source code is available from http://deep.ee.siue.edu/br/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:18:43 PDT