I discovered Ghostery in the summer of 2012, when I was researching web-tracking and specifically web-tracking done through web fingerprinting. Ghostery is a really cool browser extension which helped me identify the domains that popular web fingerprinters used to deliver their code and thus allowed me to isolate and study the fingerprinting code. You can read all about that in our paper titled: “Cookieless Monster: Exploring the Ecosystem of Web-based Device fingerprinting“.

Since then, I’ve installed Ghostery in all my browsers and use it to quickly find out which third-party trackers, each website uses. For those of you who don’t use Ghostery (you should definitely check it out after you finishing this post), Ghostery will match network requests and JavaScript/HTML filepaths with third-party-tracker blacklists and notify you when it gets a match. It also has the ability to block specific trackers, from running altogether.

For instance, on my page, securitee.org, I am using StatCounter, a third-party web-analytics framework which fits the definition of what someone would call a third-party tracker. Thus, if you visit my site with Ghostery installed, you will, by default, get a pretty purple box as follows:

Ghostery’s purple box

Today, while searching for something completely different, I realized that the way this works is that Ghostery adds a div element (styled as purple box) in the DOM of the webpage. After a couple of seconds, Ghostery automatically deletes the purple box, so that it doesn’t annoy the user. So, just for a few seconds, the page’s DOM contains one of those:

What this means, is that there is a window of time in which the visited webpage has the ability to find out whether the current user is using Ghostery or not, and also to manipulate the contents of that purple box.

Why should I care?

There are many reasons why a dodgy site would want to be able to detect Ghostery and thus many reasons why you should care. For instance:

• Fingerprinting. Now, the site knows that you are one of the, say 700,000 users that use Chrome and have Ghostery installed. While this may seem like a lot, Chrome currently has more than 50% of the browser market. Thus, with such a simple trick, we are narrowing down from hundreds of millions to less than a million users. Combine this with other vectors (e.g. screen size, plugins, and fonts), and you are more unique than you would expect. If you don’t believe me, check out Panopticlick and then read our paper
• Misguiding. Some sites have a list of third-party trackers that almost matches the height of your screen. The ability to modify, or altogether hide, that tell-tale purple box can be very appealing to them. I want to be fair here and say that Ghostery is also using a dedicated box (shown when you click on the little Ghost next to the status bar) which cannot be touched by JavaScript running in the page.
• User Discrimination. If a company really, really, wants to track you, and they detect the presence of Ghostery, they may do all sorts of evil things. For instance, they could on purpose break the page so that you attribute the broken functionality to Ghostery rather than to the page itself.

Detection Methodology

There are probably many elegant ways to detect that Ghostery <div>. I, however, never claimed to be elegant . What I did, is I wrote a small function that is called many times per second, which bruteforces all the possible identifiers of that div element. While this sounds like a lot, it isn’t. I noticed that all purple boxes have an id equal to “ghostery-alert-X” where X is an integer from 1 to 9999. Once the page starts, the function will keep on trying to find the ghostery <div>.

var tries = 0;
var int_id = window.setInterval(function(){
     for(var i=0; i < 10000; i++){
           var cid = "ghostery-alert-" + i;
           var purple_box  = document.getElementById(cid);

            //Ghostery installed
            if (purple_box != null){
                //Do dodgy things

                window.clearInterval(int_id);
            }
            else if(tries >= 1000){
                window.clearInterval(int_id);
            }
     }
     tries += 1;
 },10);

Since I’m running this code every 10 milliseconds, I am also purposefully deleting the function after 1000 tries (should be about 10 seconds) so that it doesn’t keep on polling the user’s browser for ever.

If there is a purple box, this script will find it. As I mentioned earlier, you can do all sorts of things once you find it. Since I am not an evil guy, I decided to just make my mark and leave it at that:

Hijacking the purple box

Interestingly, in Firefox, the div has a static id equal to “ghostery-purple-bubble” which makes the whole thing trivial (and me kind of sad…).

What can be done?

If Ghostery decides that, that purple box is a must, then it will need to be recreated using a background page of a Chrome extension instead. Sure, it won’t be floating as nicely on the page, but it wouldn’t be detectable (at least in this way) from an “inquiring” page. As a matter of fact, Ghostery already has such a page which appears when you click on the little blue ghost (giving you many more details for each tracker), so maybe the purple box should go, altogether. I cannot predict whether tracking companies will pick this up, but if you want to make sure you can, for now, manually disable that purple box.

