Interesting read on the evercookie!

http://samy.pl/evercookie/

 

What joy. All the more reason to browse sandboxed or in a virtual session.

 

@ ratchet

Great find

We might get some more input about it from here too - http://www.broadbandreports.com/forum/r24830645-Evercookie-The-nightmare-is-here

 

Also in reply to stuff posted here: https://www.wilderssecurity.com/showthread.php?t=282702

Using Firefox 3.6.10
Is it just me or does this not work at all when you simply disable http cookies in the browser preferences. Only when I enable them other cookies are being set as well.

In about:config: disabling dom.storage blocks the 3 html5 storage cookies, disabling all three caches blocks the png cookie (type cache*enable into the search bar). The history CSS attack/vuln/feature has been plugged in Firefox. LSO can be blocked by symlinking the appropriate dirs to /dev/null or setting the permissions/ACLs to read only. Silverlight, anyone using it? Yeah, thought so.
Or ctrl-shift+del does the trick too. Or NoScript.

No need for a VM. IF you know all this it's really not scary and a non-issue. Admittedly a big IF for a lot of netizens. Or maybe they are using a browser that doesn't give them full control :/

 

I use Sandboxie and Returnil. But I do have an external hard drive that stays connected most of the time. I wonder how dangerous that is? I download a lot and save lots of stuff. Can these cookies install on an external HD?

 

No...

 

Thanks. I am so glad to here.

 

Why not? What prevents the script from writing to any available drive?

 

Not a cookie issue, but one you should should be aware of since you use external drives. One piece of very sophisticated malware that will get you in a heartbeat (and sometimes not know for days) is SALITY. The W32/Sality variants hide the entry point, disables task manager and infects ALL .exe and .scr files. All of them - across partitions and attached drives. It's often found in cracks and shady software and most often uses .dll exploits, but was recently dropped by infection through a simple visit, at the right time, to The Pirate Bay. Some have suggested using fixed drive letters deep into the alphabet and not use e-j as some of the Sality's only infected drives up to 'J'. Why? Who knows? This is one nasty mutating trojan - one of the worst I've ever seen.

Here's Microsoft's MPC encyclopedia entry for Win32/Sality:
http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Win32/Sality

 

Do you know how Javascript works? Or browsers?
Have a look at the code if you don't believe me, it's open source after all.
Bottom line: Cookies are only stored and read from a handful places, all residing in the user's directory. Secondly the browser itself is preventing Javascript from doing anything nasty.

In order to do what you are suggesting one needs to exploit an unpatched vulnerability in the browser, not an easy task and certainly illegal.Do you think any legitimate site would resort to such tactics? Evercookie on the other hand is greyware at worst.

 

GesWall+IE8 could stop evercookie?

 

I'm not sure if GesWall does prevent anything. I do not use it but if I understand it correctly it's an IDS. However evercookie is not malicious and does not constitute a "intrusion" of any kind. All it does is it uses several different browser "features" in a clever way.

IE8 can be configured to stop evercookie from working, for example by simply disabling and whitelisting javascript per domain. From my testing on Firefox simply blocking (and whitelisting) cookies alone does the trick too.
Deleting private data should* get rid of all "cookies" except LSO which has to be cleared in it's own settings (right click on any flash object and select settings) or by hand in Windows Explorer (in %APPDATA%\Macromedia).

*Simple to test but I'm currently on Linux.

 

Yes, but not in Firefox 4. It also not really a vulnerability but a feature(giving visited links another color)which can be abused. At first because of this Mozilla wouldn't change it, but in the end they choose safety over functionality and disabled it by default. However, I saw in FF4 beta 6(only beta version I've tried btw) that it is enabled again. You can disable it in about:config by turning layout.css.visited_links_enabled to false.

 

BleachBit

Supposedly deals with Evercookies !

https://www.wilderssecurity.com/showthread.php?goto=newpost&t=283005

 

I guess not. It,s not its job.

 

Pfffffffffff....

 

Is this the same "author"?

Source:
http://news.softpedia.com/news/XSS-Worm-Hits-Orkut-158198.shtml

 

May be SBIE can.

And probabaly Geswll too after some custom rules but I am not sure.

 

So simply clearing all cache and history info in firefox, while using CCleaner removes are traces of the evercookie?

I did that, and I tried to recover the cookie, and all I got was "uid = null" this means that all the cookies were deleted, right?

 

That's correct, all cookies are deleted and the ID is gone. However there appears to be a trace left because for some reason when cleaning the cookies some don't get erased but overwritten with zero or something, hence the "null". But nothing to worry, it obviously can't be used to identify you anymore.

 

From what I read on the website, the "null values" are from HTML5 Session storage and HTML5 local storage. Where can i delete these manually?

 

I think Firefox has an extension called SQLite Manager that allows one to view all SQLite databases and even edit them.

As with all extensions, caveat emptor.

 

It seems the evercookie has more methods and the number is still growing.
Original list:
- Standard HTTP Cookies
- Local Shared Objects (Flash Cookies)
- Storing cookies in RGB values of auto-generated, force-cached
PNGs using HTML5 Canvas tag to read pixels (cookies) back out
- Storing cookies in Web History (seriously. see FAQ)
- HTML5 Session Storage
- HTML5 Local Storage
- HTML5 Global Storage
- HTML5 Database Storage via SQLite

Now these are also on the list:
- Silverlight Isolated Storage
- Storing cookies in HTTP ETags
- Storing cookies in Web cache
- window.name caching
- Internet Explorer userData storage

And there are also future plans for adding these two:
- Caching in HTTP Authentication
- Using Java to produce a unique key based off of NIC info

 

Thanks, that gives a good explanation of the various methods of the evercookie and how to stop it