Over the last few months, I’ve been following with interest the updates LastPass have issued around the security problems they had in the second half of last year.
If you’re not familiar with the story, a tinpot summary is that:
- LastPass discovered an unauthorised third party accessed their development environment in August of last year, via an improperly exposed endpoint.
- The attacker appeared not to have done anything malicious at that point (and, being a development environment, no customer data was at risk).
- LastPass assured customers that they’d fully contained the attacker and strengthened their controls in response.
However, LastPass then revealed in November that they’d detected “recent” (the timeline isn’t clear) unusual activity in a “third-party cloud storage service”, based on access gained in the August 2022 incident. (Other commentators have already speculated that this storage service is likely to be AWS, since LogMeIn, LastPass’s parent company, migrated from Oracle Cloud to AWS a few years ago). This time, “certain elements of customer data” were accessed: the cloud storage was holding backups of production data.
Virtually all customer data, as it turns out, as the backups contained “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”, and also contained an encrypted copy of customer vault data. As it’s encrypted, the attacker does not immediately have all passwords of LastPass customers, but it does pose major risks nonetheless, which I’ll go into in a moment.
After the first incident affecting the development environment, LastPass stated they’d implemented threat modelling, among other things, to enhance security. Given they then fell victim to the second, more significant, breach, it looks to me like they either didn’t do it properly or didn’t do it fast enough.
This story is a classic example of the aftermath of many corporate breaches. A few things caught my eye reading this.
First, kudos to LastPass for the transparency (even if, as some folk have pointed out, the updates were a long time coming after the actual incident). However, LastPass admits the second breach (in production) was a direct consequence of the first breach, in the development environment. Therefore they clearly did not fully contain the attack in August as they’d stated.
So, despite many tech companies following the best practice of separating development and production environments, this does not automatically mean you can neglect security in the development environment. A threat model done up front would’ve revealed the issues that could crop up at this point, and given LastPass a better view of what the real risks are. Development accounts usually pose more business risks than most teams realise.
Second, though LastPass’s production environment was never impacted by either incident, the production backups were, and these have posed just as much of a risk as an actual production breach would have (just look at the headlines that have emerged).
Again, I find this time and time again in my threat modelling exercises with clients: without threat modelling, key risk areas are missed. Backups often get overlooked, but application logs, code repositories, credentials and others pose similar dangers.
In these scenarios, you have two options:
- exhaustively secure “everything”, or
- perform an assessment that finds where the risks are, and prioritise based on the risk.
In short, the former doesn’t work. Businesses will always plump for the second, as it is quicker, more cost-effective, and still gets the outcomes you need. Threat modelling is by far the best way I’ve found to quickly find the important risks and how to solve them.
Lastly, this story says to me that LastPass have consistently underestimated the business risk of several parts of their infrastructure. A security incident on an exposed endpoint in a dark corner of the development environment led to the exposure of customers’ encrypted password vaults. In other words, only one step away from the crown jewels and full compromise, as far as customers are concerned. LastPass failed to understand that their development environment posed such a big risk, and failed to understand that their backups posed such a big risk.
The fallout has been clear - customers are fearful, they don’t know whether to trust LastPass with their data any more, and the PR damage is significant.
Customers are also placed at direct risk here, in two ways.
First, for each vault the attacker has, a single password is the only protection against complete compromise.
And we users have a bad track record on password security, to put it mildly. LastPass has recognised this, as shown by their blog posts highlighting how they’ve strengthened master password requirements over the years. But even with a strong master password, your vault may succumb to eventual compromise, as attackers that perceive enough value in these vaults will buy the resources to try ever-more-elaborate passwords and passphrases to crack them open.
If you’re a LastPass customer reading this, my advice is to immediately reset all your passwords that are contained in your LastPass vault, because presumably some of those passwords grant access to services or data that are sensitive or important to you.
(I ran some numbers: I couldn’t easily find an estimate of how many customers LastPass have, but I assume at least 1 million. Say the average customer has 1,000 passwords, as I do. If the attacker cracks just 1% of the vaults they have, that’s 10 million new sets of credentials they can now sell on the dark web or use to gain access elsewhere. For many customers not all those passwords will be randomly generated but manually inserted, so may also succumb to reuse attacks. I expect the attacker to crack more than 1% of vaults as time passes and that LastPass have more than 1 million customer accounts, so this figure is a floor.)
Second, because personal customer data was also revealed en masse in the breach, customers are now quite exposed to phishing scams, which is the subject of a new class-action lawsuit against LastPass filed a few days ago. (And of course, that lawsuit will wreak more damage to LastPass’s reputation.)
To be clear, I don’t see an overwhelming exodus of customers and I’m not foretelling the doom of LastPass, but I do see this incident dealing a big dent to public confidence in LastPass’s security, which they’ll have to work hard to earn back.
This is despite the heroic efforts of their security team to isolate and contain the attacks, despite all the other attacks they’ve repelled and despite the transparency they’ve admirably shown in their updates to customers.
It’s tempting to say at this point that had they had a threat model, none of this would have happened. That’s not true - threat modelling is no silver bullet -but a threat model driven by business risks, not technical risks, would have highlighted many of these risks up front to LastPass.
LastPass clearly cares about security, and I’m sure it’s a significant operational cost for them. Had they had a better view of the business risks up front, that investment might have included mitigating the risk of the vulnerabilities this breach has so publicly exposed.
Reading this article might be promoting you to think about your own cloud security. Get started by completing my free AWS Security Scorecard - link below.
