Please provide a short (approximately 100 word) summary of the following web Content, written in the voice of the original author. If there is anything controversial please highlight the controversy. If there is something surprising, unique, or clever, please highlight that as well. Content: Title: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure Site: One of the top three cloud providers is Google Cloud Platform (GCP), which offers a range of services including a managed database service called CloudSQL. CloudSQL is capable of supporting three different database engines: MySQL, PostgreSQL, and SQL Server. By their nature, databases tend to contain large amounts of information, and often contain sensitive information such as PII , Developer Secrets, and even financial data like bank accounts or credit cards. In our research, we chose to focus on CloudSQL because of its potential impact on customer data. Many vulnerabilities have been disclosed in MySQL and PostgreSQL hosted in all 3 major cloud environments ( GCP , AWS and Azure ). The integration of database engines to native CSP services required significant changes to be made which exposed new risks and vulnerabilities. Unlike the other two, SQL Server is not an open-source DB, which means that it could not be modified by the cloud providers. To integrate SQL Server to their environments, cloud providers built their own security layer on top of the database engine. In this blog, we reveal a new critical vulnerability in GCP CloudSQL service that was discovered by our Dig research team. SQL Server Basics SQL server has 4 system databases:  Database Name Description Master  contains all the system objects, and information about the SQL Server instance MSDB used by SQL Server Agent for scheduling alerts and jobs Model used as a template, for every new database created on the SQL Server instance Temp used to hold temporary objects and result sets for sorting, aggregation etc. Understanding SQL Server permissions: server permissions vs. database permissions To gain a better understanding of this new vulnerability and its impact, it’s important to understand how permissions are structured in SQL server. Server permissions contain operations that are done on the instance level, for example CREATE / ALTER / DROP database (or other objects like logins, audit etc.) that is considered at the server level. `CONTROL SERVER` is the most powerful permission a user can be granted on the instance level. Database permissions contain CREATE / ALTER / DROP on objects inside the database (like tables, triggers, users etc.). `CONTROL DATABASE` is the most powerful permission a user can be granted on the database level. Default permissions on GCP SQL server The default permissions that are granted to a user define the starting point to our research as described below: The default login and user for SQL Server on GCP is `sqlserver`, and is granted with the GCP role `CustomerDbRootRole`. This role does not allow the default `sqlserver` user to create/alter anything on the server level. The default user has no permissions on sys objects, which means that the user cannot create objects in any system database. Vulnerability discovery: escalating from a basic CloudSQL user to full-fledged sysadmin on the container Following are the steps in which this vulnerability was uncovered: First hop: privilege escalation to DbRootRole Our research began when we identified a gap in GCP’s security layer that was created for SQL Server. This vulnerability enabled us to escalate our initial privilege and add our user to the DbRootRole role, a GCP admin role. The screenshot below shows that the principal `sqlserver` is a member of both `DbRootRole` and `CustomerDbRootRole`: Second hop: Gaining control on the host container With the role `DbRootRole` we were able to do many things that we didn’t have permission to do before. Still, the `DbRootRole` is not a sysadmin role and doesn’t have full permissions on the SQL Server instance. As our research progressed, we found another critical misconfiguration in the roles permissions architecture, which enabled us to further escalate our privilege, and this time we could grant our user the `sysadmin` role. At this point we bypassed the barrier and got full control on the SQL Server. `sqlserver` user default privileges `sqlserver` user privileges after second privilege escalation The Impact: Gaining access to all the data By assuming complete control on the database engine, our user was granted access to the operating system hosting the database. At this point we could access sensitive files in the host OS, list files and sensitive paths, read passwords, and extract secrets from the machine. In addition, the host has access to the underlying service agents which could potentially lead to further escalation to other environments. Gaining access to internal data like secrets, URLs, and passwords can lead to exposure of cloud providers’ data and customers’ sensitive data which is a major security incident. With access to the operating system, we managed to find some internal Google URLs related to the docker image repository. We could also access the internal repo which later was fixed and the access from non internal IPs was blocked.  Google’s internal docker image repository URL: ‍ Reading /etc/passwd: ‍ The disclosure process: Collaborating with Google VRP Program The professional team at Google identified our research activity within 8 days of our initial vulnerability discovery. The team reached to us with the following email: The following weeks were dedicated to collaborating with the Google team to address the newly discovered security vulnerability, resolve it, and handle the necessary formalities related to the finding. Needless to say that if you tried to follow the hops described above - it is no longer possible. Research Timelines  February 5th 2023 - GCP CloudSQL vulnerability discovered by Dig’s research team. February 13th 2023 - Google’s vulnerability reward program identified activity and reached out to Dig’s research team. During April 2023 -The vulnerability was successfully addressed and resolved.  April 25 2023 - We were rewarded by GCP VRP program. ‍ Dig Security: Helping organizations protect their sensitive data with DSPM and DDR Dig is an agentless multi-cloud data security platform that discovers, classifies and protects sensitive data. Using Dig’s data classification engine, you can quickly locate your most critical data and organizational “crown jewels” in structured and unstructured data assets.  Dig prevents exposure of sensitive data with full data security posture management ( DSPM ) capabilities, highlighting data misconfigurations, access anomalies and data vulnerabilities that increase the risk of a data breach. Dig is the first to provide real-time data detection and response ( DDR ) engine to ensure an immediate handling of newly discovered data related incidents by integrating with existing security solutions.  Get your free data risk assessment today.