4950932 2000-03-28 19:14 /185 rader/ Postmaster
Mottagare: Bugtraq (import) <10390>
Ärende: Security Problems with Linux 2.2.x IP Masquerading
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <38E043BD.BF9BB32D@digitaldefense.net>
Date: Mon, 27 Mar 2000 23:31:41 -0600
Reply-To: H D Moore <hdm@SECUREAUSTIN.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: H D Moore <hdm@SECUREAUSTIN.COM>
X-To: "BUGTRAQ@SECURITYFOCUS.COM" <BUGTRAQ@SECURITYFOCUS.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
[ 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
(4950932) ------------------------------------------(Ombruten)
4952062 2000-03-29 07:25 /28 rader/ Postmaster
Mottagare: Bugtraq (import) <10392>
Ärende: Follow-Up: Security Problems with Linux 2.2.x IP Masquerading
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <38E0F4F5.27B9C164@secureaustin.com>
Date: Tue, 28 Mar 2000 12:07:49 -0600
Reply-To: H D Moore <hdm@SECUREAUSTIN.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: H D Moore <hdm@SECUREAUSTIN.COM>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
Following the "NetBIOS Info" thread on Incidents mailing list at SF,
Robert Graham <bugtraq@NETWORKICE.COM> 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
(4952062) ------------------------------------------(Ombruten)
4952148 2000-03-29 08:33 /40 rader/ Postmaster
Mottagare: Bugtraq (import) <10395>
Ärende: Re: Security Problems with Linux 2.2.x IP Masquerading
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@securityfocus.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <E12a1vv-00038E-00@rioja.localnet>
Date: Tue, 28 Mar 2000 20:45:47 +0100
Reply-To: Nigel.Metheringham@VDATA.CO.UK
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Nigel Metheringham <Nigel.Metheringham@VDATA.CO.UK>
X-To: H D Moore <hdm@SECUREAUSTIN.COM>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Message from H D Moore <hdm@SECUREAUSTIN.COM> of "Mon, 27 Ma
2000 23:31:41 MDT." <38E043BD.BF9BB32D@digitaldefense.net>
hdm@SECUREAUSTIN.COM said:
> The UDP masquerading code only checks the DESTINATION PORT to
> determine if a packet coming from the external network is to be
> forwarded inside.
this is due to a number of hosts/services returning UDP from an IP
other than that which the original UDP packet went to - for example it
is frequently the case that NFS servers just use the interface ip
address "closest" to that which the NFS op came from.
I'll give this some thought to work out a way of narrowing this hole
(I don't think it can be completely closed without causing other
problems).
However, in general I would not advise the use of UDP masq for a
firewalling gateway - since the only thing that people are normally
putting through the UDP side is DNS, you are much better advised to
put a decent caching name server on the gateway box and block UDP
through completely.
Nigel.
--
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000 Fax +44 1423 858866 ]
(4952148) ------------------------------------------(Ombruten)
4958679 2000-03-31 01:18 /90 rader/ Postmaster
Mottagare: Bugtraq (import) <10411>
Ärende: Re: Security Problems with Linux 2.2.x IP Masquerading
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@securityfocus.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <20000330121140.B7563@monad.swb.de>
Date: Thu, 30 Mar 2000 12:11:40 +0200
Reply-To: Olaf Kirch <okir@CALDERA.DE>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Olaf Kirch <okir@CALDERA.DE>
X-To: H D Moore <hdm@SECUREAUSTIN.COM>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <38E043BD.BF9BB32D@digitaldefense.net>; from hdm@SECUREAUSTIN.CO
on Mon, Mar 27, 2000 at 11:31:41PM -0600
Hi everyone,
I have a couple of observations on this masquerading problem.
HD Moore wrote:
> We have demonstrated that it is possible for us to 'hijack' the enternal
> side of a masqueraded connection, so now what?
This sounds a lot more dramatic than it really is. What you have
achieved is that you can send packets to a disused internal UDP port.
Granted, if the probing is refined you may even turn up a "live"
port. But if I understand masquerading correctly, twisting the
masq rule will not make any UDP packets sent by the internal client
automatically wind up at the attackers site.
So you will never know what sort of application is using that
masqueraded UDP port unless it is also serving requests on that same
port (like samba, or a DNS forwarder).
I concede that allowing anyone to inject UDP packets into the internal
network is still a bad feature of a masquerading firewall :-)
> 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
Detecting the presence of a masqueraded connection based on the IP ID
may not work if they use randomized IDs (I think recent kernels do
that). However the TTL will also be at least one less for packets
that come from an internal host.
Nigel Metheringham wrote:
> this is due to a number of hosts/services returning UDP from an IP other
> than that which the original UDP packet went to
I understand the rationale but not the consequences drawn from this.
When a remote server accepts a packet on interface A but sends out
the reply on interface B, the _port_ from which it sends the response
should still be the same. So it may be acceptable for some people if
the remote IP is ignored, but not the port.
In addition, I see no reason why the remote packet should update the
masquerading rule. The only consequence will be that when the
internal client sends another packet, the old masq rule will no
longer match, and a new port will be allocated (could this be used to
DoS the masq gateway?).
IMO, it would be good if the masq code defaulted to refusing any
packets arriving from the outside that do not exactly match an
existing masq rule. There could be a run time switch that allows
for a looser interpretation where packets with non-matching remote
IP are waved through (but the masq rules remain unaltered).
Note that there's some risk in this: if the masq code ignores the
remote address but checks the remote port, the attacker is now
able to determine the remote port an internal client is talking to,
and can thus decide what kind of packet it sends (e.g. the special
crash-the-win2k-DNS-client datagram).
Again, HD Moore writes:
> > UDP 04:35.12 192.168.1.100 10.10.187.13 1035 (63767) -> 12345
> ^-------[ expiration of the udp tunnel has been updated ;)
I believe a packet from remote should probably not update the masq
rule's life time. Imagine your internal client contacting a DNS
server that's not under your control. The DNS server could keep that
comm channel open as long as it wants to.
Cheers
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir@caldera.de +-------------------- Why Not?! -----------------------
UNIX, n.: Spanish manufacturer of fire extinguishers.
(4958679) ------------------------------------------(Ombruten)
4958681 2000-03-31 01:21 /101 rader/ Postmaster
Mottagare: Bugtraq (import) <10412>
Ärende: Re: Security Problems with Linux 2.2.x IP Masquerading (fwd)
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Authentication-Warning: kleintje.nozone.nl: tony owned process doing -bs
MIME-Version: 1.0
Content-Type: MULTIPART/Mixed; BOUNDARY=bg08WKrSYDhXBjb5
Content-ID: <Pine.LNX.4.21.0003302006530.6189@kleintje.nozone.nl>
Message-ID: <Pine.LNX.4.21.0003302006520.6189-200000@kleintje.nozone.nl>
Date: Thu, 30 Mar 2000 20:07:53 +0200
Reply-To: Tony den Haan <tony@CHELLO.NL>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Tony den Haan <tony@CHELLO.NL>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
This message is in MIME format. The first part should be readable
text, while the remaining parts are likely unreadable without
MIME-aware tools. Send mail to mime@docserver.cac.washington.edu
for more info.
--bg08WKrSYDhXBjb5
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0003302006531.6189@kleintje.nozone.nl>
---------- Forwarded message ----------
Date: Thu, 30 Mar 2000 14:52:36 -0300
From: Juanjo Ciarlante <jjo@mendoza.gov.ar>
To: Tony den Haan <tony@chello.nl>
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: Security Problems with Linux 2.2.x IP Masquerading (fwd)
On Tue, Mar 28, 2000 at 10:53:51PM +0200, Tony den Haan wrote:
> didn't see it here yet, so i decided to forward:
>
> [ 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.
>
> {nice example snipped}
Current UDP semantics were inserted sometime ago as a resource saving
hack:
_map_ internal box UDP port _at_ masq box by being "destination
loose" (DLOOSE) and thus:
. saving from creating a new masq tunnel for each {src,dst} pair
. allowing some applications that require comunicating with
same (masq'd) UDP source addr:port.
The core problem is precisely not being able to actually _know_ when
internal box has closed the port.
You can easily revert to good"old" way (1 tunnel/pair) by commenting out
#define CONFIG_IP_MASQ_LOOSE_DEFAULT 1
at ip_masq.c:418 (stupid patch attached)
This should drop hijack'ing ... Could you try and tell us?
Of course, if we change the default, some way to enable it back
perhaps on a per-application basis (ip_masq module) MUST be done.
Regards
--
-- Juanjo http://juanjox.kernelnotes.org/
... because there IS an OS that CAN follow your power
--bg08WKrSYDhXBjb5
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: <Pine.LNX.4.21.0003302006532.6189@kleintje.nozone.nl>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="ip_masq.c.noDLOOSE.diff"
--- net/ipv4/ip_masq.c.dloose Thu Mar 30 14:51:06 2000
+++ net/ipv4/ip_masq.c Thu Mar 30 14:57:24 2000
@@ -415,7 +415,7 @@
/*
* By default enable dest loose semantics
*/
-#define CONFIG_IP_MASQ_LOOSE_DEFAULT 1
+/* #define CONFIG_IP_MASQ_LOOSE_DEFAULT 1 */
/*
--bg08WKrSYDhXBjb5--
(4958681) ------------------------------------------(Ombruten)