hello123

Whats All The Hubbub?!


Cookie Grabbers, hereto referred to as "CG" can make you lose your account before you even know its gone.
People have been getting CGd all over Neopets. Assuming you're immune and it won't ever happen to you is the first mistake to be made. People have been targeted specifically, people have just come across the wrong user lookup. In this guide I will attempt to explain how CGs work, why TNT hasn't done anything yet, and most importantly... How to protect yourself.

So How Is It Possible?

CGs are very basic coding that can be implemented into almost any page on most web pages, usually without you ever knowing that you've been nabbed. A bit of PHP, a dash of Javascript and you got yourself a CG. The PHP translates the personal information stored on your computer into a format that can be read and saved by the Javascript. Most recently Neopets has disabled PHP and Java across their site. So we should all be nice and safe now right? WRONG! Flatnukes (Flatnux for short) is a recent addition to the coding world and allows any scripts to be run regardless of whether or not the original coders attempted to block it. It was intended to be used so you wouldn't need to go through an entire page of code just to add in a bit of Java or XSS when you originally coded it to be blocked, more recently it has been used for more devious methods.

What Happens Once You're CG'd?

Once a CGer gets your cookie, there is still a process to get into the account and therefore, you have time to protect yourself as best you can. The information that was processed and snagged by the PHP/Java will be saved in a hashed fashion into a .txt file. Most sites aren't stupid enough to save a cookie in an ACCOUNT:PASSWORD fashion, most are a combination of login time, name, password, and any other odd information that will make unhashing the password even more difficult. This information is then encrypted, hashed, and saved on your harddrive until the CG manages to get a hold of it. Unhashing passwords and accounts is a process, and takes a bit of time (usually up to 3 or 4 hours with the help of a program). Once again, this is the time you should be added PINs and changing passwords, if you know you've been CG'd that is.


Does TNT Know About This?
They undeniably do, but stopping an entire coding language is a difficult process, and the fact that Flatnux has been made specifically to override said code makes it even MORE complicated. I'm sure they are working on getting it fixed, and have been at it for at least 3 months. The time for the exploit is running out, but it only takes a day to lose your account to a CG forever.

How Can I Protect Myself?

Here it is, the reason you're probably visiting this guide. The answer is extremely simple and you will likely be shocked at how easy it is to avoid being CG'd... Meet my good friend NoScript!

Chrome: https://chrome.googl...lpidmdajjpkkcfn
Firefox: https://addons.mozil...addon/noscript/


Edit: Props to Jibri for Chrome NotScripts.


If you're using IE/Safari I would highly suggest switching as neither of them offer access to a Java blocking option and you will ALWAYS be susceptible to CGs!


If there are any questions feel free to PM me and I promise to help you out to the best of my (and your) ability. This concludes the first guide from your friendly neighborhood Abradix! Expect to see more soon.

You don't need to know PHP to do Cookie Grabber. You just need to know basic javascript and basically set up another page that accepts input/parameter. Basically Cookie Grabber uses XSS exploits to steal your cookie. It is no use to 'delete' your cookie, it won't make any difference. Also, Java != Javascript, it is totally 2 different programming and unrelated (probably just related in some of the syntax).

I have never use before Noscript plugin but reading from the plugin page, it seems to have the ability to block the Cookie Grabber, however I am unsure if you need to do settings on the plugin to activate the 'Disable Javascript function'. Checking from this page - http://noscript.net/ from the screenshot, it gives me the thought that it is set to default to disable the javascript. So probably it would work by just installing it. However if you are using Firefox, you can do it another way to protect yourself from Cookie Grabber.

Tools -> Options -> Content -> Untick the 'Enable javascript' would protect yourself from being 'Cookie grabbed'.

