Privilege Escalation
The easiest and most obvious way to elevate our privileges in the database
would be to authenticate with a user
that has sysadmin role membership.
Although we might not be able to compromise such a user through
an initial phishing attack,
we could perform enumeration
and lateral movement within Active Directory
to obtain access to a user account with sysadmin role membership
This approach may produce varying degrees of success.
In this section, we’ll use a different approach
that relies on Impersonation.
We can accomplish this with an EXECUTE AS statement,
which provides a way to execute a SQL query
in the context of a different login or user.
It is important to note that only users with the explicit Impersonate permission
can use impersonation.
This permission is not part of the default set of permissions for most users,
but database administrators sometimes introduce misconfigurations
and this can allows us to escalate our privileges.
For the purposes of this example, we have introduced
an impersonation permission misconfiguration
in the SQL server running on dc01.
There are two ways we can leverage impersonation.
First, we can impersonate a different user at the login level
with the EXECUTE AS LOGIN statement.
Second, this can do this at the user level
with the EXECUTE AS USER statement.
We'll cover both scenarios.
First, we will demonstrate impersonation at the login level.
Because of our unprivileged access, we cannot easily enumerate
which logins our current login can impersonate.
However, we are able to enumerate which logins allow impersonation,
but not which logins can impersonate them.
We can get this information with the database query.
This query uses information from the server_permissions table,
which contains information related to permissions,
and the server_principals table,
which contains information about logins on the server.
The WHERE clause limits results to permissions relevant to impersonation,
while the FROM clause combines records from the server_permissions table
and the server_principals table,
through the grantor_principal_id and principal_id fields.
Finally, the SELECT clause returns, by name,
all unique principals from the server_principals table
that match these conditions.
This will give us all the logins that allow impersonation.
We can modify our C# console application to issue this query
by replacing the previous xp_dirtree procedure.
We have also included a while loop
in case there are multiple logins that can be impersonated.
With the code updated and compiled,
we'll execute it,
to discover that the sa login allows impersonation.
Although we do not know who is allowed to impersonate it,
at this stage we at least know that the sa login allows impersonation.
Let’s try to impersonate the sa login.
Inorder to learn more about how this works,
we'll update our code to list the login name
before and after impersonation.
To do this, we’ll reuse the code from an earlier section
where we executed the SQL
“SELECT SYSTEM_USER” command.
This code will perform the impersonation through the EXECUTE AS LOGIN query.
After updating and compiling the code,
we can execute the application.
We find that our unprivileged login can impersonate the sa login.
This effectively gives us database server administrative privileges.
Later we'll explore how to use this privileged access to obtain code execution
on the host operating system.
For now, let's try a variation of the impersonation technique.
As we mentioned before,
it’s possibleto allow impersonation of a login as well as a database user.
There are two prerequisites for this type of privilege escalation.
First, impersonation must have been granted
to our user for a different user
that has additional role memberships,
preferably the sysadmin role.
In addition, a database user can only perform actions on a given database.
This means that impersonation of a user with sysadmin role membership
in the database does not necessarily lead to server-wide sysadmin role membership.
To fully compromise the database server, the database user we impersonate
must be in a database that has the TRUSTWORTHY property set.
The only native database with the TRUSTWORTHY property enabled is msdb.
As is the case with many databases, the database owner user has the sysadmin role.
To illustrate the privilege escalation technique,
the guest user has been given permissions to impersonate dbo in msdb.
We can perform the impersonation by first switching to the msdb database,
and then executing the “EXECUTE AS USER” statement.
In the code, we also replaced “SELECT SYSTEM_USER”
with “SELECT USER_NAME()”.
Our modified C# console application will perform the user impersonation
and then query for the current user context
with USER_NAME.
We have successfully impersonated the dbo user
and obtained sysadmin role membership.
Nice!
In this section, we covered how impersonation can be used to provide
privilege escalation inside the SQL database
if misconfigurations are present.
At the end of this module,
we'llcover an additional way of obtaining higher privileges.