Conclusion

I want to repeat, once again, that Ghostery is an awesome tool (I use it daily and I will keep on using it) and thus this post is not meant to be a criticism towards it. I am merely pointing out how minor choices done in a browser context (e.g., “Wouldn’t it be nice to add a small floating box?“) can have later repercussions that may negatively affect a user’s privacy.

Till next time

Nick Nikiforakis

In this post, I want to summarize the findings of our remote inclusions study so that you can get a glimpse of the size of the problem and hopefully get curious enough to read our 12-page paper So, about a year ago we were concerned that web-site administrators are including JavaScript code from remote-sources without too much thinking. This can lead to issues because:

1. The remotely included code can be buggy and you are thus introducing vulnerabilities to your own site, when you choose to include it
2. The remote host can be malicious and use its scripts to attack your users and exfiltrate data from your site
3. The remote host can be targeted by an attacker, as a way of reaching a harder to get target (e.g. your page)

This lead us to conduct the largest, to-date, web crawl with a focus on remote JavaScript inclusions. Based on the top 10,000 Alexa sites, we crawled over 3,300,000 pages and recorded approximately 8.5 million remote inclusions. The findings that I want to share with you, in this blog post are the following:

1. Even though most sites of the Alexa top 10,000 include code from up to 15 remote hosts, there are sites that include code from up to 295 remote hosts. Assuming that only one of these hosts is enough to fully compromise your script-including site, trusting almost 300 of those is, at the very least, worrisome
2. As far as remote inclusions as concerned, Google is king, owning 5 out of the top 10 most included scripts found in our study
3. Certain web-tracking and market-research companies (like addthis.com and scorecardresearch.com) have crept their way into the 10 most popular remotely-included JavaScript scripts. This should raise some eyebrows, since these are sites that most users have never directly visited and are not aware of their existence.
4. A large percentage of JavaScript providers seem to not be too interested in keeping their software and servers up-to-date. This can be problematic, when a motivated attacker targets them and if you include code from them, they are essentially the weakest link in your security chain.
5. In our logs of remote JavaScript inclusions, we found the following, previously unknown, vulnerabilities:
   • Script inclusions from locahost: We found over 130 script inclusions which were requesting their “remote” JavaScript from localhost or 127.0.0.1. What this means, is that a user’s browser will try to fetch the necessary JavaScript code from the user’s own machine. Couple this, with multi-user systems, where users have the ability to run web-server processes (think smartphones) and you have a recipe for disaster. A malicious user can poison the vulnerable page by providing malicious JavaScript for all these requests. We called these Cross-User Scripting attacks
   • Script inclusions from private-network IP addresses: Same as above, but now the site tries to include code from hosts such as “192.168.1.1″. This means that the attacker now just needs to be in the same local network (Cross-network Scripting).
   • Script inclusions from non-registered domains: This is one of my favorites. We found 56 domains that were supposedly providers for JavaScript, but they were not registered!!! This means that an attacker can simply register a domain and start providing malicious JavaScript to anyone who requests it. We registered two of these and recorded about 85,000 requests for JavaScript in two weeks! We called these Stale Domain-name-based Inclusions since these are domains that were once full sites and even-though they expired, other sites kept on requesting scripts from them.
   • Script inclusions from non-responding IP addresses: Addressing a remote host directly by its IP address means that if that host gets assigned a new IP address, you should update your records. We found some interesting cases of sites requesting JavaScript from IP addresses that did not even have a web server listening on the appropriate port. While harder to exploit, an attacker who gets hold of a particular IP address will be able to inject code on the victim pages (Stale IP-address-based Inclusions)
   • Script inclusions from typosquatting domains: That’s probably my favorite one We found some unregistered domains that were actually mistypes of the intended domain (e.g. googlesyndicatio.com, missing the final n). We realized that the developers messed-up when writing the script inclusion and requested code from the wrong domain. By registering googlesyndicatio.com, we actually recorded more than 163,000 requests for JavaScript in two weeks! This goes to show that developers, like all others, are also prone to misspell domains. These misspellings however have the potential to cause much greater damage than a user’s mistypes in her own browser. We called this attack Typosquatting Cross-site Scripting(TXSS).

In total, we found that there are many ways for an application to be attacked based on a remote JavaScript inclusions. In addition to all the findings mentioned above, we also studied script-inclusions over time and we evaluated the practicality of two straightforward countermeasures, i.e., coarse-grained sandboxing and local script copies, and showed how feasible (or not) is each one, given the current popular scripts of the web.

