search

wiz-sec / open-cvdb

An open project to list all publicly known cloud vulnerabilities and CSP security issues
https://cloudvulndb.org
Creative Commons Attribution 4.0 International
306 stars 61 forks source link

Update cloudsql-privesc.yaml with info from Google's security bulletin #180

Closed dutchiechris closed 5 months ago

dutchiechris commented 1 year ago

After reviewing Google's security bulletin updated summary, references, and re-calculated severity rating.

korniko98 commented 1 year ago

@dutchiechris I had entirely missed that Google published a bulletin about this, thanks! We'll review your edit and update accordingly.

0xdabbad00 commented 1 year ago

Despite GCP's additional information, I wouldn't call this Low. I documented my beliefs for having originally scored this as High here: https://github.com/wiz-sec/open-cvdb/issues/178#issuecomment-1564894609

I believe the severity needs to take into consideration some things beyond customer impact. It's unclear what actual access the attackers had. The original article states they got "got full control on the SQL Server". Does that mean RCE as root? If so, that is High, as the attacker could back-door their access such that they could remain hidden from defenders. Minimally, they obtained some form of arbitrary file read access, but it's unclear if that was even root, as they read from /etc/passwd instead of /etc/shadow. Even if the only access was arbitrary read as a non-root user exceeds my personal threshold for what I view as Low severity, as it seems clear to me a security boundary was defeated (in that users are not expected to have that access). I could possibly see this being reduced to Medium, but that would be based on guesses.

Neither the researchers nor GCP provided sufficient details to have better confidence in what an appropriate severity is, so partially to encourage GCP to improve their transparency, I'm inclined to leave this severity as High.

dutchiechris commented 1 year ago

Indeed the info from Dig and Google could be much more detailed.

Reading the Dig blog closely they claim access to the DB and the host container where the DB was running; the title GCP CloudSQL Vulnerability Leads to **Internal Container Access** and Data Exposure and later Second hop: Gaining control on the host container.

Reading the Google bulletin it says Because the attack requires access to a customer administrator account, this vulnerability didn't expose any customer data that the attacker didn't already have access to. Moreover, this vulnerability didn't give the attacker any access to other Cloud SQL for SQL Server instances. This issue was not a security incident and no data was compromised.

My interpretation of the two sources are that researchers accessed resources that are supposed to be private to Google to run the managed server instance (both db and container os level) but were unable access the data or control plane of any other instance or tenant. To achieve this private access they started with administrative access to the instance.

Regarding severity, I calculated as follows using the Piercing Index with values: A1 = 1 A2 = 1 A3 = 1 A4 = 1.05 A5 = 1.05 A6 = 3 A7 = 1 A8 = 0.9

The result was 1.6 which equates to LOW.

dutchiechris commented 1 year ago

Any thoughts on my previous comment?

labyrinthinesecurity commented 7 months ago

Catching up on this thread only today! I've looked at Dig's latest report, now dated september 2023. The researchers claim to have accesses an internal Google repo (readonly I suppose), and, from what I understand, service agents and machine keys (but the exploit for agents and keys is not proven). I think this supports the fact that the tenant boundary (between Google and the compromised customer) was crossed, as well as the cross service boundary, at least on the data plane, and in readonly mode. My two cents: given the lack of more detailed information, I would recommend to be conservative and keep the score as High.