Password managers: Attacks and defenses Silver et al. USENIX 2014

As a regular reader of The Morning Paper, I’m sure you’re technically savvy enough to know not to use the same password across all the websites you use. To make good quality site-unique passwords practical therefore, you probably use a password manager. Maybe you remember that slight feeling of unease you had when you first started using one, since it puts all of your passwords in one place (and then for many password managers, syncs that ‘one place’ across devices and the cloud). Still, it’s better than the alternative right? In ‘Password managers: attacks and defenses,’ Silver et al. show us that many password managers contain one major vulnerability. Unfortunately, that vulnerability is the fact that they can be used to (auto)fill in password fields! Since this is a 2014 paper, it’s possible several of the attack vectors described have subsequently been closed (if you know of an updated report on this, please let us all know in the comments). My suspicion is that variations of these attacks remain.

TL;DR – don’t use autofill.

The evil coffee shop attacker

The attacker is assumed to be able to enact an active man-in-the-middle network attack – i.e., to interpose and modify arbitrary network traffic originating from or to a user’s machine. However, there is no requirement that the user explicitly visit or login to any particular site in order to steal the credentials for that site.

A rogue wifi router in a coffee shop (for example) is all that is needed – connect to it and your passwords could be gone.

We call this type of attacker the evil coffee shop attacker. These attacks require only temporary control of a network router and are much easier and thus more likely to happen in practice…. In many of our attacks the user need not interact with the victim web site and is unaware that password extraction is taking place.

Sweep attacks

The basic sweep attack works against any password manager that supports autofill of password fields. The target user connects to the WiFi hotspot controlled by the attacker.

When the user launches the browser, the browser is redirected to a standard hotspot landing page asking for user consent to standard terms of use. This is common behavior for public hotspots. Unbeknownst to the user however, the landing page contains invisible elements that implement the attack.

In other words, by the time you’re looking at the fully loaded landing page, most of your credentials could already be gone – in tests, about ten passwords can be extracted per second.

There are three basic ways the attacker can use the landing page to sweep passwords:

1. In an iFrame sweep attack the landing page contains invisible iFrames pointing to arbitrary pages at multiple target sites. When the browser loads the frames, the attacker injects a login form and javascript into each of them (we’ll look at ways of doing that next). An autofilling password manager kindly auto-populates the corresponding password field with the user’s password.
2. Instead of using iFrames, the attacker can use multiple windows instead. by requiring a window to open before the user can gain access to the wifi network, the user can be encouraged to disable any popup blocker. Multiple windows will be more noticeable than invisible iFrames, but injected javascript can e.g., minimise them, or hove them to the edge of the screen. They can be closed as soon as the password has been stolen.
3. The third approach is to use a chain of redirects. When the user requests some page, the attacker responds with a redirect to a site for which the attacker wishes to learn the password. The injected javascript adds a login form, and hides the page details. As soon as the password manager autofills the password and it has been exfiltrated, the browser is redirected to the next target site, and so on in a chain, eventually loading the user’s originally requested page. The user sees a slow wifi connection…

As of 2014, the following table shows the tested password managers and which were vulnerable to these sweep attacks:

Injection

Sweep attacks rely on the attacker’s ability to modify a page on the victim site by tampering with network traffic. The attacks are simplest when the vulnerable page is the login page itself. However, any page that is same-origin with the login page is sufficient, as all password managers associated saved passwords with domains and ignore the login page’s path.

One easy setup to attack is sites that serve a login form over HTTP (bad practice), and only use HTTPS for the submission. As of October 2013, 17% of Alexa Top 500 sites with login forms did this. I’d like to think the number is less today but I don’t have the data.

Any HTTPS webpage with active content fetched over HTPP is also vulnerable (most browsers block this). Any XSS vulnerability on any page of the victim site will also work (even if the login page is served over HTTPS). In fact, an XSS vulnerability anywhere on the site enables the attack without even needing a rogue WiFi – so long as the web attacker can lure the victim into visiting a site the attacker controls.

Broken HTTPS connection (e.g. bad certificates) also lead to vulnerabilities as an attacker can serve the modified login page using a self-signed certificate. The browser will complain, but the user will often click through the warnings (especially when they occur as part of logging onto a WiFi network – or so they think).

A special prize goes to embedded devices which serve login pages over HTTP expecting to be on a private network protected by WiFi encryption, or (e.g.,) home routers that serve login pages over HTTPS but use self-signed certificates.

Exfiltration

Once the javascript in the attackers page has the desired password, exfiltration is pretty straightforward. One approach is to load an invisible iFrame and pass the credentials as parameters, another is to modify the action of a login form to submit to an attacker-controlled site.

What if your password manager doesn’t autofill?

All of the attacks described thus far take advantage of automatic autofill password managers to work when the user does not interact with the login form. However, the exfiltration techniques we described work regardless of how the login form was filled. If the user’s password manager requires user input to fill password and an attacker can trick the user to interact with the login form without them realizing it, the same exfiltration techniques can be used to steal the password as soon as the password form is filled.

The authors describe a clickjacking attack that can work in this scenario – although of course we are now limited to stealing only one password at a time.

Supporting weaknesses in password managers

A number of password manager behaviours beyond simple autofilling help the attacker, these mostly seem to fall into the camp of password managers trying to be robust to changes in site implementation details. The following table provides a short summary, see section 2 in the paper for the longer explanation regarding each column.

Defenses

The main proposed defence is secure filling, which requires a modified browser (and modified password managers to work with the modified browser).

if a login page is loaded over HTTP but submitted over HTTPS, no browser or password manager implementation provides security once the login form has been filled with the user’s password: JavaScript can read the password directly from the form or change the form’s action so that it submits to a password stealing page hosted by the attacker. The goal of secure filling is that even if an attacker injects malicious JavaScript into the login page, passwords autofilled by the password manager will remain secure so long as the form is submitted over HTTPS.

Secure filling requires:

1. The password manager to store the action present in a login from when username and password were first saved
2. When a login form is autofilled by a password manager, it becomes unreadable by JavaScript (hence the requirement for a modified browser).
3. If username or password fields are modified (by the user or JavaScript) while an autofill is in progress, the autofill aborts clearing the password from the password field and making the field readable agin.
4. Once a form with autofill is submitted and after all JavaScript code that is going to be run has run, the browser checks the form’s action matches the stored one and only submits if so.

Note this would also mean, for example, that we need to treat initial registration pages specially as they often include client-side validation of password strength (requiring js access).

We disclosed our results to the password manager vendors, prompting several changes to autofill policies. Due to our findings, LastPass will no longer automatically fill password fields in iFrames, and 1Password will no longer offer to fill passwords from HTTPS pages on HTPP pages.

There’s a recent and relevant post from Khad Young at 1Password explaining why 1Password doesn’t offer autofill capabilities that also discusses sweep attacks.