-----BEGIN PGP SIGNED MESSAGE----- Hello NANOGers, I am sending this to you for your evaluation and possible feedback. The CERT/CC has reviewed a report describing a method that significantly improves an attacker's chances of successfully circumventing a firewall. In a mail thread taking place on the Bugtraq mailing list, research is described which may allow an attacker to circumvent a firewall. - - Paper: <http://online.securityfocus.com/archive/1/296122/2002-10-19/2002-10-25/2> - - Thread: <http://online.securityfocus.com/archive/1/296558/2002-10-19/2002-10-25/1> In this message, we begin by presenting some background information for those who are unfamiliar with TCP/IP connection semantics. We then go into specifics regarding how an attacker can circumvent various firewalls by using specially crafted packets. Next, we examine the various impacts resulting from exploitation of this vulnerability. Finally, we present a sample mitigation strategy that will enable you to better protect resources located behind firewalls. - ---Background on TCP/IP Connection Semantics--- As many of you may know, to establish a TCP connection, the client and server must participate in a three-way handshake. The client system begins by sending a SYN message to the server. The server then acknowledges the SYN message by sending SYN-ACK message to the client. The client then finishes establishing the connection by responding with an ACK message. The connection between the client and the server is then open, and the service-specific data can be exchanged between the client and the server. A firewall can be used to manage the connection setup and subsequent traffic flow between the client and server. In general, firewalls are of two types: packet-filtering firewalls, and application-level firewalls. Packet filters look at the source, destination, types, and options associated with the packet, while an application level firewall can "look inside" the packet to examine application-specific attributes. This document is concerned primarily with packet-filtering firewalls (which are much more common), including routers acting as packet filters. Section 3.4 (Establishing a connection) of RFC793 (Transmission Control Protocol) describes the three-way handshake as the standard procedure used to establish a connection. Firewalls will typically not allow this process between hosts that are not permitted to communicate with each other. For example, if an attacker sends a packet (with the SYN bit set) to a victim server, the firewall will not relay this packet to the victim because the firewall's rules only allow packets with the SYN bit set to originate from certain hosts. As a result, the three-way handshake will not be completed, and the attacker will not be able to establish a connection with a host behind the firewall. This method of filtering SYN packets is typically the method used by packet-filtering firewalls to prevent certain hosts from "getting past the firewall." - ---How the Attacker Can Bypasses the Firewall--- An attacker is free to set whatever flags he chooses to set on any packet. RFC973 defines the meaning of certain bits, but does not address scenarios in which odd bit combinations are encountered. The method in which the packet is handled is left up to the TCP implementer. As you might imagine, different implementations handle these "odd bit combinations" in a variety of ways. Some implementations are more liberal in what they accept, and choose to treat ANY packet with the SYN bit set (regardless of what other bits are set or unset) as the opening in the three-way handshake. Some implementations are more conservative, and drop packets with unexpected combinations of flags. In the case of a liberal packet-filtering firewall, it may allow a packet to pass if, for example, the FIN bit is set, even if the SYN bit is set. This ambiguity results in a vulnerability in certain conditions. Suppose you have a "liberal" firewall which passes packets if the FIN bit is set, regardless of the value of the SYN bit. Furthermore, suppose you have a "liberal" host that accepts a SYN bit as the opening of the three-way handshake even if the FIN bit is set . An intruder can now send a packet with the SYN and FIN bits set, and establish a connection with the host behind the firewall in violation of the expected behavior. In effect, the firewall says,"I'll let this packet pass because its a FIN packet," but the host says, "I'm going to establish a connection because its a SYN packet." In reality, the meaning of a packet with the SYN and FIN bits set is undefined. Research has shown that multiple TCP implementations will allow a TCP session to be established with hosts located behind the firewall by setting certain combinations of bits in an initial packet. This research indicates the following TCP implementations are "liberal" in what they accept. Linux (2.4.19 Kernel) Solaris 5.8 FreeBSD 4.5 Windows NT 4.0 The researchers go on to indicate that, "Other OSes than those tested above are expected to behave in a similar manner after obtaining such a discouraging result..." Additionally, it appears that many firewalls are unexpectedly liberal in passing packets. We are investigating both aspects of this systemic vulnerability. - ---Impact--- The impact of this vulnerability is that an attacker may be able to establish connections with hosts behind firewalls in violation of implied security policies. As a result, an attacker can send data to hosts and services that he ordinarily cannot reach by exploiting this vulnerability. As an example, consider the following scenario. You want your internal name server to be able to initiate zone transfers with certain hosts external to your network. Depending on what firewall implementation you are using, you might have a rule that looks similar to the following. iptables -A FORWARD -p tcp -s 10.10.10.1/32 --dport 53 -j ACCEPT And, you may have a rule that permits the reply, that looks like this: iptables -a FORWARD -p tcp --sport 53 -d 10.10.10.1/32 ! --syn ACCEPT Because of the ambiguous nature of TCP semantics, *anyone* can attempt *inbound* TCP connections to *any* port on 10.10.10.1 using SYN,RST packets sourced from port 53. Hopefully you do not have other services running on this machine, because now the attacker can connect to any listening services on the host in question. You might also imagine that an intruder could leverage this flaw to exploit a vulnerability in passive software listening promiscuously on the inside of the firewall (e.g. vulnerability in tcpdump <http://www.kb.cert.org/vuls/id/776781> or some similar vulnerability). The specific kinds of packets that may bypass a firewall are highly dependent on the implementation of the firewall. - ---Mitigation Strategies--- Create filtering rules designed to drop and/or reject packets with certain combinations of bits set in initial synchronization packets. Paul Starzetz <paul@starzetz.de> (the author of the research) proposes using the following mitigation strategy for systems making use of iptables. Please note that this particular ruleset will only protect you from an attacks using the combination of the SYN & FIN bits. iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j LOG -m limit --limit 10/m --log-level "LOGLEVEL" --log-prefix="bogus packet" iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j DROP Please make sure to include VU#464113 in any feedback you send to us at cert@cert.org. This unique, random number will help us track correspondence and coordinate our activities. As always, thanks. Regards, Ian Ian Finlay Internet Systems Security Analyst - CERT/CC Operations Networked Systems Survivability Program =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= CERT (R) Coordination Center Email: cert@cert.org Software Engineering Institute WWW: http://www.cert.org Carnegie Mellon University Hotline: +1-412-268-7090 Pittsburgh, PA USA 15213-3890 FAX: +1-412-268-6989 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBPbdDDmjtSoHZUTs5AQHPsAP/T8SR/K8OZ4IT5neq3kxMMF5JFPLrKdmq DgmDZD1QFDvNHd6P9WOZsI8ike70r7y/ACX5Idlt2LIk3IKO48pcHIQ2F0fWl3Z5 gxt03egJLhEtdIwEMz64Jt9HvKEz2rhZiXI8b3cL4aS7PzEfMxYGiOFUJJbmox3M dvhwkv4xANY= =lFt7 -----END PGP SIGNATURE-----