Thursday, July 29, 2010

Stealing AutoComplete form data in Internet Explorer 6 & 7

At the time of this writing Internet Explorer 6 & 7 collectively command 29% market share (~500M users), making them STILL the world’s most widely used Web browser when combined together. Similar to the recent Safari AutoFill vulnerability, a malicious website may surreptitiously obtain an IE 6 & 7 users private information including their name (aliases), addresses, telephone numbers, credit card numbers, place of work, job title, search terms, secret questions & answers, etc. by simply abusing HTML form AutoComplete functionality. Furthermore, the attack may succeed even if the user has never been to the malicious website or provided any personal information.

IE 6 & 7 have a feature (Tools > Internet Options > Content > AutoComplete Settings > Forms) that remembers user-submitted values entered into HTML form text field across disparate websites. When AutoComplete form is enabled, users submitting their email address to website A (input tag with a name attribute of “email”) have their data saved in the browser so that when any other website asks for an email address using a text field of the same name (i.e. “email”), the remembered values will appear in a convenient down-down menu. When a user selects one of these previously submitted values, by either mouse-click or the enter button, it is AutoComplete’ed into the text field. Put simply, the names, addresses, credit card numbers, and so on provided to website A are made available by the browser in the AutoComplete menus of website B, C, D, etc. One key exception is if website A has marked their forms or input tags with autocomplete=“off”, but users cannot rely upon this measure.

<* form>
<* input type="text" name="name">
<* input type="text" name="company">

<* input type="text" name="city">

<* input type="text" name="state">

<* input type="text" name="country">

<* input type="text" name="email">
<* /form>


Activating the UI AutoComplete functionality (drop-down) requires a user to type the first character of a remembered value (behavior is search-like), double-click into the field, or by pressing the down arrow while focus is within the field. It is the down arrow functionality that can be taken advantage of to perform an AutoComplete data theft.

Down-Down-Enter
All a malicious website must do is create a text field with a commonly used attribute name, again such as “email,” then dispatch a series of down arrow and enter keystroke events with javascript. By initiating Down-Down-Enter, the first AutoComplete value of that field becomes accessible to javascript where it can sent to a remote location. As shown in the live demo proof-of-concept code & video below, this process can be scaled out to steal the data from dozens of text field names in seconds, obviously representing a major breach in online privacy and security.

This issue could be further leveraged in multistage attacks including email spam, (spear) phishing, stalking, mass data collection, and even blackmail if a user is de-anonymized while visiting objectionable online material. Such attacks could also be easily and cheaply distributed on a mass scale using an advertising network where likely no one would ever notice because it’s not exploit code designed to deliver rootkit payload. This no guarantee or effective way to determine if this has not already taken place.

At this point it is very important to emphasize two key facts. 1) This issue affects only IE 6 & 7. While IE 8 & 9 also possess the AutoComplete forms feature, they are immune. This makes the number of Internet Explorer users that are safe from this vulnerability about the same as those exposed. 2) The AutoComplete form feature is NOT enabled by default in IE 6 & 7, bringing the affected rate under 100%. To be affected, users would have had to manually turn on the feature in the preferences or by clicking “Yes” when the browsers asks if they’d like to do so after filling out a non-password form. When considering the second method of activation it should be reasonable to assume that a nontrivial number of people are affected. User are often inclined to click “Yes” to a browser recommendation, especially ones providing such convenience. Also, nothing suggests to the user that they should turn off AutoComplete at any point or that it is even on, so presumably they’d forget about it.

File this hack under yet ANOTHER reason for people to abandon IE 6 & 7, which have been very hazardous to user security for quite some time. So while the obvious answer is to simply “upgrade” to IE8, Chrome, FF, etc. for a variety of reasons nearly 1/3rd of the Web hasn’t or can’t yet do so. Fortunately in this case all a user must do to protect themselves is disable AutoComplete in forms.

Proof-of-Concept Video & Live Demo:



