It’s All Bad News: An update on how the Lastpass breach affects Lastpass SSO

Every week, almost without fail, I come across one thing that confuses, entertains, or most commonly infuriates me. I’ve decided to keep a record of my adventures.

A few weeks ago I released a detailed analysis of how the Lastpass breach affected Lastpass’ SSO implementation. Today, Lastpass quietly sneaked an update into their ‘Recommended Actions for Lastpass Business Administrators’ that completely eviscerates both the information Lastpass provided customers and the advice from my previous post. Let’s jump in.

Background

For a more in depth primer on Lastpass SSO see my previous post.

Lastpass provides a technical implementation whitepaper that describes how Lastpass vault passwords are generated (which is the same for all SSO integrations)

Hidden Master Password = base64(SHA256(K1 XOR K2))

This equation defines K1 as the company wide secret and K2 as the user generated secret. K2 is stored at Lastpass and fetched via an API using an id_token signed by your SSO provider.

In Lastpass’ latest update they indicated

The K2 component was exfiltrated by the threat actor as it was stored 
in the encrypted backups of the LastPass MFA/Federation Database for 
which the threat actor had decryption keys.

They subsequently try to walk back the impact of this statement by saying:

The security reference model we implemented for split knowledge was 
chosen to defend against this specific situation where knowledge of 
only one of the split knowledge components would give away nothing 
of the resulting key.

The Problem

Don’t be fooled. The way in which this ‘split’ key was set up makes the K1 less of a ‘secret’ and more of a speed bump. Why is this? The K1 doesn’t change, is the same for the whole organizations, and is available to every employee who ever set up/used your enterprises Lastpass.

How can this be? Well, the Lastpass K1 is (for most IDPs) set as an Access Token grant.

This means that any user who looks at their web browser console or proxies their traffic can access the K1 by simply base64 decoding the JWT Access Token as it goes across the wire.

Of course, this also means that any attacker, who has the K2s, can target any individual user at the company with Lastpass access and use their access to gain obtain the company wide K1 (Bonus: We already know that the breach divulged the company name of the vault in plaintext).

Cryptographically this also means that all master passwords are linked. If the attacker cracks one K1 for an org, they get access to all the orgs vaults (ouch).

This whole process is compounded by the fact that information keeps trickling out, making it near impossible for affected parties to respond. For instance, a little more than a month ago, Lastpass support explicitly indicated (to multiple sources) that K2s were not impacted.

The Solution

The suggested solution from Lastpass is to rotate your K1 (oh that sounds simple… right?). To do this successfully, you need to de-federate and re-federate each and every one of your users. On the bright side, re-federating users seems to rotate the users K2 (I did not independently validate this, yet). At this point you are much better off starting a new tenant, at least you get nice onboarding emails.

Please note, that rotating your passwords will not strictly resolve the impact of K2s being compromised. As mentioned, until users are re-federated, K1s and K2s remain the same. Another breach locally or of Lastpass would result in all future passwords being compromised.

Yup, everything is fine, nothing to see here.