Symantec Reporting Server Password Disclosure

1123

06 March 2020

05 June 2007

CLOSED

MEDIUM

4.3

SUMMARY

 

The administrator password for Symantec Reporting Server could be disclosed after a failed login attempt.

Risk Impact
Medium

Remote Access

Yes

Local Access

Yes

Authentication Required

Yes

Exploit publicly available

No

 

AFFECTED PRODUCTS

 

Affected Products

Product

Affected Version

Updated Version

Solution

Reporting Server

1.0.197.0

Reporting 1.0.224.0

SAV 10.1 MR6 build 6000 (10.1.6.6000) or later

SCS 3.1 MR6 build 6000 (3.1.6.6000) or later

Note:
Symantec Reporting Server is distributed with Symantec AntiVirus Corporate Edition 10.1 and later and Symantec Client Security 3.1 and later. The first publicly available version of Reporting Server was 1.0.197.0. All builds of Reporting prior to the Updated version listed above are impacted by this vulnerability.

ADDITIONAL PRODUCT INFORMATION

 

Unaffected Products

Product

Version

Build

 

Norton product line

all

all

 
 

 

ISSUES

 

Details
Symantec Reporting Server is an optional web application within the Symantec System Center console that can be used to create reports about Symantec Client Security and Symantec AntiVirus products in an enterprise network. Symantec was notified that a failed attempt to log in to the Reporting Server could result in displaying a hashed version of the password. An attacker could potentially use the hashed password to gain access to the Reporting Server database with administrator rights.

This issue is a candidate for inclusion in the Common Vulnerabilities and Exposures (CVE) list (http://cve.mitre.org), which standardizes names for security problems. The CVE initiative has assigned CVE-2007-3022 to this issue

MITIGATION

 

Symantec Response
Symantec engineers confirmed that this vulnerability exists in the versions of Reporting Server included with Symantec Client Security 3.1 and SAV CE 10.1, as indicated in the table above. Updates have been released to address the vulnerability.

A successful attacker would gain access only to the Reporting Server database. The attacker would not automatically have access to other programs on the computer, unless the same account and password are used for other programs. As a best practice, the accounts created for managing Reporting Server should not use the same id and password as the users’ network login credentials.

During the internal review of the issue, Symantec engineers also identified and fixed a separate issue which could allow an attacker to disable the authentication system for the SCS Reporting Server. If successfully exploited, this could allow a remote attacker to bypass authentication and access the reporting database.

Updates for both issues are included in SAV CE and SCS builds indicated in the Solution field of the Affected Products table above.

Mitigation

  • Uninstall Reporting Server if it is not being used
  • Symantec Client Security Console and the Reporting Server interface should be restricted to trusted access only.
  • Ensuring that the Console is never visible external to the network greatly reduces opportunities for unauthorized remote access.
  • User accounts for Reporting Server should be different than the user's network login account.

 

Applying the Updates
Reporting Server is an optional component of Symantec Client Security, and it can be updated (migrated) independently of the rest of the program. For more information, please see this knowledgebase document:

Migrating Reporting Server for Symantec Client Security 3.1 and Symantec AntiVirus 10.1 http://entsupport.symantec.com/docs/n2007012213220048

Symantec is not aware of any customers impacted by this issue, or of any attempts to exploit the issue.

As a part of normal best practices, users should keep vendor-supplied patches for all application software and operating systems up-to-date. Symantec strongly recommends any affected customers update Reporting Server immediately to protect against possible attempts to exploit this vulnerability.

ACKNOWLEDGEMENTS

 

Symantec would like to thank Mikko Korppi for reporting this issue, and coordinating with us on the response.