How to Use OLE Automation to Exploit SQL Server

Preamble

We can evaluate numerous security scenarios as members of the Imperva Research Labs. In this article, we’ll look at SQL Server database security.

Security specialists frequently deploy honeypots and wait for hackers to fall for the bait. Honeypots are pretty valuable since they allow us to study a variety of attacks and learn more about the tactics and techniques used by bad actors to attack databases.

Here’s a look at the current “Database Attack Landscape.” It is a follow-up to Imperva Research Labs’ SQL Server research from 2018. Watch “A Deep Dive into Database Attacks [Part II]” to see their findings. You can see how little the assault landscape has evolved in the last three years in that essay.

We’ll look at how attackers to launch malware, achieve persistence, and take control of a system to join it into enormous botnets or elevate privileges to enter a company’s network.

While other publications focus on the virus itself, we’ll concentrate on the database side of the assault, the dangerous functions, and the capability housed within the SQL Server to communicate with other Windows OS components known as COM objects. WMI, XML, HTTP, WScript, VBScripts, and other processes are examples.

Hackers employ attack strategies that have the best probability of succeeding. The ultimate goal is to have core functionality defined in many versions. It is one of the reasons why we find hackers utilizing the same techniques with minor variations over time; exploit recycling is highly common. Over time, the database attack landscape hasn’t changed much, and exploitation methods rehash.

One such target is SQL Server OLE Automation, a built-in functionality in various SQL Server editions. We’ll go through some of the strategies in detail and discuss how to keep your SQL Server safe from future assaults.

What Are OLE & COM Objects?

Once we’re in the meat of the assaults, we’ll need to familiarize ourselves with specific Windows terminology, particularly OLE and COM objects.

Object Linking and Embedding (OLE) is an acronym for Object Linking and Embedding. It’s a Microsoft-developed technology that allows one application to link things with another. OLE evolved and was reimplemented on top of COM later. The Component Object Model (COM) is a software component interface standard with a binary interface. Said, COM lets one program share its capabilities with other programs.

OLE Automation Procedures

SQL Server’s “OLE Automation Procedures” allow the server to interact with other COM objects using OLE. In terms of data security, this widens the attack surface.

There are many good examples of using COM objects to achieve lateral movement.

This power is supplied simply by enabling the “OLE Automation Procedures,” a risky database setup. SQL Server also includes several enhanced procedures for linking and interacting with COM objects.

Extended Procedure refers to the capacity to run software from a remote location. The OLE Automation Procedures employ ‘odsole70.dll’ to interact with COM objects.

The routines listed below provide everything we’ll need to run a complex assault that interacts with other COM objects:

• sp OACreate — Creates an instance of an OLE object.
• sp OAMethod — Calls the method of an OLE object.
• sp OAGetProperty — Gets the value of a property on an OLE object.
• sp OASetProperty — Modifies the value of a property on an OLE object.
• sp OADestroy — Destroys a previously generated OLE object.
• sp Gets information about OLE Automation problems with OAGetErrorInfo.
• sp OAStop — Stops the whole server’s OLE Automation stored procedure execution environment.

Practical Usage

Here are a few examples of using OLE Automation to perform attacks in the real world.

Interact with the COM object “filesystemobject” in Example #1:
​
We saw how to write files by dealing with the ‘filesystemobject’ in “A Deep Dive into Database Attacks [Part II].”

However, the COM object ‘filesystemobject’ allows us to do much more; we can copy files, control drives, etc.

Click here for a complete list of the ‘filesystemobject’ methods from Microsoft documentation.

The attacker uses the method described below to copy executables under alternate names and locations to prevent detection. If a security policy is in effect, this strategy allows the attacker to remain undetected. It also complicates the post-mortem investigation:

Figure 1: Replace the names and locations of the executables ftp.exe and cacls.exe.

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

We can use ScriptControl to run a scripting language like VBScript or JavaScript within our SQL Server. It is one of the COM objects’ most potent abilities.

Here you may learn more about the ScriptControl COM object, its methods, and properties.

On this are instances of how to use the ScriptControl technique. The first step is to register, and the second is to download malware:

Making a User Account
​
The attacker uses JavaScript to establish an account, change its password, and add the new version to the administrator’s group in the example below:

Figure 2: The attacker creates a Windows account, changes the password, and adds the report to the administrator’s group.

Can download malware
​
The following example demonstrates how to get malware from a remote server, save it to a file, and run it:

Figure 3: Malware is downloaded from a remote server by the attacker.

Interact with the Windows Management Instrumentation (WMI) COM object in Example #3:
​
The architecture for managing data and processes on Windows-based operating systems is Windows Management Instrumentation (WMI).

In the following example, the attacker grants everyone complete access to Windows Script Host, allowing anyone to run scripts in several languages.

The action will have the SQL Server security context because it is conducted within the SQL Server process.

The following are the actions performed by the attacker to gain full access:

To connect to the local WMI server, use the ‘SWbemLocator’ object.
The attacker then retrieves the ‘wscript.exe’ security settings.
Make a new ‘SecurityDescriptor’ object.
Its permission is set to ‘SE DACL PRESENT’.
Set the security settings for ‘wscript.exe’ to the newly established security descriptor.
“Indicates an SD that has a DACL,” according to the msdn explanation of the ‘SE DACL PRESENT’ permission. If this signal is not set, or if it is set but the DACL is NULL, the SD grants everyone complete access.”

Because the DACL was not specified on creation in this situation, the security descriptor will let everyone have full access to wscript.exe.

Figure 4: An attacker uses WMI to set executable permissions.

Disable Configuration

It’s best to turn off the option to use those SQL Server features:

Figure 5: Disable SQL Server’s OLE Automation functionality.

Remove Execution Permission on Extended Procedures

Another way to ensure that those powerful methods aren’t employed is to simply remove them:

Figure 6: Remove the EXECUTE permission from SQL Server’s hazardous routines.

Better Safe Than Sorry

There is no method to prevent OLE Automation from engaging because it is a built-in feature. It’s good to keep track of things like re-enabling the configuration, recreating the extended procedures, and running the methods.

Summary

After gaining access to the database, an attacker is unlikely to stop there.

Many known incidents document where attackers chose to become “residents” inside the organization’s network, undertake a lateral movement, and exfiltrate data from many databases after exfiltrating data from one database. In my blog “Know Your Enemy!” you can learn more about different sorts of attackers and data breaches. The four types of cyber attackers who are now attempting to compromise your security and the white paper “Lessons Learned From 100 Data Breaches.”

We witnessed how the attacker could change the executable permissions on the OS, copy and edit OS files to remain undetected, and then deploy malware and run scripts on the victim server. Without having physical access to the OS, the attacker created everything from within the SQL Server service, yet he nevertheless had a significant impact on the underlying OS settings.

The OLE Automation function is powerful, which makes it extremely risky. If you aren’t using OLE Automation, it should be turned off. Can reduce the attack surface by turning off extra database functionality.

Imperva provides various tools to help our customers defend against database attacks, both on-premises and in the cloud.

About Enteros

IT organizations routinely spend days and weeks troubleshooting production database performance issues across multitudes of critical business systems. Fast and reliable resolution of database performance problems by Enteros enables businesses to generate and save millions of direct revenue, minimize waste of employees’ productivity, reduce the number of licenses, servers, and cloud resources and maximize the productivity of the application, database, and IT operations teams.