Roger's Information Security Blog

Source code for Symantec Endpoint Protection 11 and Symantec Antivirus 10 has been stolen. According to speculation in news reports, the source code had been provided to the Indian government and was compromised from their servers. Security companies often provide source code to be able to sell software in a country. I suppose they are worried about NSA backdoors.  This hack highlights the problems with loaning out your source code.

Symantec downplayed the severity of the report saying SAV 10 is no longer sold (end of support in July 2012) and SEP11 is 4-5 years old.

Even if the source code was a from a earlier version, I am confident the source code doesn’t change that much in a major build.    Symantec Endpoint Protection 11 may have initially been released 4 or 5 years ago (can that be right?) but it is still the main version in use today.   Its successor SEP 12.1 was only released in July and most people would wait before deployment.

I was a bit surprised by some of the reactions in to this disclosure.   Rob Rachweld of Imperva says there is “not much hackers could learn from it” because they already analyze antimalware products.   The Atlantic Wire quotes Bruce Schneier as saying it isn’t a big deal.

I think it is a big deal.   Antivirus products do have vulnerabilities.   Antivirus products are widely deployed and often it is possible to find out what a particular company is using.   Isn’t code analysis easier than trying to blackbox test or trying to reverse engineer the code?  Depending on how diligent Symantec has been, I think this could lead to more security updates for Endpoint Protection.

Chris Parden, Symantec spokesmen says the are developing a remediation process for enterprise customers still using affected products.

After fighting with duplicate hardware IDs in Symantec Endpoint Protection not that long ago, it was surprising to find the problem back again.   Were these left over from the original problem, or was this a return engagement.   And if it was a problem cropping up again, was it caused by someone forgetting to do the ghost load correctly or something else?

Symantec Endpoint Encryption uses a hardware ID as a GUID to differentiate clients.   If a GUID is cloned to multiple computers your reporting and policies are affected.   We tend not to find these problems until we move a client to a new group and find other computers showing up in the new group instead.

It turns out the old SEP 11 instructions for preparing to clone a image don’t quite work with 12.1.     With SEP12.1 on Windows 7 64 bit, we found an additional copy of sephwid.xml in C:\ProgramData\Symantec\Symantec Endpoint Protection\PersistedData\sephwid.xml.   It wasn’t mentioned in the SEP11 instructions, and every machine from the image ended up with the same hardware ID.   If you are manually fixing duplicate GUIDs keep that in mind.

It turns out there are instructions specifically for SEP12.1.

How to prepare a Symantec Endpoint Protection 12.1 client for cloning – http://www.symantec.com/docs/HOWTO54706

How to repair duplicate IDs on cloned Symantec Endpoint Protection 12.1 clients  – http://www.symantec.com/docs/TECH163349

 They don’t give manual instructions (at the time of this writing) on removing the hardware ID in 12.1, but they do provide a executable for the job.   I haven’t tested this exe out, but one thing bothers me.   The instructions say if you use tamper protection you must disable this.   If you require a password to stop the smc service you must disable that.    We don’t use tamper protection, but we do require a password to stop the smc service using the smc -stop command.  I wish they would allow me to provide the password at the command line as the sylink dropper tool can do.   The good news is that by setting up a separate policy for these clients in order to disable the password requirement to stop the SMC, you can then identify the remnant accounts based on the duplicate hardware ID that could be deleted.

Symantec Endpoint Protection 12.1 was released on July 5th.   A post on Symantec Connect says they are deploying the upgrade licenses via snail mail and sending in alphabetical order.   To a certain extent, I can sympathize with a desire to not overwhelm support.   But I feel that people who participated in the beta program should be given access to the bits immediately.

I logged into https://licensing.symantec .com and selected Version Upgrade.  Next I selected “I Don’t Have an Upgrade ID”.   Select your customer number and select upgrade on the following screen.   If none of the one’s listed give you a SEP upgrade you’ll need to find your license pdf and use the customer number associated with the purchase of SEP. 

I then had a valid serial number to use at https://fileconnect.symantec.com.   After downloading the bits, I found that unfortunately SEP 12.1 is requiring me to use a license file.   I figured this might be coming.   in SEP11, Symantec required small business to use license files.   I haven’t had to use a license file since we started using Symantec Antivirus more than 10 years ago.   I feel like this is only an unnecessary complication.

Next I began working on an upgrade plan.   I currently am running SEPM on a Windows 2003 server.   This seems like a good time to change that to Windows 2008 R2.   One method would be to bring up a second server with Windows 2008 R2 and SEPM 12.1.   I prefer to keep my computers reporting to a server with the same name and IP.   That means I’ll be using a disaster recovery scenario.  

The first issue I’m finding is a lack of documentation for recovering SEP11 recovery files into a SEP12 server.  I’m thinking I may be better off upgrading the existing server to SEP 12.1 and performing a DR backup, then turn the server off and bring up the Windows 2008R2.    Another possibility is to put SEP11 on the Windows 2008R2 server and then upgrade it to SEP12.   I prefer to keep the new server “cleaner” than that.

I would think this would be a relatively common scenario.   But all I can find is the linked Symantec knowledge base article that states SEP11 DR files can’t be imported into the standard SEP12 DR files.   I understand that.  But I would still think it could be done manually.

I’ll be trying to get some more answers before doing the upgrade, even in the test environment.