OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Our old friend Firewall-1
From: Chris Brenton (cbrentonSOVER.NET)
Date: Sat Mar 11 2000 - 20:28:59 CST


Greetings all,

The Dartmouth Collage security group has uncovered a problem with
Firewall-1 which could lead to the protected site handing out more IP
address info than intended.

Under certain nominal load conditions (CPU less than 40%, 200+ active
sessions) Firewall-1 will begin "leaking" packets with their private
address information in tact. The result is that the receiving site will
receive a SYN=1 that it will be unable to respond to. Once the client
attempts a resend, the target network (or anyone in the middle) can use
the source port information to enumerate the client's true IP address.

Here is a Snort trace which has been sanitized and formatted for easier
viewing:
Mar 9 14:01:19 172.30.1.10:1721 -> 192.168.1.5:80 SYN **S*****
Mar 9 14:01:48 200.200.200.5:1721 -> 192.168.1.5:80 SYN **S*****

Mar 9 14:04:35 172.30.1.10:1858 -> 192.168.1.5:80 SYN **S*****
Mar 9 14:05:05 200.200.200.5:1858 -> 192.168.1.5:80 SYN **S*****

Mar 9 14:23:25 172.16.5.20:4868 -> 192.168.1.5:80 SYN **S*****
Mar 9 14:23:51 200.200.200.5:4868 -> 192.168.1.5:80 SYN **S*****

So the first packet goes out with the private address information still
in place and SYN=1. When the client does not receive a reply, it
retransmits the SYN=1. Since FW-1 considers this to be part of the same
session, the same source port number is assigned. If the second packet
gets translated properly (as in these traces) the source port info can
potentially be used to map the legal IP address to the private address.

Of course the problem here is that a would be bad guy now knows the
client's true IP address. If enough hosts are recorded, its possible
that most of the internal network address space could be enumerated.

This problem has been noted on Firewall-1 versions 3.0b & 4.0. 4.1 has
not been checked but its expected that the same problem may exist. We
where able to reproduce the problem on a Nokia IP440 and NT. I've seen
this problem on Solaris 2.6 as well, but do not have the data to back up
the statement.

A quick fix is to apply egress filtering to the border router and block
all private addressing that attempts to leak though. A how-to on egress
can be found at:
http://www.sans.org/y2k/egress.htm

Cheers all,
Chris

--
**************************************
cbrentonsover.net

* Multiprotocol Network Design & Troubleshooting http://www.amazon.com/exec/obidos/ASIN/0782120822/geekspeaknet * Mastering Network Security http://www.amazon.com/exec/obidos/ASIN/0782123430/geekspeaknet