Citrix XenDesktop Exploit
This is an exploit to gain access to a corporate network through an employee’s unmanaged personal computer via a Citrix XenDesktop VDI.
I’m frustrated by the sales pitch for XenDesktop and am concerned for those who have bought into the misleading claim that it is “safe from hackers and protecting the corporate network from unmanaged devices” (Source: https://www.citrix.com/go/products/xendesktop/feature-matrix.html).
To Be Fair
The Citrix App itself isn’t technically broken or vulnerable anymore than any other remote desktop method. In fact, Citrix XenDesktop may be one of the best remote desktop products on the market. Your corporate network is definitely NOT “safe from hackers” simply because you are using this product, though. The burden is really on the XenDesktop customers, as much as Citrix, to implement effective mitigations for this exploit that I’m releasing.
Dangers of trusting XenDesktop alone
Before I get into the exploit, let me list some of the general risks of using XenDesktop for your remote workers:
- Key Logging: Keyloggers are a dime a dozen. Actually, that is not entirely true. There are dozens (maybe hundreds?) of FREE keyloggers. Google: “site:github.com keylogger”. Any data being typed by your employees into your “secure” network from their infected personal computer can, and very likely is, being collected by malware/hackers operating on the box.
- Screen Scraping: Just like a keylogger harvests data going “into” your corporate network, a screen scraper is collecting data coming out of your network. Do your employees access member PII and sensitive “internal use only” data from remote through XenDesktop? If so, then the hacker operating on your employee’s computer likely has that data!
- KVM (Keyboard-Video-Mouse) into your network: When hackers gain admin access to your employee’s personal computer, they can use something like RDP over reverse SSH, or install a remote desktop tool, such as VNC, LogMeIn, TeamViewer, etc.. Once they install this, they will have KVM-like access into the infected employee computer, which in turn, has KVM-like access into your corporate network!
- Loss of control: By default, a XenDesktop deployment provides zero guarantees about the hygiene and security of the unmanaged personal computer. Your employee could hold the trophy for “worst secured computer in the world” and “most infected computer in the world,” but be given the same level of access into your network as the next person. Think about the policies you have (hopefully) in your corporate network that protects you from threats – Endpoint AV and EDR; Group Policy; Proxy filters; Software import control; limited user/non-admin accounts; and on and on. How well does that protect your corporate assets? Assuming it’s done right, it does a pretty good job of blocking the continual onslaught of attacks in any corporate network. Do you have any of that running on your employee’s personal computers 24/7? Ask yourself, what is preventing those computers from getting owned? Did you finally have the “oh suck” moment just now?
What are the odds of it happening to you?
So you made the decision to move to XenDesktop because it was going to save you a few bucks in hardware costs, huh? There’s an old saying that a chain is only as strong as its weakest link. How weak do you think some of your employee’s personal computers are? According to various sources, approximately 24-30% of all home PCs are infected with malware at any give time. A company with more than about four people using XenDesktop is likely to have at least one employee with an infected home computer accessing your corporate network/data. If you’re not terrified at this point, you may want to explore career choices outside of IT security…or even IT for that matter. Just kidding…not really.
Exploit Code – Assumptions
Okay, here’s the fully automated exploit code that will pwn a corporate network from an unmanaged PC. There are a few assumptions:
- The attacker has remote code execution on the employee’s personal PC (obviously), even if it’s just command line execution.
- The employee has an active connection to the corporate network over XenDesktop. If not, it would be trivial for an attacker to fire it up and connect using captured creds from the keylogger.
- The XenDesktop session is maximized. With about two extra lines of code, the script could be modified to hit the maximize button though.
- The remote machine’s screen is not locked. Again, it would be trivial to add a line of code to this exploit to enter the unlock password.
- The RAT (Remote Access Trojan) being downloaded is designed to get through your corporate security stack…trust me, it’s trivial to get through.
Exploit Code – Description
The code below, when run, will identify the XenDesktop window on the employee’s personal PC, make it active, open Internet Explorer in your corporate network (the XenDesktop VDI), download a RAT (an executable in this example), and install/run it. This code has “sleeps” between every command, mainly for demo purposes. Most of the sleeps could be removed (or greatly reduced) giving an overall execution time of just a second or two. If you block exe downloads in your network, this could work just as easily by downloading a base64 encoded binary (for example) and using built-in decoders (certutil for example) before running it. Or, it could just download and run a PowerShell based RAT…because who blocks PS at the perimeter or prevents execution at the end host?
Exploit Code – Repository
Now, for the most important section. Here are things you need to implement ASAP if you already have XenDesktop, or before you implement it:
- MFA (Multi Factor Auth) for accessing the XenApp server. This is a given. If you are not doing this, I’d question the security of your corporate network in general. MFA makes is much harder for an attacker to start a XenDesktop session unless they have compromised your employee’s credentials AND their MFA token/device as well. This is not unheard of, but it is harder for the attacker to do and, therefore, less likely. This mitigation would not have prevented this exploit, though, because we’re running from the victim’s PC, which is connected already to the XenDesktop session.
- Short duration (5-10 minute) screen lock on your corporate VDI, with MFA. What if the XenDesktop screen is locked? Assuming the attacker has a keylogger, they’ll have the user’s creds and can easily unlock it with about two more lines of code. Use MFA on the VDI itself also, not just the XenApp dashboard so the user has to supply a token at the initial VDI login AND every time the screen is unlocked. This will force the hacker to work while the user is on or in that very small window between the user stepping away and the screenlock. In doing this, the likelihood of the user noticing and reporting the attack will greatly increase.
- Forced Security Policies on employee PC. Employee’s personal PC’s should have a forced security policy, matching your corporate policy as close as possible: requirement for AV, EDR, up to date patches, firewall, proxy and email filter, etc. Also, if possible, you should limit the use of admin privileges on your employee’s personal PC’s. These are, hopefully, all the same things that secure organizations do for their corporate assets. Why would you have strict security policies in your corporate network but not extend those policies to your employee’s home network?
- Monitoring. Think of the monitoring you have in your corporate network that detects threats. You should be collecting as much as legally possible from your employee’s computers to monitor for threats.
- Behavioral Analytics. Although you would still have the key logging and screen scraping concerns, you must implement the best “insider” threat protections available. Consider a product such as Microsoft Advanced Threat Analytics to look for anomalies. Not only will this help you catch attacks in your network through an infected employee’s personal computer, but this will also help you catch rogue employees.
Remember, the burden is really on you, the XenDesktop customer to implement effective mitigations for this exploit. I hope I have inspired you to stop, consider, and build effective mitigations against the risk of Citrix XenDesktop from unmanaged personal computers. Please leave feedback below.
Disclosure to Citrix
- 24 JUN: Notification sent to Citrix along with a draft of this write-up. I also asked if they wanted to respond to the article and provide information on additional products or configuration guides to help mitigate the risk.
- 27 JUN: They responded with a “We will get back to you with feedback”
- 28 JUN: They responded again agreeing that it wasn’t something they could really patch, but rather a customer configuration issue (a need to harden the VDIs). They did not provide any recommendations for the unmanaged home computer. Here are the details of their recommendations to mitigate the risk (in the VDIs).
XenDesktop customers can find guidance on securely deploying and managing their environments on the Citrix web site. Some specific resources that relate to the areas you mention are below:
- Getting Started with Citrix XenApp and XenDesktop Security: https://docs.citrix.com/content/dam/docs/en-us/xenapp-xendesktop/xenapp-xendesktop-7-6/downloads/getting-started-with-citrix-xenapp-xendesktop-security.pdf
- System Hardening Guidance for XenApp and XenDesktop: https://www.citrix.com/content/dam/citrix/enus/documents/products-solutions/system-hardening-for-xenapp-and-xendesktop.pdf
- How to: Securing the NetScaler Gateway using OPSWAT: https://www.citrix.com/blogs/2014/09/26/how-to-securing-the-netscaler-gateway-using-opswat/
I’m highly impressed with the speed at which Citrix responded to my inquiry and provided feedback. Unfortunately, the mitigation options provided do not effectively mitigate the bulk of the risk in this article. IMO, the security community should continue to work with Citrix on these type issues to ensure a more secure product/platform, and therefore protection of our data.