Google cloud misconfiguration poses risk to customers

How does it work?

At first glance, the issue with the getSerialPortOutput API appeared to be limited to potential data leaks.

"By itself, this API represents not much more than a stealthy method of exfiltration," Johnston wrote in the report. "While interesting, it would be much more powerful if we could identify a companion API method that would enable an adversary to send data to the machine. Combined, the methods would enable complete command and control (C2) over a machine with only cloud credentials."

Mitiga discovered and tested two possible attack vectors that involve abusing another API, SetMetadata. Both cases began with an attacker gaining access to a victim's cloud credentials, which enabled API permissions for SetMetadata. One instance involved traditional network-based methods of lateral movement prior to the malware infection, while the other leveraged API-abusing malware.

With the APIs, a threat actor could send malicious commands inside custom metadata to VMs in the Google cloud. Without additional access controls, threat actors could gain control of the VM.

Though applying these techniques requires relevant permissions such as GCP credentials, the sharing and reusing of administrative passwords and usernames are common among enterprises and can lead to a higher probability of leakage.

When compared with on-premise networks, cloud credentials are incredibly powerful, Johnston said. Often, having that credential is the only requirement to access the system.

The risks are further highlighted by another step in the alternative attack sequence that involves gaining API permissions for getSerialPortOutput. The cloud instance is available even to low-permission viewer roles, according to the report.

"An adversary could potentially use this method to stealthily exfiltrate from a system which the adversary gained access to via a traditional method," Johnston wrote in the report.

While he has not observed threat activity around the misconfiguration, Johnston said it's hard to confirm that for all customers, which is one reason why Mitiga wanted to publicize its findings. If the attack vector was being exploited, it would be relatively obvious, according to Johnston. However, the risks were not clearly documented by Google, he said.

"It does involve repeated calls to the Google AP,I which was concerning to us and why we wanted to push forward with this research and why we wanted to engage with Google in the first place," Johnston told SearchSecurity. "I couldn't find any research that these APIs were hazardous -- or at least it wasn't very plainly clear -- and that was our principal concern."

Disclosure and remediations

Mitiga reported the findings to Google's vulnerability reporting program (VRP); both vendors agreed the issue is not a vulnerability, but a misconfiguration that could be used to bypass firewall settings.

UPDATE 5/5: The original version of this story included a quote from Mitiga's blog post, which stated that "both Mitiga and Google agreed that the finding wasn't a vulnerability, but rather simply dangerous functionality." Mitiga updated the post today to clarify that Google did not share the belief that the functionality was "dangerous," and SearchSecurity removed the quote from this article to reflect the update.

Mitiga recommended that Google make two changes to the getSerialPortOutput function, including restricting its use to only higher-tiered permission roles, and allow organizations to disable any additions or alterations of VM metadata at runtime. Mitiga also recommended a revision to GCP documentation to make it clear that access to VMs is not entirely restricted by firewalls and other network access controls.

However, Google disagreed with a majority of the recommendations.

"After a long exchange, Google did ultimately concur that certain portions of their documentation could be made clearer and agreed to make changes to documentation that indicated the control plane can access VMs regardless of firewall settings. Google did not acknowledge the other recommendations nor speak to specifics regarding whether a GCP user could evade charges by using the getSerialPortOutput method," Johnston wrote in the report.

Google awarded Johnston $100 through its VRP for the misconfiguration report.

A Google spokesperson provided the following statements to SearchSecurity.

"We worked closely with the security researchers on improving our documentation in case other customers, like them, had understood that firewalls would prevent access from Google. We explained to the researcher how it's always going to be necessary for some mechanism to have access to the VM. For example, it will always be necessary to turn it off if it is malfunctioning," the statement said.

"Google Cloud clarified in the documentation that this access described in the report is allowed. An attack from this vector requires privileged access, and if someone already had privileged access then it's unlikely that they would pick the metadata server as their attack method."

Google recommended customers use VPC [Virtual Private Cloud] Service Controls to protect against ingress access through a cloud console to GPC resources like VMs.

In order to harden systems against the GCP misconfiguration, Mitiga recommended assigning specific permissions as needed to users in adherence with the principle of least privilege, as opposed to built-in roles.

However, cloud security is an evolving area that requires a different level of attention compared with on-premise networks, Johnston said. The biggest takeaway Mitiga gained from this discovery was the many unintended side effects of transitioning to the cloud.

While Johnston said the cloud has been amazing for developers and the pace of development in terms of creating enterprise-grade applications, there are additional challenges when it comes come to cloud security. Some of that confusion stems from the terms and ideas that were taken from traditional on-premises networks that don't always apply to the cloud in the same way. One example is the common vulnerability and disclosure program.

Another example centers around the shared responsibility principle upon which the cloud operates. Johnston said it can cause confusion as to how exactly it is shared, but understanding the difference in how the cloud alters these terms as well as the underlying technology is important to cloud security.

"As organizations continue their cloud journey, it's really important to understand what the attack surface of your cloud looks like and make sure that you have the proper logging and alerting in place," he said.