However when you disabled javascript, or used 'Noscript' plugin to disable javascript, some sites you are viewing (not neopets) might not work, however it would still protects you from being attacked by XSS exploits from other website. So you probably would have some problem viewing some other legitimate websites that requires javascript to run. Some legitimate website you view, especially those websites that is built running on AJAX or using jQuery technology would pose problems like website not running properly or functions is missing. Then you would need to re-enable your javascript for the webpage to work normally. However remember to off it once again when you are going to neopets or some other important websites that you wouldn't want your cookies to be grabbed.

A cookies is saved in a .txt file for most or probably all of the browsers. I just took a look on my own neopets cookie. It tells me that the confidential information are 'hashed' instead of encrypt. Also, no password are stored. From what you said earlier on, the cookie stealer would requires a program to run to crack the information. I can tell you that is wrong. They don't need to crack the hash information. It would take forever for them to crack the hash, or probably few hours like you said if it appear on a rainbow table but from this case I see, a rainbow table most likely wouldn't help. The cookie stealer just need some simple stuffs to access your account, the process I can tell you is less than 10 second to access your account with your cookie

Using neopets PIN function will guard access to your SDB and bank, however it wouldn't guard your account fully.

As what other users suggested, 'relogging' of account. I can say it might work. Seeing from the neopets cookie sample of my own, I am 'guessing' that the 'logged in' function is binded onto the cookie based on login sessions and your username instead of username:password. Therefore re-logging in might erase the previous session when your cookies are being stolen therefore changing the session existed, thus expiring the previous cookie when the attacker stole your cookies. So yep it might work.....

The more effective way of stopping it was to enable 'Plain text Neomails only'.

You can't do 'Plain text Neomail only' since it's on HTTP browser. HTTP browser does "HTTP GET" method to retrieve HTTP data through port 80 from the web server, the web server sends out the correct plaintext data according to what your browser requested. Your browser crafts out the plaintext data into application level to display the output to your browser.

The browser reads HTML codes and output, codes such as script tags are also in HTML code, therefore if someone is able to write script tag to be send in plaintext, the browser will automatically read it as a script and launches the script. This is how XSS attack works. How they defend against XSS attack is through filtering of tags, like filtering the word script, < >, &lt, &gt, %60 and etc. And how the XSS filtering works is crucial, there are ways to bypass the filter if the filter is not properly coded to look for all possibles ways to block out the script tag 'plain text word' to be POST.

This is how the recent neomail steals your cookies by POST you a neomail with text that crafts out a script tag for HTML to read it as running a script, so your browser then launches the script and it appear to do some POST-ing of your cookie to somewhere through the document.cookie function in javascript to retrieve the current cookie you are using.

However setting HTTP-only parameter for cookies if only your browser supports, will block the XSS attacks. As document.cookie is the command to retrieve your cookie, the command is actually a javascript function. So making the login cookie to be HTTP-only restrict access to the cookie file through HTTP only, therefore javascript has no privilege right to retrieve the login cookie, and therefore using document.cookie javascript command couldn't retrieve the login cookie data as the client javascript does not have the privilege to do so. As the cookie can only be read and used by HTTP only.

That's how you block the XSS script, however your browser must be supporting the use of HTTP-only parameter, if not it won't work. But nowadays most browsers supports it, it's just that the developer isn't implementing it for extra precaution against XSS attack.

Actually if you look into it, MD5 on it's own is no longer considered secure for password storage. If the MD5 hashes are uniquely salted, then yes it's secure but on it's own, whilst chances of collision are LOW it does exist. Go look up password hashes and hashlists. For 'good' passwords (which would be unlikely to be cracked anyway) MD5 should be more than sufficient.

If MD5 hashing WAS very secure, why would Mozilla have wiped the passwords of a large number of users when a bug resulted in a hashlist of their stored MD5'd passwords being posted (look it up, it happened). I concede on the point regarding how Mozilla stores it's passwords and got myself mixed up regarding the issue with Mozilla posting the hashes.

And yes, I realise hashing and encryption are 2 different things. Hashed strings cannot be 'decrypted' as such. When hashed passwords stored in a database, the method of verifying that information is to hash it then compare the matched hashes. This would obviously not work for a 'Remember Me' form as the submitted information would obviously need to be the unhashed string.

