Neither Mozilla nor WebKit folks have felt that this issue merits secrecy, so now that information about it is in the wild, I’ll go ahead and post about a fun new social engineering hack that will probably be making its rounds in the not-so-distant future. The vulnerability is with regards to how easy it is to create a XSS + worm + phishing attack without necessarily triggering a non-technical user’s security alarm.
Step by step instructions on how to recreate this follow, though I have left out sample code (an exercise for the less scrupulous readers).
Instructions
- Create a Facebook group, ‘Get $25 from $BANK’. (This works on any social networking site.)
- Provide simple, easy-to-follow directions that will walk the person through using a “javascript:” URL. We’ll use that to cause the user to create their own XSS hole in the social networking web application.
- Create the worm code to automatically propagate requests to new victims. This code should automatically invite all of the target’s friends to join said group. This has a huge advantage by occurring in a TRUSTED ENVIRONMENT: “Your friend Joe Smith has invited you to join the group, ‘Get $25 from $BANK’.” This is an example of worm code in the wild. UPDATE: Facebook appears to have pulled down the group I was linking to. I’ve got a screen capture, but I’m not sure I want to re-post the worm code.
- Add a script loader into the worm code. Any will do.
- Create a piece of JavaScript with code that replaces document.body.innerHTML with a facsimile of $BANK’s website. Load it with aforementioned script loader.
- People will join the group, execute the “javascript:” link, invite all of their friends to join said group, and be placed in a phishing circumstance.
- Steal usernames and passwords from thousands of people.
- Profit.
Why this is more effective.
To this point there isn’t anything that really stands out as different from other phishing attacks except that the “javascript:” URL that was entered previously will remain in the location bar in all of the big 4 browsers: IE, Firefox, Safari, and Opera. That is a pretty big exception because it serves to mask that the user is presently on facebook.com, controlled by example.com/maliciousscript.js.
With properly written instructions on the Facebook group the user will implicitly believe that they are on the actual $BANK site in spite of the “javascript:” URL being displayed in the location bar, because they specifically pasted it there to create the action. Especially if it looks something like this: javascript:'https://www.$BANK.com/?';(function(a){/*dosomething*/})();, which could even fool some very smart people I know. And just like that, you’ve exploited a user’s trust to empty their bank account.
Bonus points to anybody who implements it like a pyramid scheme. The first 2500 stolen accounts get paid from taking the next 2500 accounts to the cleaners so that you get positive feedback from folks who are actually getting money. You can then come back the next day and clean out their accounts.
Toward a solution.
To help resolve this issue I propose that immediately after execution of a “javascript:” URL browsers return the location bar to its prior state. This would at least prevent the phishing site from hiding behind the “javascript:” URL that many users might trust.