RE: Critical Vulnerability in Altiris Deployment Server architecture

["Brooks, Shane" <SBrooks@xxxxxxxxxxxxxx>]

This is the response we received from Altiris when we submitted this issue to 
their people - please respond with your comments/thoughts:


<snip>
Subject: 

Design flaw in Altiris Deployment Server - Attacker can take over all clients 
on a network with Admininstrator Rights and Remote Control ability
</snip>


<!--- Begin Vendor Response 

Deployment Solution Server-to-Client Security

This is in response to the article titled "Critical Vulnerability in Altiris 
Deployment Server Architecture."

Deployment Solution allows any managed client computer to attach to the nearest 
Deployment Server within a secure environment, while also providing options to 
secure the communication of Deployment Server to its Deployment Agent (commonly 
called AClient) using multiple security safeguards. No critical vulnerabilities 
exist in the Altiris Deployment Server architecture as suggested in the 
"Critical Vulnerability in Altiris Deployment Server Architecture" article. 
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.

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. 

To further secure this setting, the administrator should set the Administrator 
password on AClient. 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. 

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

          end vendor response -->







PRODUCTS AFFECTED:

---------------------------------------------------------------------------------------------



ALTIRIS DEPLOYMENT SERVER - 5.x, 6.x, possibly other versions (untested)

POSSIBLY OTHERS? - I have not worked with any of the other Altiris products, so 
I do not know if they are vulnerable to this, similar or other possible 
exploits.





SUMMARY:

---------------------------------------------------------------------------------------------



There is a design flaw in the Deployment Server architecture that could allow 
an attacker to take complete control over all Altiris clients on a network with 
relative ease.



The flaw is that the AClient.exe process does not request any authentication 
from the Deployment server and will happily connect to any Deployment server it 
finds and give it complete Administrator rights to the machine along with the 
ability to Remotely Control it.



This flaw can be exploited via physical or wireless access to the network 
Deployment Server is on, or remotely through a compromised system anywhere on 
the network that Altiris Deployment server is on and can potentially give an 
attacker complete administrative access to some or all managed clients.



This can be done with little or no advance knowledge of the network or client 
configurations prior to the attack, depending on the AClient.exe configuration 
used.





THREAT MITIGATION:

---------------------------------------------------------------------------------------------



Due to a design flaw in the AClient.exe's lack of a proper authentication 
system, there is little you can do to prevent these exploits.



The best things you can do to protect yourself until Altiris fixes their 
product is:



1) DO NOT USE THE "Use TCP/IP Multicast to locate a Deployment Server" OPTION 
WHEN INSTALLING ACLIENT.EXE.  Put in a fixed IP address and Port number when 
installing the client.  



This will make it more difficult for someone to exploit this flaw, as they will 
have to disable the existing deployment server first, or use some other trick 
to make the attacker's machine seem like the "real" Deployment server.



2) TURN ON THE "Encrypt Sessions with Server" AND THE "Require Encrypted 
Sessions with Server" OPTIONS WHEN INSTALLING ACLIENT.EXE.  



This will require a client computer to reboot before it can be compromised, 
which creates an additional barrier of entry to an attacker, and give you more 
time to react in the event a Rogue Deployment server is detected on the network.



3) TURN ON THE "Remain Connected to the server" OPTION WHEN INSTALLING 
ACLIENT.EXE.



This will provide less of an opportunity for a client to unknowingly connect to 
a Rogue Deployment Server by maintaining the connection to the one the client 
first connected to.



4) DO NOT USE THE "Advertise the server this client is connected to through 
multicasting" OPTION UNLESS ABSOLUTELY REQUIRED.



This would prevent a rouge deployment server from obtaining an additional 
compromise vector (the advertising AClient.exe connected to a rogue DS) to new 
machines to control.





SAMPLE EXPLOITS:

---------------------------------------------------------------------------------------------



PREREQUISITE:



BadGuy gets access to the network either (1) physically, by walking in the door 
and plugs his laptop into any network jack anywhere in the building or 
connecting to a wireless network access point inside or outside of the 
building, or (2) by gaining access to any computer on the network, such as 
through any variety of cracks, viruses, trojans, stolen password, etc..  For 
purposes of this discussion, I will assume that he simply walks in the door and 
plugs in a network cable, though it really makes no difference how he connects 
in order to exploit this flaw.



SCENARIO ONE:  AClient.exe configured to connect to Deployment Server via 
network broadcast



His laptop is running its own copy of Deployment Server ("DS" from here on) 
(which is available for a free download online (though it is limited to 10 
clients)).  When clients are booted up, they will send a broadcast request to 
the network.  If the laptop responds faster than the company's "Official" DS 
("ODS" from here on) , then the client will connect to it, and BadGuy now has 
complete control over the client through the AClient service.



Furthermore, if BadGuy can knock the official DS off the network (through any 
variety of Denial of Service attacks, ARP Poisoning, etc.) it can assume the 
role of the ODS, with the same IP address even, and take over more clients.  
Additionally BadGuy can potentially determine the IP address of the ODS by 
watching network traffic and seeing the broadcast messages that are sent to the 
ODS, in order to determine the IP address to attack and assume the role of.



SCENARIO TWO:  AClient.exe configured to connect to Deployment Server via 
direct IP address (for example, IP: 1.2.3.4) or hostname.



Same as above, but BadGuy can redirect clients to his laptop by ARP-Poisoning 
(which makes the network's switches and routers think that the laptop is the 
machine they should send connect to for the IP address 1.2.3.4) or by using a 
Denial of Service attack to knock the ODS offline, and the laptop then starts 
functioning with the IP address

1.2.3.4.



Again, complete control of all clients is on the network is easily achieved.



SCENARIO THREE:  AClient.exe configured to connect to Deployment Server via 
encrypted connection.



Same as above scenarios except that it will require that a client to reboot 
(for any reason) before the client can be hijacked.  When the client computer 
reboots, it will request new session keys from the DS, in this case the 
BadGuy's DS, and will use these keys (now provided by BadGuy's DS) to encrypt 
the session communications.





POSSIBLE FIX (for ALTRIS):

---------------------------------------------------------------------------------------------



The root of this problem is that the AClient does not require any 
authentication to connect to it.  It will happily talk to any DS that it finds.



The AClient must be modified (and therefore the Deployment Server itself) to 
provide a method of authorizing a DS to talk to AClient, and possibly the 
vice-versa.



The simplest method of fixing this would be have a password set for each 
AClient upon installation.



Upon connecting, the client and server would verify that they are talking to an 
authorized system using standard password-testing methods (ie: don't send the 
password to the other system, send a hash of it to prevent spoofing and getting 
the password that way).  Only after authentication would the client and server 
be allowed to interact further.





VENDOR NOTIFICATION:

---------------------------------------------------------------------------------------------



Altiris tech support was notified of this problem and sent the details of this 
vulnerability on Friday, November 21, 2003.



Altiris confirmed the problem and assigned it to a support ticket which was 
escalated for management attention.



I was informed that it had been scheduled to be fixed in a future release, but 
they did not provide an ETA or any other details.



Since then no follow-up inquiries to Altiris have been responded to.



Since it has been nearly a year, with three new versions (6.0, 6.1, 6.1sp1) and 
it still does not appear to have been resolved, I am publishing this alert to 
inform systems administrators of the vulnerability to their networks.





ANALYST INFORMATION:

---------------------------------------------------------------------------------------------
 

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





_________________________________________________________

The information contained in this message is privileged, confidential and 
intended only for use of the individual or entity addressed above.  If you 
have received this communication in error, please immediately notify us
by reply and delete the same.  Thank you.