failcoat

Step 1 Testing Block Testing
Step 2 Exfiltrating Data Testing
Step 3 Verify Vulnerability Testing
Unfortunately, it appears that you are vulnerable to the Failcoat bug. We sent the following data out:


    which you can see here.
  
Congratulations, you're not vulnerable to the Failcoat bug!
Initial site is not blocked, can't continue the test.

First of all, this site is NOT associated with Blue Coat, or Symantec. We're just trying to help people check for potential problems, and then fix them. (A link to an official page is down below.)

The Problem:

ProxySG policy can grow to become quite complex. Unfortunately, sometimes code in one layer can affect code in earlier layers in adverse or undesirable ways. The impact of these cases can be minor or major. One such case, of the Major Impact variety, can allow the Proxy to actually pass on a GET or POST call to a destination that's rated as Malware (or any other blocking category). Worse, this happens even though the client machine sees a normal block page, leading you to think that all of the traffic was blocked to the malicious site. While not an actual vulnerability in the Proxy, it is certainly an undesirable side effect of incorrect policy. And that's tricky to test for...

The Test:

This site was built to provide a quick and easy way to test your Proxy, to see if it contains policy rules that allow this situation to occur.

To test, simply click the "Run Test" button. The test consists of three steps:

Step 1 - A simple request is sent to a site that is rated as Malware. (Note: it's not actively malicious, but it needs this category rating for the test.) Assuming you are running this test behind a ProxySG, you should see a "Blocked" result. (If your Proxy is not blocking any access to Malware sites, you have a much larger configuration problem!)

Step 2 - A second request is sent to the same domain, but this time it is a POST with a block of random data, simulating an exfiltration attempt by a malicious actor.

You're hoping to see a "Got Blocked" result. But wait, this is just from the client computer's perspective. How does it know if the request was completely blocked, or only "mostly blocked" (to steal a meme from Princess Bride). To find out, we have to do the Step 3 check.

Step 3 - In this step, we send a request to a different domain (one that is not rated as malicious), and ask the "normal" domain if the "malware" domain happened to get that POST data we just tried to send. (The domains are on the same server, to make this check easy.)

You're hoping to see a "Not Vulnerable" result in Step 3 -- meaning your policy (A) correctly blocked the client's request, and (B) that the Proxy did not accidentally send the request on to the malware site as a result of some other policy rule it was trying to follow.

If instead you get a "Vulnerable" result, you need to fix your policy. Blue Coat has created a page to explain how such contradictory policy can arise, and how to go about fixing it:

http://bluecoat.force.com/knowledgebase/articles/Solution/000032877

Once you think you've fixed your policy, feel free to come back and re-test.

Finally, if re-testing still shows that you're failing, and you're not sure why, so you need to open a support ticket, please mention "failcoat" when you do...

This may help get prioritized service (or not, but it's worth a try), as a Blue Coat representative has indicated that they are very interested in seeing cases where our test shows a policy failure, but it is NOT fixable by the KB article's proposed remediation.