by Rik Farrow <rik@spirit.com>
Christmas Day, 1994, remains a date to remember in the history of Internet security. Tsutomu Shimomura is not at home, but his Sun workstations are up and running, waiting for the attack that will bring him into the limelight, and lead to the capture of Kevin Mitnick. But it was the most unusual form of the attack which caught my attention--an attack that may once again be possible.
The Sequence Number Attack relied on a known flaw in the TCP connection protocol, as well as insecurely configured UNIX systems, to succeed. In May 2001, CERT published an advisory saying that the method used by most vendors (including Microsoft) for preventing sequence number guessing was flawed.
The CERT advisory was written more like a technical paper than their usual style, littered with references. But the question for those interested in Internet security was simple: is this a serious issue, or a just a theoretical problem?
Sequence numbers are used in TCP headers as method for communicating the number of bytes sent, relative to a known starting point, the Initial Sequence Number, or ISN. When a system receives a TCP packet, it sends a packet back containing the sequence number as an acknowledgement. The acknowledgement informs the sending system that all bytes up to and including the packet containing that sequence number have been received. If the acknowledgement is not received, the sending system will wait awhile, and try again. This protocol provides reliability in data transmission while using TCP connections.
Initiation of a TCP connection involves exchanging ISNs. The connecting
system sends a packet with the synchronize bit set (SYN) in the
TCP header. This packet contains the connecting system's ISN.
If the receiving system is listening at the port
specified in the TCP header, it will send the connecting system
a packet with both the SYN and the ACK (acknowledgement) bits
set, and include its own ISN. When the connecting systems
receives this acknowledgement, it sends its own acknowledgement
back to the receiving system, as the final part in what is
called the "three-way-handshake". For the rest of the
connection, each system will
always include a sequence and acknowledgement number in the
TCP headers, so that received data is acknowledged, and the
communication remains in sync.
The use of sequence numbers makes it very difficult to spoof TCP connections without sniffing the packets traveling between the connecting and receiving systems. If the packets can be sniffed, an attacker can inject spoofed packets that contain the correct sequence and acknowledgement numbers, and hijack the connection. The addition of the spoofed packets throws off the synchronization for either the connecting or receiving system, which will reset the connection when attempts to resynchronize fail. So, hijacking a TCP connection when sniffing can succeed, but the connection will be broken (reset) within a short time.
The attack against Shimomura did not involve hijacking. Instead, the attack sought to spoof a trusted IP address, so that a trusting server would permit the attacker's commands to be executed, opening up the trusting server for complete remote access.
The attack took place in three phases. The first phase disabled the trusted server so it would ignore the packets sent from the trusting server. This attack, now known as a SYN flood, was key, as without it, the trusted server would reset the spoofed connection. In the second phase, the attacker collects ISNs from the trusting server, so that the attacker can use the list of ISNs to predict the next ISN generated.
In the final phase, the attacker sends packets spoofing the source address of the trusted server. The trusted server ignores the acknowledgement (SYN-ACK) packets it receives because of the SYN flood earlier, and the attacker then spoofs an acknowledgement from the trusted server. If the acknowledgement contains a correctly guessed ISN, the attack succeeds. If not, the attacker can try again.
As the details of this attack were understood, vendors began to add some randomness to the ISN generated. There is a problem with generating purely random ISNs, as it would then be possible for a new connection between two system to receive a leftover packet from a past connection and accept it as part of the current connection. For this reason, ISNs must always be greater than past ISNs, to prevent collisions with stale packets that arrive late. Vendors dealt with this problem by generating a small random number, or, in Microsoft's case, a time-dependent value, and adding it to the previous ISN.
What the CERT advisory points out is that simply adding a random
number to previous ISNs is not sufficient. In research initiated
by Tim Newsham, of Guardent, (see Resources)
and followed up by researchers at
BindView, the CERT advisory makes it clear that in some cases,
ISNs can still be guessed. Remember that the attacker doesn't
get just one attempt, but can try over and over again--computers
are very good at repetitious tasks.
Also, another aspect of TCP supports a potential denial of service attack. When a TCP packet with the RST (reset) bit set is received, the connection is immediately dropped. If anyone could send packets with the RST bit set, well, this would be a ridiculously easy was to disrupt communications. Instead, RST packets must contain the correct source and destination addresses and ports (the socket data), as well as contain an acknowledgement value that is within the current window. The window is a range set by the receiver of TCP packets, the number of bytes that can be sent without receiving an acknowledgement. Window values can be set to zero to pause transmission, but normally range from as little as 512 bytes to as much as 32 kilobytes, and can be even higher. So, if an attacker knows the socket data, can guess a range for the ISN, all the attacker has to do is send a relatively small number (5000) packets spread across the range, and if one is within the window of the current acknowledgement number, the connection is reset.
The problem with this scenario is that the attacker must now not only guess the ISN, but also the socket information for a current connection. The server's part of the socket information does not need to be guessed: both the IP address and port address of some service on the server are easy to discover. What is difficult is guessing which client IP address has a connection open. And even more difficult, what source port will be used (as clients are assigned the next free port address greater than 1023 by custom). Only if the client side of a connection can be anticipated can the connection than be reset by guessing the ISN.
There are applications where there is easy to do. DNS servers communicate between each other over TCP using port 53. And IRC servers have lots of simultaneous client connections, and a simple netstat command can reveal the socket information.
What about the Sequence Number Attack, or TCP hijacking? The Sequence Number Attack requires that the victim be using the UNIX 'r' commands, and trust other systems, and that this network not be protected by a firewall. The firewall would not only not protect against external access to the known-tobe -dangerous 'r' service ports (512-514/TCP), but also permit packets with obviously spoofed source address into the victim's network. Possible, yes, most likely only on open networks (such as some universities or research sites).
And TCP hijacking? This is even more difficult, as the attacker must not only guess the ISN exactly, but also know the socket information. If the attacker can sniff the TCP connection, then the socket information is accessible--and so if the ISN info. Again, connections with a common server, like IRC servers, make this scenario more likely.
The point of the CERT advisory is that most vendors have only
included halfway measures to make ISNs unguessable. Linux,
OpenBSD, and FreeBSD actually implement versions of RFC1948,
a scheme devised by Steve Bellovin to make guessing ISNs
impossible. Sun Microsystems and SGI include an RFC1948 ISN
generator, but disable it by default. IBM's AIX 4 uses
RFC1948 by default. True RFC1948 ISN
generators are computationally expensive, as they use
MD4 or MD5 hashing algorithms to calculate ISNs, which is
undesirable from a performance perspective.
At this time, it remains to be seen if ISN guessing should be considered important enough for vendors to make RFC1948 ISN generation the default. Without knowledge of a specific and realistic threat, it appears that even half-baked randomness may be good enough for ISN generation.
The sequence number CERT advisory CA-01-09: http://www.cert.org/advisories/CA-2001-09.html
Tim Newsham's Guardent paper: http://www.guardent.com/comp_news_tcp.html
Michael Zalewski's BindView paper: http://razor.bindview.com/publish/papers/tcpseq.html
RFC 1948, with Steve Bellovin's solution: http://www.faqs.org/rfcs/rfc1948.html
[sidebar]
New Killer Exploit for Windows 2000 and IIS5 Surfaces
While recent columns have focused on exploits of Linux systems, this does not imply that nothing new has shown up for Microsoft systems. The Windows Scripting Host was updated because just opening email or visiting a Web site containing XML content could be used to execute code--even with IE levels set to the host secure level.
But that was just a small problem. The real issue surfaced when
a security company, while testing a Windows NT/2000 scanner,
uncovered a buffer overflow exploit for IIS 5.0 on WIndows 2000.
The company, eEye,
contacted Microsoft, and provided a tame 'proof of concept' exploit.
Microsoft quickly responded, producing a patch and a Security
Bulletin (MS01-023).
Within one day, a hacker going by the name of dark spyrit had written a fully functioning exploit named jill. Jill is a 'script kiddie' exploit, in that dark spyrit has done all the difficult work, and anyone who can compile and execute it can get Local System privileges on any unpatched IIS 5 server. Netcraft estimates that in the first week of May 2001, there were 1.69 million Web servers (some virtual) running IIS 5.
The exploit works through firewalls, only requiring access to ports 80 or 443 (or whatever ports IIS's HTTP server is listening to). The specific vulnerability involved Microsoft's implementation of the Internet Printer Protocol, which is accessed via ISAPI using any URL ending in .printer. The jill exploit is designed to execute cmd.exe, and make an outgoing connection to the IP address and port of the attacker's choice. A firewall configured to prevent outgoing connections from the IIS server would prevent this connection, but would be powerless to defend against other variations of this attack.
The exploit harkens back to Rain Forest Puppy's August of 1999 attack against IIS 4. Once the exploit became available in script kiddie form, exploits of IIS-based Web servers soared. And versions of IIS 4 that are still vulnerable to the 1999 attack can still be found on the net today. EEye also published a different exploit of IIS 4 two years ago. Hopefully, IIS owners will have gotten the message and updated their servers.
The Microsoft Security Bulletin:
http://www.microsoft.com/technet/security/bulletin/ms01-023.asp
The eEye advisory:
http://www.eeye.com/html/Research/Advisories/AD20010501.html
The IIS 5.0/Windows 2000 CERT advisory CA-01-10: http://www.cert.org/advisories/CA-2001-10.html
[end sidebar]