[ Security Problems with Linux 2.2.x IP Masquerading ] Summary: Due to lax checking in the masquerading kernel code, an attacker is able to rewrite a linux masq gateway's UDP masquerading entries so that the remote host and port are whatever they choose. This creates a tunnel between whatever host and port they want and a UDP port on an inside machine. The attacker is unable to tell what local inside ports and addresses are being used, but they can determine the number of currently masqueraded connections and the number of different hosts using those connections behind the firewall. Any network where UDP traffic is masqueraded to the outside is vulnerable to this, including DNS, TFTP, NetBIOS, and a multitude of other applications which rely on UDP transport. Since UDP is a connectionless protocol, the only way to determine that a masqueraded connection is no longer being used is by timing it out due to lack of activity or receiving ICMP messages indication the port is closed. The result is that there is a 5 minute time-out by default for all masqueraded UDP sessions, allowing an attacker enough time to find and exploit the connection with some of the methods outlined in the Examples section below. Details: For those familiar with the linux masquerading system, please jump to the next paragraph. IP masquerading is an implementation of NAT (Network Address Translation) for the linux OS. It allows you to connect an internal network using private addresses to an external network (internet) in a fairly secure manner. All packets coming from the internal network and destined for the external network are rewritten so the source of those packets is the masquerading gateway's external address and the source port is the gateway's source port. This only requires one external IP address to enable internet access for hundreds/thousands of internal machines and is therefore a popular method for many businesses and home users with broadband connections. The TCP and UDP protocols require both source and destination ports as well as source and destination addresses to work. The source port for outgoing UDP/TCP connections is usually picked from the first available port between 1024 and 65535 on the originating host, so how does the masq gateway relay these connections AND be able to use these protocols for its own networking? The kernel sets aside the ports 61000 to 65096 by default for handling the masqueaded connection entries, allowing for a theoretical maximum of 4096 of both UDP and TCP connections at a time. These values can be changed in the code or through the /proc file system. Now when connection request from internal host A comes in from local port 1035 and its destination is the external DNS server Host Z on port 53, the masquerading machine adds a new entry to the masquerading table that looks like this: Host A:1035 (651001) -> Host Z:53 The port in paranthesis is the local port the gateway uses to send the forwarded UDP datagrams from and the port it uses to receive responses back from Host Z. The next paragraph describes how the vulnerability found allows an attacker to modify the right side of the above connection to allow traffic to come from thier host back into the internal network to the local port on the inside host. The UDP masquerading code only checks the DESTINATION PORT to determine if a packet coming from the external network is to be forwarded inside. It then sets the remote HOST and PORT to the source address and source port of the incoming packet. An attacker only needs to determine the local port on the masq gateway to be able to rewrite the masq table with thier own address and port, which is trivial considering the relatively small port range set by default for use by masqueraded conenctions (65100 - 65096). Now how do you determine which one of these ports is the local port on the gateway for the masq connection? Easy, we send a probe packet to each of these hosts and watch the IP ID field in the responses. The IP ID field is sequentially incremented on each host's TCP/IP stack for each packet they send out, so the masq'd port ICMP response will have the IP ID of the INTERNAL host, which is almost always at least 1000 away from the current IP ID of the gateway machine. See the Examples section below for packet traces of a complete scan/attack. Examples: We know that example.com has a linux masquerading gateway and that thier DNS server is outside of this firewall. We can come to the conclusion that internal machines must be able to contact the external DNS server to be able to access the internet. We start sending our probe packets: Host A is our internal workstation (192.168.1.100) Host B is our masq gateway (192.168.1.1 / 10.0.0.1) Host C is the DNS server (10.0.0.25) Host X is the attacker (10.10.187.13) ipchains -L -M -n on the masq gateway BEFORE the probes > UDP 03:39.21 192.168.1.100 10.0.0.25 1035 (63767) -> 53 [ tcpdump from attacker's machine ] ( we picked source port 12345 for our packets just so the trace would be easier to follow) [ snip -- this starts at port 61000 ] 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63762 unreachable [tos 0xd8] (ttl 245, id 13135) 10.10.187.13.12345 > 10.0.0.1.63763: udp 0 (DF) [tos 0x18] (ttl 254, id 23069) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63763 unreachable [tos 0xd8] (ttl 245, id 13136) 10.10.187.13.12345 > 10.0.0.1.63764: udp 0 (DF) [tos 0x18] (ttl 254, id 23070) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63764 unreachable [tos 0xd8] (ttl 245, id 13137) 10.10.187.13.12345 > 10.0.0.1.63765: udp 0 (DF) [tos 0x18] (ttl 254, id 23071) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63765 unreachable [tos 0xd8] (ttl 245, id 13138) 10.10.187.13.12345 > 10.0.0.1.63766: udp 0 (DF) [tos 0x18] (ttl 254, id 23074) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63766 unreachable [tos 0xd8] (ttl 245, id 13139) 10.10.187.13.12345 > 10.0.0.1.63767: udp 0 (DF) [tos 0x18] (ttl 254, id 23083) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63767 unreachable [tos 0xd8] (ttl 244, id 17205) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The above packet's ID is substantially different, we may have found a masq'd connection !!! 10.10.187.13.12345 > 10.0.0.1.63768: udp 0 (DF) [tos 0x18] (ttl 254, id 23084) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63768 unreachable [tos 0xd8] (ttl 245, id 13140) 10.10.187.13.12345 > 10.0.0.1.63769: udp 0 (DF) [tos 0x18] (ttl 254, id 23088) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63769 unreachable [tos 0xd8] (ttl 245, id 13141) 10.10.187.13.12345 > 10.0.0.1.63770: udp 0 (DF) [tos 0x18] (ttl 254, id 23090) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63770 unreachable [tos 0xd8] (ttl 245, id 13142) 10.10.187.13.12345 > 10.0.0.1.63771: udp 0 (DF) [tos 0x18] (ttl 254, id 23091) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63771 unreachable [tos 0xd8] (ttl 245, id 13143) 10.10.187.13.12345 > 10.0.0.1.63771: udp 0 (DF) [tos 0x18] (ttl 254, id 23092) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63772 unreachable [tos 0xd8] (ttl 245, id 13144) [ snip -- all the way to the upper end of our masq ports ] ipchains -L -M -n on the masq gateway AFTER the probes > UDP 04:35.12 192.168.1.100 10.10.187.13 1035 (63767) -> 12345 ^-------[ expiration of the udp tunnel has been updated ;) w00t! We now have a working tunnel from our host to port 1035 on the inside machine! Exploitation: We have demonstrated that it is possible for us to 'hijack' the enternal side of a masqueraded connection, so now what? There is not a whole lot we can do to the closed local udp port on the inside machine, so its time to examine other applications/protocols that use UDP for transport and what security risks there are in allowing unrestricted external access to thier source ports. I leave this as an excercise to the reader... -HD Following the "NetBIOS Info" thread on Incidents mailing list at SF, Robert Graham mentioned a utility he wrote to automatically respond to netbios port 137 name probes with a netbios name lookup back to the originating host. He mentioned that it seems to cut right through state-based firewalls and NAT systems because the response probe looks like a response to the outgoing probe. Assuming that a host on an inside network is sending out these netbios name queries (1), an attacker could exploit the linux 2.2.x vulnerability and be able to query the netbios names of internal machines. -HD 1: http://www.robertgraham.com/pubs/firewall-seen.html#netbios