A Deep Dive into Database Attacks [Part I]: SQL Obfuscation

Today, data breaches are a threat to every organization. According to a report from Risk Based Security covering the first half of 2017, over 6 billion records were exposed through 2,227 publicly-disclosed data breaches. The number of exposed records is already higher than the previous all-time high at the end of 2016.
An organization’s database servers are often the primary targets of external and internal attackers. We recently embarked on a new research project we named StickyDB to learn more about database hacking – understand common database attacks, tools and techniques employed by attackers, how they gain access, what their actions are once inside, what their end goal is and more.
To conduct this research, we established a honeypot net for popular SQL/NoSQL databases like Microsoft SQL Server, MySQL, Oracle, and MongoDB and then monitored access to these databases over a period of six months. To make life easier (and more attractive) for invaders, we configured our database honeypots with weak default credentials and vulnerable web applications at the front-end.

Figure 1: Our database honeypot net (mapped in Shodan)
Among other things, our honeypots “participated” in several wide-spread database attack campaigns like the MongoDB and MySQL ransomware attacks we wrote about last year, which infected tens of thousands of databases.
We’ve broken down our research results into a series of posts. In this first post, we dive into a method used by hackers to access databases called SQL obfuscation. We review what it is, how it works, and the ways attackers use it.

What is SQL Obfuscation?

Being aware of security controls that protect digital assets, attackers in many cases use evasion techniques to go under the radar and mount their attack without being detected and blocked by security mechanisms. One of the most popular evasion techniques, mostly applicable against pattern-based security mechanisms is obfuscation – generating an instance of the attack that does essentially what the attack is intended to do, but is purposely built to look very different from the pattern the security control looks for.
For example, obfuscation of SQL statements (we refer to this later as SQL obfuscation) is very common as a means to bypass web application firewalls (WAF) and execute SQL injection attacks, and to confuse database activity monitoring (DAM) solutions that SQL-parse database traffic. This technique is common among attackers, automation tools and pen testers to implicitly run SQL commands against databases. One of the most common methods to sustain a SQL injection attack is using SQL HEX encoding, where plain text “readable” SQL transactions are converted to HEX characters (0-9, A-F), hence making them unreadable and more difficult to monitor by DAM and database firewall (DBF) solutions. So, a “select * from passwords” in a DAM solution would look like: “73656C656374202A2066726F6D2070617373776F726473”.
While SQL HEX encoding attacks are relevant for all databases, in our research, we focused on SQL Server and MySQL databases.

Patterns of SQL HEX Encoding Attacks

Based on the data analysis, we detected several patterns of SQL HEX encoding attacks. Surprisingly, one out of five attack queries on SQL Server leveraged HEX encoding techniques. This type of attack is less common for MySQL databases.
In this section, we’ll present the common patterns of those attacks, and explain their purpose and structure.

Microsoft SQL Server

The following is the most common pattern of a HEX encoding attack against SQL Server:

In the example above, the attack commands are placed in variable a, when they’re encoded as HEX string. Then obfuscated commands are executed by the exec(@a) statement. Behind HEX-encoded queries we found various types of attacks. We’ll show several examples of such attacks in the ‘Under the Hood of Obfuscated Queries’ section.
Another example of a HEX query we observed in Microsoft SQL Server:

The above Transact-SQL (T-SQL) delivers a malicious payload to a target system. It creates and writes a file (typically an executable or DLL) to a specified location on a targeted system. The attack was accomplished using ADODB.Stream object (which has a class identifier of ’00000566-0000-0010-8000-00AA006D2EA4’) and OLE automation[1] (sp_OA) stored procedures. OLE procedures let you to work with COM objects[2] from within T-SQL. You can use these procedures to create a COM objects and use that object’s methods and properties. For example, use the File System object to open, read and write files directly within T-SQL.

MySQL

Based on analysis of attacks on MySQL, we detected three patterns of HEX-encoded queries. These patterns intended to deliver a payload to a target system through SQL commands.

The collection of commands in pattern 1 and 2 loads a HEX-encoded portable executable (PE) into a table and then extracts it into a file on a targeted system.

The collection of commands in pattern 3, decodes and loads a DLL into a file on a target system. Then, it creates a new SQL function that resides in delivered DLL and executes the function using the SELECT command. This function downloads and saves another executable in a specific location, changes its permissions to ‘777’ (everyone can read write and execute) and finally executes it.

Under the Hood of Obfuscated Queries

We collected and decoded HEX-encoded attack queries with the goal of understanding what attacks are behind the obfuscated queries.
We found that HEX-encoded queries are often used against MySQL and MS SQL Server as advanced binary-to-hex conversion methods to deliver a payload to a target system through SQL commands. Once the payload is on the target system, it converted from hexadecimal format back to a binary executable, and then executed. We recognized different methods of payload delivery and execution. These methods will be discussed in our next blog post.
HEX-encoded queries are also used to modify database security configurations to increase an attack surface. They usually manifest themselves in enabling services and features. The following queries enable advanced options and turn off the default trace. Default trace provides a rich persistent log of activity and changes primarily related to the configuration options. Afterwards they retrieve information about all existing traces using fn_trace_getinfo procedure and then stop them.

Furthermore, we observed attacks on MS SQL which had the purpose of controlling Microsoft-Windows-SharedAccess and SQL Server Agent services via the calling of xp_servicecontrol() procedure.
The attacks stop the Microsoft-Windows-SharedAccess service, which is responsible for Internet Connection Sharing. This action is actually stopping the Windows Firewall.

In addition, the attackers use xp_servicecontrol() procedure to start an SQL Server Agent service which runs SQL jobs that contain further attack commands.

Up Next

SQL obfuscation is just one method used by attackers. With the next posts in this series, we’ll describe remote code execution techniques, the code attackers run, how they cover their tracks, and how to mitigate the risks.
[1] OLE Automation is an inter-process communication mechanism created by Microsoft.
[2]  Component Object Model (COM) is a binary-interface standard for software components introduced by Microsoft in 1993. It is used to enable inter-process communication object creation in a large range of programming languages.