BSides Rhode Island presentation and slides

Over this weekend I went to BSides Rhode Island to give a presentation about the research I’ve been doing in regards to WordPress plugins. The video can be found here, thanks to Irongeek.

I promised at BSides to release my slides and some of my code. So without further ado, here’s the presentation file: Large-scale application security

And here is the code:

Thanks to the team behind BSides RI for giving me the chance to present my technique and research used for finding these vulnerabilities. I’d encourage anybody to not only go to a BSides near you, but also have a go at finding vulnerabilities in WordPress plugins. It’s a ton of fun!

CVE-2013-2692 – Or when your OpenVPN is a bit too open





When analyzing the OpenVPN Access Server, it quickly became apparent that the administration interface lacked any basic level of CSRF protection, which was easily demonstrated with a CSRF form like this, which will add a new user with admin privileges, using the username “csrfaccount” and password “qweasd”:

For this to be effective, we need to ensure that the server is configured to use “Local” authentication. This means OpenVPN controls the authentication, rather than using PAM/RADIUS/LDAP. We can do this with these two simple requests:

When we have changed the authentication method, we need to commit the change:

If we do a CSRF attack against a target using these 3 requests(Which can be done with the method described in my post about multi-stage CSRF attacks), we can then authenticate to the OpenVPN AS admin interface using the account details csrfaccount/qweasd. This further allows us to take over the server.

Conditional CSRF – Or how to spray without praying

A part of the goal of my latest project, WordPress CSRF Exploit kit – A novel approach to exploiting WordPress plugins, was to show some novel techniques that I’ve been picking up on in terms of exploitation of web applications and delivering payloads in neat ways. One goal specifically was to deliver an array of different potential payloads depending on specific conditions and not spray and pray. The one that is the most obvious, is whether or not the target has a specific plugin installed. My approach ended up being a somewhat obscure but neat one that others have documented before. Specifically, the onload/onerror attribute on certain HTML elements that pull in outside resources. Lets deconstruct a landing page as you’d see it from the above project:

What we can observe here is a bunch of different image/script tags all pointing to a potential file existing on a remote system which belong to a specific WordPress plugin. In the event that the plugin is not installed on the host, nothing happens. We’re not loading them for display as I’m sure you guessed. Rather, we’re hoping to get the onload attribute invoked, which contains some convenient javascript of ours.

In the event that the vulnerable plugin is detected, in this case we redirect to a page that contains our actual exploit payload. This means we don’t have to send all possible payloads at once, but can have some obscurity until we know we can hit something interesting. Or in other words, you can spray a target and not have to pray that your exploits work, because they won’t trigger unless a target has the plugin you’re targeting.

This approach is not new, as it has been used in the past for things like trying to resolve different host-names/ip/port ranges on an internal network through a hooked browser to scan for other web applications to target. In this case, we’re using this approach to detect the presence of a vulnerable plugin on a, granted that it’s a pre-determined, target. By being able to not have to do up-front poking at a running system, we’re able to achieve a lower turn-around time on delivering a payload that either hits a target or simply just does nothing.

So there you have it. This is probably not an useful approach to take in all cases where you exploit a CSRF vulnerability. But it’s still an interesting approach and hopefully will inspire others to consider thinking about being more sneaky(Don’t spray and pray!) in their exploitation attempts and make full use of the wonderful things HTML and javascript offer you!

WordPress CSRF Exploit kit – A novel approach to exploiting WordPress plugins

Over the last few weeks I’ve been on roll with finding CSRF vulnerabilities in WordPress plugins. That’s all nice and good, but when you’ve got 30 of them, it’s a shame to not take it a step further and show the dangers of them! This project is solely designed to show off a few random thoughts of mine, and most importantly to hopefully inspire others to think along these lines. This project is solely meant for educational purposes, not attack against running services or people.

The project shows a few basic concepts in regards to the process of pulling off a CSRF attack against a large number of WordPress sites. Some things worth pointing out:

  • It’s not designed to simply spray and pray. You define the target URLs you want to hit and then you have an unique URL for each blog you can go phishing with.
  • Then it will use the onload function of an img or script tag to detect the presence of the vulnerable plugin on the target blog on request through the unique URL pre-defined
  • We generate the payload on request with an uniquely identifying URL to ensure it’s not easy to extract the exploits.
  • You get max 2 requests to the script per IP. That is all a compromise needs. After that, you get nothing back. Makes it harder for researchers life
  • We deliver a beef hook. Because beef is cool and god damn tasty

I want to stress especially the “novel” use of the onload function of img/script tags. People in the past have used it to detect the presence of different host-names/”port scanning” internal systems by vectoring through a hooked browser. I say that’s cool and all, but you can take that further and use it to detect the presence of a plugin on a target on demand, making you able to be much more sneaky. When the markup detects a plugin present on the target, it redirects the browser to the exploit, and no further requests can be made by that IP to the script.

