Today I checked in McAfee’s latest and greatest enterprise VirusScan product into my software repository. Installing the VIRUSSCAN8800(169).zip extension was a non-issue, but when I attempted to install VIRUSCANREPORTS120(136).zip, I received the below error:
Unable to install extension. Installation error: upgrade: [echo] Upgrade called for VIRUSCANREPORTS (version 1.2.0.136) BUILD FAILED C:\PROGRA~1\McAfee\EPOLIC~1\server\extensions\installed\VIRUSCANREPORTS\1.2.0.136\install.xml:730: java.sql.SQLException: Violation of UNIQUE KEY constraint 'U_OrionQueryGroup_Name'. Cannot insert duplicate key in object 'dbo.OrionQueryGroups'. Total time: 2 seconds
A little searching on the web led me to this thread in the McAfee Management Platform community and I was able to successfully install the VIRUSCANREPORTS120(136).zip extension after following the advice of trimone:
- From the ePolicy Orchestrator console, select “Queries”
- Under the “Groups” column, select “VirusScan Enterprise”
- Under “Group Actions”, select “Delete Group”
- Confirm your selection
- Retry installing the extension (Menu –> Software –> Extensions –> Install Extension)
The VirusScan Enterprise Extensions should now show “VirusScan Enterprise Reports” as 1.2.0.136.
A paper has been published by SySS GmbH illustrating that under certain circumstances this vulnerability can be exploited to escalate the privileges of the local user.
Their paper is available here for those interested in reviewing it in detail. For the rest reading, I’ll summarize it:
The SiteList.xml and ServerSiteList.xml files used by the McAfee agent have read permissions granted to all users of the local system. These files contain information regarding what repositories the client will use for product updates as well as the account credentials used to connect to them. The account password is encrypted within the file, however SySS was able to develop a python script that can decrypt the passwords with ease. This can be particularly concerning in environments using UNC repositories, as the domain account and password used to access the repository may have escalated privileges over what the local user has.
My takeaways from this?
- Don’t assume that any password hash is secure.
- Ensure that any account credentials used for repositories only have access to the repository data and nothing more.
- If you’re using UNC shares, consider using local accounts instead of domain ones.
Regarding the UNC repositories, McAfee has released KB70999, “Important Information on using Download Credentials in ePO” which details some best practices for securing UNC shares for repository use. The KB can be found here for review.
I myself am wondering what changing the ACL on the “McAfee\Common Framework” directory to something more restrictive might introduce as issues. If anyone has experience with this, I’d be interested to hear your results.
Ran into a situation where I needed to remove a DP from all packages since it have already been previously decommissioned. I’m linking to this extremely helpful script as provided by Russ Slaten here (http://blogs.msdn.com/b/rslaten/archive/2006/03/01/removing-a-retired-dp-from-all-your-packages.aspx) for future reference.