Bugtraq mailing list archives
Re: Security Problems with Linux 2.2.x IP Masquerading
From: okir () CALDERA DE (Olaf Kirch)
Date: Thu, 30 Mar 2000 12:11:40 +0200
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.
Current thread:
- Re: Esafe Protect Gateway (CVP) does not scan virus under some, (continued)
- Re: Esafe Protect Gateway (CVP) does not scan virus under some Eric Chien (Mar 24)
- Re: Esafe Protect Gateway (CVP) does not scan virus under some Jason Brvenik (Mar 24)
- Re: Esafe Protect Gateway (CVP) does not scan virus under some Lea, Michael (Mar 24)
- Security Problems with Linux 2.2.x IP Masquerading H D Moore (Mar 27)
- Follow-Up: Security Problems with Linux 2.2.x IP Masquerading H D Moore (Mar 28)
- privacy problems with HTTP cache-control Martin Pool (Mar 28)
- Objectserver vulnerability Howard M. Kash III (Mar 29)
- Citrix ICA Basic Encryption Dug Song (Mar 29)
- Re: Citrix ICA Basic Encryption Weld Pond (Mar 28)
- Re: Citrix ICA Basic Encryption Chris Knight (Mar 29)
- Security Problems with Linux 2.2.x IP Masquerading H D Moore (Mar 27)
- Re: Security Problems with Linux 2.2.x IP Masquerading Olaf Kirch (Mar 30)
- Remote DoS Attack in Windows 2000/NT 4.0 TCP/IP Print Request Server Vulnerability Ussr Labs (Mar 30)
- Re: Esafe Protect Gateway (CVP) does not scan virus under some Ian Turner (Mar 27)