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.

Symantec Endpoint Protection (SEP) 11 is getting long in the tooth.   It was a huge step forward.   But I’m starting to look forward to the next release.   Symantec released a small business edition with version 12.   So I’m calling the next version of SEP, SEP12.1.    That isn’t official.   Here’s a list of what I’d like to see in SEP11

Full 64 Bit Feature Parity
Enough is enough.   With the release of Windows 7, 64 bit is starting to be adopted by regular users.   Some companies have made 64 bit the standard for their Windows 7 corporate rollout.

Symantec does not currently support application and device control on 64 bit.  Companies don’t want to have different levels of security for 32 versus 64 bit computers.    We use the Device control part of Symantec to disable the wireless card when a wired connection is present.   I see that as critical functionality.   This is causing us to be unable to use 64 bit laptops.   Further the helpdesk wanting to hold down complexity seems to be against 32 bit laptops and 64 bit desktops.   To avoid twice the testing they want all 32 or 64 bit computers.

I can no longer find the knowledge base article, but I recall there being less keylogger protection in 64 bit SEP11 due to kernel protections by Microsoft.   Not sure that one could be fixed without hooking the kernel outside of approved APIs.    (not a good idea).

Wireless Management
As I mentioned, I use Application and Device Control to disable wireless cards when wired connected.   This is an important security consideration to prevent the client from being attacked by someone in the parking lot while they are on our network.  

The problem with the current method (besides the 64 bit issue I covered in the last section), is Symantec leaves it up to the SEPM administrator to manually add the device ID for each device they wish to block.   This is decidedly not cool.   Each time we start bringing in a new laptop model I need to update the block rule with the new device ID.   It’s not just wireless cards.   I’d like EVDO/3G wireless modems disabled as well.   Symantec should be doing this in a more automatic way.  

IPv6
Symantec Endpoint Protection 11 does not understand IPv6.   With the built-in firewall you can only allow it or block it at the protocol level.   You can not have rules based on source/destination addresses/ports.   I don’t think I need to belabor the point.   IPv4 address exhaustion is months away according to some reports.   Some ISPs are already conducting IPv6 tests with end users.  

IPv6 support is listed as in development and to be in the next major release.  

To the Cloud
Symantec did rather well in Gartner’s December 2010 Endpoint Protection Magic Quadrant.   I believe the in the cloud protection was even mentioned.   The problem is in the cloud reputation scoring is currently only available for home users.    I believe all of Symantec’s major competitors already use this sort of community scoring as an extra layer of protection, and have for some time.   

With in the cloud protection, there is a community based reputation score assigned to files so they can be treated appropriately.

I understand Symantec is a big company, but it needs to innovate protection, not lag behind while using other parts of the company (consumer) as test beds for new engines and new techniques.

Performance Improvements
I know that Symantec Endpoint Protection was a big step up over Symantec Antivirus 10 in terms of performance.   But that was many years ago.   According to some comparison numbers Endpoint Protection could use some speed improvements.   Not near the top of my list but worth mentioning.

Single Agent/ Single Console
Those of us using GuardianEdge for encryption are hoping to have a unified point of management.   One agent to upgrade.   One less thing to update, one less place to look for reports.

Some of these items are already listed at Symantec Ideas.   Some of them, like IPv6, are already known to be in the next major release.   At Symantec Connect, you can use the Ideas section to suggest a new feature or functionality, and vote or comment on other people’s suggestions.  

I dont have a lot of complaints about SEP.   I do hope that a few of these things get cleared up in the next version.