As 2021 begins and remote work has gone from a growing trend to a necessity for many enterprise companies around the globe, administrators and management are re-evaluating their enterprise VDI solutions.

“From a cyber and data security perspective, as well as a technological perspective, there are many challenges with the current environment,” says Steven Estep, director of operational risk for Independent Community Bankers of America. Part of the issue, he says, is how quickly financial institutions had to set up work-from-home capabilities and how reliant they are on new business tools needed for secure remote collaboration.

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. These attacks have increased in 2020, as hackers take advantage of so many workers being moved quickly to a work from home model.

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 (known as Bring Your Own Device policies) – 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. 

WordPress Appliance - Powered by TurnKey Linux