Skip to main content
Information Security

Return to Revisions

7 of 7
Documented one more backdoor
Wladimir Palant
Wladimir Palant
  • 927
  • 1
  • 8
  • 12

Disclaimer: I created PfP: Pain-free Passwords as a hobby, it could be considered a LastPass competitor.

I've been looking into the security issues of several password managers on a number of occasions. In particular, I reported twelve security issues to LastPass so far and analyzed the design decisions that led to these. So while paj28 gave a very good general answer about password managers, I can provide some details.

When people talk about the security of online password managers, they usually focus on server security. The focus is on how easy is it to compromise the server and what will happen then. This is only one attack vector however, because attacking your local password manager instance might lead to the same results. In fact, attacking the browser extension might be a more promising course of action, as the data is already decrypted there and you won't leave traces in any logs.

Let me look at these two aspects separately.

Attacking the browser extension

There is a lot of historical data on vulnerabilities in the LastPass browser extension. All these vulnerabilities could be exploited by arbitrary webpages. At the very least, these are:

Did you notice a pattern here? LastPass has been struggling for years to secure their AutoFill functionality and to restrict access to their internal API. Each time a new report proved that their previous fix was incomplete.

Now it isn't unusual that password managers fail to implement AutoFill securely, most of them had issues in this area when I checked. While totally avoidable, these issues are common enough that I even compiled a list with recommendations to avoid the traps.

But the internal API issues are quite remarkable. LastPass exposes this API to websites in a number of different ways. It's meant to be restricted to lastpass.com but the logic is so complex that the restrictions have been circumvented several times in the past. And while LastPass did their best to downplay the severity in their official announcements, each of these issues allowed websites to read out all passwords at once. Worse yet, the last report by Tavis Ormandy proved that the internal API could be used to make the binary LastPass component execute arbitrary code on user's machine. Same could probably be done with all the previous flaws which exposed internal API.

One could of course ask why LastPass failed to restrict access to the internal API properly. But the better question is why this API is exposed to websites at all. That's because a significant part of the LastPass functionality isn't contained in the extension but rather relies on the LastPass website to work. That's a very problematic design decision but so far LastPass didn't seem interested in fixing it.

Attacking server-side data

Let's state this very clearly: we don't trust the server. It's not that we particularly distrust LogMeIn, Inc. - at least not more than any other company. But our passwords are very sensitive data, and even the most ethical company might have a rogue employee. Add to this the possibility that US authorities demand them to produce your data, something that isn't even necessarily associated with a criminal investigation. Never mind the possibility that their servers get hacked, like it already happened once.

So it is very important that your data on the server is encrypted and useless to anybody who can get hold of it. But what can possibly stop the attackers from decrypting it? Exactly one thing: they don't know your master password which is used to derive the encryption key. So the essential question is: does LastPass sufficiently protect your master password and encryption key?

In this area, I am not aware of any publicized research but my own, most of it written down in this blog post. My conclusion here: LastPass suffers from a number of design flaws here, some being resolved by now while others are still active.

Bruteforcing the master password

If the attackers got their hands on a bunch of encrypted data, the most straightforward decryption approach is: guess the master password used to derive the encryption key. You can try an unlimited number of guesses locally, on whatever hardware you can afford, so this process will be comparably quick.

LastPass uses PBKDF2 algorithm to derive the encryption key from the master password. While being inferior to newer algorithms like bcrypt, scrypt or Argon2, this algorithm has the important property of making key derivation slow, so attackers doing guessing locally will be slowed down. The time required is proportional to the number of iterations, meaning: the higher the number of iterations, the harder it will be to guess a master password.

For a long time, the LastPass default was 5,000 iterations. This is an extremely low value that provides very little protection. I calculated that a single GeForce GTX 1080 Ti graphics card could be used to test 346,000 guesses per second. That’s enough to go through the database with over a billion passwords known from various website leaks in barely more than one hour.

Following my reports, LastPass increased the default to 100,000 iterations mid-2018 which is far more adequate. Of course, if you are an important target who could expect state-level resources being thrown at guessing your master password, you should still choose an extremely strong master password.

Getting hold of data to bruteforce

One of my findings in early 2018 was that the script https://lastpass.com/newvault/websiteBackgroundScript.php could be loaded by any website. That script contained both your LastPass username and a piece of encrypted data (private RSA key). With your LastPass username being also the password derivation salt, that's all someone needs to bruteforce your master password locally.

This issue was resolved quickly of course. However, the flaw was obvious enough that I'm left wondering whether I was the first to discover it. While I urged LastPass to check their logs for signs of this vulnerability being exploited in the wild, to my knowledge this investigation never happened.

"Server-side rounds" as useless protection

