Citrix Virtual Apps and Desktops 7 - Local Privilege Escalation

Description

Citrix Virtual Apps and Desktops 7 (https://docs.citrix.com/en-us/citrix-virtual-apps-desktops-service.html) is a set of services used to deliver and manage Citrix applications and virtual desktop instances. Included in Citrix Virtual Apps and Desktops 7 is the Citrix App Layering Guest Service service for Microsoft Windows, which allows independent components of a virtual machine to be assigned, patched and updated. These components include the Windows system itself, applications, and user settings/data.

The Citrix App Layering Service service is initiated as a Windows system service, which executes the C:\Program Files\Unidesk\Uniservice\UniService.exe binary when an account authenticates to the Citrix instance. This service is executed by the high-privilege LocalSystem (NT AUTHORITY\SYSTEM) account.

F-Secure discovered that the service referenced this binary without quotations. If a vulnerable system is also configured with insecure filesystem permissions, a threat actor could hijack the service's execution, by placing an executable in the root C:\ directory. This binary would then be executed with NT AUTHORITY\SYSTEM privileges.

Impact

Threat actors with user-level access to a Citrix virtual desktop instance, running Microsoft Windows configured with insecure filesystem permissions, could execute arbitrary PE files with NT AUTHORITY\SYSTEM privileges by hijacking the execution of the Citrix App Layering Guest Service.

Remediation

It is recommended to follow the vendor's remedial advice and upgrade to Citrix Virtual Apps and Desktops 7 version 2009 and above. Alternatively, hotfixes for specific Citrix Virtual Apps and Desktops/XenDesktop software versions can be obtained from the vendor's security update page. Note that this advisory also contains hotfixes for separate vulnerabilities which also affect the software, CVE-2020-8270 and CVE-2020-8283. A link to the vendor's security advisory is shown below:

https://support.citrix.com/article/CTX285059

Additionally, it is recommended that Windows filesystem permissions should prevent non-administrative users from creating arbitrary binaries in the root C:\ directory. Below are example C:\ drive permissions on a default Windows 10 Enterprise 2016 LTSB installation (version 14393). These permissions prevent arbitrary binaries from being created in the root C:\ directory.

C:\>icacls .
. BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Users:(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)
NT AUTHORITY\Authenticated Users:(AD)
Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW)
Successfully processed 1 files; Failed processing 0 files

Details

The Citrix App Layering Guest Service references an unquoted service path. Observe the command output below, which shows the unquoted service path:

PS C:\Users\citrix_test\Desktop> sc.exe qc UniService
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: UniService
TYPE : 10 WIN32_OWN_PROCESS
START_TYPE : 4 DISABLED
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : c:\Program Files\Unidesk\Uniservice\UniService.exe -R
LOAD_ORDER_GROUP : Unidesk
TAG : 0
DISPLAY_NAME : Citrix App Layering Guest Service
DEPENDENCIES :
SERVICE_START_NAME : LocalSystem
PS C:\Users\citrix_test\Desktop>

This service path is referenced in the value for the HKLM\SYSTEM\CurrentControlSet\Services\Uniservice\ImagePath registry key, as shown in the screenshot below:

This issue is only exploitable if non-standard NTFS permissions have been applied to the system's C:\ directory. On modern Windows systems, default C:\ directory NTFS permissions prevent non-administrative accounts from being able to create new files in the root directory. However, this is not always the case in enterprise environments, especially for systems which are modified considerably from base installations due to the addition of software which may require non-standard file permissions to be applied.

If non-administrative users have the permission to create arbitrary binaries in the C:\ directory, then an authenticated threat actor could create a program called "C:\program.exe" in the C:\ drive. The next time a user logs into the Citrix virtual desktop instance, C:\program.exe will be executed in place of the binary referenced in the Citrix App Layering Guest Service with administrative privileges.

Prerequisites

A Citrix virtual desktop instance running Microsoft Windows, configured with Citrix Virtual Apps and Desktops 7 version 2006 or below.
NTFS permissions allowing the creation of files (not directories) in the C:\ drive, for non-administrative users.

Steps to reproduce

Create a binary in the C:\ drive named program.exe on the Citrix virtual desktop instance. For demonstration purposes, the following C# code was compiled into a binary, which was copied to the the C:\ drive and renamed program.exe. The code executes the whoami command and pipes the output to a text file in the example "citrix" user's directory. Make sure to adapt any file paths before compilation.

using System;
using System.Diagnostics;
public class Class1
{
   public static void Main(string[] args)
    {

        Process cmd = new Process();
        cmd.StartInfo.FileName = "cmd.exe";
        cmd.StartInfo.RedirectStandardInput = true;
        cmd.StartInfo.RedirectStandardOutput = true;
        cmd.StartInfo.CreateNoWindow = true;
        cmd.StartInfo.UseShellExecute = false;
        cmd.Start();

        cmd.StandardInput.WriteLine("whoami > c:\\users\\citrix\\desktop\\test.txt");
        cmd.StandardInput.Flush();
        cmd.StandardInput.Close();
        cmd.WaitForExit();
        Console.WriteLine(cmd.StandardOutput.ReadToEnd());
        }
}

Reboot the virtual machine and then log into the machine using a valid Windows account.
Observe that program.exe has been executed in place of C:\Program Files\Unidesk\Uniservice\UniService.exe as shown below. A warning message may also be displayed if Windows detects the newly-created executable in the C:\ directory, depending on the configuration of the Windows machine, however at this point the binary has already been executed:

12/06/2020	Vulnerability discovered.
13/06/2020	F-Secure conducts further testing to confirm impact.
15/06/2020	Vendor notified of issue.
30/06/2020	Vendor validated issue and confirmed impact. Vendor agreed to inform F-Secure regarding patching time lines.
01/11/2020	Vendor provides disclosure date of 10/11/2020.
10/11/2020	Vendor releases official advisory and patches for affected software.
11/12/2020	F-Secure releases detailed advisory of issue.