POST_START

Understanding Privilege Escalation Through Production Group Grants

I recently had the opportunity to audit the access controls for our production data catalog. One of the key concerns was identifying potential privilege escalation risks. I knew that understanding the grants assigned to the production catalog and its objects was essential. I started by examining the grants at the catalog level.

SHOW GRANTS ON CATALOG production;

I saw a representative result like this:

principal | actionType | objectType
data_analysts | SELECT | TABLE
data_engineers | MODIFY | TABLE

This output showed that the data_analysts group had SELECT access to tables, while the data_engineers group had MODIFY access. It was clear that these groups had different levels of access, which is a good starting point for understanding privilege boundaries.

I wanted to dig deeper and check the grants at the schema level to see if there were any discrepancies or potential escalation paths. I ran the next query to examine the sales schema within the production catalog.

SHOW GRANTS ON SCHEMA production.sales;

I saw a representative result like this:

principal | actionType | objectType
data_analysts | SELECT | TABLE
data_engineers | MODIFY | TABLE

Interestingly, the grants at the schema level were the same as those at the catalog level. This consistency was reassuring, but I wanted to make sure there were no hidden or more granular permissions that could allow for privilege escalation. I decided to check the grants on a specific table within the schema.

SHOW GRANTS ON TABLE production.sales.orders;

I saw a representative result like this:

principal | actionType | objectType
data_analysts | SELECT | TABLE
data_engineers | MODIFY | TABLE

The grants on the table orders were identical to those at the schema and catalog levels. This uniformity suggested that the access rights were consistent across all levels of the data hierarchy. However, it also raised a question: could a user with MODIFY access at the schema level potentially access tables they shouldn’t?

I verified that the grants were applied consistently and that there were no additional permissions granted at the table level that might allow for escalation. It was important to ensure that the data_engineers group had only the necessary permissions and that no user could leverage broader access to gain control over more sensitive data.

Through this process, I learned that reviewing grants at multiple levels—catalog, schema, and table—is crucial for identifying potential privilege escalation risks. It also reinforced the importance of maintaining strict access controls and regularly auditing permissions to ensure they align with the principle of least privilege.