Following a security incident in 2011, LastPass implemented an additional security mechanism: in addition to your PBKDF2 iterations on the client side they would add another 100,000 iterations on the server. So in theory, if somebody could get data off the server, this would increase the effort required to guess your master password.

In practice, I could conclusively prove that these additional 100,000 iterations are only applied to the password hash. All the other pieces of user data (passwords, RSA keys, OTPs and more) are only encrypted using the encryption key derived locally from your master password, no additional protection here. Conclusion: this additional "protection" is a complete waste of server resources and doesn't provide any value whatsoever.

Getting in through the back door

No matter how weak the protection, brute force attacks will always be ineffective against the strongest master passwords. However, the design of LastPass contains plenty of backdoors that would allow decrypting the data without expending any effort.

The web interface

LastPass conveniently provides you with a web interface to access your passwords without the help of a browser extension. This feature is a trap however: whenever you enter your master password into a login form on the web, there is no way of knowing whether it will hash your master password with PBKDF2 before sending it to the server or whether it will transmit it as clear text.

Remember that we don't trust the server? Yet a trivial modification of the JavaScript code served up by the server is enough to compromise all your passwords. Even if you inspect that JavaScript code, there is too much of it for you to notice anything. And it would be possible to serve up the modified code only to specific users.

Account settings

Even if you use the browser extension consistently, whenever you go to the account settings it will load up the lastpass.com website. Here again, there is no way for you to know that this website isn't compromise and won't steal your data in the background.

Several other pieces of the extension functionality are also implemented by falling back to the lastpass.com website, and LastPass doesn't see the issue here.

Recovery OTP

LastPass has the concept of One-Time Passwords (OTPs) that you can use to recover data from your account if you ever forget the master password. These OTPs allow decrypting your data but aren't normally known to the server.

To make recovery even more reliable, LastPass will create a recovery OTP automatically by default and store it in the extension data. The issue here: the recovery process has been designed in such a way that the extension would immediately give lastpass.com that recovery OTP on demand, without even notifying you. So a compromised LastPass server could ask the extension for your recovery OTP and use it to decrypt your data.

According to LastPass, this issue has been resolved in August 2018. I don't know how they resolved it however, at least I couldn't see any of the obvious solutions in their code.

Exposure of the encryption key

There is also a number of occasions where the extension will directly expose your local encryption key to LastPass servers. This is meant to help web-based LastPass functionality integrate better with the browser extension, but it nullifies the effects of encrypting data locally. The following actions are all problematic:

  • Opening Account Settings, Security Challenge, History, Bookmarklets, Credit Monitoring
  • Linking to a personal account
  • Adding an identity
  • Importing data if the binary component isn’t installed
  • Printing all sites
  • Clicking on a breach notification

The last one is particularly serious because the LastPass server can send you breach notifications at will. So this allows LastPass to gain access to your data whenever they like, rather than waiting for you to use problematic functionality on your own.

More design flaws

  • As you can see by yourself by opening up https://lastpass.com/getaccts.php while logged in, the LastPass vault is by no means an encrypted blob of data. It rather has encrypted data here and there, while other fields like the URL corresponding to the account merely use hex encoding. This issue was pointed out in this 2015 presentation and more fields became encrypted since then - still by far not all of them however. In particular, a report I filed pointed out that Equivalent Domains not being encrypted allowed LastPass server to modify that list and extract your passwords in that way. This particular issue has been resolved in August 2018 according to LastPass.
  • Same presentation scolds LastPass for their use of AES-ECB for encryption. Among other things, it gives away which of your passwords are identical. LastPass has been transitioning to AES-CBC ever since, yet when I looked at my "vault" I saw a bunch of AES-ECB-encrypted credentials there (you can tell because AES-ECB is merely a base64-encoded blob whereas the LastPass variant of AES-CBC starts with an exclamation mark).
  • Recovery OTP being created automatically and stored in the extension data means that anybody with access to your device and email address can access your LastPass account. This is actually documented and considered a low risk. Maybe one of your co-workers played a prank on you by sending an email in your name because you forgot to lock your computer - next time they might take over your LastPass account even if you are logged out of LastPass.
  • Speaking of being logged out, the default session expiration time is two weeks. While certainly being convenient, there is a reason why most products handling sensitive data have much shorter session expiration intervals, typically well below one day.
  • For combining a value with a secret (e.g. as a signature) one would usually use SHA256-HMAC. LastPass uses a custom approach instead, applying SHA256 hashing twice. While the attacks that HMAC is meant to address don't seem to play a role here, I wouldn't bet on somebody with better crypto knowledge than me not finding a vulnerability here after all. Also, the server side will occasionally produce some SHA256 tokens as well - I wonder what kind of humbug is going on where I cannot see it and whether it's really secure.
Wladimir Palant
  • 927
  • 1
  • 8
  • 12