Cenzic 232 Patent
Paid Advertising
web application security lab

Stealing User Information Via Automatic Form Filling

One of the most annoying things for many users is filling in form fields on websites. It’s tedious for them to type the same information over and over again, especially when it’s something a simple as a their personal information like name, phone number, address, credit card number, expiration date, and the like. Unfortunately this can spell trouble for many users who use websites that are vulnerable to XSS.

Some (not all) automated input automation tools do so blindly. That is, they don’t ask for user input when they input data. In fact they don’t really do much validation at all, except the names of the common form fields. So what does the attacker do? They create a form submission inside their XSS script with all the common field names that they are interested in. Once the automated input box enters all that information it captures it and logs it.

The best part is the form submission does not have to be visible. In fact, it probably works better if it’s not, because then it is highly unlikely to raise suspicions. It’s really not phishing, as it doesn’t actually require the user to believe anything, as the social engineering portion of the attack is not there (assuming the XSS itself doesn’t require it). As such you can steal user information through any page, as long as the automatic form submission requires no user input to fill the form.

14 Responses to “Stealing User Information Via Automatic Form Filling”

  1. Legionnaire Says:

    I’d never thought of that but, nevertheless, always considered it as a very bad idea. Having all your personal details (including credit card info) stored in some place in your PC doesn’t seem like a wise decision. Another con of this is sharing a computer with other people. Once they visit a website requiring user details they will be presented with your own!

  2. RSnake Says:

    I agree completely. In some way or another they have to be converted back into plaintext to be sent to the server, which means they aren’t particularly protected. All it takes is some vague browser vulnerability to get me to click on something I don’t want to and poof, all my information is stolen. I think I’ll just type it out by hand. Call me crazy!

  3. WhiteAcid Says:

    How about using this to find the routers details. I image people either leave their router details as default or change it but have their browser remember it for them (I don’t, but that’s different).

    This is an awesome idea though.

  4. WhiteAcid Says:

    Wooo. I’ve used this (in a PoC, non evil) XSS and it worked. Given that it’s now almost 6am and I started around 2am I’m pretty damn happy, and hungry.

  5. elitemofo Says:

    OK, I am assuming this is now a legit reason to disable AutoComplete, what about the new browsers where “AutoComplete=off” does not work to prevent the storage of HTML form information, is this PoC you developed WhiteAcid still working?

    Please post the details of which browsers you tested your PoC under. I am interested from a developer point of view.

  6. WhiteAcid Says:

    I guess I was too tired to post a link. I still haven’t slept, but here you go:
    http://sla.ckers.org/forum/read.php?2,131
    It’s a very messy PoC because it’s on a real site (as opposed to a test site) and some ajax was required. I now realise it could have been done much better, but I’m not in the mood to make the code neater.

    You could leave AutoComplete on but set it to remember only part of your password, means there’s leff for you to remember.

  7. ha.ckers.org web application security lab - Archive » Programmatic Password Theft Is Back Says:

    […] The title of this post was going to be “we weren’t slashdotted again” but I thought that was just a little too sarcastic. Yesterday Slashdot ran an article on password theft via XSS. If this looks familiar it’s because it is. We have been talking about this for a few months here and here. I’m not bitter, but the information on slashdot is incorrect. The first example of this was actually built in a lab environment nearly two years ago and we’ve been talking about this since August. But who’s counting? […]

  8. pagvac Says:

    Another PoC and attack walk-through tested on FF 2.0:

    1. Enter any fake credentials on
    http://ikwt.dyndns.org/projects/RCSR/legit_form.html and click on “Login”

    2. If “Remember passwords for sites” is enabled, FF should prompt you to save the password.

    3. Click on “Remember”

    4. Now, in order to illustrate that FF will automatically fill in the
    credentials on any form located on the same site which uses input
    names *equal* the the legitimate form access the following URL:

    http://ikwt.dyndns.org/projects/RCSR/evil_form.html

    If it worked, you should see the username and password field filled in automatically by FF. Of course, an evil form like this looks very
    suspicious, but this is just an example to make the point that FF
    trusts and fills in the form simply because it’s located on the same
    site and uses input names equal to the legitimate form.

    Now, in order to make our evil form more effective we just added the following line the in the username and password fields:

    style=”display: none;”

    Finally, we change our submit button for an image that will make a
    good bait. In this case we choose beautiful Scarlett Johansson :-)

    If you click on the image, you should see your credentials forwarded
    to Google within the URL:

    http://ikwt.dyndns.org/projects/RCSR/evil_form_2_without_JS.html

  9. Jungsonn Says:

    @pagvac

    That’s an excellent example! it’s really scary also. I think you can automate it also with a little javascript that sleeps for 10sec. and then submits the form with XHR in an iframe. Pow!

  10. SecuriTeam Blogs » Firefox 2.0.0.1 - no fix to Password Manager flaw yet Says:

    […] New Firefox version 2.0.0.1 arrived with no fix to Password Manager Information Disclosure vulnerability. This issue was reported on 21th November with this news-type report. Ha.ckers Blog wrote about the problem in August already. The related Bugzilla Bug #360493 was opened earlier, by Robert Chapin too. […]

  11. maluc Says:

    yes, it can easily be done with javascript using document.getElementById(’formId’).submit() .. instead on using a long timer, just check with timeouts every 100miliseconds, if document.getElementById(’usernameId’).value isn’t blank

    however, pagvac’s is a great social engineering way when javascript isnt allowed, but html is.. or if people are surfing with javascript off (although you’d need a persistent HTML on the attack site then)

    very clever. and will work for myspace

  12. maluc Says:

    Unfortunately, it won’t work on myspace.. because profiles are on profile.myspace.com and you login on login.myspace.com or www.myspace.com

    But it still makes for a useful PoC viewable here http://www.myspace.com/140890831

    normally, instead of showing a blank .gif you would redirect them to the profile instead - so no one would be the wiser. disabling javascript won’t save them on this one.

    Wordpress won’t let me post the code, but it’s no different than pagvac’s method.

  13. cahdito Says:

    whay the internet is more vulnerable than private network, highlightind password vulnerabilities

  14. Phil Says:

    I had an incident once, I was browsing a website when a script took the browser to paypal, as my Master Password had already been entered into the browser previously My login and Password autofilled in and OK selected then it took me to a payment page with a few hundred quid on, luckily I had NOSCRIPT and it interviened. Otherwise it would have clicked OK and I could have posted the details!!