Analyzing LastPass' Recent Security Incident Notification

Introduction: Understanding LastPass' security incident

Part 1: A good looking disclosure.

The notification briefly details the facts of the breach: LastPass observed anomalous activity in their developer environment, determined that an unauthorized entity compromised a single developer account, and took some “proprietary LastPass technical information.”  

Then the notification jumps right to the question on everyone’s mind: are my credentials safe? In their online FAQ, their answer is unambiguous:

This is a very good thing. Whenever a company announces that they’ve been breached, users are left to wonder what they aren’t being told. Imaginations run wild over sentences like ‘we have seen no evidence that this incident involved any access to customer data,’ (which LastPass used verbatim on their blog.) Is there evidence that you are specifically avoiding looking at because you don’t want to have to announce a worse breach?

Of all the grief being given to LastPass on Twitter and Reddit: if you suggest that LastPass is minimizing the appearance of the incident, you are accusing them of lying. By being resolute in stating that customer data was not affected, we can rest assured that they aren’t weaseling out of a such a grave announcement.  

That said, it’s probably worth cautioning the reader: hackers use source code to find vulnerabilities. Sometimes they find secret internal-use credentials buried in source code, increasing the “blast radius” of the attack. Sometimes documentation that might be referred to as “proprietary technical information” hold enough architectural details to reveal design flaws in a large-scale system.  

Nevertheless, we at Arnica are satisfied that this notification is timely, assertive, and believable.

There were two things that we were happy to see aren’t in the LastPass notification. The first is any sort of reassurance that LastPass “takes the security of its customers very seriously.” This has been a weaselly phrase since it was first used in a breach notification. Since then, it has transcended hollowness and today is practically an insult. The second is any bemoaning how their very advanced attackers used highly sophisticated attacks which they could never have been expected to stop. Whenever I see this weepy milquetoast defense, I know that my vendor probably got popped with SQL injection.  

This is no one’s first rodeo; thank you LastPass for respecting our intelligence by avoiding these tropes.

Part 2: It’s never too early to learn a lesson.

LastPass are being conservative with technical details and while it’s tempting to indulge in speculation, it’s also disrespectful. Nonetheless, a little guesswork can make it easy to piece out lessons for those interested in stopping or preventing similar attacks in the future.

For example, LastPass claims a partial disclosure of source code, rather than a complete disclosure. Why is that? Perhaps LastPass doesn’t use a monorepo pattern code repository. Perhaps they do but have good access control. Or perhaps they merely have decent enough defense in depth that they spotted the extrusion and contained it before a complete disclosure of source was possible. Or something else entirely. We don’t need to speculate on LastPass’ specific security posture to know something fortuitous happened to prevent full disclosure. And if we aren’t doing any of these actions, perhaps we should.

Conclusion: A development system is a production system to a developer.

It used to be believed that we could keep our development systems safe if we kept them firewalled off from external access. This didn’t work because developers don’t reinvent wheels. Synopsys’ most recent OSSRA report states that 94% of codebases include open source dependencies.

An attack against a developer account, the toolchain, a dependency, or the repo is an attack against the software itself. Therefore, the developer environment represents an under-appreciated attack surface, one that we at Arnica are passionate about securing.