freshidea – stock.adobe.com
The Asset Key Thief vulnerability gave rise to multiple potential attack scenarios that could have impacted thousands of Google Cloud users, but has now been safely fixed
Google Cloud has fixed a potentially dangerous application programming interface (API) vulnerability in its platform that, had it been exploited by malicious actors, could have led to widespread data breaches across multiple public clouds.
Dubbed Asset Key Thief and disclosed through researchers at SADA, a California-headquartered cloud security consultancy with UK offices in Dorset, the bug was uncovered on 7 February 2023 and reported through the Google Vulnerability Reward Program the same day. Following some back and forth, Google accepted the vulnerability on 23 February, and it was fixed and verified on 14 March.
“Supporting our customers as they transform their organisations in the cloud means constant vigilance when it comes to security,” said SADA chief technology officer Miles Ward.
“No public cloud is immune from vulnerabilities, and we all must act fast, collaborate openly and communicate transparently when we spot a vulnerability.
“We commend Google Cloud for how quickly and thoroughly they responded when we brought this bug to their attention,” he said. “We’re proud of the work SADA’s engineers put into ensuring that our customers’ data remains safe.”
The vulnerability itself existed in the Cloud Asset Inventory API and related to a persistent access mechanism known as Service Account private keys, and affected all Google Cloud customers that had enabled the API with principals granted specific permissions – cloudasset.assets.searchAllResources – on the applicable environment for a limited period.
In practice, this meant anybody with the needed permission could use a specific gcloud SDK command to exfiltrated private key material of a Service Account in the Google Cloud environment that was created or rotated in the prior 12 hours, and take over the identity of, and permissions associated with, said account.
Impact assessment
Had the vulnerability been exploited in the wild, its impact would have varied depending on the permissions held by the exploited accounts.
The SADA team posited three potential scenarios that may have unfolded:
- In the first scenario, the theft of a private key from an organisation level Service Account used for infrastructure-as-code provisioning assigned the “overly permissive” Owner role would give a malicious actor access to virtually all resources and data in the victim environment;
- In the second scenario, the theft of a private key from a default Service Account assigned the Editor role would give an attacker access to all resources in that individual’s project, or enable them to conduct further activity, such as spinning up illicit cryptominers, racking up substantial extra charges for the victim;
- In the third scenario, the theft of a private key from a Service Account that had the ability to assume the identity of other Service Accounts in a centralised management structure – perhaps for tech support reasons – would have let an attacker chain access through various Service Accounts until hitting one that had access to sensitive customer data.
Although the vulnerability has been fixed, SADA is still recommending that Google Cloud users scan for potential occurrences of the exploit technique, looking for abnormal Service Account behaviour, and rotate their Service Account user-managed keys.
If your Google Cloud environment has data access logs enabled for ADMIN_READ activity on the Cloud Asset Inventory API, you will also be able to search for instances of exploitation. Additionally, the Google Cloud Security Command Center Premium service includes built-in detectors to spot abnormal behaviour that may have arisen through the vulnerability.
Read more on Cloud security
Read More
Thomas Ramage