Last Call for LastPass

We examine the flaws endemic to LastPass' product, and their bungled response to and disclosure of their recent compromise.

Jan 07, 2023

As many of you would have already heard, the August breach of LastPass was revealed to have been much worse than originally thought with unencrypted customer data and encrypted password vaults now confirmed to have been nicked by the attackers.

It's hard to see how this update - the third since their initial disclosure of the breach - wasn't designed to obfuscate the impact and shift blame to customers, with its release coinciding perfectly with the beginning of the end-of-year holiday season.

I've held off on publishing anything on the topic as I was hoping LastPass would come clean on their shoddy handling of the disclosure, but despite a deluge of bad press on the matter, they've kept silent.

Hence, this post.

I'll start with a quick summary of what's happened so far, before highlighting the impact LastPass' systemic inaction and evasiveness has had on their customers and business. I’ll close by addressing the ongoing viability of LastPass as both a product, and a vendor, and what this means for the future of password managers as a security measure.

TL;DR:

After discovering evidence of compromise in their developer environment in August 2022, LastPass investigated and reported they evicted the attackers after just four days - no customer data/password vaults were affected, and the hackers only got their hands on a bit of source code and some "technical information". No worries.

Except that despite claims by CEO Karim Toubba that the network was "physically separated" and that they had since deployed additional "enhanced security controls" and monitoring, we've now learned that the attackers were somehow still able to pivot into their cloud-based storage and retrieve the very data LastPass was meant to protect - customer password vaults.

Their latest advisory found the attackers leveraged the information stolen from their original compromise of their development environment in order to obtain "credentials and keys [from another employee] which were used to access and decrypt some storage volumes within the cloud-based storage service."

While unknown, it's possible this lateral movement could have been achieved through something as simple as a hard-coded password in a script, pilfered from the development environment in the initial intrusion.

What went wrong?

When considering the events that brought us to this point, a number of failings are apparent in three distinct areas:

The product - specifically, its use of outdated and inconsistent encryption implementations and master password complexity requirements. Futhermore, LastPass' assurances that the hackers would have trouble cracking stolen password vaults hinges entirely on customers adopting "best practices" for security;
The response - the security team appear to have fixated on securing their source code and Production environment. This diversion of resources ultimately meant they were unable to mitigate or identify the attacker's lateral movement into their cloud environment and consequently - to secure their crown jewels;
The disclosure - getting lawyers to draft a damage-minimising advisory that shifts blame and understates the risk to users; releasing it three days before Christmas and without any meaningful outcome or means of recourse for customers.

Insufficient PBKDF2 iterations

The LastPass advisory claims their product uses a "stronger-than-typical implementation" of 100,100 cycles of the PBKDF2 algorithm to salt and hash master passwords, in order to increase their resistance to password cracking.

Not only is their implementation unremarkable when compared to other password manager offerings (e.g, the free BitWarden product uses 200,001 iterations) - it's much less than the 310,000 iterations recommended by the OWASP standard.

Moreover, LastPass only implemented this in 2018, with accounts created prior to that still only configured with the previous 5,000 iterations, making it exponentially easier for their master passwords to be brute-forced.

Worst still - some users have reported their accounts were configured with as few as 500, and even as little as one iteration (yes, a single iteration - the bare minimum) applied to their master password.

Infosec veteran Wladimir Palant has shared this detailed explanation that illustrates the potential consequences of these legacy settings. See below for a key extract from his post:

Figure 1: The average password can barely be considered “protected” by previous iteration counts

Legacy Password Requirements

LastPass currently requires a 12 character master password - increased from 8, back in 2018.

This change was never enforced for existing accounts, with prior users still able to log in using eight character passwords and having never received a prompt or notification warning them of the change.

While four characters may not seem like much, it could potentially increase the time taken for a single RTX 3090 GPU to crack a complex, PBKDF2-protected password up from 10 years to 363 million years.

Figure 2: Password table for cracking a PBKDF2 hash function using an RTX 3090 GPU.

Considering the attackers will likely have more than one graphics card at their disposal, and that some users are bound to have inadvertently used passwords present in public wordlists - those four characters may just mean the difference between compromise and safety for many customers.

Unencrypted URLs & metadata

The attackers were able to exfiltrate a significant amount of sensitive customer metadata, namely:

Company names
End user names
Billing addresses
Telephone numbers
Email addresses
IP addresses which customers used to access LastPass
Website URLs from password vaults

All of these metadata fields were left unencrypted - by design - in LastPass.

Wladimir Palant cites three instances - in November 2015 (page 67), January 2017 and July 2018 - where LastPass were warned that they needed to encrypt URLs and other metadata fields in their product.

As we can see from this breach, LastPass elected to ignore those warnings.

For the hackers, the utility of this information - particularly given their theft of encrypted password vaults - is significant.
It would allow an attacker to:

