Decon Evercookie: Temporarily Shake Evercookie with User ID Deletion

AgXphoto.info
by John O'Keefe-Odom

Evercookie may resist removal by the user, but it does not seem to effectively withstand removal of the user, as in, removal of the contaminated login ID.

Receiving "evercookie" also seems to be dependent upon the use of browsers with "javascript enabled."

Building a new user login and destroying a contaminated one could be done, with some additional file saving in less than 30 minutes. Bold re-creation and contaminated directory deletion seems to be something that's do-able in less than 2 minutes.

The difference in time consumed rests with the deliberation and care for preserving other files associated with the user ID affected, before it is destroyed.

Removal Time: Under Five Minutes

Predicted elapsed time to erase the "un-removable" cookie: two to five minutes of normal operation and typing by a familiar user. This would be for one affected account, manual removal, through typing commands in Terminal, responding to identified processes through inspection and education.

It's not forever. Evercookie removal seems to take longer to recognize and prepare for than it takes to carry out.

Removal takes about five minutes, if you're prepared to delete a user ID, which anyone on the Internet should be prepared to do anyway. Burning the bridge behind you only takes a moment. Sometimes it's the right thing to do.

Summary

Shake evercookie by destroying User IDs like a one-time pad.

Preventative User Behavior

Establish, maintain, and destroy at irregular intervals, User IDs used only for Internet surfing. Same as the procedure for isolating or containing actions on the computer by restricting certain activities to certain User IDs. Avoid associating User IDs with specific people, particularly if you are the only user of a given computer.


Narrative

I picked up the dreaded evercookie HTML5 malware. Used to track computer users across the Internet, this particular type of cookie is aggressive about resisting deletion. It has a special "undelete" feature built into it that stores ten copies of itself on available memory systems.

I'm not absolutely certain about what this program is or does, but I used these simple steps to detect and manually, but brutally, contain the Evercookie.

I mean "contain" as in, once the login ID is deleted, the evercookie's behavior seems to stop and not reoccur.

Procedure:

• Detection through unusual processes in TOP
  
• Containment through deleting affected user ID
• Light containment with browsers initiated from within a separate volume
• Manual-input protections from disposing and recreating user IDs on a system based on desire
  
• Periodic hard-drive reformatting
  
• Periodic system destruction and reconstruction
  

Detection:

I found the evercookie first a few days ago, not knowing what it was. It showed up in Terminal when I ran TOP. This command reveals the top-consuming processes running on the computer.

At the same time, history related functions in Firefox were not working properly. The browser was suddenly providing unusual warnings. Bookmarks were gone; and, simple "BACK" and "FWD" functions were not working right.

When I ran a quick check of the system in Terminal, a program I use daily, I observed a bunch of "DesktopC" processes that I do not normally see on my system. Rightly or wrongly, I notice that these coincided with the occurrence of this browser problem. For this reason, and the arrival of recent publications on "evercookie," I suspect that what I was seeing was the effect evercookie had on my system.

NOTE: I provide the following guidance for use at your own risk. Read through and decide for yourself before proceeding. These solutions work because they involve deliberately destroying or disorganizing data. Thanks.

Normally, to put a stop to a process, this simple "KILL" command followed by the process number, will stop that particular program. In the case of this Evercookie, I noticed that there were ten unusual processes called "DesktopC" which were running. Also, I noticed that for every one I deleted, another new one would appear.

It was that new-appearance which got my attention. Normally, in TOP what would occur would be that when a process is deleted, whatever next one on the list (among the top consumers of power on the system) would be displayed. Almost always, because of the great variety of applications running on a system, this would be something of another name.

Attempts to issue a KILL command for all of those processes in one line were unsuccessful in my case. It might work; but, by the time I got around to trying it the process numbers had already spread themselves out so much that I could not remember them all to get them in one easy to type line.

Notable Exception:

I noticed that this problem only infected one user ID on my system. Even though I am only one person, like a lot of old operators, I maintain several user IDs for different kinds of uses. For example, I like to write simple programs in C: that has its own user ID. Browsing the Internet? Its own user ID. And, so on.

When evercookie arrived, it infected some user IDs, but not others. To observe this, when I would switch IDs around some, and running Terminal and TOP in each, I noticed that the DesktopC processes were not all consistently appearing.

The Brutal Solution:

To contain the symptoms, and I would like to emphasize "symptoms," I deleted the user ID that was infected with this problem.

That may seem harsh to some people, but if you are in the habit of running your systems as somewhat disposable anyway, it's just healthier. If you have so much stuff under your user ID right now that deleting it seems like a bad idea to you, it might be time to clean up some stuff, archive some backup copies, and get set to take the plunge sometime in the future.

With the deletion of that user ID which was infected with evercookie, those particular "DesktopC" processes stopped running. I suspect, but do not know, that those processes were running with that name, and there, because of instructions I had given to my browser about where to place downloads.

Keep in mind that just because something is not running now doesn't mean it's gone forever.

Notice also that this problem, evercookie, arrived through using the system on the Internet with other applications in use. So this thing has already traveled through pathways deeper than a user ID by the time it is detected. For example, multiple users may draw from the same browser application which helped evercookie arrive in the first place.

Prevention:

I noticed no good all-manual directions on the Internet for removing evercookies. There were a few programs which offered or claimed to control this problem, but I was skeptical of them. Back in the mid-90s, we saw a lot of programs, particularly marketed as scanners or cleaners, which would just replicate the tracking problems and re-route the results to a different destination. Since this evercookie problem is only a week old, I didn't feel too hot about trying those kinds of solutions lest I fall prey to the same old tricks.

Of the recommendations I can make with my limited knowledge of computers, probably the more brutal ones, of disposing of user IDs and reformatting your system at will: those ideas may seem inconvenient, but will probably only offer the only real help I could suggest to you.

I mention all of this because yesterday I saw some younger girls in a coffee shop complaining about how all of a sudden their computers were misbehaving. They were really frustrated, and I wonder if they had a more advanced form of this problem.

# # #

Possible Alternate Course of Action:

It also occurred to me later that if this evercookie is detected, one possible course of action is to use "ps -A" command in Terminal (*nix systems) to locate the running processes, and then "KILL" all of those in one command-line statement.

I have not tried this particular route, but it may be possible. It would be important to destroy or confuse all of the processes involved in one action.

# # #

References:
New York Times:
http://www.nytimes.com/2010/10/11/business/media/11privacy.html?ref=technology

PCMag.com:
http://blogs.pcmag.com/securitywatch/2010/09/new_evercookie_claims_its_toug.php#comments

"Evercookie" most frequently referenced website:

[Warning: disable javascript in your browser before visiting. Site involves evercookie automatic generation.]

[Note: the evercookie site listed makes use of, to my surprise, Google Analytics tracking cookies. Notice the Google account number in the source code for the page if you visit.]

http://samy.pl/evercookie/

Website sharing similar Google Analytics tracking ID number:
[No other coordinating information on evercookie]
http://pastie.org/pastes/1077104

Pastie.org web pages related to longevity, but not appearing directly relevant to evercookie (it was unusual that rigorous persistence was coincidental and colocated):
http://pastie.org/1
http://blog.pastie.org/2010/09/pastes-are-forever.html#comments

Commentary on a web page review, based on the code found in the "pastie.org" reference page 1077104, with code replicated in thread:
[No other information on evercookie. Located by searching Google for a set of html creating a mailto link back to code posted on pastie.org's page sharing the Google UID]
http://www.dreamincode.net/forums/topic/166499-what-language-is-this-written-in/

# # #