Bugtraq mailing list archives
Our old friend Firewall-1
From: cbrenton () SOVER NET (Chris Brenton)
Date: Sat, 11 Mar 2000 21:28:59 -0500
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 -- ************************************** cbrenton () sover 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
Current thread:
- TESO advisory -- wmcdplay krahmer () CS UNI-POTSDAM DE (Mar 11)
- Our old friend Firewall-1 Chris Brenton (Mar 11)
- Re: Our old friend Firewall-1 Hugo.van.der.Kooij () CAIW NL (Mar 14)
- Re: Our old friend Firewall-1 Chris Brenton (Mar 15)
- TESO & C-Skills development advisory -- imwheel Sebastian (Mar 16)
- Re: TESO & C-Skills development advisory -- imwheel WHiTe VaMPiRe (Mar 19)
- Re: Our old friend Firewall-1 Hugo.van.der.Kooij () CAIW NL (Mar 14)
- Re: TESO advisory -- wmcdplay Kris Kennaway (Mar 11)
- CSS Exploits + RDS (IE5) Shane Hird (Mar 12)
- Advisory Update: ServerIron TCP/IP predictability fixed Andrew van der Stock (Mar 12)
- Exploit for Mandrake 6.1 (PAM/userhelper bug) Paulo Ribeiro (Mar 14)
- Re: Exploit for Mandrake 6.1 (PAM/userhelper bug) Darron Froese (Mar 17)
- Re: Exploit for Mandrake 6.1 (PAM/userhelper bug) Matt Davis (Mar 17)
- Exploit for Mandrake 6.1 (PAM/userhelper bug) Paulo Ribeiro (Mar 14)
(Thread continues...)
- Our old friend Firewall-1 Chris Brenton (Mar 11)