Elevation of privileges from Editor to Global administrator?

Let me first briefly explain an elevation of privileges attack. In such attacks, a user with no or limited permissions is able to obtain more privileges. For example, a CMS editor with permissions to edit content is able to elevate herself to a global administrator.  

Now, let’s go back to the customer’s concern. He sent us the following piece of code:

<script runat="server">
protected void Page_Init(object sender, EventArgs e)
{
    Guid guid = CMS.CMSHelper.CMSContext.CurrentUser.UserGUID;

    new System.Threading.Thread(
        new System.Threading.ThreadStart(()=>
        {
            var info = CMS.SiteProvider.UserInfoProvider.GetUserInfoByGUID(guid);
            info.IsGlobalAdministrator = true;
            CMS.SiteProvider.UserInfoProvider.SetUserInfo(info);
        })).Start();
}
</script>

Inserting this code into a page template layout will allow a user to elevate their privileges. But this is only possible on a Kentico CMS that has not been configured to be sufficiently secure. To remove this risk, there is the Design permission called Edit ASCX code. Let’s take a look.



When you grant the Edit ASCX code permission to a certain role, then a user in that role can edit such code in layouts and transformations and can run any code in them - for example, the code that elevates privileges. Without the permission, the user cannot do this.
 
A very similar problem is found with editing SQL WHERE and ORDER BY properties in various web parts (e.g. the query repeater). Again, there is a permission for the Design module called Edit SQL Code. If you grant this to a role, a user in that role can write any SQL statement into WHERE and ORDER BY. Without it, the user can only write simple WHERE conditions like “UserID = 1” and ORDER BY statements like “UserID”.



Now let’s take a look at the Reporting module. The Reporting module allows you to write any SQL statement in order to get data from the database into a chart. This could also be dangerous because a user can, again, elevate privileges or get sensitive data from the database. This risk can also be removed through permissions.

The reporting module has the permission Edit SQL Queries which indicates whether the given role can edit SQL queries in reports.
 


Alternatively, you can change a connection string for reports. With that, you can create a special user account on database level with limited permissions. For example, the database user will not be able to execute any UPDATE/INSERT/DELETE queries. Another approach could be to separate the data into multiple databases. The first database would contain only reporting data and the second, all other data including users. Then, the reporting module would be able to work only with reporting data (and the user would not be able to execute dangerous queries). Of course, in this scenario, you have to somehow deal with data synchronization.

The configuration of multiple connection strings contains these three steps:

1.    Open web.config file and specify a new connection string in the <connectionStrings> section. The name attribute must be unique.

2.    Go to SiteManager->Settings->Security&Membership and select the new connection string as the default report connection string in Reporting category.


 
3.    Set the connection string permission of the Reporting module. A user in a granted role can change the connection string of a report. No other user can do this unless she is the global administrator.



The last configuration option I want to mention is Site Manager -> Settings -> Security & Membership -> Administration -> Enable code editing for site administrators. Here, you can specify whether site administrators (global administrators without access to Site Manager) can edit ASCX, Reporting SQL queries and WHERE and ORDER BY in web parts.



From a security standpoint, best practice is not to grant any of the permissions listed above to any roles. You should also not allow site administrators to edit code. If you do not follow this, you risk elevation of privileges.

There are some scenarios, however, where this practice could be ignored – perhaps for a user who has full administrator privileges, but doesn’t want to use them (they might be afraid of their potential faults).