In-Depth

Ransomware: Coming to a Hypervisor Near You

Hyper-V is at the top of the risk chart.

• By Trevor Pott
• 08/08/2016

Ransomware encrypts files and then pops up a message informing the user that decryption of their files will cost some amount of money in bitcoin. The costs go up with the number and size of files. As the technique becomes more popular with criminals, more and more ransomware strains are not reliably unlocking files when the ransom is paid. Ransomware targets servers as well as endpoints.

2016 has seen an increased focus on attacking servers with ransomware. As a virtualization administrator, a ransomware-infected hypervisor is my nightmare scenario.

Users of Microsoft's Hyper-V hypervisor are clearly at the highest risk. Hyper-V is Windows. "A" cannot be separated from "B". Most ransomware strains that exist can infect Hyper-V, including those not specifically designed to attack servers. The route of infection can be a little complicated, but where there's a will, there's a way.

Perhaps more to the point, Hyper-V is almost never deployed as Hyper-V server. Survey after survey of Hyper-V administrators shows that not only are they installing Windows Server as their hypervisor, they are installing the full-fat GUI version instead of the core version. The cut down and hardened Hyper-V server sees adoption primarily in large environments where dedicated specialist IT roles and large teams exist.

Beyond Microsoft
It is a popular misconception that individuals not using Windows are safe from ransomware. This is incorrect. Nor only do Linux, Android, iOS and macOS variants of ransomware exist, but Synology NASes (which are Linux based) were rather famously hit by the "Synolocker" ransomware variant in 2014.

I have personally seen proof-of-concept VMware ESXi-based ransomware strains. They scare me. Similarly, ransomware that already exists for Linux can make short work of any KVM-based solution. Not to mention the number of storage arrays that themselves run some form of Linux or BSD. Administrators don't always patch virtualization hosts as often as they should. There have been very few direct threats to those hosts; so for most, why bother unless the patch solves an immediate problem or provides a desired feature?

Array updates are even more lax. A single storage array can be running thousands of workloads at any given moment. Every time you patch it or reboot it there is the risk of something going wrong. Why invite trouble?

In 2015 we learned just how badly coded the OpenSSH and OpenSSL libraries really are. There are a seemingly endless number of critical vulnerabilities; that means gaining access to systems using these libraries is trivial. Those are just two examples out of many common libraries that underpin today's enterprise infrastructure.

The bad guys don't have to directly connect to your hypervisor or array's management interface to infect it. The eggshell security of being behind the corporate firewall doesn't work today. All someone has to do is infect a desktop with the ability to talk to the right IP address. Or maybe they infect a desktop, which infects a printer, which infects a switch, which infects a thermostat, that happens to have a NIC on the datacenter's management network. Now they can get at the hypervisor. Or maybe the lights-out management controller. There's always a way in, if you care to try.

Dark Days
Once the hypervisor's infected, all sorts of havoc can be wreaked. Every virtual machine (VM) on that device can be encrypted. The administrative credentials used to access that unit can assuredly access the rest of its cluster as well. Most likely, every single hypervisor across the entire organization is now vulnerable; and they'll be infected in short order, wiping out every single workload. For many organizations, those same credentials will allow access to the backup and disaster recovery solutions. Given that only a handful of backup solutions make up the majority of the market, it's child's play to use those credentials to delete, corrupt or encrypt backups to make the ransomware's sting more potent.

It is 2016, and entire enterprises with redundant datacenters and complicated backup schemes can be utterly wiped out because one virtualization admin plugs their infected phone into their desktop to charge.

Denying Reality
What's most damning is the denial. Administrators the world over deny that this is a real threat. Backup solutions utilizing entirely separate administrative planes add a layer of complexity that nobody wants to deal with. Entirely offline backups are complex and expensive.

Vendors especially don't want to hear any of this, because the current push in the industry is for huge, vertically-integrated stacks, especially among hyper-convergence vendors. They don't want us backing up our VMs to third-party storage. Snapshots and clones on our hyperconverged clusters should be enough for anyone!

I've spoken to many of these vendors. Their top developers often don't even believe they're vulnerable, thinking that ransomware is something that only happens to guest OSes. Their solution will always be, "Buy more of our hyper-converged nodes, they're the only datacenter infrastructure you need!"

This will get a lot worse before it gets better. Eventually, a Fortune 2000 company is going to get wiped out by this. The resulting lawsuit will obliterate the sysadmins involved and several of associated vendors. Then – and only then – will we start to see vendors care about the possibility of hypervisor ransomware. By then it will be too late.

Not If, But When
Don't be the warning the rest of us learn from. Make sure that your backups infrastructure is completely separated from your production infrastructure. Make sure that if your production infrastructure is infected -- even at the hypervisor level -- your backups are safe. Make cold, offline copies if you can. Be paranoid. Be safe. And remember: ransomware is not a passing fad. It is the new reality. It extends beyond Windows. And it absolutely, positively will happen to you in the fullness of time.