Check out our full paper for all the juicy details
Till next time

Nick Nikiforakis

Specifically, when you upload a picture, you can share it with your friends or groups of friends who also need to install the special plugin in order to view your picture. Once they do, the picture is visible, but! McAfee claims that you can’t save it on your computer or take a screenshot and then paste it in an imaging program. Naturally, I wanted to put their claims to the test

I started by uploading a picture of myself and sharing it with myself . Then I tried to right-click on the image but I couldn’t get the usual image dialogue. Next stop, “Print Screen”. Here’s what I got when I pasted the contents into mspaint.

First screenshot using “Print Screen”

I used Window’s 7 preview on the bottom, so that you can see that we are indeed on McAfee’s application page on Facebook. Then I tried going back to my slashdot tab and taking a screenshot of that.

Print-Screening Slashdot doesn’t work while my McAfee tab is open

Unsurprisingly, McAfee’s funky plugin starts messing up other tabs. In order to get your print-screening abilities back, you need to close their tab and then either resize your browser or minimize it and then maximize it (otherwise the blackness remains put).

So, ok you say, it kind of sucks, but what about breaking it? Well, I am not good at reverse-engineering binaries so reverse-engineering their plugin was out of the question. I started experimenting with moving the browser to various places of the screen or maximizing and then immediately hitting “Print Screen”. None of them worked… and then.. lightbulb! I remembered that there are screen-capturing extensions for Firefox.So, I installed Abduction! and tried again.

Here is the extra menu item when I right-clicked on McAfee’s page:

“Save Page as Image” option by the abduction plugin

I clicked it, chose the part of the image that I wanted to capture and then saved the resulting file to my desktop. Result?

Success

You see my smile? This, is the smile of success! Of course, you can save just the picture, but I wanted to show that it is indeed McAfee’s page on Facebook.

Conclusion

If it comes to your computer, it’s yours

Cheers
Nick

AdChoices "pledge"

So, the important points of the above text are:

“It’s our goal to make these ads as relevant and useful as possible for you. Google doesn’t create categories, or show ads, based on sensitive topics such as race, religion, sexual orientation, or health. ”

Sounds reasonable. Let’s see the ad that actually got me here.

An AdSense ad about dating, based on religion, while watching a video-clip from a popular Christian band

One can claim that the ad is targeting single people, but it is actually targeting the intersection of Christian and Single, thus effectively targeting both.

Google, don’t be evil.

Now, in Chapter 9, he talks about “Content Isolation Logic” and in one specific section he touches on the document.domain property of the DOM of a page. So, in short, when two pages, foo.example.com and bar.example.com want to communicate through JavaScript, by default they cannot since the Same Origin Policy allows accesses only when the protocol, domain and port fully match. Since, “foo.example.com” !== “bar.example.com” the check fails and thus the domains can’t communicate. Since this is somewhat too rigid, a developer can choose to relax the domain of his page from foo.example.com to example.com. In JavaScript, this is a simple assignment to the document.domain property:

document.domain = "example.com";

If both pages first do the same relaxation and then attempt to communicate (e.g. read each others’ cookies, read content in the DOM and add/remove nodes) all is well. Now obviously “foo.example.com” can’t relax its domain to “www.google.com“. The new relaxed domain must be a higher-level domain from where it already is. For the same reason, the page “foo.example.com” can’t relax its domain to “foo.foo.example.com” since that is not really relaxing

Relaxing more than you should

Now, as a web developer you have about a thousand ways in which you can screw up the security of your site. One of them is to relax your domain too much. What would happen if “foo.example.com” relaxes its domain to “com“? That is a valid higher-level domain after all. Well… there is no good reason for a person to do that, other than a severe misunderstanding of how the whole thing works. For this reason, all modern browsers disallow the setting of document.domain to a TLD value… well, all except Chrome that is.

I decided to make a simple experiment. I resolved locally two domains, myattacker.com and myvictim.com. myattacker.com first relaxed its domain to “com” and then loaded myvictim.com in an iframe which also wrongly relaxes it’s domain to “com”. A short script in myattacker.com attempts to reach in the iframe and read the HTML of the body of the loaded page, containing a secret value. If it succeeds, it dumps the contents of that iframe in its own page.

Testing the browsers

