CISOs and security professionals often refer to Virtual Desktop Infrastructure (VDI) (made popular by VMWare & Citrix) and other “remote application” solutions as security barriers that hackers have a hard time bypassing. That’s a myth, and here’s why.
1. Thin client scenarios are precarious.
These virtualization efforts pose only a minor hurdle to determined cyber-criminals. An employee using a thin client to connect to a remote VDI environment running Windows is not better off security-wise than any other Windows laptop user. The remote Windows desktop is still exposed to a variety of standard malware and attack vectors, including email, web, external media, user-installed applications, and many others.
2. BYOD sounds appealing, but these laptops are probably already compromised.
In many cases, employees are allowed to connect to their corporate VDI desktops from unmanaged devices such as personal laptops – which are probably compromised already. In such a scenario, the attacker first gains control over the end user’s personal laptop; he then impersonates the user and interacts with the remote VDI desktop. This doesn’t require attacker sophistication – it’s as simple as installing commoditized off-the-shelf remote control software on the user’s personal laptop, waiting for the user to authenticate, and then controlling the VDI session in the user’s name.
Preventing clipboard operations between the user’s personal laptop and the remote VDI desktop doesn’t really help. Attackers can stealthily and instantly send an entire script via emulated keystrokes and then launch the script on the remote VDI desktop. From there, the way to complete control of the VDI desktop is short. This kind of attack doesn’t require any zero-day vulnerability and can be executed by any determined attacker.
3. You need to consider your vendors’ endpoints.
The same applies to third-party vendors and contractors who use VDI to access sensitive resources. As seen in the Target, Equifax, and Panama and Paradise papers breaches, cyber-criminals only need to infect one of the vendor’s machines and from there they have complete control of the sensitive resources available via VDI. Two-factor authentication for VDI sessions doesn’t help mitigate this risk as the attacker, already present on the machine, will simply wait for successful authentication and then launch the attack.
4. VDI and Jumphosts
The false sense of security provided by VDI can be very misleading and, in some cases, can have catastrophic consequences. Some enterprises let their IT administrators connect to privileged management consoles via jump hosts or jump boxes hosted on VDI terminal servers. While jump hosts are a healthy practice, the problem starts when the device used to access these privileged jump hosts is a compromised personal device, which is often the case. The bad guys look for IT administrators and target them personally; once they infect an IT administrator’s personal device, they can literally control the entire organization over VDI.
5. True isolation is key.
VDI is not an isolation solution. It does not isolate the remote sensitive resources from the device used by the user to access them. If you control the user’s device, you control the VDI resources.
It’s paramount that enterprises realize this risk and completely isolate access to sensitive resources. Local or remote access of sensitive resources should not be mixed with other usage, such as personal or corporate use that is exposed to the outside world. This practice is recommended by security vendors and financial industry institutions, including vendors like Microsoft and SWIFT that recommend using a separate instance of an operating system for accessing sensitive resources.