Vulnerabilities out of the box and how to fix them. (NSCap Share, INVCAD.nse, Client Policies\Altiris.Domain.XML)

Gripes and Complaints of unfixable potential(unconfirmed) low level/ high level vulnerabilities with NS. (EvtQueue Shares)

Altiris reply and Suggested Fixes

First an introduction of who I am. My name is Brent Curry, I work for a Software Security company in the Internal Security department in IT. My title is Application Security Engineer, so my role is to protect the company from any outside threats to the company internally, but I also use and administrate Altiris. I have been using Altiris for 2 years now and have been to 2 ManageFusion conventions along with several UserGroup gatherings. So now, on with the Vulnerabilities/default settings!

Vulnerabilities:

NSCap Share

Recently I found some default settings that NS sets for Folder Shares that, as someone in the Security field, makes me cringe. First let's talk about how part of the NS server works to explain why it has these shares in the first place.

Altiris NS creates a Windows Folder Share for any software deployment, this includes the Altiris Clients. Normally Altiris creates a secure share that is only viewable to the Altiris client. By default the Altiris NS Server creates a share called "NSCap". This share is where the Altiris Client can be accessed to copy to a user that needs it installed; this also contains the configuration files to which the clients access for latest configuration. Also inside this folder is 4 Event Queue folders to which the Altiris Clients copy NSE/NSI files to which have the XML format Altiris Parses and puts into the database.

Click to view.

This is where the problem is created by the NS installation. By default all the event queue folders and a folder named "Temp" have Read, Write, Execute, and "Full Control" permissions set for the "Everyone" group. There is Never a time the "Everyone" group should be given "Full Control" to a server share.

What does this mean? Well to administrators this obviously shows that anyone with a network connection to this server (Which would be the entire company/network) can browse to these directories and Deny, Add, and changes permissions even denying the Administrator's group or System account. This means that if a user with some knowledge wanted to, they can deny all user groups and D.O.S. ANY Altiris server that has default share settings.

Because all events are put in these folders by AEX Clients, the server just waits for files to be uploaded and then processes them every so many seconds/minutes. If you deny the clients to access this folder all clients can no longer report back to the server, this would not show errors on the server side but on client side. If all clients are not reporting back it's not likely an Admin would be looking at the client logs trying to figure out why there server is not working and reporting no errors. Not only this, but unless you have a dedicated Admin monitoring your Altiris server it is likely you will not even know of the D.O.S. for hours are days later.

The second scenario is that a user that wishes to bypass, hide, or modify their own database information that is sent through XML or wish to flood the Altiris database can do so without even having the Altiris Client installed. If I wanted to take down a server by flooding it, I could create a script that randomly inserts Host names and possibly GUIDs and then flood the server with Thousands of requests, and it would be extremely hard to track where it came from since it actually wasn't from an Altiris client.

How do you fix the access rights problem? Right now Altiris requires everyone to have Read/Write permissions to these folders. However, taking off the "Full Control" permission will take off the immediate and easy exploit of denying folder access.

Click to view.

These settings have been tested by myself, and in a production environment and does not cause any issues with the NS or installed solutions. However if you do make these settings do it at your own risk, be smart, make the proper backups before changes and change settings back if you find any issues in your environment.

Altiris Client Computer\INVCAD.nse

This is a file that resides in the Altiris Client's folder, in this file the Inventory of the computer is stored. This includes:

• Programs installed (hidden and viewable)
• Windows Updates Installed
• Ports open/closed
• Servers the computer Communicates with and what Ports (Which is normally hard to find out offline)
• MAC address & Ethernet settings

This makes this file a one stop shop for all the information needed to break into a network, this also is dangerous in the scenarios that someone offline (laptop) stores this information which makes it so someone who obtains the file on an unsecure connection or physically stealing the drive or laptop can get what they need to more easily break the company network.

Altiris Client Computer\Client Policies\Altiris.Domain.XML

There is a file that resides in the Altiris Client's folder under Client Policies. This file is named the full servername.xml.

Inside is the information of what Altiris Clients are installed, the Altiris server IP, etc. This is not that harmful, however a very bad thing is stored in this file. Inside is the Admin Username and Password hash used to install the client locally on the computer.

<PkgAccessCredentials UserName=" domain\username" UserPassword=" IM5xrY/df7HASHINFOHERE4vCB3ifz" />

Usually this is a Domain Admin account used, which means either a hacker or a employee who has read access to the workstation now can offline take this Username and Password hash and do an offline Brute Force to break the password, then you have full rights to the domain and the Network admins have no idea.