So, we start with Firefox, version 10. Here is a screenshot of the page:

FF stops the scripts from setting their domain to a TLD

As it should be, Firefox says no and the earth keeps spinning. How about Internet Explorer, the usual black sheep of the web?

Who would have thought? Internet Explorer 8 doesn’t like the thing…

Opera?

Opera, as expected, blocks the TLD domain set

How about Google Chrome (version 18.0.1025.108 beta), the source of all sunny, funny and nice?

Aha! And that’s how the cookie crumbles. Chrome says “sure, go on” and the attacker reaches in the victim’s iframe. Game over! This behavior can also be abused to hack a site that’s vulnerable to XSS. Instead of injecting the full malicious payload, you simply relax its domain and then proceed to inject code which will never be visible at the server-side of the vulnerable Web application, thus making detection and mitigation much harder. More on that, here.

Closing words

Now why is that, you may ask? These guys implement process per tab, client-side xss filters and what not, to protect the user from harm, even if it is the fault of a specific website. Short answer, I don’t know. The argument that changing it is hard, seems a bit flimsy to me, especially given Google’s prior engineering track record.

Till next time

Nick Nikiforakis

Suppose for a second that you are a loyal customer of babyhow.com, an eshop selling stuff for your baby. One beautiful day you receive an email letting you know that babyhow.com has moved its business and providing you with a link to read more:

http://www.babyhow.com/We_Have_Moved?%27%7d%3b%7d%74%6f%70%2e%6c
%6f%63%61%74%69%6f%6e%2e%72%65%70%6c%61%63%65%28%27%68%74%74%70
%3a%2f%2f%77%77%77%2e%63%6e%6e%2e%63%6f%6d%27%29%3b%66%75%6e%63
%74%69%6f%6e%20%64%75%6d%6d%79%28%29%7b%76%61%72%20%66%6f%6f%3d
%7b%31%3a%27%31%a

If you’ve read more posts from my blog you already know that the fact that I am hiding something from you by turning it into hex isn’t a good sign. But suppose, that you don’t know that. You click on that link, expecting to read more (copy-paste the thing and try it…its fun, I promise ). For a second you see the banner of “Bluehost.com”, a cheap shared hosting business which claims to host “millions of domains”. A second later however, you are suddenly at the main page of cnn.com. What happened? Welcome to the world of open redirects… with a twist.

Open redirects

According to OWASP, an open redirect is “an application that takes a parameter and redirects a user to the parameter value without any validation. This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it.”

Sounds dangerous, doesn’t it? Now you may think… these stupid people at babyhow.com should fix their stuff. But you’d be wrong. Babyhow.com doesn’t have an open redirect. Its their hosting provider that has!

Ads instead of errors

I recently realized that the majority of the cheap and popular shared hosting companies (verified on bluehost.com and fatcow.com) are a bit sneakier than they should be. By default, when you host a website on their servers and a user requests a page that doesn’t exist, instead of sending a vanilla 404 message, they decide to capitalize on the opportunity and serve some ads while they’re at it.  Look what happens when I ask for http://www.gordonpage.net/i_dont_exist, a domain hosted on fatcow.com and a non-existent page:

I am pretty sure that Mr. Page doesn’t know that his site is serving random ads. If he did, he would have disabled this default behavior. To add insult to injury, the script responsible for creating the iframe that displays the ads, uses the URL of the error page in an insecure way, allowing an attacker to inject arbitrary JavaScript code. The only downside is that the injected code runs within the iframe and thus you can’t access resources of the site (like session cookies). What you can do however, is redirect the whole browser to a destination of your choice. In my earlier example, the injected code was redirecting the user from babyhow.com to cnn.com, but think in terms of phishing credentials or brand wars and you get the point Here’s the link that I showed you earlier without the use of hex:

http://babyhow.com/We_Have_Moved?'};}top.location.replace('http://
www.cnn.com');function dummy(){var foo={1:'1

Big picture:

If you are using a cheap shared hosting provider and haven’t changed the default way of responding to 404 messages, your site is most likely “hosting” an open redirect that can damage both your business and your users. The sad thing is that it isn’t even your fault… its your hosting provider’s fault that tries to squeeze every last penny out of you and your visitors.

Till next time

Nick Nikiforakis

