/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! */
Hello,
On Tue, 28 Mar 2000, Joachim Feise wrote:
> /* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! */
>
>
> Found this on the Bugtraq list.
It seems that the following code is not useful:
if (proto == IPPROTO_UDP && !mport)
#ifdef CONFIG_IP_MASQ_LOOSE_DEFAULT
/*
* Flag this tunnel as "dest loose"
*
*/
ms->flags |= IP_MASQ_F_DLOOSE;
#else
ms->flags |= IP_MASQ_F_NO_DADDR;
#endif
May be it must be deleted. I have to check it again. At least the
dport can be checked instead of mport.
>
> -Joe
>
> -------- Original Message --------
> Subject: Security Problems with Linux 2.2.x IP Masquerading
> Date: Mon, 27 Mar 2000 23:31:41 -0600
> From: H D Moore <[EMAIL PROTECTED]>
> Reply-To: H D Moore <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
> [ 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
>
> _______________________________________________
> Masq maillist - [EMAIL PROTECTED]
> Admin requests can be handled at http://www.indyramp.com/masq-list/ -- THIS INCLUDES
>UNSUBSCRIBING!
> or email to [EMAIL PROTECTED]
>
> PLEASE read the HOWTO and search the archives before posting.
> You can start your search at http://www.indyramp.com/masq/
> Please keep general linux/unix/pc/internet questions off the list.
>
Regards
--
Julian Anastasov <[EMAIL PROTECTED]>
_______________________________________________
Masq maillist - [EMAIL PROTECTED]
Admin requests can be handled at http://www.indyramp.com/masq-list/ -- THIS INCLUDES
UNSUBSCRIBING!
or email to [EMAIL PROTECTED]
PLEASE read the HOWTO and search the archives before posting.
You can start your search at http://www.indyramp.com/masq/
Please keep general linux/unix/pc/internet questions off the list.
