Exfiltrate data from your super-secure Google Cloud project, using the security control built to prevent it [fixed]
Needless to say, it was ironic to find a data exfil vector using the service that “mitigate threats such as data exfiltration“: VPC Service Controls.
VPC Service Controls are the API-level firewall of Google Cloud. They isolate your GCP projects from the Internet, other projects, and other Organizations. They are the go-to control for anything related to non-network-based data exfiltration (or data breach, e.g. public Bucket).
Cherry on top, Google deemed our disclosure to be more a feature than anything else, and then they fixed it anyway (see Conclusion).
Attack path
Let’s imagine you have sensitive data running in a completely isolated VPC (no internet access) protected by VPC Service Controls.
An attacker manages to run a malicious program in one of your VM (or a Cloud Function). The attacker uses one of their credentials [1] (e.g. service account) to make API requests [2] to any Service supported by VPC Service Controls (e.g. Storage). The requests get denied by VPC Service Controls [3], as expected.
The problem: the denied requests get logged in Cloud Logging in the Attacker project, including any attacker-specified parameters provided by the attacker (oops). Hence allowing to exfiltrate data (albeit slowly) via Cloud Logging logs. See below a simple example using the name of a Bucket.
The mitigation: At the time, we recommended our Customers to monitor denied logs in the defender account, because it was also logged. To see if you were attacked via this vector previously, review deny logs by “VPC Service Controls” by unknown principalEmail.
The Google Cloud fix: As of 2021-09-21, logs for requests denied by VPC Service Controls are not anymore logged in the attacker project, only in the defender project. It is the best outcome, the defender project can still see the logs to check for abnormally or debug, while the attacker project is not able to. Kudos!
Conclusion
So was that a vulnerability? According to our Customers, yes. According to Google, no. This abuse scenario didn’t qualify as “vulnerability” or as a significant enough “abuse-related methodology” by the Google Vulnerability Reward Program (VRP). Not even HoF bragging rights for us 😉
More seriously, we believe that the underlying reason of not qualifying is because it is about the customer side of the shared responsibility model. Google Cloud (or any CSPs) expects you to understand how their services works in all their details, because questionable features are still features.
While CSPs explain everyone at length the shared responsibility model, it is a good reminder that cloud Customers are responsible for the shared responsibility reality.
Timeline
2020-10-12 – Report of vulnerability by TrustOnCloud
2020-10-28 – Assigned Severity 2 Priority 2 by Google Cloud triage
2020-11-25 – The Google Vulnerability Reward Program (VRP) panel decided “this issue’s security impact does not meet the criteria to qualify for a reward” + forwarded to Product team for them to “decide whether they want to make a change or not” with another issue marked as blocker (#171816079).
2021-09-21 – Fixed by the Product team
About TrustOnCloud
TrustOnCloud provides complete control catalogs for individual Cloud Services: 1) risk-based from our detailed threat models, 2) always-updated from new releases, and 3) audit-ready with major compliance frameworks.
We assist large financials, unicorns and government agencies to move quicker and make better security decisions in the Cloud.
To date, our control catalogs span across 70+ Cloud Services, and keeping up with CSP innovation, we analyzed 3,500+ new releases (just last year).
If you are interested to see more, we open-sourced the S3 ThreatModel, and you can get access to more by getting in touch with us.