Prioritise their cracking of vaults for users with company names, email domains, or URLs of interest, for example to:
1. Gain access to sensitive or valuable networks by abusing valid remote access credentials;
2. Siphon funds from customer internet banking accounts, crypto-currency wallets, etc.;
3. Access, search for, and exfiltrate sensitive content from email accounts, or simply hijack them to conduct highly-credible phishing campaigns;
Potentially re-use password reset links that are still valid and hijack accounts;
Perform highly targeted Phishing/Vishing of users based on their sites and associated metadata.

While encrypting URLs might typically be considered overkill, its value is significantly higher when it provides the means for an attacker to easily parse and abuse stolen password vaults.

The likelihood of any one of the above scenarios happening is high, and the impact potentially severe. This is absolutely something which should have been caught in the Threat Modelling phase of LastPass’ product design process.

The issues I’ve highlighted above are just the more well-known ones - this post highlights a litany of additional flaws throughout LastPass that every user should be aware of.

The attackers were able to rummage around LastPass' developer environment for four days, stealing source code and "technical information" that they later used to pivot into the cloud storage environment and steal customer metadata and password vaults.

The full intrusion took place over the period of four months, and while LastPass claim to have increased monitoring and deployed additional security measures, it seems to have been focused in the wrong area.

Don't follow the bouncing ball

LastPass CEO Karim Toubba was very intentional in emphasising that the Developer environment was segmented from Production, reassuring customers that only "portions" of source code were impacted; that the attackers had been evicted, and they had taken steps to prevent further attacks.

Given the attackers were observed going after and obtaining LastPass source code in their initial attack, the assumption was likely made that this was their primary objective. Given this, their security teams would have been directed to prioritise protecting it from further unauthorised access, and ensuring the actors never made it to the Production environment.

While seemingly logical, this highlights two points of failure in their response:

They followed the bouncing ball, focusing on protecting their source code while neglecting to consider the need for increased monitoring and hunting for anomalous access to their other crown jewel - customer metadata and password vaults;
They fixated on enforcing and monitoring the boundary between Development and Production environments, neglecting to consider the security of other environments such as their cloud storage.

While assumptions have to be made when deciding how to respond to an incident, defenders need to be mindful that they aren't following an assumed linear path of intrusion. Attackers can have multiple primary and secondary objectives, and take any one of a multitude of paths to get there.
In this case, it would have also been valuable to review the stolen contents for authentication material/potential lateral movement paths that the attacker could leverage in their attempts to regain access or attack other environments. This would have potentially enabled LastPass to better direct their investigative and remediation efforts in the wake of the initial breach.
Having clearly defined "crown jewels" and operating environments is a core consideration when performing Threat Modelling, and would have been instrumental in ensuring monitoring and hunting resources were appropriately distributed in a planned - not reactive - manner, when seeking to contain and mitigate this long-running attack.

You can tell a lot about a person through the way they acknowledge - or don’t acknowledge - their mistakes, and the same goes for companies.

I won't delve into this much, because I think LastPass' handling of this breach speaks for itself.

The bottom line is that I’m unable to trust a company that tries to hide from its responsibility by citing false claims of implementing "stronger-than-typical" cryptography; puts the onus on customers to have followed their best practices guide, and fails to address systemic issues in its core product over a period of years.

LastPass' viability as a Product

While the headline is that LastPass failed to evict their attackers and a substantial amount of data was stolen, the breach has highlighted fundamental flaws in their product's design and how they have (or have not, in this case) maintained it.

Improvements to security standards (i.e. the iterations of the PBKDF2 algorithm and master password length requirements) weren't applied retrospectively to existing accounts, meaning their assurances of how hard it'd be to brute force a master password count for very little. As it turns out, they were prompted multiple times by Wladamir Palant to do so, but appear to have falsely claimed to have done so, in order to get him to stop asking.

Furthermore, by stealing customers password vaults, the attacker can bruteforce the master password at their leisure with the added benefit of having bypassed any value MFA would have provided against a remote attack. Again, this is something that should have been considered as part of a Threat Modelling exercise when designing the product.

It's clear the LastPass product design is deeply flawed, poorly maintained, and uncompetitive with other free and paid alternatives such as BitWarden and 1Password.

The end of Password Managers?

Password Managers allow the ordinary user to use complex and unique passwords for each site and service they use - that alone makes it an essential protection against credential stuffing, spraying, and brute force attacks.

This breach has simply made it clear that LastPass is in a class of their own, and in all the wrong ways.

Free offerings such as BitWarden implement a total of 200,001 PBKDF2 iterations between the client and server, with important metadata such as your originating IP and site URLs either not being logged, or encrypted within your vault.

1Password is a mature, paid alternative to LastPass that is unique in that in addition to using a master password, it requires an additional Secret Key when attempting to access your password vault. This key is stored locally on your device, meaning even if an attacker was able to dump a copy of your vault like they did with LastPass, they wouldn't be able to brute-force it without also compromising your device to extract that Secret Key.

Please note I’ve provided these examples not to steer you in either direction, but to give you a starting point in picking an alternative, if you or your organisation are among those affected.
Password managers are a great solution that has real-world benefits to both individuals and businesses - LastPass appears to have simply dropped the ball in spectacular fashion in this case, while there are plenty of others that haven’t.

Opalsec

Discussion about this post