I guess I just took it for granted, but apparently, for the longest time, Internet Explorer has stored its browser cookies using plain-text filenames that were relatively self-apparent as to their site-ownership. Chrome and Firefox use a database file to accomplish things rather than singular cookie files.
Bill Pytlovany of “WinPatrol” fame recently discovered that a Windows Update has now changed that cookie-naming behavior, much to the (temporary) detriment of a cookie-management feature of WinPatrol.
Bits from Bill: Windows Update Changes IE Cookies Names
Luckily for us, Bill is both a very sharp guy, and openly communicates the best of his findings so we can now learn about this security improvement from Microsoft.
While in-of-itself this probably isn’t major news except for some application programmers who do IE cookie review/reporting, it was an interesting look at how Microsoft is continuing to try to tweak the security model for IE.
In that post in a followup update, Bill dug up some great resource linkage from Microsoft on this change over at Eric Law’s blog that is a must-read for those working directly with IE cookies in this post-update landscape.
Specifically, it is Microsoft Security Bulletin MS11-057 - Critical: Cumulative Security Update for Internet Explorer (2559049) which is impacting cookie-handling.
Internet Explorer 9.0.2 Update - EricLaw's IEInternals
From that post (which contains wonderfully illustrative screen shots of the pre and post-update cookie storing behavior) Eric explains thusly:
Cookie Filenames are Randomized
As a rule, Internet Explorer attempts to prevent Internet sites from storing content in predictable locations on the local computer, in order to foil a number of attack types. That rule is why, for instance, the Internet-cache stores content in randomly-named subfolders.
Prior to this update, Cookies were an exception to this behavior—their location was insufficiently random in many cases. Generally, cookie files were stored under the \AppData\Roaming\Microsoft\Windows\Cookies folder, in files named using the user’s login name, an@ symbol, and a partial hostname for the cookie’s domain:
Given sufficient information about the user’s environment, an attacker might have been able to guess the location of a given cookie and use this information in a multi-stage attack.
To mitigate this threat, Internet Explorer 9.0.2 now names the cookie files using a randomly-generated alphanumeric string. Cookies are not instantly renamed on upgrade, but are instead renamed as soon as any update to the cookie’s data occurs. You can see the impact thusly:
We do not expect significant compatibility fallout from this change either, as the names of these files have always been somewhat dynamic. Directly enumerating or reading the Cookie files has never been supported. Instead, local applications that wish to interact with cookies can use the InternetGetCookieEx and IEGetProtectedModeCookie APIs, or they can use the WinINET cache-enumeration functions.
Another treat in the comments is Eric’s clarification that the name randomizing behavior only (should) impact cookies from the Internet zone (in IE’s terms) and not the Intranet zone. So if you have any in-house/network applications that also create/store local cookies in IE, then they should not be randomized if your IE zone settings are set correctly.
Also, it appears that the internal contents of each cookie file are not changed by this handling and can otherwise be viewed using normal methods.
Eric specially address this operation in IE 9.0.2 but earlier in his post’s introduction he wrote that “…two of the security-related changes impact obscure Internet Explorer behaviors in all supported browser versions (6 to 9)—I’ll discuss both of these changes in this post.” So it may be that randomization will be seen in cookie stores of other IE versions.
Finally, it seems (based on my own IE 9 cookie store review post-update) indeed that the cookie-name randomizing only occurs as new cookies are being set or updated as Eric had described above in his post.
While I suspect that any forensicators won’t have much problem dealing with this IE cookie-handling change (I think someone wondered aloud about what’s in a name?), it may prevent the casual inspectors of cookie crumbs from reading too much meaning into them. However the contents, file meta-data, and such should still provide more than enough meat and potatoes to keep the pros happy.
I imagine some IE-behavior inspecting tools and utilities may need to be updated just a bit, but besides being a new “item of note” regarding the IE browser landscape and behavior, it’s will be business-as-usual.
To my untrained eyes, it’s kinda like trying to pick out the chocolate truffle ones from a box of mixed-chocolates. Unless you know the particular swirls and marks, it’s a pot-luck game.
Fortunately I’ve got a friend to help me out. Nir Sofer’s IECookiesView v1.74: Cookies viewer/manager for Internet Explorer seems to have no problems with the post-update changes. In my testing, it happily reports the correct Web-site, access-date, modify date, create date, and domain (among other details) while also showing the newly randomized filename. It does a few other things as well to make IE cookie managing a breeze.
Nothing earth-shattering here, but interesting for the geek crews.
Related and easily overlooked in Eric’s post a link to this A Primer on Temporary Internet Files post at EricLaw's IEInternals that provides some fresh info on IE Temp file handling. Sweet!
--Claus V.
No comments:
Post a Comment