On Wednesday night I suddenly received an email that my Bluehost account was deactivated due to “performance problems”. I went to my site and indeed it was down. So that was really a “shoot first, ask questions later” move from Bluehost. I started an online chat session with them where they were telling me that my sites cause performance problems to the Bluehost servers. The first tech support didn’t really know what he was talking about so for about 10′ I was on a wild goose-chase for problems. Finally I thought I knew what had happened. One of my pages performed some logging when it was visited. That file was becoming a bit big, so I thought that, that was the problem. I cleaned up my logs, told them I fixed it and asked them to reactive my account. The guy said sure and he re-enabled it.

Ten minutes later I get another email saying that my account was disabled again. After chatting online and getting nowhere, I decided to call them on the phone (international call to the US from Belgium). Eventually I discovered that the aforementioned logging site became so popular that it was bringing “too much” traffic to their servers (you remember the “unlimited bandwidth” feature, right?). I promised the guy to change the DNS records of that domain to localhost so that traffic would stop reaching their servers. He said “ok” and that I should call them in a few hours to get things re-enabled. While waiting for these two hours to pass, I received another email from my dear friends at Bluehost telling me that they decided not to reactivate my account. I quickly called them and explained that I had already fixed the issue. Their response was that the administrators at Bluehost had reviewed my site and had decided not to re-enable. That was that… no matter how hard I tried, I couldn’t convince them otherwise. To add insult to injury they refused to give me a small migration period, to allow me to take one or two days to find a replacement and then move everything, without all my websites experiencing downtime.

And that was it… I was left high and dry with about 8 sites offline (my personal site, my experiments, my blog and professional sites of friends and family) at 2:30 in the morning. That’s who Bluehost.com are… people who don’t care about you because you are a single guy in a sea of customers. One less fish is not really an issue for them. That’s why I write this post. I promised their representative on the phone that I would do all in my power to let the world know about their shenanigans.

That’s me keeping my promise. My advice to you… don’t choose Bluehost. They are very nice as long as you are within what they consider “normal”. Even if I did do something wrong (which I didn’t), there should still be room for discussion and reconciliation.  I am currently on Fatcow.com . It feels a bit like IPage but it was the best thing I could find in such a short notice. Lets see how they turn out.

Till next time

Nick Nikiforakis

What do you call a woman who first says to you “I love you” but ten minutes later she adds “I actually don’t, but don’t feel bad because I say that to all men”?

Oakland12

Mid-2011 the developers of Firefox decided that allowing the “javascript” directive in the URL bar was being abused by attackers to conduct self-XSS attacks more than it was being used for legitimate purposes. If you are not familiar with self-XSS fear not… they are quite easy to explain.

In short, self-XSS happens when an attacker convinces a user to copy-paste some malicious JavaScript code in his URL bar and hit ‘Enter’. This was used a lot in Facebook, since people there are usually very willing to follow instructions in order to get access to some sort of “video”, or “application” or information about how many people checked-out their profile today. Matt Jones has made a nice video demonstrating the attack which you can check out right here. The effect of this, is exactly the same as an attacker injecting malicious JavaScript by exploiting the usual and well-known XSS bugs (reflected, stored, DOM-based).

Self-XSS before the Internet

Back to Firefox… so Firefox decided to disallow the use of JavaScript in the URL bar. So no more self-XSS right? Wrong! In the newer versions of Firefox, there is a pretty ‘Web console’ which a user can access and type in arbitrary JavaScript that will again run in the context of the current domain.

While people have accepted this, they believe that it is a greater hassle to users who will not do it as easily as they used to do the self-XSS through the browser URL bar. The purpose of this post, is to claim that this is not true.

The ‘Web console’ of Firefox has a handy default keyboard shortcut from which it is accessible: Ctrl+Shift+K. Now compare the list of instructions that an attacker would use to conduct self-XSS in the past, and the list of instructions now.

Old:

New (you can actually follow along):

The only extra action needed to perform the attack is the Ctrl+Shift+K between the selection of the location bar (Ctrl+L) and the pasting of code (Ctrl+V). If anything I would claim that this is a smoother attack because the word “javascript” doesn’t need to be written as part of the malicious vector since the Web Console expects JavaScript and thus doesn’t need to be told: “Interpret the rest as JavaScript”.

In short I don’t  believe that this is a step in the right direction. Call me pessimistic but executing an extra step as part of getting access to “Virtual Carrots” or “Hot girls” doesn’t look like it would stop the kind of people that would fall for this attack in the first place.

Nick Nikiforakis

P.S. Happy New Year!