(Updated December 11th, 2012 – 9:115 PST)
TL;DR: Turns out there isn’t an easy way to do this with just Symantec and trying to block the Java App. We blocked *@skillpages.com on our gateway anti-spam server and that took care of the problem for the most part.
Original article
We recently experienced a user who signed up for Skillpages.com. Upon signing up they chose to import their Outlook contacts. This causes a Java Application to download to the users workstation and automatically import their Outlook contacts. Big problem for us because it also imported our entire Global Address List from Exchange. Then Skillpages.com spammed our entire organization trying to get more users to sign-up.
Blocking *@skillpages.com on our gateway antispam server (Puremessage) took care of the e-mail spam but we wanted to prevent users from running the Java App in the first place on our workstations.
Blocking the domain that the Java App is downloaded from might be a bad idea. Cloudfront.net is a redirect to Amazon’s CloudFront service and who knows what amount of legitimate uses there are for it.
Next up was trying to block the Java App as it downloaded. To do this we created a new ‘Application and Device Control’ policy with the following settings:
In a nut shell this policy will monitoring the Java processes for any attempt to write a temporary file that matches the pattern “66c3f8b9-*-temp”. We determined that the first set of characters are static and only the second group change from download to download. After implementing this policy we tried a few random sites with Java on them and didn’t have any problems with legitimate apps being accessed.
In theory this should work until Skillpages.com gets wise and changes the prefix on their Java Applet.
I’m open to better ideas if you have them.
Update – December 10th, 2012 – 12:25 PST
Checked out the results of my brilliant plan today and it looks like the temp file name has changed to ‘577a15c9-72a17cab-temp’. So much for that idea. For now I’ve added the new temp file name to our policy but I don’t think this is going to be a practical solution in the long term.
It seems Symantec can’t block the download itself which is a consistent ‘ContactsFinder.jar’ which comes from “http://dyjab6i3qfxan.cloudfront.net/20121210.6/Resources/Internal/ContactsFinder/ContactsFinder.jar”. We also don’t deploy the firewall component which might make this easier.
Update – December 11th, 2012 – 9:06 PST
So I checked again today and the temp files prefix has one again changed. I don’t think this method of blocking is going to be effective.
If you have Symantec Endpoint and have the firewall installed on your users machines you can probably block the download site directly… or if you have a Proxy server…. or if you have a modern edge firewall. Try blocking “http://dyjab6i3qfxan.cloudfront.net/20121211.3/Resources/Internal/ContactsFinder/ContactsFinder.jar”
I also finally got an e-mail back from Skillpages after requesting my e-mails be removed since I didn’t consent to them being uploaded. Skillpages instructed me to create an account with each e-mail address (effectively agreeing to their ToS and EULA) and then go to http://www.skillpages.com/i/settings#email and remove my account. Not an acceptable solution in my books.