As part of the Imperva Research Labs we have the opportunity to examine various security scenarios. In this post, we will consider database security on SQL Server.

One standard method that security practitioners use to protect databases is deploying honeypots and waiting for hackers to take the bait. Honeypots are very useful because they enable us to analyze various attacks and get more insights about the methods and techniques that bad actors use to attack databases.

Here we provide a glimpse into today’s “Database Attack Landscape”. This is a follow-up to Imperva Research Labs research done in 2018 on SQL Server. To see those findings, check out “A Deep Dive into Database Attacks [Part II]”. In that piece, you can see how little the attack landscape has changed in the past 3 years.

We will explore the methods and techniques attackers use to deploy malware, gain persistence, and take over the system to join the server into massive botnets, or escalate privileges in order to infiltrate an organization’s network.

While other articles concentrate on the malware itself, we are going to focus on the database side of the attack, the dangerous functions, and the power that is stored inside the SQL Server to interact with other components of the Windows OS called COM objects. Some examples are processes like WMI, XML, HTTP, WScript, VBScripts and more.

Hackers use attack methods that will have the most chance to succeed. Core features that are defined in multiple versions are the ultimate target. This is one reason why we see hackers using the same methods with slight changes over the years; exploits recycling is very common. The database attack landscape hasn’t changed a lot over the years and exploitation techniques are being reused over the years.

SQL Server OLE Automation is one example of such a target as it is a built-in feature for many SQL Server versions. We will inspect some of the techniques in depth and explain the ways to prevent similar attacks on your SQL Server in the future.

What Are OLE & COM Objects?

Before we dive into the depth of the attacks, we need to understand some Windows terms, Specifically the OLE and COM objects.

OLE stands for Object Linking and Embedding. It is a technology developed by Microsoft that allows one application to link objects into another application. Later, the OLE evolved and reimplemented on top of COM. Component Object Model (COM) is a binary-interface standard for software components. Simply put, COM allows for one application to expose its functionality to other applications.

OLE Automation Procedures

SQL Server “OLE Automation Procedures” enables the SQL Server to leverage OLE to interact with other COM objects. Data security-wise, this increases the attack surface.

There are excellent examples out there for leveraging COM objects to perform lateral movement.

All of this power is granted simply by enabling a small but dangerous database configuration, the “OLE Automation Procedures”. In addition, SQL Server provides multiple extended procedures to link and interact with the COM objects.

Extended Procedure simply means the ability to execute code from external sources. The OLE Automation Procedures use ‘odsole70.dll’ to interact with COM objects.

The below procedures contain everything we need to carry out a highly sophisticated attack interact with other COM objects:

sp_OACreate – Creates an instance of an OLE object.
sp_OAMethod – Calls a method of an OLE object.
sp_OAGetProperty – Gets a property value of an OLE object.
sp_OASetProperty – Sets a property of an OLE object to a new value.
sp_OADestroy – Destroys a created OLE object.
sp_OAGetErrorInfo – Obtains OLE Automation error information.
sp_OAStop – Stops the server-wide OLE Automation stored procedure execution environment.

Practical Usage

Here are a couple of examples for practical usage of attacks using the OLE Automation.

Example #1: Interact with “filesystemobject” COM object:

In “A Deep Dive into Database Attacks [Part II]”, we saw how it is possible to write files by interacting with the ‘filesystemobject’.

But the ‘filesystemobject’ COM object allows us to do much more than that, we can copy files, manage drives, and much more.

For the full list of the ‘filesystemobject’ methods from Microsoft documentation click here.

The below example describes a method used by the attacker to copy executables in different names and locations in order to avoid detection. This technique allows the attacker to stay under the radar in the case that there is a security policy in place. Also, it makes the post mortem analysis more complicated:

Figure 1: copy ftp.exe and cacls.exe executables with different name and location.

Example #2: Interact with “ScriptControl” COM object:

ScriptControl allows us to actually run a scripting language such as VBScript or JavaScript from within our SQL Server. This is one of the strongest abilities of the COM objects.

More information about the ScriptControl COM object, methods and properties can be found here.

Here are two practical examples of using the ScriptControl method. The first to create an account and the second is to download malware:

Creating an Account

In the example below, the attacker uses JavaScript to create an account, change its password and add the new account to the administrators group:

Figure 2: Attacker creates a Windows account, changes its password and adds it to the administrators group.

Download Malware

The next example shows how to download malware from a remote server, save it to a file, and execute it:

Figure 3: Attacker downloads malware from remote server.

Example #3: Interact with Windows Management Instrumentation (WMI) COM object:

Windows Management Instrumentation (WMI) is the infrastructure for management data and operations on Windows-based operating systems.

In the next example, the attacker allows full access to everyone to use Windows Script Host, which allows them to execute scripts in a variety of languages.

Note that since this action is performed from inside the SQL Server process, the action will have the SQL Server security context.

The steps taken by the attacker to achieve full access:

1. Using the ‘SWbemLocator’ object to connect to the local WMI server.
2. Then the attacker retrieves the security settings for ‘wscript.exe’.
3. Create an empty ‘SecurityDescriptor’
4. Sets its permission to ‘SE_DACL_PRESENT’
5. Set the ‘wscript.exe’ security settings to the newly created security descriptor.

The description of the ‘SE_DACL_PRESENT’ permission from msdn:
“Indicates an SD that has a DACL. If this flag is not set, or if this flag is set and the DACL is NULL, the SD allows full access to everyone.”

In this case the DACL is not set on creation, therefore the security descriptor will allow full access on wscript.exe to everyone.

Figure 4: Attacker leverages WMI to set permission on executable.

For more information about the ‘SWbemLocator’, ‘‘SWbemServices‘’ and ‘SecurityDescriptor’.

Prevention

Disable Configuration

It is recommended to disable the option to use those SQL Server abilities:

Figure 5: Disable the OLE Automation features of SQL Server.

Remove Execution Permission on Extended Procedures

Another method to make sure that those powerful procedures are not being used is just dropping them:

Figure 6: Revoke EXECUTE permission on dangerous functions of SQL Server.

Better Safe Than Sorry

Since OLE Automation is a built-in feature, there is no actual way to prevent the activation of the feature. It is recommended to add monitoring for the events of re-enabling the configuration & recreating the extended procedures and granting execution on the procedures.

Summary

Once an attacker gains access to the database it won’t necessarily stop there.

Many known cases are published where after exfiltrating data from one database the attackers decided to become “residents” inside the organization network, make a lateral movement and exfiltrate data from more than just one database. Learn more about attacker types and data breaches in my blog “Know your enemy! The four types of cyber attackers trying to breach your security today and the white paper Lessons Learned From Analysis of 100 Data Breaches”.

We saw how the attacker was able to change the executables permission on the OS, copy and manipulate OS files to stay undetected and finally deploy malware and execute scripts on the victim server. The attacker made everything from inside the SQL Server service without actually having access to the OS, but still had a deep impact on the underlying OS configuration.

The OLE Automation is a very powerful feature, which makes it very dangerous. If you are not using OLE Automation, it needs to be disabled. Disabling unnecessary features in the database will reduce the attack surface.

Imperva offers different products to help our customers to protect against database attacks, for on-premises and cloud services. For more information visit the following link.