// hit down arrow an incrementing number of times.
// separate with time to allow the GUI to keep pace
for (var i = 1; i <= downs; i++) { time += 30; // time padding keyStroke(this, 40, time); // down button } time += 15; // time padding keyStroke(this, 13, time); // enter button // initiate keystroke on a given object function keyStroke(obj, code, t) { //create new event and fire var e = document.createEventObject(); e.keyCode = code; setTimeout(function() {obj.fireEvent("onkeydown", e); }, t); } // end keyStroke


Interesting Disclosure Process

I had been researching browser auto-complete security and discovered the issue during the summer of 2009. After searching around and conferring with a couple of trusted colleagues, nothing suggested this particular issue had be previously disclosed. Feeling confident in my work, I disclosed the findings to the Microsoft Security Response Center (MSRC) on December 14, 2009. A human, imagine that eh Apple, responded the same day to say thanks and report they were actively investigating.

Over the next few days and weeks Nate and Jack from the MSRF were able to confirm the bug, verified the exposure, and kept me nicely appraised of the expected patch dates. The patches were delayed once or twice, but they kept an active dialog open. They politely asked if I could refrain from publicly publishing the materials until a patch was made available. Sure no problem, this vulnerability had been out there for about decade anyway, a couple months was no big deal. Plus, it was scheduled to be fixed long before BlackHat USA 2010 so it could safely include it my presentation.

This is when something really interesting happened.

Remember when I said nothing turned up in search engines results and no one else seemed to have recalled a similar discovery? Well in April, three or so months into the disclosure process, the MSRC shared a link privately discussing something very similar. If fact, it was damn identical! Andrea Giammarchi, member of the Ajaxian Staff, actually had found and published this issue on their blog back in September of 2008! That’s roughly 9 months before I found it independently and about nearly 1.5 years before disclosure to the MSRC. Completely unbelievable. Yet another example how often discoveries relating to security are made, missed, and rediscovered by others. Great find Andrea! Wish we all saw it sooner.

11 comments:

Kyler IE Outreach Team said...

Another good reason to upgrade to the latest, safest version of Internet Explorer.
You can download Internet Explorer 8 here:

http://www.microsoft.com/windows/internet-explorer/worldwide-sites.aspx

Anonymous said...

IE6 and IE7 let Javascript create synthetic keypress events and send them to the browser, as though the user had typed them? That's sick. Do other browsers allow that?

Seems like the broader lesson is that allowing Javascript to ever programmatically create UI input events is a really bad idea. It throws the trusted path principle to the wind.

Paul Stone said...

I found pretty much the same problem in Firefox last year:

http://www.mozilla.org/security/announce/2009/mfsa2009-52.html

At the time I also checked IE8 and Chrome to see if they were vulnerable. After finding that they weren't I moved onto other things, but it seems I should have been more persistent :)

soroush said...

Nice implementation again :)
Some vulnerabilities really need to have proof of concept to be fully discovered! I think by searching in google we can find some other 0day (design flaws) as well! but it is not easy sometimes to implement them correctly ;)
Although a bug is not something that we make it ourselve, we can look at its finding process as a patent :D
Thanks for sharing some cool ideas.

Notice Forms said...

I have still been using IE 6, After reading this article, i have downloaded IE 8 and feeling save..you were really great in helping the people using IE. Are the other browsers like Mozilla and opera safe to use?

Jeremiah Grossman said...

@Kyler: Indeed. maybe if the Web just becomes simply too hazardous for IE 6/7, people will finally move. We'll see.

@Anonymous: That is exactly the case. Somehow the browser developer needs to be able to determine the difference between real UI events and synthetic ones. And yes, other browsers have been shown vulnerable.

@Paul Stone: You know, I that that disclosure when I was doing all my research last year! Nicely done. :)

@soroush would be nice if we had an easier way to crawl the web too see if the black hats were using these things. maybe some day.

@Notice Forms: Anything modern is safer than IE 6/7. Google Chrome, Firefox 3.7, IE8, etc. They all have security/privacy trade-offs, but overall solid browsers.

Anonymous said...

Jeremiah, let me elaborate on my comment. I want to push on this harder. I think it's important to do a root-cause analysis on these kinds of security vulnerabilities. It's not enough to stop at fixing a single bug: we should always be asking ourselves what we can do to take an entire category of security bugs off the table. And in this case, it looks like the autocomplete bug illustrates a deeper architectural flaw in the handling of input events.

The short-sighted way to react to this bug would be to say "Oh, the browser provides a way for developers to check each input event to determine whether the input event is real or synthetic. The developer should have checked whether the event was synthetic before acting on it, but didn't; there's your problem. Pilot error. As long as developers always check for synthetic events everywhere they read an input event, all is well." That's short-sighted, because it is an unsafe-by-default architecture.

I think what I'm hearing is that, the way IE is implemented, synthetic input events internally look identical to real input events, unless the developer adds some extra code to check specifically for that. Well, to me that seems nuts. From a security perspective, it sounds like a poor design decision.

If I'm understanding right, why aren't people jumping on this architectural flaw? It sounds like this is an issue of broader significance than just this autocomplete bug: as long as browsers use such an architecture, then we should expect to continue to see bugs of this sort.

It also sounds like it's not just IE; it sounds like Firefox may use a similar architecture. See, e.g., bug #511615 and the fix (which is to sprinkle checks if (!IsEventTrusted(aEvent)) in dozens of places -- what are the odds that they got every place that needs it, and that this will remain true as Firefox code evolves?). So it sounds like Firefox is also using a rather dubious architecture.

Am I missing something? I know very little about browser internals, so I'm trying to infer from what information I can find -- and maybe my inferences are faulty.

Zuk said...

https://bugzilla.mozilla.org/show_bug.cgi?id=534541

Bruteforcing domains to get all passwords/usernames.

reported it 9/10 month ago, they didn't understand it at first post, but later they did.

Enjoyed the talk anyway!

Itzhak.

Jeremiah Grossman said...

@Anonymous: While not directly familiar with browser internals (the code), I'd largely agree with your assessment. Asking a browser developer to constantly do checks for synthetic events is also just asking for mistakes -- major security mistakes. Various vendors would be wise to have a deeper look into this, but I have no idea if they are or not. BizLog vulns like this have not been historically popular to get the bottom of.

Thanks for your comment!

Please email me if you can for a follow-up...

Pedro Laguna said...

I don't know if you know/try this but I create sometime ago a quick demo to steal logging details from IE: http://www.equilibrioinestable.com/ie8/

Cheers!

D. Ebt Relief said...

This is first time I am listening this thing first time that how some one can steal the auto complete form data. But it can occur in many countries.