This week, Google is rolling out a number of new cloud security technologies aimed at making the public cloud a safer place. Among them is Shielded VMs, a feature of Google Cloud Platform that protects virtual machines from the installation of rootkits and other persistent malware, as well as other attacks that could result in data theft.
Using a cryptographically protected baseline measurement of the VM’s image, the Shielded VMs feature—launched in beta today—provides a way of “tamper-proofing” virtual machines and alerting their owners to changes in their runtime state. Shielded VMs also make it possible to prevent a virtual machine from being booted in a different context than it was originally deployed in—in other words, preventing theft of VMs through “snap-shotting” or other duplication.
Major cloud providers have been trying to blunt threats to virtual machines and cloud application containers in a number of ways—with hardened operating system images for virtual machines and with “confidential computing” models that prevent compromises of the underlying machine’s operating system from providing access, for instance.
Both Microsoft and Google have launched confidential computing technologies; Microsoft’s Azure Confidential Compute was announced last September, and Google’s Asylo framework was launched in beta in May. These platforms run application containers in “trusted execution environments”—enclaves that prevent access to the data within those instances from being read by anything running on the underlying operating system or virtual environment.
But these approaches currently require applications or containers built specifically to run in trusted environments, and they’re not necessarily practical for protecting all cloud applications. Outright remote hacks of virtual machine instances on platforms such as Amazon Web Services, Microsoft Azure, and Google Cloud Platform (GCP) using operating system exploits, while not impossible, are extremely rare. However, theft of administrative credentials through spear phishing attacks—as occurred in the case of the hack of the Democratic National Committee (DNC)—offer attackers an easier way in.
As Chris Vickery, director of cyber risk research at cloud security firm UpGuard, pointed out in a discussion with Ars, human errors and system misconfiguration often leave the door wide open for an attacker to jump in. “A more common situation would be that someone left AWS credentials in a Github repo that was exposed to the public and forgot to limit the permissions on the credentials in the first place,” Vickery said. With credentials in hand, an attacker could make a snapshot of virtual machines or storage “and then migrate the snapshots over to an account owned by [the attacker] for pilfering,” he said. Alternatively, they could gain access to the virtual machine itself and drop rootkits or other malware that give them persistent access.
The latest evidence of that emerged in the indictment filed by Special Counsel Robert Mueller earlier this month, which described a previously unmentioned Russian state attack on cloud services used by the DNC. Hackers from Russia’s Main Intelligence Directorate (GRU) were able to gain access to a virtual machine used for analytics development by the DNC and save snapshots of the virtual server, allowing them to essentially clone the virtual server and create another instance of it within the same cloud service, extracting data at their leisure.
Locking things down
To fight this sort of attack, Shielded VMs use a combination of firmware-based UEFI Secure Boot and vTPM—a virtual Trusted Platform Module, which can generate and store “sealed” encryption keys. Those keys are used for Secure Boot, which ensures that the VM will only run authenticated software, and for Measured Boot, which checks against previous baselines of the virtual machine’s configuration to provide even greater control over the integrity of the VM before it is launched.
Both Secure Boot and Measured Boot can help defend against rootkits that might execute during the operating system startup, as well as kernel-level malware. Measured Boot can also surface information about the integrity of VMs’ runtime state through StackDriver, Google’s virtual machine monitoring tool.
The vTPM can also be used to store “sealed” drive encryption keys, making it difficult if not impossible to gain access to the contents of a virtual machine’s drives unless the operating system boots in a “known-good” state. If the VM’s operating system, boot loader, or firmware image is compromised, the system won’t reboot—so an attacker won’t be able to decrypt the virtual disks. The same would be true if a snapshot of the VM is moved into a different context by an attacker.
Google is working on a similar integrity-protection technology for its container environment, Google Kubernetes Engine. Binary Authorization, a feature that will be released in beta soon, will allow users to require signature verification of container images before they can be deployed—an administrative feature aimed at ending the “YOLO” deployment approach often associated with DevOps-type cloud environments. The Binary Authorization signature can be created as part of the development and testing pipeline as a final blessing before deployment—and used alongside GCP’s Container Registry Vulnerability Scanning (with Ubuntu, Debian and Alpine Linux-based images) to perform pre-deployment security checks.