Drupal 7 SQL Injection (CVE-2014-3704)

Written on:October 17, 2014
Add One


This vuln has been getting a lot of attention, and rightfully so. The good news is an update is available (and a supplemental patch has been released as well). The bad news is that it’s pre-auth SQLi. The basic problem is the way Drupal core 7.x versions prior to 7.32 construct a SQL query. Contrary to some claims, this is not a flaw in the use of prepared statements/parameterized queries, which are still viable options for preventing SQL injection. The flaw in this case manifests itself before the prepared statement is constructed and executed. Let me show you what I mean…

Basic Vulnerability Overview

The  public function query (found in ../includes/database.inc) looks as follows:

As you can see, it does use a prepared statement but before doing so calls the expandArguments function (also in database.inc). Here’s an excerpt of that function:

Notice how the function parses the $args through the array_filter function before incorporating them into the query via the preg_replace function. This doesn’t pose a problem if the passed arg is not represented as an array with a defined key. For example, during login, the name parameter is passed as follows:


In the case of this login function, the query would be constructed as follows:

SELECT * FROM {users} WHERE name = :name AND status = 1

However, what happens if we were to pass the user parameter as an array with a defined key? Here’s the query after being processed by expandArguments when passing name[0] instead of name:

SELECT * FROM {users} WHERE name = :name_0 AND status = 1

As you can see, it incorporated the key value (0) directly into the sql query (by concatenating it to the parameter name with an underscore). Knowing this, we can inject crafted key values to execute SQL injection attacks. Since the login function is vulnerable, this is a pretty significant pre-auth vulnerability.

Here’s an example of how this could be used to add a user to the database:


Here’s a look at this query before being processed by the vulnerable expandArguments function:

SELECT * FROM {users} WHERE name = :name AND status = 1

And after…

And the result…


This being SQL injection, there are other options for exploit including data extraction. For example, here is an example of a pre-auth inference-based attack that extracts the admin user’s password hash.


Of course, success will depend on flood control and other brute-force protections employed by the site.

PoC Test Exploit Code and Video

Here’s a PoC script if you want to try the exploit for yourself on a test instance. All it does is add an admin user with password ‘pwnd’. There’s really no verification in this basic PoC script that a user is actually added so you’ll need to log in to check. A quick video demo follows.


Here’s a really short video demo of the above PoC code:


So what are the takeaways here? Well, of course upgrade or patch your installation of Drupal if it’s vulnerable. Also, while prepared statements are important tools in preventing SQL injection, they don’t do much good if you incorporate untrusted user input into the SQL query first!

If you haven’t patched yet, you may want to check your logs. The exploit may trigger an error message that looks something like this:



Check your Drupal logs for similar error messages which may indicate attempted or successful exploit attempts and look for any new accounts that may have been created or admin accounts whose passwords may have been changed recently.

Phishing for Shellshock

Written on:October 10, 2014

Introduction I thought I was done writing about Shellshock, but a recent discussion with some colleagues got me back on the topic. We were commenting about how organizations tend to react very quickly to patching external assets for a bug like Shellshock but many probably wait to patch internal assets due to a false sense of security. It got me thinking about how an external actor could exploit a bug like…


Shellshock – Targeting Non-CGI PHP

Written on:September 30, 2014

I’ve seen debates as to whether or not it’s possible to have an unpatched PHP server running in mod_php mode (i.e. not CGI) that is vulnerable to Shellshock. From my testing, the answer appears to be Yes…with some prerequisite conditions. First, the PHP application would have to be using Bash for its system commands — exec(), passthru(), system(), popen(), etc. This is pretty obvious since Shellshock is a Bash-specific vulnerability. Although PHP system command…


The Search For Shellshock

Written on:September 28, 2014

Introduction By now there are hundreds or even thousands of posts and articles about the Bash “Shellshock” vuln and more will be written tomorrow (and the next day …). With that in mind, this post will be fairly short and I won’t be rehashing what shellshock is or why it’s a problem. For that you can simply Google “shellshock” and you’ll find all you wanted to know and more. If you want…


Why Google Makes My Job More Difficult

Written on:September 23, 2014

Let me start this post by saying I’m a huge Google fan. I use multiple Android devices and like many others, I’ve become an avid user of services such as Gmail, Docs, Maps, Photos, and Youtube. I even find myself fondly reminiscing about discontinued services such as Reader. And, if you’re like me, Google search has become an instrumental tool in your professional endeavors. So please keep in mind, this post is…


Windows Exploit Development – Part 7: Unicode Buffer Overflows

Written on:September 3, 2014

Introduction In this seventh installment of the Windows Exploit Development Series, I’ll introduce Unicode Buffer Overflows. We’ll start with a brief introduction to Unicode (what it is and why/how it’s used in Windows) and then jump right in to some example exploits. If you plan on following along, I recommend you have the following: A Windows environment (XP or Win 7 — my demos will be on the latter) Metasploit, Alpha2 or…


Fun With Teensy

Written on:July 21, 2014

Introduction I’ve been wanting to write about the Teensy and its application in security testing or some time now. It’s extremely useful for executing scripts on a target machine without the need for human-to-keyboard interaction. It can be used to bypass auto-run, AV scanning, and encryption policies commonly targeting removable media devices in an enterprise environment. I’ve used it in my security testing to run recon/enumeration scripts, execute reverse shells, exploit local…


Solving the 2014 DBIR Puzzle Challenge

Written on:May 6, 2014

Intro This year’s challenge was quite…well…challenging. Unfortunately Andrij, Will, and I were not able to repeat last year’s win and had to settle for second place. Frankly, at one point we weren’t sure we were going to finish at all, so we’ll take it! Read on to see our approach to finding the clues and solving the puzzle – and all of the frustrating missteps along the way. Day 0…


Understanding WordPress Auth Cookies

Written on:April 20, 2014

Introduction A recently published vulnerability prompted me to take another look at the wp_validate_auth_cookie WordPress function which is responsible for validating authenticated user requests and ultimately controls access to to your WordPress installation. This post is not about that specific vulnerability (more info here) but rather about how WordPress generates and validates authentication cookies to authorize user requests. If you’re a WordPress user, I encourage you to read on to see what stands between malicious actors and…


Windows Exploit Development – Part 6: SEH Exploits

Written on:March 25, 2014

Introduction The buffer overflow exploits covered so far in this tutorial series have generally involved some form of direct EIP overwrite using a CALL or JMP instruction(s) to reach our shellcode. Today we’ll take a look at a different approach using Windows Structured Exception Handling (SEH). Before I begin explaining the basic mechanics of Windows Structured Exception Handling (as it’s implemented in an x86, 32-bit environment) it bears mentioning that…