Re: Security Problems with Linux 2.2.x IP Masquerading

[okir () CALDERA DE (Olaf Kirch)]

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.