The LastPass Breach is a Wake Up Call for Cloud Data Security

Originally published by Dig Security.

Written by Ofir Shaty and Ofir Balassiano.

For many LastPass employees – from software engineers to C-level executives – the last few months have been hell. Since December, the company has been embroiled in what’s shaping up to be a major data security scandal.

You can find the full details elsewhere (such as in this Ars Technica story or in the LastPass blog), but to recap: LastPass suffered from two data breach incidents in August 2022. In the first incident, some proprietary data was stolen – including development and source code repositories, internal scripts, and documentation. However, LastPass announced at the time that customer data wasn’t compromised.

Unfortunately, this was not the case in the second incident, which occurred shortly thereafter (and only discovered at the end of February). A DevOps engineer was specifically targeted by the attacker, who exploited a third-party software vulnerability on the employee's home computer, along with information stolen in the first breach. The attacker used this vulnerability to gain access to cloud backups – and to access a shocking amount of the most sensitive data imaginable.

What we know was stolen (so far)

LastPass is not just another software company. It's an organization whose mission statement is closely tied to managing extremely sensitive user data - passwords. These credentials are the keys to every element of our online identity. In an increasingly-digital world, they can unlock our personal correspondence, our health data, and our financial records. And as a popular tool in this space, it holds credentials for millions of users – many of whom are now at risk.

According to the inventory published by LastPass, we now know that the attacker managed to steal backups of all customer vault data - encrypted copies of LastPass customers' password vaults and digital access credentials.

Specific login details are still protected by master passwords; but should the hackers manage to crack them, they would gain full access to credentials used across the web. While LastPass mentioned this would take “millions of years”, others have rightfully noted that the time frame might be much shorter for customers who didn’t choose a strong master password to begin with.

In addition, the attacker now has their hands on:

• The split knowledge component ("K2") Key which can be used to decrypt customer data
• A backup of LastPass's multi-factor authentication (MFA) database, which contained copies of LastPass MFA Authenticator seeds, and telephone numbers used for MFA (if enable)
• Unencrypted customer data, including metadata and URLs
• DevOps secrets that were used to gain access to LastPass's cloud-based backup storage
• Configuration data, API secrets, and third-party integration secrets

This is an eye-watering amount of sensitive data that can now be used maliciously. It's not at all clear if the company will manage to regain user trust and recover from the blow dealt to its reputation. It's safe to guess that dozens - across engineering, security, and upper management - will spend months or years mitigating the damage. The broader damage caused by this leak is not entirely clear.

Cloud security isn’t data-centric – which allows these incidents to fly under the radar

One of the most shocking aspects of these incidents is how long they took to uncover. The initial breach happened in August, and was reported by LastPass in December. The second incident ended on October 26, and was only uncovered at the end of February.

LastPass took months to detect the incidents, and additional months to understand the full scope of each breach and the extent to which customer data was compromised. This led the company to issue conflicting statements which only furthered the reputational damage to themselves, and potentially hindered their customers from applying the correct mitigation measures.

(In all fairness, while discovering that a major incident happened four months ago seems terrible, it’s actually better than some industry benchmarks. IBM has found that the average time to identify a data breach is 243 days).

These incidents are a direct result of current gaps in cloud data security, starting with lack of visibility. Sensitive data is a lucrative target for threat actors - as can be seen in the rapid growth in ransomware attacks (PDF). Data is one of the most valuable assets a modern enterprise holds, and a leak can cost millions. And yet, most companies don't have an easy way to understand where their sensitive data is stored, how data flows between environments, and who has accessed it. This is the type of context that was missing in the LastPass incident; and consequently, the full scope of the incident went undetected for months.

Would better CSPM have helped? Here’s a quote from LastPass’s announcement:

"Alerting and logging was enabled during these events, but did not immediately indicate the anomalous behavior... The threat actor was able to leverage valid credentials[...] to access a shared cloud-storage environment, which initially made it difficult for investigators to differentiate between threat actor activity and ongoing legitimate activity."

There's no certainty that a CSPM tool would have helped detect this incident faster:

• Without knowing the full context of the data being accessed - in this case, highly sensitive customer records - there would be little reason for a CSPM tool to flag the behavior as suspicious.
• Even if the incident had been detected, it could easily have been buried in notifications unless the alert indicated the potential exfiltration risk (which again requires taking data context into account).

To prevent this type of incident, businesses need data-centric security. Tools that are able to see 'into' the data itself, identify sensitive records, and monitor them in real time, could have prevented these incidents or allowed LastPass to discover them earlier and mitigate much of the damage.

How to avoid becoming a cautionary tale

The LastPass incident should serve as a flashing warning light. If your organization stores large amounts of sensitive customer data, you need to prepare for a data breach incident. It can happen to any company; there is no way to completely protect yourself from human error. But there are steps you can take on the technology side.

Before a breach incident:

Use DSPM to improve the security posture of your cloud data:

• Find and contextualize any data that might be at risk. Create an inventory of sensitive data assets, classified according to the type of data (PII, PCI, etc.)
• Identify vulnerabilities to address: E.g., publicly accessible or unencrypted assets, shadow data assets on unmanaged data stores
• Manage access to sensitive data and regularly ensure that permissions are minimal and strictly necessary.
• Reduce the attack surface by removing unused or duplicate backups of sensitive data.
• Prioritize policies according to the content and context of the data, starting with sensitive customer records.

During a breach incident:

Use DDR to dramatically reduce mean time to detection (MTTD) - think minutes or hours rather than 4-8 months:

• Identify when a sensitive data asset is being accessed by an unauthorized or suspicious actor
• Identify when a seemingly-legitimate actor is behaving in suspicious ways, such as exfiltrating large volumes of data from S3).
• Get alerted to critical incidents as they happen and respond immediately.

After a breach incident:

• Assess what type of data was exfiltrated: What was accessible to the attacker? How much customer data was lost? Which customers were impacted? Having an inventory of your sensitive data assets, via the DSPM tool, will help you answer these questions (and share your findings with customers) quickly.
• Get the full forensics of the attack, including which vulnerability was exploited and whether this could lead to follow-up incidents as in the LastPass case.
• Get accurate information with customers so that they can take immediate remediation steps on their end (e.g., switching their master password).

The broader implications: this could probably have happened to you

It's legitimate to hold LastPass to a higher standard than most, and to ask some hard questions about their security practices. A company that asks users to trust it with this information needs to do better – and indeed, the hot takes have been fast and furious. But the more pertinent question for most of us should be: if it happened to LastPass, could it also happen to us?

After all, LastPass is a digital-native company; it has a dedicated security team and an experienced C-Level security officer; presumably, it also has a strong incentive to be extra-cautious about security. And yet, calamity struck. Are other enterprises - who often suffer from serious cloud skill gaps, and rely on messily-migrated legacy architectures - actually in a better position to avoid this type of incident?

The reality is that this type of data breach could happen to most. The lack of visibility, shockingly high MTTD/MTTR, and poor forensics that were uncovered during this incident are not a LastPass-specific problem; they are an industry-wide challenge. The takeaway from this incident should be to ask some hard questions about your own cloud data security situation – and to find ways to improve it.