A normal series of events would be:

  1. An attacker sets up this script with pre-defined targets(targets variable) with an unique URL for each target blog
  2. The attacker then spams out a link to the running script with the unique URL for each target blog
  3. When a target clicks the link to this script, we validate that the URL contains the unique identifier that resolves to a blog URL
  4. The script the generates a random URL for each exploit we have with the target blog URL put in that can then be requested
  5. We output to the user a series of img/script tags with onload attributes that redirect to the unique URL generated in step 4. These tags look for specific plugins on the targeted blog
  6. If none of the plugins are detected on the blog, we redirect to google
  7. If any of the plugins are detected, we redirect to the uniquely generated URL made in step 4
  8. The exploit is now written out to the user, submitting the CSRF with a XSS payload pointing to our beef instance
  9. We now delete all cached exploits made for the requesting IP

There’s a number of improvements that could be made to this. It could be designed to spray and pray through iframes, but that is much much dirtier, and not the goal of this proof of concept. I urge anybody who finds the concept to be useful to run with it if they so desire. I’ll be adding more exploits as advisories are published. Otherwise, I’m curious to hear people’s thoughts on this.

Vulnerability chaining, magic quotes bypass with hexadecimal literals and data exfiltration

I have a pet peeve. It’s when people argue that vulnerabilities that exist in an administrator interface, though not inherently critical, does not need to be fixed. Many administrator interfaces assume that if a user has access to it, the user can be explicitly trusted. And that leaves entire applications at a risk that’s easily fixable, yet developers refuse to acknowledge this.

A such example is what I’m going to talk about in this blog post more in depth. I already showed an example of a similar issue over here. But what happens when you take this sort of triple-joy attack further to its logical conclusion? First though, let’s take a look at the WP Easy Gallery plugin!

SQL Injection analysis
I first came across this issue through some tools I coded to discover extremely obvious vulnerabilities, which exist all over. It alerted me to the fact that there was a good likelihood of a SQL injection condition existing in the /admin/add-images.php file. Let’s look!

It pulls either the “select_gallery” or “galleryId” POST parameter. That’s then passed to two SQL queries without being cast to integers. That’s clue 1 right there that this is something we need to dig a bit deeper into. The file name is a clue that these pages are most likely not publicly accessible, as well as that there’s a check at the top of the file to ensure the file isn’t called directly. So this relies on somebody having access to the admin interface. And the admin needs to be silly enough to insert SQL into a query string parameter, but only blindly. We need to now establish whether or not the SQLi is blind or not.

A good clue is to grep the file for echo statements. Here are some examples:

Bingo! Our injection vector is not blind. And what is more, keep in mind for later that no output encoding is done. This is important.

CSRF vector
Without access to the WordPress administration interface directly, there’s a few means which we can achieve the delivery of a payload to exploit the SQL Injection vulnerability. Given that we need to deliver the items through the POST variables, we have to evaluate the application for the absence of any mitigation against CSRF attacks. In theory, a CSRF attack should be impossible. In reality though, many WordPress plugins do not CSRF protect their admin interfaces despite WordPress offering a very easy way of mitigating the attack.

Evaluating this for this attack vector can either be done by sampling a request with Burp Suite Pro and have it do the boring work of generating the appropriate form(Can be done by hand easily), or reading the code and see if there’s any actual CSRF tokens being inserted and validated anywhere that could be a kill joy for us. As it turns out, there’s a complete absence of this. So we now have a delivery method for a payload that could execute some arbitrary SQL and show the result to the user. But just outputting the list of users and their password to the admin user is rather boring. We need to find some way of exfiltration this data to us.

Data exfiltration through XSS and magic quotes bypass
Remember back how we determined that the SQL results was in no way output encoded. It’s presumed of course that any data in the database was input by the admin, and as such completely not dangerous. What dangerous content can you possibly get from an integer column that auto-increments automagically? As it turns out, this is critical for turning this vulnerability into a beast.

We can’t possibly hope for the admin user to email us the result of the SQL injection output. So we need to somehow use the fact that we control the output of the SQL query to our advantage, and the fact that we can mostly unhindered write anything to the rendered page of the admin is a good start. So if we were able to put in either some JavaScript that’d infiltrate data for us, or a simple img tag which causes an external request, we can achieve our goal. Of course, the one thing that stops us is this pesky thing called magic quotes. We could try and put in some HTML into our SQL query, but if we have to use characters like quotes, magic quotes will make that a no-go. But what we can however do, is use the hex-literals feature that MySQL kindly offers us.

If you’ve never encountered hexadecimal literals before, you can try and neat little experiment in MySQL like this: SELECT CONCAT(“foo”, 0×626172). This will output the string “foobar”. You can check out why by playing with the HEX and UNHEX methods, which will give you the hexadecimal values of different values. But slapping 0x in front of those values, it’ll act as if a string or integer for all intents and purposes. This offers us the wonderful ability to input arbitrary characters into a query using only hexadecimal digits(0-9 and A-F).

Putting it all together
So far, we’ve determined:

  • The plugin has a SQL injection vulnerability in the administrator interface
  • The SQLi is not blind
  • The output from the query is not output encoded
  • The plugin does not protect against CSRF attacks

