Update: This issue was quietly fixed in IE v11.09 in June 2014.

NameTag - Internet Explorer 11 InPrivate Mode Information Disclosure Vulnerability

Nametag

Background

To improve the user-experience of touch browsing, the Internet Explorer 11 team made several changes to the password manager feature of the browser. Internet Explorer 11 fixes several bugs that prevented the browser from properly storing usernames and passwords for web forms.

By default, Internet Explorer’s autocomplete feature requires the user undertake an explicit action (typically, clicking into a username field and selecting a saved username) before the username and password fields are populated by a stored username and password.

For the further convenience of touch users, IE11 introduces a new password autofill function, whereby stored credentials are automatically inserted into the form fields without user interaction under 5 conditions:

  1. The user has elected to store username/password combinations in the browser
  2. The user has only stored one set of credentials for the target page
  3. The target page is delivered over HTTPS
  4. The target page is not framed
  5. The target page does not contain any mixed content

These five restrictions help protect IE11 users from a variety of password stealing attacks which have been executed against browsers over the years.

The Vulnerability

Unfortunately, the autofill feature omits an important 6th test:

6.       Credentials must not autofill when the browser is InPrivate

This omission leads to an Information Disclosure vulnerability when the user is utilizing the browser’s InPrivate mode. If, while InPrivate Mode, a user visits a site for which they have previously stored a password, that user’s identity is immediately available to the webpage with no action on the user’s part.

Consider the following scenario:

Begin an InPrivate session and navigate to Google.

After a few privacy-sensitive searches (e.g. "genetic disorder"), click the
Images button on the homepage.

But I accidentally clicked twice -- the Images page loaded and replaced the Images button with a You+ button which caught my accidental second click.

At that point, I was navigated to the Google Login page with my information pre-filled:

Google login form with autofilled credentials


At this point, Google could associate my private queries with my subsequently autofilled login information, violating my privacy expectations.

Sample Repro

1.       Store a password for Google

2.       Launch Internet Explorer in Private Mode and navigate to https://accounts.google.com/servicelogin?hl=en&continue=https://www.google.com/

3.       Observe: Your credentials are immediately available to the DOM with no user interaction

Discussion

Because the IE11 password autofill lacks restriction #6, the user can be unmasked simply by browsing (intentionally or unwillingly) to any site for which they have a saved password. Even if the user chooses not to login, it’s already too late—their credentials have been made available to the script on the page and thus the user is exposed.

InPrivate’s primary target is “over the shoulder” privacy; the IE team has declined to address this issue with the explanation that the feature does not claim to provide any privacy from websites.

However, in practice, over-the-shoulder privacy is not all Internet Explorer attempts to provide with InPrivate. That’s why, for instance, InPrivate has always sent the “DNT” header even though that has nothing to do with “over the shoulder” scenarios. More importantly, the choices made in the implementation of InPrivate demonstrate that it was designed to ensure that a user should not be identifiable when they visit a site InPrivate, even if they’ve visited that site before. That’s why, when an InPrivate session starts, the session starts with an empty cookie jar, empty HTML5 storage, and previously cached responses are not pulled from the WinINET cache. If any of these persistence behaviors were absent, the user’s privacy would be violated because sites could use the cookie/storage/cache information as a “token” to associate the InPrivate instance with a prior, non-private session, and thus potentially “unmask” the user.

Autofill data acts as a persistent user token which breaks the isolation between InPrivate traffic and non-private traffic. This isolation came at a great cost (major development complexity & significant runtime performance penalty) but it was deemed essential for the feature: it includes isolating the cache, cookies, and storage. Such isolation isn’t unique to IE; all browsers’ privacy modes enforce such isolation.

It is important to note that InPrivate intentionally does not prevent the user from reusing previously-cached AutoComplete data, but that reuse requires an explicit user action, making it the equivalent of the user simply reentering the information. Importantly, one of the security guarantees for AutoComplete is that a site must not be able to enumerate the user’s AutoComplete history, which prevents an attack whereby such information could be used to silently or automatically unmask the user. Microsoft has previously issued patches for MSRC cases when it was discovered that enumeration-prevention could be bypassed.

Vulnerable Software

Internet Explorer 11 Desktop

Not Vulnerable

Internet Explorer 11 Mobile on WinPhone 8.1 (does not offer Password Autocomplete while InPrivate)
Internet Explorer 10 (Does not include autofill feature)
Chrome 32 (Does not autofill while Incognito)
Firefox 28 (Does not autofill in Private Browsing Mode)

Workarounds

What would it have taken to fix this?

    if (IEIsInPrivateBrowsing()) return;

Timeline

    March 20 2014 - Reported to MSRC ([email protected])
    April 11 2014 - MSRC reports that “this will not be patched as a security issue” and indicates that they have no objection to public release of this report.
    June 10 2014- Internet Explorer v11.09 update fixes the issue (though it's not listed in the list of fixes)



©2014 Eric Lawrence. All Rights Reserved.