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