Popular password management company LastPass has been under the pump this year, following a network intrusion back in August 2022.
Details of how the attackers first got in are still scarce, with LastPass’s first official comment cautiously stating that:
[A]n unauthorized party gained access to portions of the LastPass development environment through a single compromised developer account.
A folllow-up announcement about a month later was similarly inconclusive:
[T]he threat actor gained access to the Development environment using a developer’s compromised endpoint. While the method used for the initial endpoint compromise is inconclusive, the threat actor utilized their persistent access to impersonate the developer once the developer had successfully authenticated using multi-factor authentication.
There’s not an awful lot left in this paragraph if you drain out the jargon, but the key phrases seem to be “compromised endpoint” (in plain English, this probably means: malware-infected computer), and “persistent access” (meaning: the crooks could get back in later on at their leisure).
2FA doesn’t always help
Unfortunately, as you can read above, two-factor authentication (2FA) didn’t help in this particular attack.
We’re guessing that’s because LastPass, in common with most companies and online services, doesn’t literally require 2FA for every connection where authentication is needed, but only for what you might call primary authentication.
To be fair, many or most of the services you use, probably including your own employer, generally do something similar.
Typical 2FA exemptions, aimed at reaping most of its benefits without paying too high a price for inconvenience, include:
- Doing full 2FA authentication only occasionally, such as requesting new one-time codes only every few days or weeks. Some 2FA systems may offer you a “remember me for X days” option, for example.
- Only requiring 2FA authentication for initial login, then allowing some sort of “single sign-on” system to authenticate you automatically for a wide range of internal services. In many companies, logging on to email often also gives you access to other services such as Zoom, GitHub or other systems you use a lot.
- Issuing “bearer access tokens” for automated software tools, based on occasional 2FA authentication by developers, testers and engineering staff. If you have an automated build-and-test script that needs to access various servers and databases at various points in the process, you don’t want the script continually interrupted to wait for you to type in yet another 2FA code.
We have seen no evidence…
In a fit of confidence that we suspect that LastPass now regrets, the company initially said, in August 2022:
We have seen no evidence that this incident involved any access to customer data or encrypted password vaults.
Of course, “we have seen no evidence” isn’t a very strong statement (not least because instransigent companies can make it come true by deliberately failing to look for evidence in the first place, or by letting someone else collect the evidence and then purposefully refusing to look at it), even though it’s often all that any company can truthfully say in the immediate aftermath of a breach.
LastPass did investigate, however, and felt able to make a definitive claim by September 2022:
Although the threat actor was able to access the Development environment, our system design and controls prevented the threat actor from accessing any customer data or encrypted password vaults.
Sadly, that claim turned out to be a little too bold.
The attack that led to an attack
LastPass did admit early on that the crooks “took portions of source code and some proprietary LastPass technical information”…
…and it now seems that some of that stolen “technical information” was enough to facilitate a follow-on attack that was disclosed in November 2022:
We have determined that an unauthorized party, using information obtained in the August 2022 incident, was able to gain access to certain elements of our customers’ information.
To be fair to LastPass, the company didn’t repeat its original claim that no passwords vaults had been stolen, referring merely to “customers’ information” being pilfered.
But in its previous breach notifications, the company had carefully spoken about customer data (which makes most of us think of information such as address, phone number, payment card details, and so on) and encrypted password vaults as two distinct categories.
This time, however, “customers’ information” turns out to include both customer data, in the sense above, and password databases.
Not literally on the night before Christmas, but perilously close to it, LastPass has admitted that:
The threat actor copied information from backup that contained basic customer account information and related metadata including company names, end-user names, billing addresses, email addresses, telephone numbers, and the IP addresses from which customers were accessing the LastPass service.
Loosely speaking, the crooks now know who you are, where you live, which computers on the internet are yours, and how to contact you electronically.
The admission continues:
The threat actor was also able to copy a backup of customer vault data.
So, the crooks did steal those password vaults after all.
Intriguingly, LastPass has now also admitted that what it describes as a “password vault” isn’t actually a scrambled BLOB (an amusing jargon word meaning binary large object) consisting only and entirely of encrypted, and therefore unintelligible, data.
Those “vaults” include unencrypted data, apparently including the URLs for the websites that go with each encrypted username and password.
The crooks therefore now not only know where you and your computer live, thanks to the leaked billing and IP address data mentioned above, but also have a detailed map of where you go when you’re online:
[C]ustomer vault data […] is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.
LastPass hasn’t given any other details about the unencrypted data that was stored in those “vault” files, but the words “such as website URLs” certainly imply that URLs aren’t the only information that the crooks acquired.
The good news
The good news, LastPass continues to insist, is that the security of your backed-up passwords in your vault file should be no different from the security of any other cloud backup that you encrypted on your own computer before you uploaded it.
According to LastPass, the secret data it backs up for you never exists in unencrypted form on LastPass’s own servers, and LastPass never stores or sees your master password.
Therefore, says LastPass, your backed-up password data is always uploaded, stored, accessed and downloaded in encrypted form, so that the crooks still need to crack your master password, even though they now have your scrambled password data.
As far as we can tell, passwords added into LastPass in recent years use a salt-hash-and-stretch storage system that’s close to our own recommendations, using the PBKDF2 algorithm with random salts, SHA-256 as the internal hashing system, and 100,100 iterations.
LastPass didn’t, or couldn’t, say, in its November 2022 update, how long it took for the second wave of crooks to get into its cloud servers following the first attack on its development system in August 2002.
But even if we assume that the second attack followed immediately but wasn’t noticed until later, the criminals have had at most four months to try to crack the master passwords of anyone’s stolen vault.
It’s therefore reasonable to infer that only users who had deliberately chosen easy-to-guess or early-to-crack passwords are at risk, and that anyone who has taken the trouble to change their passwords since the breach announcement has almost certainly kept ahead of the crooks.
