When it comes to providing desktop applications to internal and external company end users, a wide range of virtualized deployment technologies have become established in recent years. This enables external access, for example from home or in a bring-your-own-device (BYOD) setup. Common systems include virtualization on the basis of Microsoft Terminal Services and within a Citrix cluster. The following article uses Citrix as a synonym for the entire group of virtualization solutions.
In general, the target application is installed and set up in a container OS (usually Microsoft Windows). The virtualization environment can now be used to start the application, for example via a web UI. The client installed on the end user's PC establishes a connection to the Citrix server and retrieves the corresponding configuration. Subsequently, a window opens on the client PC which transfers the UI of the released application to the client via a proprietary protocol. During interaction with this application, only mouse and keyboard interactions are sent to the application instance running in the central cluster. This is an advantage because no local installation of the target application is required on the end user's system. All you need is a receiver application that can establish a connection with the Citrix server.
Deployment via Citrix has many advantages from the perspective of an operations team. The application is installed centrally and only once within the container OS – the same applies to application updates. User groups can be increased by activating the application in the Citrix profile of the respective persons.
Contrary to a pentest of a classic desktop application with a local installation, some verification steps are not possible in the Citrix environment due to virtualization, such as a check of the security of the local installation. The focus here is on authorization management for configuration and binary files within the installation directories. Since the client is not installed locally in the case of deployment via Citrix, these test steps are not required. Another central component is the analysis of network traffic between the target application itself and its associated backend servers. This analysis is also not possible in the Citrix context, as only mouse and keyboard interactions are transmitted to the Citrix server.
However, this encapsulation within a Citrix virtualization creates new attack vectors, which are the basis of such a pentest. As already described, the application requires a container OS on the server side, which provides the application's runtime environment. This operating system runs transparently in the background of the application and is used by all end users accessing the application. If an attacker is now able to break out of the context of the released applications and access the underlying operating system, further possibilities arise to attack other users, the infrastructure in neighboring network segments or other virtualized applications.
Breakout techniques
The objective of the analysis is to find all possibilities for breaking out of the application's encapsulation and accessing the container operating system directly. The following sections briefly summarize some of the common vulnerabilities and attack techniques that are performed as part of a pentest.
In a Citrix environment, applications often use functions of the underlying operating system, usually Microsoft Windows, to map individual use cases. To open files, for example, the standard Windows file explorer is integrated. If this has no further restrictions, it is possible to use it to examine the file system of the container operating system. Depending on the configuration, it is possible to start an interactive command line session and execute any commands on the container.
Microsoft Windows, as well as all other operating systems, provide a large number of keyboard shortcuts in a standard installation. These are supposed to simplify the operation of the system for experienced users. During a Citrix breakout test, we also analyze whether such shortcuts are available in the container operating system and can be used to break out of the encapsulation. The Windows "Sticky Keys" feature is a good example of this. Pressing SHIFT 5 times quickly opens a dialog. This provides a link to the control panel of the container operating system. From here, it is possible to start a command line session via the navigation bar or, as shown in the screenshot below, to execute any commands directly on the system.
There is another attack technique that can be used if the target application requires a built-in web browser. Such browsers provide a variety of functions for accessing the file system. For example, the content of a web page can be saved in a file, which opens a file explorer. If the internal browser provides a URL bar, it is possible to test whether other websites, including publicly available ones, can be accessed. This allows, for example, the reloading and execution of binary files. Via file:///C:/Windows/System32 you can also access the local file system, as shown in the following illustration.
Further attacks can be made via print dialogs or the built-in Windows help, for example. Looking for vectors that enable a breakout is highly dependent on the functionality of the application.
Conclusion
An application that is provided via Citrix should be prepared for this type of virtualization in order to eliminate the attack vectors described above. Ideally, it should use as few standard functions of the operating system as possible. Even the container operating system should be prepared for operation in such an environment, for example by deactivating shortcuts. Furthermore, the application should be securely installed in the container. In other words, the executing user should only have the authorizations required for operation and execution in the file system. We also recommend additional protection mechanisms such as the explicit allow listing of required binary files on the operating system and monitoring in the form of endpoint protection.
Our experience from many previous analyses shows that only a small proportion of tested applications are prepared for operation in Citrix virtualization. In consequence, it is often possible to break into the container in various ways. During an analysis, we check for all possible breakout vectors and subsequently document them with step-by-step instructions for reproduction after the analysis. If a breakout is possible, we also check the configuration of the container operating system and examine which attack vectors potentially arise here. Key words here are checks for privilege escalations in an administrative context, or whether other end users using the target application are vulnerable. If the application accesses backend systems such as databases, application servers or file shares, we also recommend checking these on a system level. Our recommendations in the final report give an overview of the necessary protective measures that help to harden the application, backend systems and the Citrix cluster.