So we need to create a CSRF request which contains an image tag which contains an URL to a server we own, where the output of the SQL injection is in the src of the tag as a part of the query string. A bit of stitching together a CONCAT statement by encoding the HTML we need using HEX(), we end up with this result:

With that, we end up with valid rows of “images” in the $imageResults query. When the ID parameter now gets output onto the page, we now have a HTML tag for each user on the site, like this:

When the page then renders, the image tags will try and fetch each of these URLs. Given that you own the domain contained in the injection, you can now fetch the HTTP logs and now you have a full set of hashes for the WordPress installation. Game over!

WordPress Advanced Custom Fields remote file inclusion vulnerability


Secunia Advisory SA 51037

Analysis of vulnerability
A Remote File Inclusion vulnerability exists in the Advanced Custom Fields plugin for WordPress. By exploiting an unsafe use of array_merge which takes user-input in /core/actions/export.php, it is possible to override a value used for an include:

By posting another value for acf_abspath to the script, we can overwrite the value which is used for the two require_once calls. For instance, we can make a request like this which will request /wp-load.php and /wp-admin/admin.php from


Two-stage CSRF attacks

This week I ran into an interesting problem. I was doing some poking around with my DLink DIR-615(EU) router while working on some firmware reverse engineering. It occurred very quickly to me that the router had no protection against CSRF attacks. As with many other routers, the router also doesn’t enforce you to set a password for the Admin account, which simply sets it up for getting owned.

As it turns out, the vulnerability I found was already well-documented, but I saw no exploit which targeted both the CSRF attack and the default weak credentials in a single exploit. This would be needed for even a semi-reliable exploit to be delivered over the internet. I wondered why, and started investigating what would we required.

The target

The DLink DIR-615(EU) runs on a default IP( with default credentials being the Admin account with no password. The authentication system is kind of funky, in that on a successful authentication no cookie is set. Rather, it simply authenticates your local IP. I’ve not dug into this much further, but the short version of this story is that you either have to hope that the user has authenticated against the router somewhat recently, or you need to authenticate as a part of the attack.

The two requests we need to make to log in and do something to abuse this CSRF, such as change the admin password and enable remote management, are as following:


 The problem

In order to get a reliable CSRF exploit for this, we’d really like a single page we can send an user to, and it takes care of making these requests to do the exploit. But this turned out to be not quite so easy, and googling turned up very few suggestion for how to make several requests in order and time them correctly to allow authentication before the CSRF attack request. Here were some of the ways I tried:

Failed solution 1: A single page with 2 forms, calling document.formname.submit(); in sequence

This didn’t work. What ended up happening is that the login form wasn’t submitted. Also because we submit the form, we end up with the problem that the browser navigates to action URL. This is because of the default target of the form(_self).

Failed solution 2: A single page with 2 forms that has a target _blank or an iframe

Given the navigation issue I encountered in my first attempt, I started testing out how the target of the form affected things. As it turns out, modern browsers are really not big fans of iframes or new windows. Targeting a frame simply didn’t work. And when you use _blank as a target, the user has to explicitly allow it in modern browsers. In order to exploit this reliably, we can’t rely on user interaction.

Failed solution 3: XMLHttp requests

AJAX is wonderful. So I figured why not try and come up with a solution using XMLHttp and a bit of Javascript. This fell flat very quickly, as XMLHttp respects same origin policy.

The solution

A solution to this would require following:

  • Control of timing between requests
  • To still have control of the page the user loaded, even if the form navigates to a target.
  • No popups
  • Little, if any, indication to the user that their router is being owned

My solution ended up being a bit less neat. However it works quite well against any default browser without any noscript and such(Which would break most CSRF attacks requiring to post, unless you want to rely on user input). It’s quite a bit along the line of the idea of setting each form target to a different frame. But since I couldn’t get them to target an iframe in a single page, I split the payload into 3 parts.

  1. Landing page with 2 iframes, each containing their own payload
  2. A login request
  3. A delayed CSRF attack against the vulnerable page as desired

The main landing pages is quite simple, as it just loads each page for execution:

By setting the width and height, all you’re left with is a tiny dot on the screen. This could be mitigated by doing some styling potentially to render it off screen.

Second step is to log in. Here we rely on the fact that the admin user by default does not have any password set.

Nothing fancy really happens here. We just have to make sure that the user is authenticated for our second stage, which is the CSRF attack which exploits the real weakness in the router:

The key here is that while the first login iFrame is loaded straight away, we have to wait to make sure that the request happened. This could be anything from 5ms to a second. In this case, we wait 5000ms to be safe. This could likely be lowered a lot.

This was validated against the EU version of the D-Link DIR-615 with 8.0A firmware. And while it probably could be optimized quite a bit and made a lot prettier/subtle, it addresses something which I couldn’t find a solution to easily on Google/WAHHv2. This could potentially be a lot simpler against a target that accepts a GET requests to do the same. But this will work for both by simply changing the method in the form.