The point of all of this is to make it hard and not obvious to exploit a server, especially if a company is highly integrated and dependent on Altiris like many are. It's just like locking your door to your car, you know a thief can just break your window but it's more likely he will go to an easier to steal unlocked car then one with locks, alarm, etc. If determined, a thief (or hacker) will find a way to break in, but it's more likely he will then get caught before he can take/do what he wants, thus more likely to deter him.

Gripes and Complaints:

Altiris requires you to Supply an administrative username/password, this is required to install the Altiris Client after it is copied from the share. This has to be an Admin account on all clients, so more than likely it's a Domain Admin. This domain admin already has full rights to all Shares on this server, which means there is no need to give "Everyone" access to the Client install folder. The reason you would not want to give access to this folder this gives any user the right to look at your Altiris configuration to which they could use to get around or find out information about your Altiris server or network. Even if you don't use a Domain Admin for the Altiris client install it would be smarter to give the client admin access to the Client Install folder share only and not "Everyone".

Second after the client is installed it then has the ability to access and request authentication to folder shares as it does with the Software Delivery solution. This would be a much more secure way to also have the Event Queue folders work, having some sort of authentication rather than "Everyone" who has network access to be able to Queue XML to the server. However I understand the reason, compatibility with Unix OS, but there are better ways to do this. Unix is able to Authenticate just like a Windows box, it may not be a domain account but you certainly could add UNIX only specific local accounts to those local shares.

There are many other possible vulnerabilities available with this being open as it is, it's just a matter of time before someone finds or uses these vulnerabilities. While I am not specifically going into detail or taking the time to show all possible vulnerabilities (yet) you can use your imagination for anyone that is familiar with application and network security.

I do understand why most of this was made like this, however with Altiris growing in use by Enterprises, it's my opinion that more should be looked at into security for Notification Server. Especially now with Altiris being part of Symantec (security company) this should be something built into 7, when it seems even with 7 they are leaving most of the lock down up to the Server admins. Most server admins are not also the Altiris admin/manager in enterprise corporations, along with it's easy to miss these vulnerabilities.

The suggestions down below, cover most, but not all my concerns. I would recommend you to follow the suggestions, although it is kind of a pain, if it's not done, anyone with any network access to your company can DOS your Altiris Server.

Official Altiris Security Vulnerability and User Intervention Instruction Reply:

Brent,
The following is the response we just received from the NS engineers to the concerns you raised. Some are being addressed in the upcoming NS 7.0 release while others have workarounds to your concerns currently. However, they are looking to make additional product improvements to address many of those as well.
- Mike

• Permissions on NSCap Folder. For NS 6.x, the default installation did not lockdown the NSCap folder for various reasons. These reasons included the ability to allow unauthenticated agents to post inventory, or to allow UNIX/MAC/Linux agents to post inventory who are not easily able to authenticate to a windows domain or workgroup, etc. Completely removing anonymous access to the NSCap folder would required that all NS Agents be authenticated before submitting inventory, which will cause problems for any new machines that need to be managed that are not part of the authenticated group or are UNIX/MAC/Linux machines. Also, it is important to note that only NS Agents 6.0 SP3 and later included the ability to connect to the NSCap folder with authentication. For this reason, direction has been created to allow security conscience customers to enhance security by locking down this folder as appropriate for their configuration. The attached document contains procedural steps that can be taken to further enhance the security configuration of the Notification Server. For NS 7.0, the default installation still includes anonymous access to NSCap but the "Everyone" group has been removed. Additionally, further security increases can be implemented to restrict access to the NSCap folder as defined in the attached file.
• INVCAD.nse File. He is correct that this file does contain computer specific information, however the invcad file stores information gathered from only the local machine. There is no information in this file that someone with physical access to the box could not obtain.
• Credentials in the Client Policy File. The client policy file does contain credentials that are used to access the package server for the NS implementation. However, these credentials are encrypted. We are working to improve security of these credentials provided to the Agents by moving this information to a more secure store using MS DPAPI, however these changes are still in development.
• The required account to rollout the NS Agent is different than the package credentials that are stored in the Client Policy File on each client machine. When rolling out the NS Agent, the administrator has the option of using the default credentials (AppIdentity - those provided during installation) or by specifying credentials to use. It is important to note that by default during installation the package credentials are set to the same as the AppIdentity account. If the NS administrator does not wish the NS AppIdentity to be stored encrypted on each of the client machines they have the option of changing the package credentials as appropriate to a lesser privilege account through the NS Console. The package credentials are only necessary to allow the client machines to access the file share on the package server.

Along with this e-mail Altiris also linked the NS Security Config doc to which I have attached. However this document is 3 years old.