Message-ID: <20041030062921.4349.qmail@www.securityfocus.com>
Date: 30 Oct 2004 06:29:21 -0000
From: Brian Gallagher <bugtraq@...mondsea.com>
To: bugtraq@...urityfocus.com
Subject: Re: Critical Vulnerability in Altiris Deployment Server architecture


In-Reply-To: <771B638360252E4E8C31ED28FBA45803030855@...CEX01>

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@...mondsea.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

Powered by blists - more mailing lists