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.