September 24, 2018

Comments

  1. Anything that adds usability overhead to password manager auto-fill feels like a challenging proposal. (And user opt-out is always a relatively ineffective control to mitigate systemic issues like this.)

    But what about auto-applying the write-only property to a form as soon as it’s been auto-filled? In other words, once the browser has auto-filled a field, the field is considered to be in a locked-down state with no further DOM access. That could create some publisher pain for those who are using JS to access the email field in legit ways to instrument a better login form, but that would be putting the burden on a small class of websites, and not on users using auto-fill.

    • Gunes Acar says:

      That sounds like an interesting idea to explore. One can imagine autofilled credentials are not needed to be checked for password strength or duplicate usernames – common cases of legit script access to login forms. Still, one needs telemetry or web measurement data to back this up.

      The question is whether browsers will ever ship write-only elements or similar protections 🙂

  2. Here, firefox addon Privacy Badger (PB) immediately flagged rawgit.com as a tracker and blocked the sniffer script. Probably it was known before? Sadly, it is not really an option to recommend PB: users do enjoy the faster page-loads, but when a site breaks, and that can happen, they are clueless at first, and then annoyed by the fact, that PB cannot read their minds and so they have to manage something; even though the PB interface is quite easy to use, IMO.

  3. Jeffrey Goldberg says:

    Disclosure: I work for AgileBits, the makers of 1Password.

    1Password is not vulnerable to this attack specifically because we have never allowed for “automatic autofill”. (Despite strong user request for such a behavior.) 1Password will automatically fill a form on the user’s command, but never without some user action.

    We’ve required user action precisely because we consider the web page to be a very hostile environment. What David Silver refers to as “sweep attacks” have been known about both in theory and practice for quite some time. But even prior to learning of those, we felt that user action should be required.

    Here is something I wrote in 2014 in response to some of the many customer requests for more automated behavior.

    https://discussions.agilebits.com/discussion/comment/153916/#Comment_153916

    • Kevin Blake says:

      That was what I thought when I read about this on BGR, but they specifically called out 1Password and LastPass browser plugins:
      “To quickly fill in usernames and passwords saved in a password management app like 1Password and LastPass, you have probably installed browser addons. It’s those tiny browser apps that are targeted by scripts.“

    • Anonymous says:

      If the 3rd party script is on a login page (which happens less according to the analysis, but still happens), a user might use the 1Password keyboard shortcut to fill in the legitimate form. Will 1Password fill in the credentials into the fake form too?

    • Donald Wardlaw says:

      1 password does indeed autofill some sites I go to, including banking sites. I don’t understand Goldberg’s comment

      • Anonymous says:

        You must have had some other password manager (most likely that built-in to the browser) save those passwords if they’re being filled with no interaction on your part. 1Password indeed does not fill anything until you ask it to. It has no option to autofill a password upon page load.

  4. I’ve tried the demo, but after sending the fake e-mail/password I’ve got an error page (404) only…
    At the next try it was working, but the result is two question marks 🙂
    (I use Firefox with NoScript addon)
    But you’re right, if I allow running JS from rawgit, then it can steal my e-mail-password couple.
    It is a little bit scarie… 🙁

    • I use LastPass on Firefox but I also got 2 question marks – even with auto fill enabled.
      Have I done something wrong?

  5. Per the 1Password comment above, would something like LastPass, with autofill enabled, also be vulnerable? I am guessing it would be.

  6. Craig Lurey says:
  7. Graham Stanton says:

    This is just one way you can be tracked online by third-party services. Plugging this “hole” wouldn’t do much to stop the tracking.

    The standard way to integrate with a third-party network is for the site owner to place HTML code (either JavaScript or even an IMG tag) that sends the site’s own cookie ID for a user to the third party. The site can via a server-side API call, or via an offline batch process, send all user information associated with that cookie ID to the third party. The third-party code doesn’t need to “scrape” anything for this to work.

    Of course, this requires cooperation of the primary website. But any site including tracking code is already working with the tracker.

    • Gunes Acar says:

      Fixing this would also protect against malicious scripts that exploit the same vulnerability through XSS attacks or malvertising campaigns. The server-side communication is possible, but costly compared to including one line of JavaScript.

  8. I am bit Confused here, Is it possible to extract and send all stored credentials within the browser’s password manager OR only the credentials for that particular site(In which the tracking script is not present on the login page) which user has visited can be possible?

    Thanks
    Ankur

  9. KeePass combined with the extension can autofill the password if the autofill is enabled (configurable through the extension).

    For Gecko-based browsers, there is signon.autofillForms option in about_config that can prevent the attack.

  10. Thanks for your fine efforts on this subject.

    Are there any legal minds in the group who can explain how this scripting and password capturing is NOT a violation of telecommunications intercept laws? Did we give away those privacy rights in a user agreement somewhere?

    https://www.law.cornell.edu/uscode/text/18/2511

  11. Hi,
    My website is listed as a website using audienceinsights js script… but I find no trace of this script in my code source.
    So I do not understand how you have found this script on my website and why he is listed in your article…
    Could you please contact me and explain?
    Maybe there is another js using this script but I am not able to find it.
    Thanks for your help
    David

    • Gunes Acar says:

      Hi David,
      Your site embeds media-clic.com, which loads a script from themoneytizer.com, which finally loads audienceinsights.net:
      https://www.excel-downloads.com/
      ->
      https://pub3.media-clic.com/www/delivery/asyncjs.js
      ->
      https://ads.themoneytizer.com/s/requestform.js?siteId=10013&formatId=1
      ->
      https://static.audienceinsights.net/t.js

      Your site (excel-downloads.com) was crawled on 2017-09-13.

  12. AConcernedAussie says:

    I’m not a web-site developer so excuse a my web-dev ignorance, but this scenario stuck me as a potential for exploitation.

    If, through this exploit method described, would it be possible for a site who has embedded (say) Paypal onto their web-page (via a hidden iFrame or a window.open method where the source of the child window is manipulated somehow) to then be able to grab your paypal login credentials since the parent window is able to read (and modify ??) elements of the child iFrame or child window?

    I understand the PayPal detects that it is running in an iFrame, and blocks rendering of any content. But does the same hold for a Child Window and other services

    See http://www.dyn-web.com/tutorials/iframes/refs/iframe.php which demonstrates controlling an iFrame from a parent window.

    • Gunes Acar says:

      Hi AConcernedAussie,

      That’d be a devastating attack but access to cross-origin frames will be prevented by the same-origin policy.
      The post you linked to describes access to frames from the same origin.

      • AConcernedAussie says:

        Thanks Gunes
        My instincts were telling me what you have said, but thought it worth asking 🙂
        The link was for my benefit more than anyone elses, when I started looking at the possible broader outcomes

  13. Has this autofill vulnerability been addressed by the browser manufacturers yet? Anyone know?