> 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:06:24 PDT