Desktop Authority Client Module
Desktop Authority Client Agent begins with the Windows login process. Users having the slogic.bat script run the script from their authenticating domain controller’s NETLOGON share at login. This begins the sequence that prepares the machine for engine operation, prepares the engine and then finally runs the engine, applying the configuration to the machine.
The following diagram explains the various control flow and operative parameters associated with SLAgent and client.
The following subsections describe the different components and their role in the in a basic security mechanism process.
SLAgent
SLAgent is a COM library of objects and methods that are called by the Kixtart script. Kixtart is a logon script runs on Windows client machines or desktop. A restricted process can call into SLAgent to perform tasks that require higher permissions.
Slstart
Slstart is responsible for logon provisioning in the client machine. It is also responsible for launching the KIX execution.
For more details on these components, you can refer to the DA Overview
KIX
KiXtart is a free-format scripting language and has rich built-in functionality for easy scripting. It supports COM (providing access to ADSI, ADO, WMI, etc) and thus is easily extensible. Since version 4.50 KiXtart comes with inbuilt pre-tokenization system for faster loading and smaller scripts and providing some level of intellectual property protection through obfuscation.
Penetration test and results
User can gain access to the privileged operations by tampering the Desktop Authority Application.
DLL Side loading
-
The required elevation for privileged operation is governed by the Client Service. To interact with this service, Desktop Authority uses the COM object, for example SLAgent.
-
A restricted process can call into COM function to perform tasks that require elevated permissions to protect itself from being misused by the user. A validation in place ensures that this COM object can only be used during the execution of SLogic.bat and its child processes.
-
A user can gain access to the Desktop Authority administrative user by altering user files/configuration.
-
The DLL side loading technique was used to tamper the DA Application.
By creating a DLL, which in turn calls the COM API (Ex: SLAgent), elevated privileged for operations can be obtained.
These DLLs are loaded using side loading and are registered to run when the DA runs the KIX script. This is possible because KIX creates COM objects inside it.
For more information, please refer https://pentestlab.blog/tag/inprocserver32/
Current Implementation Details
Present security mechanism
The current design allows side-loaded DLLs (maclicious DLLs) to call COM APIs during the logon process. To mitigate this, an encryption mechanism has been implemented in the kix file.
Cause
The KIX Script invokes the COM APIs to provision client machine.
User can access this encryption algorithm by gaining access to the .KIX file which is available for few seconds in the user context.
By knowing encryption algorithm one can call the COM APIs with required parameters to get the privileged operations executed and hence they can tamper the system.
Sequence and Block Diagram for KIX operation
-
SLStart decodes the slengine.dll to slengine.KIX
-
SLStart Executes the slengine.KIX file
-
slengine.KIX calls SLAgent COM APIs as needed.
-
SLAgent COM API interact with DA Client Service to get the elevated operations done.
Block Diagram on DA Client Module (Existing Design)
Refer - https://wiki.labs.quest.com/display/~Praveer.Kumar@quest.com/Details+of+existing+solution
Proposed Design and Solution
Protecting COM APIs
We protect COM APIs in two steps:
- Protect the KIX file.
- Detect DLL registration which allows them to use the COM objects during logon process
Sequence Diagram for KIX execution (Proposed Design)
-
SLStart Executes the Script.KX file with required parameters
-
Script.KX calls SLAgent COM APIs as needed.
-
SLAgent COM API interact with DA Client Service to get the elevated operations done.
Refer - https://wiki.labs.quest.com/pages/viewpage.action?pageId=589642162
Block Diagram on DA Client Module (Proposed Design)
Refer - https://wiki.labs.quest.com/display/~Praveer.Kumar@quest.com/Details+of+new+Solution
Protecting the KIX file
The protection for KIX is enabled by using a highly secure, tokenized and encrypted kix file with extension. KX, and password enabled. The size of file is 467 kb (reduced by 80%), enabling faster loading and execution. For more details, check this link http://www.kixtart.org/manual/Notes/PRETOKEN.htm.
Hiding Command Line argument
In general, a user can see the arguments being passed to an executable. To mitigate this, the command is configured in such a way that normal user can only see the wKIX32.exe operation, and not the command line argument passed to it.
wKIX32 expects password as an argument to run the protected .KX file. This prevents a normal user from gaining access to the KIX file as there is no way to know how COM APIs are being called.
Following images shows the difference in details tab of WKIX32.exe from Windows task manager.
-
NORMAL USER
-
ADMIN USER
How KIX protection helps
The COM APIs called from the KIX carry a token along with the parameter, that is parsed in the COM function. If the token is not obtained, then the function exits without proceeding further.
Example call to COM API:
So, any call to COM API is validated within the function.
DLL Detection and Deletion at logon process
An implemented feature is to detect the any DLL registration to the COM CLSID entries in the HKCURegistry.
This validation happens just before we run the KIX script during logon. If it detects any registration to the COM objects, it deletes the registration and locks the Registry, denying the malicious scripts to run as part of the logon process.
COM Calls Protection Technique
This section describes the protection technique in detail.
We send one of the parameters to the COM functions with a token as suffix, when we call from the KIX engine(.KX) file. This parameter is extracted from the arguments received and validated in COM function.
If the validation fails then this call is an unauthorised call, COM function returns without any processing.
Solution Testing
Following is the way we stress tested the solution in a situation as described:
Use Case 1
Performing the PEN test on the current build led to observation that DA does not allow DLLs to run in the client machine.
Please refer How to perform Pen-test
Use Case 2
An attempt to decrypt the .KX file was made and it was observed that it is not possible to decrypt password protected and tokenized file.
Tools used for decryption are listed in Technical Resources section.