We're experiencing a real renaissance among desktop applications, thanks to cloud services that have added Desktop As A Service to their offerings. This service allows us to stream the image of a native application running on a cloud machine directly to our browser. We interact with it as we would with a normal application, except that, by design, we have limited access to the system. And that's our main goal as pentesters - to escape from the Matrix (application) into the system shell! In a conventional test of a desktop application, the focus is primarily on the application itself and its associated files. However, for applications running under DaaS, the audit extends to the entire runtime environment.

In this article, you will learn about some methods that have been used in REAL pentests. Although you may encounter some of the presented vulnerabilities in classic desktop applications, and sometimes their severity is relatively low, in a cloud environment, we expand the attack surface, and consequently, the risk.
What is the difference in vulnerabilities? Firstly, any Code Execution class vulnerability will be executed within a remote system, let's think of it a bit like executing RCE within a web application. A vulnerability that would require a victim to interact, such as Command Injection in a configuration file or DLL Hijacking, becomes a serious threat that extends beyond the victim's local computer. The application providers become the victim, and we become the one performing the action.
Classical Vulnerabilities Desktop as a Service providers give users the ability to upload files to remote machines. Often, we are limited to one specific folder where we can save these files, but there are several ways to get around this restriction, which is especially useful for exploiting DLL Hijacking.
DLL Hijacking DLL Hijacking, also known as DLL preloading, is a technique where an attacker exploits a vulnerability in a system or application to replace a legitimate Dynamic Link Library (DLL) file with a malicious one. When an application attempts to load a particular dynamic link library, the operating system searches specific paths for the DLL file, usually starting with the application's current working directory. If an attacker places a malicious DLL file in one of these higher-priority search directories, it can be automatically loaded by the application instead of the legitimate DLL file.
Most importantly, in the context of Desktop as a Service, this vulnerability leads to code execution by loading a malicious DLL file. Normally for classic desktops, this vulnerability gets a severity of low for user-space and high for kernel-space services and applications, respectively. And here, in practice, through exploitation, we get the intended effect - escaping from the application level and gaining access to the system shell. Alternatively, you can use typical hacking tricks like a reverse shell.
You can try to exploit this in a number of ways: try to replace some executable file with CMD/PS, or put CMD/PS in a place accessible to the environment user. Below, we provide sample code for a DLL binary file. This code writes the result of the whoami command to a file at a location accessible to us, serving as a Proof of Concept. Naturally, this represents just the tip of the iceberg of what's possible in an attack scenario.
To protect against DLL hijacking, it's crucial for operating systems and applications to be properly configured to minimize the risk of this form of attack. This includes controlling the search paths for DLL files, using digital signatures to verify the integrity of DLL files, and regularly installing system updates and patches to address known vulnerabilities.
It is also recommended to use only the necessary libraries and to configure the Safe DLL search mode, which places additional restrictions on the library search process. Furthermore, if it's not necessary for vulnerable services to run with high-level privileges, switch to using a user account with the minimum necessary privileges.

For more information you can look here:

https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

Command Injection Command injection occurs when attackers trick a system into executing unauthorized commands. This can happen through applications or configuration files by altering input data in a way that makes the system execute unintended commands. Often, this vulnerability shows up in places where the application takes user input and sends it directly to the system or a command interpreter without proper validation or sanitization.
In the context of configuration files, command injection vulnerabilities can have severe consequences, especially in Desktop as a Service infrastructure. DaaS, also known as Desktop Virtualization, provides virtual desktop environments hosted on remote servers, allowing users to access their desktop environments from anywhere with an internet connection. Here's an example of how command injection can impact DaaS infrastructure, particularly in configuration files.
Consider a scenario where a DaaS platform utilizes a configuration file to define startup programs and their associated arguments for users' desktop environments. In this scenario, the DaaS platform allows users to specify the startup program along with any arguments they wish to pass to it, providing customization options tailored to their needs.