We both however agree wholeheartedly that users shouldn't be too concerned about 'remote' access of their stored passwords... unless they were extremely lax in their security, which if they were, would result in more issues then Neopets stuff being stolen.

anyways, @ 2am and work in 5 hours, I am off to bed.

-POST CITED FOR INCORECTNESS

They wiped the whole MD5 hash because it is been leaked. If not they wouldn't need to wipe the passwords. If the MD5 hash isn't leak in the first place, it would still be quite secure using it. You would probably just need to worry that your password is a dictionary word or that is in some record of MD5 rainbow table. If not it would be quite safe. Just that it is easier to be cracked, or rather say bruteforce to get the same hash doesn't means that it's unsafe. It's just easier to be cracked compared to SHA-256 or SHA-512 which is a lot harder since it has more key bits. Of course, salting the MD5 would make it much more secure, however unsalted MD5 for Mozilla case is also consider reasonably secure as cracking a MD5 hash is almost impossible unless your password just sucks lol. The flaw of collision attack in MD5 just reduce the number of possibilities for a bruteforce attack to be carried out, but carrying one to decrypt one of it with bruteforce attack (not to compare it with rainbow table attack or dictionary attack since this won't work if the hash is not in the record of the dictionary or rainbow table) would take months to years to a few lifetime to crack it. It is like 'no one would really waste the effort to do it'. Oh anyway, the string collision would only be a problem for if the string to be hash is damn long, then it would have string collision. Example - For a 20 length password, there still wouldn't be any collision with any 1 - 19 length password, and it would already take a few hundred or thousand of years to bruteforce the hash already.

-POST CITED FOR INCORRECTNESS

Firefox stores the passwords as MD5 Hashes. No longer the most secure, as certain strings of letters can result in the same MD5 hash (hence hashlists becoming more and more prevalent.

Hashing and encryption are 2 different stuffs. And password hashing with MD5 up to date is considered very secure, why wouldn't it be secure? The chances of MD5 string collision is like very low, it's like one in a billionssssss chance of having string collision. Password hashing with MD5 is not really vulnerable to the crypto collision attack. Unless your password is a dictionary word, else cracking the MD5 hash is almost impossible as it takes years to bruteforce it. And it's not possible to use MD5 hashing method to save the 'saved password' plaintext. Because it would be almost impossible for Mozilla to reverse it, unless they keep a reference of the plaintext to the hash key somewhere, which is pointless in this way since then they cannot really 'remember' the password, but just returning the hash of the plaintext which would be invalid password lol. Therefore they are using some encryption method to ENCRYPT the password, so that it can be reversible if only they have the 'key' to decrypt it.

Anyway, Firefox doesn't hash the saved password with MD5. It only encrypts/decrypts the password using the key3.db file. key3.db is the file that holds the key to encrypt and decrypt the password in plaintext. However the decryption process can be done easily under the Security tab options easily in Firefox.

Back to topic, I don't think there is any remote attack on stealing key3.db and signons.sqlite file which stores your username password. Unless you are infected with some backdoor virus or someone did a remote buffer overflow attack on you to plant backdoor, which I don't think it worth the time to do it. Most probably what you should concern about that is just local security issues instead of remotely.

So does this exploits still going on now or is it fixed?

Anyway this exploit is call Cross Site Scripting

I guess it's that neomail doesn't have script tag properly filtered, and the hackers managed to find a way to bypass the filters and craft a javascript to post our cookie through document.cookie method and posting at some website of theirs.

Anyway, neither than disabling neomail from friends only, you can also choose to disable running your javascript for your browser to protect yourself. However this is not recommended as many websites, including neopets runs javascript, so disabling the option might let some functions not able to run properly. Neopets should consider using HTTP-only cookies to prevent any future XSS attacks as nowadays most people have their browsers updated, so it will prevent most people from getting attacked by XSS exploits.