Re: Critical Vulnerability in Altiris Deployment Server architecture

[Brian Gallagher <bugtraq () diamondsea com>]

In-Reply-To: <771B638360252E4E8C31ED28FBA45803030855@OLCCEX01>

Greetings,

(I tried posting this to the list last week but it didn't seem to make it so I'm posting it again.)

Let me say up front that I actually like this product.  I want to use it with my own clients, but I need to get this 
problem fixed before I can recommend it in good conscience to my customers.

One reason I posted this was because I WANT them to fix it so I can sell it to my people and use it.  The other reason 
is that they have an installed base of thousands of organizations, including many governmental agencies, and I don't 
want people to be able to compromise government networks this easily.  Heck, I even emailed a couple govt agencies 
(even the FBI) trying to figure out the best way to report this safely, and got nowhere.  Only after failing all the 
normal routes of 
notification did I post it here.

My detailed responses are inline, below.

Brooks, Shane wrote:

> This is the response we received from Altiris when we submitted this issue to their people - please respond with your 
> comments/thoughts:
>
> Deployment Solution allows any managed client computer to attach to the nearest Deployment Server within a secure 
> environment, 

That's their "official loophole" right there that they are trying to use, "within a secure environment".

I'm still waiting for anyone to demonstrate a "secure environment" on an Internet-accessable TCP/IP network with normal 
human users and modern operating systems.  The Bugtraq and Full-Disclosure lists are pretty convincing evidence that 
there isn't one.

If having "a secure TCP/IP network environment with a connection to the Internet" is a pre-requisite to using their 
product, almost nobody will ever qualify to use it.

> while also providing options to secure the communication of Deployment Server to its Deployment Agent (commonly called 
> AClient) using multiple security safeguards. 

Yes, they have multiple security safeguards, but they are missing the most important one: Authentication.  Without this 
missing piece, the rest of the  security safeguards are effectively useless.

> No critical vulnerabilities exist in the Altiris Deployment Server architecture as suggested in the "Critical 
> Vulnerability in Altiris Deployment Server Architecture" article. 

I thought I demonstrated that there were vulnerablities pretty well, with a variety of easily demonstrable exploits 
bypassing each one of their security safeguards.

But since they are unconvinced, here's another one that will let you compromise any computer running AClient on it if 
you have physical access to it.  Note that this is a fairly common situation and can be done in any college campus 
computer lab, or at the desk of somebody in an office when they go to the bathroom.

Take a laptop with Deployment Server installed and a cross-over network cable and plug the other end of the cable into 
the target PC's network jack. 

You can now do any of the original exploits detailed in the first post and root their machine before they notice.  
Worst case, you can reboot their computer by pulling the plug and letting it reboot, at which point your laptop will 
provide it the new encryption keys.  If you need to bypass the IP checking feature of AClient, run Ethereal on your 
laptop, see what IP the machine is trying to connect to, and change your laptop to be that IP.

Done.  You've rooted their box without ever even having to try to logging into it.  Install a back door (via your rogue 
DS, just to make it fast, easy and ironic) and you now have a point of entry for attacking the rest of their network of 
computers when you leave.  Worst case, the person notices their machine rebooted and is at the login screen without 
reason to suspect anything beyond that.

> Basics of Deployment Server-to-AClient Communication 
> Altiris Deployment Solution provides two basic ways to connect from the AClient on managed computers to a managing 
> Deployment Server:
>
> 1.     Use TCP/IP multicast to locate a Deployment Server, or
>
> 2.     Use TCP/IP to connect to a specific Deployment Server identified by name or IP address.
>
> The first option, Use TCP/IP multicast to locate a Deployment Server, is the default option. Using this setting, 
> AClient will connect to the first Deployment Server it finds on the network subnet. This is a distinct advantage in a 
> secure network in order to easily allow client computers to attach to the nearest Deployment Server. It is true that 
> if the multicast option is used on an unsecured network, anyone with access to that network can manage client 
> computers by setting up an intercepting Deployment Server and connecting to and managing all incoming client traffic. 
> For this reason, the multicasting option should only be used within a secure LAN where any rogue Deployment Server 
> would be identified immediately. The requirement of a secure network is common to any product that supports 
> multicasting and it does not constitute a security flaw.

Again, this concept of "a secure network" is fantasy.  It doesn't exist in any useful fashion.  Don't design a product 
for an environment that doesn't exist.  When the default option is a setting that allows all your managed computers to 
be easily compromised by any computer on the network, something is very wrong.

> The second option, Use TCP/IP to connect to Deployment Solution, allows the system administrator to specify the server 
> name or IP address of the Deployment Server, and the port through which it will communicate. Using this AClient 
> setting, the client computer can connect only to the Deployment Server specified by name or IP address. 

Unless, you simply "pretend" to be this IP address, through a variety of ways detailed in the original post and here.

> To further secure this setting, the administrator should set the Administrator password on AClient. 

The Administrator password only keeps the computer user from changing the settings on the AClient on that computer.  
This password has absolutely nothing to do with authenticating the server or the client to 
each other.

It is possible that they added this feature in the new versions and I missed it, in which case I will applaud Altiris 
and start using their product myself.  If this is the case, please let me know where this setting is changed and I will 
happily make a retraction/correction post.

> With these settings in place, the managed client computer will only connect to the specified Deployment Server. For 
> example, in the dialog below AClient properties are set to use TCP/IP to connect to the server named osrhgap312ka on 
> Port 402. With the administrator password set and by specifying the IP address of the legitimate Deployment Server, it 
> is not possible to set up a rogue Deployment Server. 

Unless the Administrator password has been changed as I mentioned in the lines above, it is still possible to set up a 
rogue Deployment Server, as described in this and other posts.

> Altiris has added certificate communication between AClient and Deployment Server and will release this enhancement in 
> the next version of Deployment Solution. 

Great!  That will make it an even better product, and I applaud Altiris for their progress.  But they need to fix their 
basic implementation first for their installed base.

   - Brian

-- 
Brian Gallagher - DiamondSea.com - brian () diamondsea com
We Make E-Commerce Easy - No Technical Experience Required
Consulting - E-Commerce - Web Site Design - Custom Programming
http://www.DiamondSea.com - Toll-Free: 800-604-1476 - Fax: 888-411-8144