Password managers: attacks and defenses
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.
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.
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:
As of 2014, the following table shows the tested password managers and which were vulnerable to these sweep attacks:
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.
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.
The main proposed defence is secure filling, which requires a modified browser (and modified password managers to work with the modified browser).
Secure filling requires:
- The password manager to store the action present in a login from when username and password were first saved
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.