Frankly Speaking - Analyzing the LastPass hack pt. 2
Breaking down their disclosure
Hope everyone is having a restful holiday! I’m still running a sale for paid subscriptions until the end of the year. Thanks for all the support! If you want to support me more, you can get it for 50% off.
LET’S BE FRANK
In my last newsletter, I talked about my thoughts on the LastPass hack. There was some confusion on where I drew certain conclusions, and in general, people wanted me to break down the official announcement to better understand my thought process, so here it is!
In general, I believe the announcement was purposefully vague and tried to downplay the severity of the breach. It seems like other security experts share my beliefs. Although I believe that LastPass’s intentions were not malicious and meant to fully evade, I do believe that it’s the company’s job or their PR team’s job to minimize fallout. In many ways, I feel for the LastPass’s security team. They are doing their best. It’s important to know that the security team rarely has strong influence on external communications, which is primarily decided by the leadership/executive team who lack full context.
However, I described in the other post that there are some mitigations in place, such as MFA for important sites (hopefully, you don’t also double up your LastPass as your MFA device…) and having critical sites ramp up their fraud and account takeover detection as a result of this.
Ok let’s get started!
In keeping with our commitment to transparency, we want to provide you with an update regarding our ongoing investigation.
Like Wlamdir Palant said, this isn’t about transparency. It’s required by US law since customer data was taken. If they wanted to be more transparent, they would have provided more details in the their disclosure.
While no customer data was accessed during the August 2022 incident, some source code and technical information were stolen from our development environment and used to target another employee, obtaining credentials and keys which were used to access and decrypt some storage volumes within the cloud-based storage service.
This part is a bit confusing to me. If you scroll to the “September 15” portion of this disclosure, it says that the threat actor’s activity in August was limited to just 4 days. They did admit that the threat actor didn’t access any customer data or encrypted vaults. I’m surprised that they didn’t investigate potential blast radius of getting access to a development environment, i.e. are there secrets that allow access to production, etc.? Maybe, there isn’t, but how was the hack used to target another employee? Were they phished? Did the technical information give access to account? I’m a bit confused on how this happened.
There are two realistic scenarios:
There were production secrets in the development environment for some highly privileged users that weren’t supposed to be there or were stored in a way that the security team didn’t know. LastPass likely told Mandiant the environments were separate, and Mandiant was able to confirm the basics based on information provided by the security team. However, the threat actor, who had more time, was able to figure out that this wasn’t true and find production secrets.
The threat actor was able to figure out which users were highly privileged and phish or social engineer that employee in some way.
It’s not clear which it is. I don’t know enough about LastPass’s internal security measures and engineering practices/culture to infer which scenario was more likely.
LastPass production services currently operate from on-premises data centers with cloud-based storage used for various purposes such as storing backups and regional data residency requirements. The cloud storage service accessed by the threat actor is physically separate from our production environment.
This paragraph is hard to parse. It tries to minimize the situation with technical jargon. The backups are a replica of the on-prem production environment. I guess the point here is to show the attacker is likely not lingering around their actual production environment, which probably has more sensitive information.
These encrypted fields remain secured with 256-bit AES encryption and can only be decrypted with a unique encryption key derived from each user’s master password using our Zero Knowledge architecture. As a reminder, the master password is never known to LastPass and is not stored or maintained by LastPass.
Ok, this is good news. That’s why it’s probably in bold in the announcement.
Since 2018, we have required a twelve-character minimum for master passwords. This greatly minimizes the ability for successful brute force password guessing.
There’s not too much information about people who have LastPass from before. According to a former employee, it seems like the OG LastPass users might not have had their backups re-encrypted. We don’t know how far backups go. That’s not a great omission.
In response to the August 2022 incident, we eradicated any further potential access to the LastPass development environment by decommissioning that environment in its entirety and rebuilding a new environment from scratch. We also replaced and further hardened developer machines, processes, and authentication mechanisms.
Decommissioning is a good idea because it removes any persistent threat vectors the attack left. However, have they fixed the problem that allowed the attacker to access? It seemed like from their previous report “the method used for the initial endpoint compromise is inconclusive.” It’s not fully clear they have solved the problem.
We have added additional logging and alerting capabilities to help detect any further unauthorized activity including a second line of defense with a leading managed endpoint detection and response vendor to supplement our own team
Yeah, it’s surprising the LastPass didn’t detect anything strange, but it was the cloud storage company that detected this. Why was there such insufficient monitoring/logging?
In response to this most recent incident, we are actively rotating all relevant credentials and certificates that may have been affected and supplementing existing endpoint security. We are also performing an exhaustive analysis of every account with signs of any suspicious activity within our cloud storage service, adding additional safeguards within this environment, and analyzing all data within this environment to ensure we understand what the threat actor accessed.
What are the relevant credentials? I was hoping to figure out how the threat actor got these credentials to figure out which of the two scenarios above led to the breach.
There are still many outstanding questions.
When did the second hack happen? The timeline for the attack is unclear. When did the threat actor access the cloud storage? Was it after the investigation of the first hack was complete?
What process was broken so that the attacker could obtain the decryption keys to the cloud storage environment from an employee?
It seemed like there were multiple actions that the attacker took. Why were none of them detected? This seems like an important attack vector/path. Why wasn’t there sufficient monitoring? Was this attack vector not considered after the previous hack?
There are definitely some important omissions in this announcement. They would argue that it’s meant for consumers who are less technically savvy, but LastPass has enterprise customers. There should be some more details to give security teams in those enterprises a better sense of risk.
I’m not sure we will learn more at this point, but I hope they do figure out a way to clean this up and re-establish trust.