A critical vulnerability, known as Shellshock, relies on a flaw in the GNU Bash command interpreter. The flaw could allow an attacker to insert malicious code in the environmental variables used by the operating system to remotely execute shell commands.

 

The ProxySG Appliance is not vulnerable to Shellshock.

 

Now that we have that out of the way, did you also know that the ProxySG Appliance can also help your organization deal with Shellshock?

Through policy, the ProxySG Appliance can block requests attempting to exploit Shellshock.

 

If you have the ProxySG Applaince deployed in Reverse Proxy mode, ie, front ending your application servers, you can use the following policy examples to deny requests trying to instantiate the Shellshock exploit. There are two versions of the policy, one for SG6.5.2 and later, and one for pre SG6.5.2 versions. The policy will evaluate the HTTP headers and HTTP request line for the “() {“ pattern used in the exploit. Here is an example of the policy for SG6.5.2:

 

Policy for SGOS  v6.5.2 - Supports new syntax http.request[].regex:

 

<proxy>

; Shellshock DENY policy, SG6.5.2 or later

DENY request.raw_headers.regex="\(\) \{" 

DENY http.request[name,value].regex="\(\) \{"

 

Policy for earlier versions of SGOS 6.x (pre SGOS  v6.5.2)

 

<proxy>

; Shellshock DENY policy, pre SG6.5.2 version

DENY request.raw_headers.regex="\(\) \{"

DENY url.regex="\(\) \{"

 

Note that these policies will increase CPU utilization a little to search for the exploit pattern. They can be modified to target only CGI type exploits as follows:

 

Policy for SGOS  v6.5.2 version targeting CGI servers

 

<proxy>

DENY raw_url.path.regex="cgi" request.raw_headers.regex="\(\) \{"

DENY raw_url.path.regex="cgi" http.request[name,value].regex="\(\) \{"

 

Policy for earlier versions of SGOS 6.x (pre SGOS  v6.5.2) targeting CGI servers

 

<proxy>

DENY raw_url.path.regex="cgi" http.request.raw_headers.regex="\(\) \{"

DENY raw_url.path.regex="cgi" url.regex="\(\) \{"

 

These are just some examples of how to apply policy. For example, instead of DENY, you can change the policy to just log requests. This might be useful for other proxy deployments (such as forward/explicit proxies) where internal clients have been compromised and are generating requests to servers.