Schneier on Security
A blog covering security and security technology.
« Details Removed from Book at Request of U.S. Department of Defense |
| Real-Time NSA Eavesdropping »
September 23, 2010
Extremely persistent browser cookies:
evercookie accomplishes this by storing the cookie data in several types of storage mechanisms that are available on the local browser. Additionally, if evercookie has found the user has removed any of the types of cookies in question, it recreates them using each mechanism available.
Specifically, when creating a new cookie, it uses the following storage mechanisms when available:
- 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
And the arms race continues....
EDITED TO ADD (9/24): WARNING -- When you visit this site, it stores an evercookie on your machine.
Posted on September 23, 2010 at 11:48 AM
• 63 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Tried this on a Mac with Safari and FireFox; doesn't do what he claims. Of course, that could just me more misdirection...
Well, it's open source and the author does not seem to intend it for particularly malicious purposes
That's pretty impressive. I like the canvas one.
Use the browser built into KDE Kontact.
This is one place where security by obscurity works.
A combination of FlashBlock and perhaps RequestPolicy, combined with caching set to 0 and a block on the ever cookie creator domain results in no ever cookies being successfully set on FF 3.6.10 on RHEL 5.4
If I don't block the domain cookie creation then just a standard cookie is created.
None of the cookie methods claim to work for Google Chrome 6.0 in incognito mode.
None of these are completely new, but the combination of these does make for one tough cookie :-).
Yeah, these digital tyrants want to tattoo their number on our digital forearms by any means.
Konqueror 3.5.10 without Flash & vanilla cookies is not vulnerable as of right now. I suspect this is because it simply does not support the features used.
Yes, with NoScript pretty few of them work (normal cookies keep working of course). But that is an easy to overcome obstacle. If a site doesn't work like I expect it to I immediately (temporally) allow the site.
I was surprised that even if I clear the last hour of my history (Firefox 3.6) historyData and pngData still remain. And if I clear all my history, the pngData still doesn't go away. Frightening.
So, would somebody please post a simple description of how to delete all the stuff that ever cookie creates? Anything it can create, surely we can delete or overwrite?
One trick, for users with a modicum of technical skill, is to create a pristine profile for Firefox, with all required settings, bookmarks, etc and back its directory tree up to a tar or zip archive.
Then wrap a script around Firefox that destroys the profile's directory tree on exit and reinstantiates it from the archive on browser start.
Best combined with cookies off, scripts and flash off, adblock etc and linking ~/.adobe and ~/.macromedia to /dev/null.
It doesn't entirely prevent these attacks on privacy, but it will ameliorate them to a large extent, if the user is not too profligate with tabs, and periodically restarts the browser.
For the truly pissed off, there is also the option to create a VM on virtualbox, qemu, vmware, or whatever, and reinstantiate that from a known clean snapshot each time a browser is required - possibly combined with an anonymising proxy.
Of course what the above tricks really need, is a good, simple and intuitive, graphical skin for unskilled users on multiple platforms.
According to the article, private browsing modes will clear these cookies when the browser window is closed.
And by article, I mean FAQ
>This is one place where security by obscurity works.
The problem is that obscurity doesn't work for very long, not that it doesn't work at all.
Besides, what I think you are getting at isn't obscurity, it is "security by being a low-value target".
They discussed this on HN a day ago http://news.ycombinator.com/item?id=1714446
Once that was done, simply restarting my Firefox (with Better Privacy loaded to clear the LSO) and clearing cookies took care of it.
At what point does it become criminal computer trespass for a website to take great steps to contaminate my machine when I am, by my actions, making it abundantly clear that I don't want those things on my computer?
If I did to the server what these guys are doing to my client, I'd have the FBI at the door.
All these things have been known to those in the browser privacy side of things forever.
The value of this excellent open-source demonstration of the techniques is to bring the issues to wider attention and start a debate.
The bad guys don't make open source demonstrations, they keep the code to themselves.
It attempts to store data that I may not approve of on my computer and make it hard for me to either set policy to prevent it or remove it.
Malicious by definition.
The thing that I wonder, (and I could probably figure it out by looking at the source code sufficiently) is what this does if you modify one of the cookies it sets. Does it then regenerate both the valid cookie and your "cooked" cookies in all places?
Doesn't work with OpenBSD, FF3 in private browsing, cookies disabled & noscript enabled.
@Paranonymous at September 23, 2010 1:40 PM uses a technique very close to mine. You can also use multiple profiles... for example, a Facebook profile, a gmail profile, one for general browsing, etc., all with individual about:config settings.
torproject: initial tests show torbutton stops the evercookie attack against your privacy, mainly because torbutton forbids flash from loading
I'd be worried, but I'm guessing CCleaner will be all over this - one more step for them to clean.
These are just the type of things the HOSTS file is good for. Mapping any domains using this technique to a non-routed IP makes them go away. Unfortunately it's a never ending battle...
Does not work with Firefox 3.6.10 with Adblock plus 1.2.2 and BetterPrivacy 1.48.3 and Firefox set to "Keep cookies until Firefox closes".
Creating the evercookie, closing Firefox and revisting the page yelds all nulls.
Copy a clean firefox directory into tmpfs on startup. then mount it on a directory in .mozilla_firefox. Add every place that might record something to it.
After you reboot everything is gone.
This obviously ONLY works when you reboot your system from time to time. But you could umount/mout the tmpfs
If you want to keep recording bookmarks and installed plugins, handle them by way of links.
CCleaner 2.34.1200 removes Evercookies on Opera 10.62, windows 7 pro ita
Does not persist on uzbl. My guess is the only cookies that would are the classical type. These are purged when uzbl is closed.
I forgot to mention I don't have flash installed. So there's that as well.
Sorry for triple post, if the moderator wants to merge my posts I'm fine with that.
Here's the output form the example when I try to recover the cookie,
Cookie found: uid = undefined
pngData mechanism: null
etagData mechanism: null
userData mechanism: undefined
cookieData mechanism: null
localData mechanism: null
globalData mechanism: undefined
sessionData mechanism: null
historyData mechanism: undefined
dbData mechanism: null
lsoData mechanism: undefined
I was wondering when bruce would cover these. I use better privacy for the LSO's and I am told that using a virtual machine for every session and dumping it after will keep stuff out, but you guys are the computer experts, I'll look here for tips.
I own my hard drive, if anyone else want to use it for their purposes, either they pay rent to me every month or they are illegal squatters tresspassing on my property.
google used to try to have a near never-ending cookie back in the day. It was frowned upon by the early privacy activists.
now they just tie all your information to a single account, it's a lot more effective. i can't see big business using such nefarious techniques, if only because actual user account implied information between accounts and services is a lot more efficient, and privacy is a more public issue these days.
i guess if the underworld (porn, et al) get hold of this, and get it working properly it'll be something to be feared.
Three words: Live Linux CD.
Ok, maybe that's four words if you decompose the acronym.
@yak: "I use better privacy for the LSO's and I am told that using a virtual machine for every session and dumping it after will keep stuff out, but you guys are the computer experts, I'll look here for tips."
No magical VM-escape or whatever involved.
Using Sandboxie, I deleted the "evercookie" in a second and wasn't able to re-discover it.
Most modern browsers can be configured such that this isn't a problem, with the exception of persistent storage and flash cookies.
For several browsers (Chrome, Firefox, and Opera) the FlashBlock user script (greasemonkey) will work to reject unwanted flash applications. That will take care of flash cookies for most of us (unless you elect to run the flash application that sets them).
I'm an Opera user and I cannot seem to disable persistent storage, but all of the rest are prevented by a few user settings.
This can be prevented using the web surfing method I recommend to clients. Well, it will be limited rather than prevented. I recommend doing the web surfing in an isolated virtual machine with a very controlled method of sharing persistent or local documents. The latter is somewhat of a trade secret but I'm sure you could come up with it.
The virtual machine should be running a hardened version of Linux and the browser data on a RAM drive. A read-only, RAM-based Linux distro on a dedicated machine with KVM switch works as well. Every time the VM is reset to the snapshot, all data is erased. The more you do it, the more resistance you have to persistent malware. The only way to defeat the system is to find a vulnerability in the TCB. This is the processor, firmware, BIOS, hypervisor and a few trusted apps. More in some hypervisors. That's better than having the entire Linux stack as the TCB.
Recent developments that make this setup easier are QubesOS. QubesOS is Joanna Rutowska's project that uses Xen hypervisor, a trusted GUI, and Linux VM's to separate certain activities. You could have a regular desktop and then one or more VM's for web surfing. Use one to surf while the other is restoring to snapshot, if it has that capability. I haven't used it yet but I like its design. The use of Xen and it's console-guest model's huge TCB makes the assurance questionable.
converts PDFs freely online, works better than Adobe's on-line conversion page, has no ads, you don't download the PDF prior to converting.
should you decide you're stupid enough to download pdfs, convert them with "pdftohtml", never, I repeat never load them with any software, whether mac, pc, linux, etc.....
@ orange dot
"should you decide you're stupid enough to download pdfs, convert them with "pdftohtml", never, I repeat never load them with any software, whether mac, pc, linux, etc....."
That statement reeks of stupidity itself. Never download your college course materials and open them. Never download PDF's from trusted sources that virtually never have an infection. (ACM, IEEE and Citeseer are examples on my end.) Never download and open mandated PDF forms from government sites.
Wow, your warning says to act on the ultimate state of paranoia regardless of the risk involved or utility in opening PDF's. Fortunately, most people reading and posting here are smart enough to know security is about risk management. Threats + Likelihood of Occurrence = Risk. Risk vs Reward vs Prevention/Recovery Costs = Decision on how to deal with it. Usually, opening PDF's from good sources poses no problems. Even people I know who continuously download PDF books via BitTorrent from reliable sources (w/ RSS feeds and such) say they haven't ever been infected. So, determine risk and trustworthiness of source, then choose to open or not. Don't freak out over every PDF you encounter. That's just nonsense.
A private browsing could be done by :
$ HOME=/tmp/fire firefox
$ rm -rf /tmp/fire
But this rely on sofware using $HOME. Some try to be clever (like glib) and get the real home from passwd...
As for evercookie, you can basically neuter all of evercookie's current and planned methods without making your browsing any more bothersome by using this combination of of Firefox extensions and tweaks:
- Unset "Accept third-party cookies", set "Keep until 'I close Firefox'", and install CS Lite. (CS Lite gives you NoScript-style convenience for setting cookie exceptions on trusted sites so they can remember you between sessions)
- Install BetterPrivacy (Whitelist-based Flash LSO and DOMStorage removal)
- Set "Clear history when Firefox closes" and make sure "Cache" is set in the "Settings..." button for it. (Forces the pngData and etagData portions to session-only)
- Install NoScript and make sure "Apply these restrictions to whitelisted sites too", "Forbid Java™", "Forbid Adobe® Flash®", and "Forbid Microsoft® Silverlight™" are checked in the Embeddings tab. You can set "Scripts Globally Allowed" if you want. What's important is the strong FlashBlock-like protection against his planned Silverlight and Java tracking mechanisms (especially Java since it'll use your MAC address rather than generating a new random ID each time) and the second layer of protection against Flash LSOs. Theoretically, you can also unset "Forbid Adobe® Flash®" as long as you've got BetterPrivacy, but why rely on only one layer of security... especially when it's a more reliable alternative to the FlashBlock extensions.
- Set "browser.sessionstore.privacy_level" to 2 in about:config to ensure that none of your "session-only" stuff gets persisted by crash recovery or session-saver extensions.
- Make sure you're running a version of Firefox new enough to have the getComputedStyle() :visited patch. This kills off web history storage. (The bug tracker seems to say it's landing in Firefox 4, but I've got it blocked in 3.6.9, so maybe NoScript or BetterPrivacy is doing some runtime patching for it)
userData is IE-only, so Firefox users need not worry about it. HTML5 Database Storage was only implemented in WebKit before they changed their mind about enshrining SQLite in a standard, so same thing. As far as I can tell, "window.name" should be made session-only by the browser.sessionstore.privacy_level tweak, so these instructions cover all present and future storage mechanisms currently announced.
The secret to dealing with things like evercookie is looking at each storage mechanism as its own problem so you don't get distracted by the combined product when looking for solutions.
It'll be interesting to see if, in the next 5-10yrs, things like these get regulated
The types of storage here fall into four categories, as far as I can tell.
1) Stuff that browsers treat like cookies: cookies, session storage, local storage, database storage. These are all basically equivalent to long-lived cookies: when the user clears cookies, the browser will clear them too. Using all of them instead of just one doesn't help store things longer, at least in principle.
2) History storage. This is related to a well-known history-sniffing attack. Firefox 4 is currently the only browser to fix it, but others probably will too at some point. (Using it to store data is novel, though, AFAIK.)
3) Flash cookies, and possibly some of the other non-standard things listed. Flash cookies are a well-known problem; most users never clear them, and they aren't cleared via browser UI.
4) The crazy cache-based thing.
(4) is the only really new thing, I think. It's an interesting attack -- I don't see how browsers could defend against it without disabling caching entirely. The first three give you nothing better than just setting a cookie in Firefox 4 with Flash disabled, and nothing better than just setting a Flash cookie in Firefox 4 with Flash enabled. The PNG caching thing will still work even then, unless you use private browsing.
I propose we call these holographic cookies.
Robertson, yes, they can be deleted rather easily. BleachBit 0.8.1 deletes evercookies in Firefox, Safari, and Google Chrome on Windows and Linux
The trick, though, is that evercookies may evolve to use Java, Silverlight, etc, so rather than hard coding your own batch file /shell script, you may want to use a tool that stays updated.
(Disclaimer: I wrote BleachBit)
With the Safari browser on the iPod Touch platform, at least with version 4.0.2 of the iPod Touch OS, the following information may be of interest. Under the Safari preferences, it is possible to delete cookies, the browser cache contents, and the browsing history. If a Web page has stored data in an offline database, the Safari preferences will have a "Databases" option below the "Accept Cookies" option. (If no data has been stored in an offline database, the "Databases" option will not appear.)
SO, with the massive security nightmare that Flash is becoming, does anyone out there *not* run a flash-blocker?
(And am I the only one who found it ridiculously difficult to do the super-urgent critical Flash patch on Firefox? Why the heck doesn't it work just like a standard add-on?)
I went to Samy.pl/evercookie and did his tests, as well as downloading and running BleachBit 0.8.1, today. Passing the Samy.pl tests wasn't too hard: BleachBit eliminated the trial cookie and all references to it, as did my simple DOS script (I use Windows Vista - I know, I know ...) to wipe out the Flash Player directory and its contents, in concert with the Clear-Recent-History option in my browser (Firefox 3.6.10).
Unfortunately, it looks like neither method eliminated the Schneier 9/24 cookie mentioned above ("WARNING -- When you visit this site, ..."). I had come to this page earlier in the day using the "Posted on September 23, 2010 at 11:48 AM" link on the Schneier blog, and when I came back just now, the link was still grayed out. I can't be sure that's from the Evercookie (since I can't FIND the Evercookie), but I suspect it is. That also isn't an indictment of BleachBit, as I may not be using the program correctly, but I will agree with the other commentators: "Frightening."
"And the arms race continues....": You bet. Where there's a market, there's a way. Just follow the money.
Paranoiac: The link "Posted on September 23, 2010 at 11:48 AM" should always grey (meaning visited) because it points back to the same page it is listed on.
Thanks. Good to know. There must be something wrong with my browser (or the residue of my compulsive cookie-clearing), then, because the link "Posted on September 23, 2010 at 11:48 AM" is pretty consistently blue when I come directly to this page, and gray when I click on the link on the master blog that leads here. I have some more sophisticated experiments I want to run on Evercookie ("sophisticated" meaning "time-consuming"), and will add this low-intensity problem to the investigation regime.
I'm fairly confident that none of those
methods worked with Lynx either. It
but globalStorage.clear() does not work for me.
It also doesn't work if I don't use a computer!
I use MAXA Cookie Manager (http://www.maxa-tools.com) to manage all kinds of persistent cookies (Http, Flash, Silverlight, HTML5 DOM, ...) and clear my browser history+cache. That's enough to get rid of "evercookie".
NeverCookie for Firefox is available, beta right now, takes care of the evercookie.
Requires a new Firefox profile where your old bookmarks will not be in case you want to use it all the time.
Uncheck the "Do not show again" so the profile selection window shows when Firefox is restarted or have to research how to enable Firefox profiles for your OS.
See Slashdot article about NeverCookie.
Got this on Slashdot a while back, I run them every evening
after shutting down firefox:
1)create a bash function:
for i in ~/.mozilla/firefox/*.default/*.sqlite;
sqlite3 $i "vacuum;";
2)create an alias:
alias cleanflash='rm -rf ~/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys/* ~/.macromedia/Flash_Player/#SharedObjects/*/* ~/.adobe/*/*/*/*'
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.