<<< Date Index >>>     <<< Thread Index >>>

Re: Critical Vulnerability in Altiris Deployment Server architecture



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@xxxxxxxxxxxxxx
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