LastPass has provided another update on the second data breach it experienced last year and has confirmed that the second attack – which was linked to the summer hacking incident – involved the hacking of the home computer of a DevOps engineer.
In August 2022, hackers gained access to the LastPass developer environment and stole some proprietary source code and internal documents, but said the breach was limited to its development environment. LastPass confirmed at the time that the hacker had access to that environment for four days. Assisted by Mandiant, LastPass determined that there had not been any breach of customer data and encrypted password vaults had not been accessed. Then in December 2022, LastPass confirmed there had been a second attack.
The threat actor behind the first attack used data stolen in the first attack – a cloud storage access key and dual storage container decryption keys – to gain access to a cloud storage environment that contained basic customer account information and related metadata, such as company names, end-user names, billing addresses, email addresses, phone numbers, and the IP addresses used by customers to access the LastPass service. The threat actor also stole a backup of customer vault data from the encrypted storage data. That backup contained unencrypted data such as website URLs, and encrypted data such as website usernames and passwords, secure notes, and form-filled data.
The encrypted data could only be decrypted using users’ master passwords, which are not known to LastPass. While master passwords could be brute forced, if users had set strong passwords for their master passwords, that would be difficult and very time-consuming. At the time, LastPass was used by more than 33 million people and more than 100,000 businesses. LastPass did not disclose how many of its customers had been affected.
Further Information Released on the Second Attack
LastPass recently issued another update and provided further information on the nature of the “coordinated second attack,” which LastPass said lasted for 2 months. As was previously disclosed, information stolen in the first attack was used to gain access to LastPass’s encrypted Amazon S3 buckets. LastPass has now confirmed that this was achieved using a combination of data stolen in August, data stolen in a different data breach, and a remote code execution vulnerability, which was exploited to gain access to a senior DevOps engineer’s home computer, which allowed the threat actor to install a keylogger.
The keylogger allowed the threat actor to capture the employee’s master password when it was entered after the employee was authenticated with MFA. The threat actor was then able to access the DevOps engineer’s LastPass corporate vault. Native corporate vault entries were exported along with the content of shared folders, which included encrypted secure notes and access and decryption keys, which were used to access the AWS S3 LastPass production backups, cloud-based storage resources, and related critical database backups.
The second attack lasted from August 12, 2022, to October 26, 2022, but was not detected as the attacker used different techniques to the first attack, and since valid credentials were used, the unauthorized activity was not detected. The breach was finally detected when investigating AWS GuardDuty Alerts, which were generated when the threat actor tried to use Cloud Identity and Access Management (IAM) roles to perform unauthorized activities. The DevOps engineer targeted by the threat actor was one of only four engineers who had access to the decryption keys.
LastPass has also provided further information on the customers who were affected and the data stolen in the attack, confirming the first attack only involved 14 of 200 software repositories in its on-demand, cloud-based development and source code repositories, internal scripts from those repositories (including LastPass secrets and certificates), and internal documentation on how its development environment operated.
The second breach included DevOps Secrets, which were used to access the cloud-based backup storage and its cloud-based backup storage. LastPass said the latter included “contained configuration data, API secrets, third-party integration secrets, customer metadata, and backups of all customer vault data. All sensitive customer vault data, other than URLs, file paths to installed LastPass Windows or macOS software, and certain use cases involving email addresses, were encrypted using our Zero knowledge model and can only be decrypted with a unique encryption key derived from each user’s master password. As a reminder, end user master passwords are never known to LastPass and are not stored or maintained by LastPass – therefore, they were not included in the exfiltrated data.”
The threat actor also stole a backup of the LastPass MFA/Federation database, which included, “copies of LastPass Authenticator seeds, telephone numbers used for the MFA backup option (if enabled), as well as a split knowledge component (the K2 “key”) used for LastPass federation (if enabled). This database was encrypted, but the separately-stored decryption key was included in the secrets stolen by the threat actor during the second incident.”
The data stolen varied from customer to customer, and included “Multifactor Authentication seeds, MFA API integration secrets, and Split knowledge component (K2) Keys for Federated business customers.
Recommended Actions for LastPass Customers
LastPass confirmed that many steps have been taken since the breach to improve security, including rotating sensitive credentials and authentication keys/tokens, implementing additional logging and alerts, revoking certificates, and enforcing much stricter security policies. LastPass has also published recommended actions for customers to improve security and confirmed that no further unauthorized activity has been identified since October 26, 2022.
As a precaution, LastPass users that have not already switched to an alternate password manager and have not changed their Master Passwords for their LastPass vaults should, at the least, change their master password to a password of at least 11 characters and should ensure that MFA is enabled. They should also consider changing all passwords in their password vaults, although there is no evidence that master passwords have been obtained or any password vaults breached.