UNC Path Injection
In this section, we are going to examine an attack that can quickly lead to
code execution
on other SQL servers present in the environment.
The premise of the attack is rather simple.
If we can force a SQL server to connect to an SMB share we control,
connection will include authentication data.
More specifically, NTLM authentication will take place
and we should be able to capture the hash of the user account
under whose context
the SQL server is running.
We can then either try to crack the hash
or use it in relaying attacks.
This attack consists of a number of steps.
We will cover each of these while also discussing the required theory.
We are going to start by forcing the SQL server to perform a connection request
to a SMB share on our Kali machine.
To do that, we can use the undocumented xp_dirtree SQL procedure,
which lists all files in a given folder.
More importantly, the procedure can accept a SMB share as a target,
rather than just local file paths.
If we use our unprivileged access in the database
to execute the xp_dirtree procedure,
the service account of the SQL server
will attempt to list the contents
of a given SMB share.
A SMB share is typically supplied with a UNC path,
which has a specific format.
If the hostname is given as an IP address,
Windows will automatically revert to NTLM authentication
instead of Kerberos.
We are now ready to test a C# console app
that performs authentication to the SQL server on dc01
with the unprivileged login
and then issues a SQL query
executes the xp_dirtree procedure.
The authentication portion of the code is the same as in our
previous proof of concept.
Weâll use the ExecuteReader method again
and pass the query to the SQL server.
The SQL query to invoke xp_dirtree contains a number of backslashes,
both to escape the double quote required by the SQL query
and to escape the backslashes in the UNC path
as required by C# strings.
Now we must set up a SMB share
hat will initiate NTLM authentication when the SQL service account
performs the connection.
An easy way to do this is by using Responder,
which comes pre-installed on Kali.
Weâll need to shut down the Samba share
used with Visual Studio before starting Responder
so weâll copy SQL.exe
to our Tools folder.
With the executable copied over, letâs shut down our Samba service on Kali.
Now we can launch responder
and specify the VPN connection network interface.
With Responder running,
we are ready to start the attack.
We run the C# console application from the Windows 10 client,
which initiates the SMB connection against our Kali machine.
Within moments, we obtain a hash.
This hash is known as a Net-NTLM
or NTLMv2 hash.
Before we continue, lets quickly review the difference between NTLM
and Net-NTLM.
As covered in a previous module, Windows user account passwords
are stored locally as NTLM hashes.
When authentication with the NTLM protocol takes place over the network,
a challenge and response is created
based on the NTLM hash.
The resulting hash is called Net-NTLM
and it represents the same clear text password as the NTLM hash.
Lika a NTLM hash
A Net-NTLM hash based on a weak password
can be cracked
to reveal the clear text password.
In this example, we'll attempt to crack the hash with hashcat,
by passing a filename that contains the hash,
specify the Net-NTLM hash type with the -m,
and a dictionary file.
We also need to provide the âforce option
because we are running this command in a VM.
Hashcat reveals a password of âlabâ
for the SQLSVC service account.
Since SQLSVC is a local administrator on both dc01 and appsrv01,
we now have access to both of them.
If weak passwords are used for SQL service accounts,
this can be a quick way to compromise the operating system.
In the next section, we are going to examine a variant of this attack
that does not require the Net-NTLM hash cracking.