Endpoint Protection

Is SEP 12.1 MP4a (12.1.4023.4080) vulnerable to Heartbleed?

Currently, all hosts are internal, however the SEPM does go through squid proxy to capture daily virus updates.  

Are these systems vulnerable?

How about Symantec Critical System Protection 5.2.9 MP2? vulnerable?

Symantec is investigating and will share more info when they have it

https://www-secure.symantec.com/connect/forums/openssl-bug#comment-10000681

Early signs point to yes though per this post:

https://www-secure.symantec.com/connect/forums/openssl-bug#comment-10003581

https://www-secure.symantec.com/connect/blogs/heartbleed-openssl-take-action-now

Symantec team is working on this, there will information shared very soon on this.

CSP is NOT vulnerable, it uses a non exploitable version of OpenSSL.

The version of OpenSSl in SEP12.1RU4 is in the list of versions affected by Heartbleed, as I mentioned in my thread below:

https://www-secure.symantec.com/connect/forums/openssl-bug

I also mention that most SEP Implementations will have limited exposure to it anyway, being setup to manage only internal endpoints with no external access to 8443, 8445 or 443 (if even enabled).

The SEPM's definition update from Symantec LiveUpdate typically goes over port 80 anyway, and is in clear text to boot

Hello,

Below I have listed options to mitigate the vulnerability.

1. Upgrade OpenSSL to version 1.0.1g which should update to the latest fixed version of the software (1.0.1g)

http://www.openssl.org/source/

(steps 2 it is workaround to protect the SEPM until a patch is released for the SEPM)

2. Block off port 8445

To temporarily mitigate the vulnerability before you upgrade the Symantec Endpoint Protection Manager console, you can block the affected port with a firewall rule. However, if you block the port, the management console loses specific functionality. You should review the implications prior to implementation.

Note: The port mentioned below is the Symantec Endpoint Protection Manager default port. If you have changed the communication port, please alter the firewall rules appropriately.

Steps: Add a firewall rule to block the specific port on the computer on which you installed Symantec Endpoint Protection Manager. This firewall rule should apply to all hosts and all applications.

To confirm that the rule applied successfully, simply telnet to the port. If the rule is configured correctly, the firewall successfully blocks traffic and does not permit a connection on the port.

Note: For instructions on creating a firewall rule using the Symantec Endpoint Protection client, please see HOWTO81156: Adding a new firewall rule. If you configure the policy from the Symantec Endpoint Protection Manager, you will need to wait for the policy to propagate to the Symantec Endpoint Protection client installed on the SEPM server prior to testing. To force the SEP client to download the modified policy immediately, right-click the SEP system-tray icon and click Update Policy.

Implications: If an administrator logs in to the SEPM with port 8445 blocked, the first three reporting tabs (Home, Monitors, and Reports) will not display in the Remote Java console. Blocking port 8445 will deny access to the Remote Web Console as well. Administrators may configure firewall rules to allow access to port 8445 or 443 from explicit hosts, IP addresses, or IP address ranges to enable these features.

FIPS mode: FIPS mode utilizes port 443 for client/server communications. If FIPS mode is enabled, port 443 should be restricted. Blocking port 443 will deny communication to/from all clients that are in FIPS mode. Administrators may configure firewall rules to allow access to port 443 from explicit hosts, IP addresses, or IP address ranges to enable these features.

Symantec public article regarding the heartbleed vulnerability

http://www.symantec.com/connect/blogs/heartbleed-b...

Regards,

Mithun Sanghavi

So we should upgrade OpenSSL on our own instead of waiting on a symantec patch? Is this official?

Hello,

OpenSSL is a vendor for Symantec. Heartbleed is not a vulnerability with SSL/TLS, but rather a software bug in the OpenSSL heartbeat implementation.

For your convenience, here is a summary of steps to take:

For businesses:

• Anyone using OpenSSL 1.0.1 through 1.0.1f should update to the latest fixed version of the software (1.0.1g), or recompile OpenSSL without the heartbeat extension.  
• Businesses should also replace the certificate on their web server after moving to a fixed version of OpenSSL.
• Finally, and as a best practice, businesses should also consider resetting end-user passwords that may have been visible in a compromised server memory.

For consumers:

• Should be aware their data could have been seen by a third party if they used a vulnerable service provider.
• Monitor any notices from the vendors you use. Once a vulnerable vendor has communicated to customers that they should change their passwords, users should do so.
• Avoid potential phishing emails from attackers asking you to update your password – to avoid going to an impersonated website, stick with the official site domain.

Heartbleed in OpenSSL: A message from Symantec Vice President of Trust Services Tom Powledge http://bit.ly/1mYmlLx 

