Couple of weeks back Jeremiah Grossman posted details of his Safari Auto-Complete hack along with a really cool POC. To me the most interesting aspect of the POC is how it populates the text box with JavaScript, simulating the victim’s keystrokes.
I ran the POC in Google Chrome and as each character was entered in to the Input box, there was a list of auto-complete suggestions that popped-up. The amount of information that was in those lists was scary. Jeremiah’s POC was not designed to capture the information in the auto-complete suggestion lists, it was only looking for values that got populated in to the textbox.
I initially though it must be relatively easy to capture the information in these lists by simulating a down arrow keypress and then an enter keypress to populate the textbox. But that approach didn’t work because the list that pops up is not part of the DOM, so JavaScript has absolutely no control over this list. Infact moving the mouse over this list or pressing the arrow keys to move through the list of suggestions does not even trigger the Mousemove / KeyDown events.
After playing around for sometime I figured out one way to extract the information from the auto-complete suggestion list. This technique is not entirely automated but it only requires minimal user interaction. The user only has to press the enter key periodically and the rest is done with JavaScript. And to Social Engineer the user to press the enter key, I have written a simple game where the user is randomly shown either a white or a black box and asked to press enter when the black box is shown and do nothing when the white box is shown. The end result is actually pretty convincing.
This is how it works:
User is asked to place his mouse pointer in one section of the page. By following the mouse movement we know exactly where the pointer this is located.
We create an input element of very small width (3px) and position it just a little above where the mouse pointer rests.
Now using the same method used by Jeremiah a character is entered in to the input box.
When the auto-complete suggestion list pops up, the first entry in the list is now right under the mouse pointer and is highlighted automatically.
When the user hits enter (he thinks he is playing a game) this entry is populated in to the input box and is read by JavaScript.
Now the Input box is moved a little upwards and step 3 is repeated and this time the mouse pointer is over the second entry in the suggestion list and it is highlighted.
Step 3-6 are repeated till all values are read.
As you can see the only interaction from the user is hitting the enter key periodically. Chrome allows a maximum of 6 auto-complete suggestions per character and if the user plays the game for a couple of minutes the entire auto-complete suggestion data can be stolen by the attacker.
The POC works best in Google Chrome running on Windows. Because in this set-up an Input element of 3px width has an auto-complete suggestion list also of 3px width, it only looks like a thin white strip. And with a cleverly selected background this 3px strip is camouflaged and becomes practically invisible as done in the POC.
In Google Chrome running on Linux (thanks to Mario for verifying this) the width of the auto-complete box is not affected by the width of the input element, so even if the input element is of 3px the pop-up list is of its normal width. It’s the same story with Firefox even on Windows. If the list is of its normal width then it cannot be hidden from the user, CSS overlay techniques don’t work, and the attack becomes very obvious for the victim to see.
Another factor that makes this attack possible is that when the pop-up list appears, the ‘mousemove’ event is triggered automatically and so the entry under the mouse pointer gets selected without the user having to move the mouse. I am not sure if this is a Google Chrome specific behavior or is common to all browsers, haven’t tested that yet.
The POC is available here and there is also a video if you would like to see the attack in action.