Here's an example of such a configuration file:

In this configuration:

startup_program: Specifies the program to be executed during system startup. In this case, it's set to java -jar C:\Application\startup.jar, indicating that the Java Virtual Machine (JVM) should run the JAR file located at C:\Application\startup.jar.

startup_program_arguments: Defines the arguments to be passed to the startup program. Here, it's set to Xmx2G, which allocates a maximum of 2 gigabytes of memory to the JVM.

However, if the DaaS platform fails to properly validate or sanitize user inputs within the configuration file, it could lead to command injection vulnerabilities. Let's illustrate the potential impact of such a vulnerability:
Suppose an attacker exploits the configuration file by injecting malicious commands into the startup_program field:

In this case, the attacker's injected command **`&& echo Malicious command executed`** will be executed alongside the legitimate startup command. This could result in unintended actions being performed during system startup, such as the execution of additional malicious commands, compromising the security and integrity of the DaaS infrastructure.

Again, similar to DLL Hijacking, if we were considering a classic desktop application, the vulnerability would require a lot of user-side interaction. But in this case, we don't care because our primary goal is to escape from the application to the system shell. And any required actions can be performed by us.

To mitigate the risk of command injection vulnerabilities in DaaS configuration files, it's crucial for developers and administrators to implement robust input validation and sanitization measures. This includes validating user inputs to ensure they adhere to expected formats and do not contain malicious commands or characters. Regular security assessments and should also be conducted to identify and address any vulnerabilities before they can be exploited by attackers, thereby enhancing the overall security posture of the DaaS platform.
File Upload While file upload itself is not a typical vulnerability in desktop applications, as you might have already noticed in the context of Desktop as a Service, nothing is typical. Most importantly, in this case, we will use this mechanism to bypass several security mechanisms. Here will focus mainly on the upload functionality for system shortcuts. They are the ones that will allow us to launch applications that will increase the attack surface. Importantly, the shortcuts themselves are simple .lnk files that point to a destination and can be transferred between machines.

Shortcuts can point to various files, but importantly, executables as well. Nothing prevents you from preparing a file that will point to CMD/PS. This way, when it is uploaded, we can run CMD from our upload folder, what gives us the opportunity to bypass the lock against exploring the contents of the file system.

Below is a list of steps that can be used to make such an attack:

Before initiating an attack with a .lnk file, it's necessary to first create one. This requires access to a Windows machine. Follow the steps outlined below to create the file:

1. Open File Explorer and navigate to any folder. Right-click to open the context menu and select "New" > "Shortcut":

2. The shortcut creation wizard will open. Enter the location of powershell_ise.exe as the path and click “Next”:


3. Click "Finish" to create the .lnk file.


4. The .lnk file is now created:
To exploit the vulnerability, follow these steps: 1. Upload LNK file to Citrix environment and remember the location.
2. Create a file with any content, ensuring the extension is not associated with any application (e.g., a .dat file). Attempting to open it will prompt you to select a program, allowing you to choose the .lnk file.
3. Upload this file to the Citrix environment.
4. Navigate to the attachments section.

5. Create new attachment and upload .dat file to application.


6. Double-click the .dat file to open the "How do you want to open this file?" window. This step is crucial as if the file extension was associated with an application, it wouldn't allow you to reach this selection window:


7. Choose “Look for another app on this PC” and select the previously uploaded .lnk file:


8. After completing these steps, a PowerShell window will open, allowing further attacks by the attacker.

Summary
The post outlines security vulnerabilities in Desktop as a Service (DaaS) environments, such as DLL Hijacking, Command Injection, and File Upload. It highlights the importance of robust security measures and system configuration to mitigate these risks. More attacks will appear in part two of the article, where we will show, among other things, how to use third-party applications to escape the Matrix.





#DaaS #Cybersecurity #Pentesting #RealWorldPentests #PentestChronicles