Regards,

Apparently CSP is vulnerable depending on your version.  See from support:

Title
Data Center Security / Symantec Critical System Protection (SCSP) affected by the Heartbleed OpenSSL vulnerability (CVE-2014-0160)

Issue
 The SDCSS product (formerly the SCSP product) uses OpenSSL on the agent for secure communication with the management server.   We have analyzed CVE-2014-0160 and the product is vulnerable on the agent only, the server is not vulnerable.

Solution

The following SCSP/SDCS:SA releases use the vulnerable version of OpenSSL:
•  SCSP 5.2.9 MP3 (Windows and Unix agents)
•  SCSP 5.2.9 MP4 (Windows and Unix agents)
•  SCSP 5.2.9 MP5 (Windows and Unix agents)
•  SDCS:SA 6.0 (Windows and Unix agents)
 
The following SCSP/SDCS:SA releases are not vulnerable:
•  SCSP 5.2.9 MP2 and older (Windows and Unix agents). These agents use an older, non-vulnerable OpenSSL version.
•  SCSP 5.2.x (Linux agents). Symantec does not distribute OpenSSL for these agents. The product uses the OpenSSL provided by the operating system. Customers should examine their systems, determine if they have a vulnerable version of OpenSSL, and update it themselves if necessary.
•  SDCS:SA 6.0 (Linux agents) Symantec does not distribute OpenSSL for these agents. The product uses the OpenSSL provided by the operating system. Customers should examine their systems, determine if they have a vulnerable version of OpenSSL, and update it themselves if necessary.
•  SCSP 5.2.x Server and Console. These components do not use OpenSSL.
•  SDCS:SA 6.0 Server and Console. These components do not use OpenSSL.
 
In order for someone to exploit the OpenSSL vulnerability in the agent, they must cause the agent to connect to a malicious server. Because the agent is configured to communicate with a specific set of SCSP management servers, causing the agent to connect to a malicious server requires exploiting an additional vulnerability. Because exploitation requires chaining a series of vulnerabilities, Symantec has given this issue a low severity rating.
 
The CERT description (http://www.kb.cert.org/vuls/id/720951) identities 4 categories of sensitive information that could be leaked. Using these categories, the data that might be leaked from a SCSP agent if someone were to exploit the vulnerability are as follows.
 
•  Primary key material (secret keys) The agent does not handle primary key material.
•  Secondary key material (user names and passwords used by vulnerable services) The agent does not handle secondary key material.
•  Protected content (sensitive data used by vulnerable services). The content that might be leaked from the agent is the data that is transmitted between the agent and the management server over the OpenSSL encrypted connection. This includes SCSP event data, SCSP policy content, SCSP discovered application data, and other product content and configuration settings.
•  Collateral (memory addresses and content that can be leveraged to bypass exploit mitigations) The memory addresses and content of the agent service communicating over the network might be leaked.

New link related to SEPM:

http://www.symantec.com/docs/TECH216558

Hi,

SEPM 12.1 RU2 to SEPM 12.1 RU4 MP1 (inclusive) are vulnerable. They utilize OpenSSL 1.0.1.

The CSP server itself uses a non-vulnerable OpenSSL version

Also: if the SEP client defending the SEPM has its IPS component in place, this IPS signature will offer protection:

Attack: OpenSSL Heartbleed CVE-2014-0160 3

http://www.symantec.com/security_response/attacksignatures/detail.jsp?asid=27517

This signature was added in Security Update: 772 [Extended version: April 10, 2014 Rev: 012]

IPS is a crucial part of today's defenses.

Two Reasons why IPS is a "Must Have" for your Network

https://www-secure.symantec.com/connect/articles/two-reasons-why-ips-must-have-your-network

Hope this helps!

Mick

SEP 12.1.4.1a is now release, you can download it from file connect

Heartbleed OpenSSL vulnerability fixed in this version.

Check the available document

Symantec Endpoint Protection 12.1.4.1a is now available

File Connect Link

https://symantec.flexnetoperations.com/control/symc/registeranonymouslicensetoken

New fixes and features in Symantec Endpoint Protection and Network Access Control 12.1.4.1 and 12.1.4.1a

Hi

Symantec has released new version i.e SEP 12.1.4a which has a fix for open SSL vulnerability

Regards

Hi,

It's not the SEP 12.1.4a version, it's a 12.1 RU4 MP1a.

Followers of this thread may be interested in attending Symantec's webcast on Tuesday the 29th.  The following blog post has all the details and a link to the registration page

The Heartbleed Bug: How to Protect Your Business
https://www-secure.symantec.com/connect/blogs/heartbleed-bug-how-protect-your-business

With thanks and best regards,

Mick