[12094] in bugtraq
Re: FireWall-1 weakness
daemon@ATHENA.MIT.EDU (Mike Frantzen)
Fri Oct 1 16:43:56 1999
Content-Type: text
Message-Id: <199909302116.QAA22855@expert.cc.purdue.edu>
Date: Thu, 30 Sep 1999 16:16:22 -0500
Reply-To: Mike Frantzen <frantzen@EXPERT.CC.PURDUE.EDU>
From: Mike Frantzen <frantzen@EXPERT.CC.PURDUE.EDU>
X-To: Hugo.van.der.Kooij@CAIW.NL
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.10.9909300738360.31066-100000@bastion.nl3155vj16.vanderkooij.org> from
"Hugo.van.der.Kooij@CAIW.NL" at Sep 30, 99 07:58:22 am
> If one takes CheckPoint FireWall-1 v4.0 SP4 (latest version) and build the
> Source: Destination: Protocol: Action:
> Any citrix-server winframe accept
> A customer tried to run FTP through it and saw an accept in the log. But
> due to the lack of a server on the other side could not establish wether
> or not there was a leak.
It was passed through because there is _no_ difference between the SYN of
the FTP session and the SYN of the Citrix session (unless you believe that
anything coming from or to a NT box natively smells bad)
> Recreating this in the lab with telnet showed the same. However putting a
> working telnetd on port 1494 at the specific server did still not allow
> anyone to enter the system. After initial TCP connection setup it seems
> the firewall drops connections.
The firewall should be eating the connection. If something got injected
into the stream or the Citrix client decided to just muck up the protocol
for awhile, Firewall-1 should eat the wacky stuff and not drop the state
entry. So if the Citrix client un-dumbifies itself later in the session and
appears to be 'Real Winframe Traffic', the Firewall could let it go through.
> But this will lead to two weaknesses:
> 1. Any server defended by FireWall-1 could be subject to a DoS attack if
> the server should accept TCP sessions at port 1494. The server allows
> the initial setup and then stops forwarding.
> (That's two dependencies but we are the people that allways assume the
> worst as we are the ones that try to do the worst in such case ;-)
I don't really see how this is different that connecting to a port and
letting the connection idle. If either the client or the server reset the
connection, it should still go through the firewall and everything is kosher.
I doubt that Firewall-1 stops forwarding (aka, removes the state entry) but
it just eats the packets that do not contain information valid to the state
of the supposed 'Winframe' session.
If it really does remove the state entry, another DoS _could_ be performed.
As Lance Spitzner informed us a few months back, FW-1 doesn't care about
TCP Sequence numbers. An attacker could spoof his source IP as the person
he doesn't want to talk to the Citrix-Server. And spray packets covering all
64k source ports to the Citrix-Server. As long as the packet doesn't contain
information valid to the current Winframe state, and the session gets
dropped. [I hope I didn't butcher your name Lance]
> 2. The log only shows a succesfull start of the session but down not
> indicate any filtering. This leaves the operator of the firewall in
> the dark wether or not a session was cut off due to the missing
> winframe signature. So there is no indication off foul play and
> everyone will be assuming things are just fine.
Imagine what would happen if the Winframe protocol (or whatever it is called)
undergoes a revision in the newer version of Citrix or NT Terminal Server
(I haven't played with them since the Beta's over a year ago!) and you are
still running the same Firewall revision. Every time the Citrix machines try
one of the new features, Firewall-1 starts alarming on an attack. And the
firewall admin's pager starts doing the Macarena.
That would be a really cool DoS. I am sure the fw admin would turn off
logging pretty damn quick!
> (We all know that if a firewall is supposed to show dropped packets
> that plenty of people will never look for trouble in the sessions that
> are allowed.)
hehe, I stopped assuming that for FW-1 after I saw how many packets it would
fail to log. And the firewall would sometimes log the wrong source IP of a
packet (never could exploit it reliably though)
> I hope that this document will help people understand a oversight in the
> logging/alerting facilities that they have to deal with in FireWall-1.
I hope so too. Firewall-1's logging leaves much to be desired (and still
more to the imagination)
I'd prefer it if people didn't start equating packet filters to application
proxies but Darwinism is slow catching up :-)
later,
.mike
---
"We reject kings, presidents, and voting;
we believe in rough consensus and running code."
-- Dr. David D. Clark 1992
