Busting the VDI Security Myth

Tuesday, September 11, 2018

Tal Zamir


Many CISOs and security pros see Virtual Desktop Infrastructure (VDI) and other remote application solutions as security barriers. They think VDI isolates sensitive resources from the user's device, making it impossible for hackers to bust through. But that’s a dangerous myth. In reality, VDI is only a minor hurdle for cyber-criminals.

It doesn’t matter whether your business is using VDI so employees can access server-hosted desktops from thin clients or personal laptops, or giving third-parties “controlled” access to corporate assets, or allowing IT admins and other privileged users to use VDI servers as “jump hosts” for managing the enterprise crown jewels. Whatever the VDI use case, corporate assets are still exposed. Here’s why:

  • Thin clients

An employee using a thin client to connect to a remote VDI desktop running Windows is no better off security-wise than any other Windows laptop user. The remote desktop is still exposed to a variety of standard attack vectors, including email, web, external media, user-installed applications, and many others.

  • Unmanaged employee devices

In many companies, employees are allowed to connect to corporate VDI desktops from unmanaged devices such as personal laptops. But what happens when those end-user devices are already compromised? In these scenarios, the attacker first gains control over the 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.

Some people think that by preventing clipboard operations between the user’s personal laptop and the remote VDI desktop, you can thwart attacks. But that doesn’t really work. 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 path 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.

  • Third-party connections

Third-party vendors and contractors who use VDI to access your corporate resources make your business just as vulnerable as employees with unmanaged devices. As seen in the recent Target, and Equifax breaches, cyber-criminals only need to infect one of the vendor’s machines. After that, they can gain control of sensitive resources via VDI. Two-factor authentication for VDI sessions doesn’t help mitigate this risk because the attacker, already present on the machine, simply waits for a successful authentication and then launches the attack.

  • Privileged users

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 often a healthy practice, problems begin when the device used to access the privileged host 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.

The VDI Isolation Problem

Why doesn’t VDI work for security? It all comes down to this: VDI is not an isolation solution. It does not isolate the remote sensitive resources from the device used to access them. If hackers control the end-user’s device, they control the VDI resources. 

Anything short of a full isolation approach leaves you vulnerable. That’s why local or remote access of sensitive resources should never be mixed with any corporate or personal usage that is exposed to the outside world. This guidance is being recommended more and more by security vendors like Microsoft and financial industry institutions like SWIFT (PDF), which propose using a separate instance of an operating system (OS) for accessing sensitive resources, including those residing on VDI.

Isolation in Action

So what would this look like in practice? A new, hypervisor-based approach entails turning end-user devices into software-defined endpoints, in which each endpoint has multiple isolated VMs. This approach fully isolates access to sensitive resources, without limiting the user’s freedom or requiring multiple laptops or desktops. 

Everything a user does runs in one of their endpoint’s VMs, including OSes and all applications. One OS can be used for personal, unlocked usage, and the other for accessing sensitive resources, either locally or via VDI. Attackers controlling the personal VM cannot see or control the sensitive VM. They’d have to break out of the VM to be able to breach the security of the system. This provides the assured protection businesses need and the high productivity users crave.

VDI on its own provides a false sense of security that is misleading, at best, and can be devastating to business, at worse. It’s paramount that enterprises realize this risk and take appropriate isolation measures to protect their business.

About the author: Tal is a passionate entrepreneur and veteran R&D leader with 15 years of experience in the cyber and IT domains. Tal started his official career in the Israeli Ministry of Defense, in which he pioneered multiple mission-critical cyber products. He then joined the leadership team of Wanova – a desktop virtualization startup that was later acquired by VMware. He holds multiple US patents as well as an M.Sc. degree in Computer Science from the Technion.

Possibly Related Articles:
Enterprise Security Security Awareness Breaches
breach Virtual Desktop Infrastructure VDI isolation corporate assets
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.