LastPass, one of the world's largest password managers with 25 million users, disclosed that an unauthorized party had gained access to portions of the LastPass developer environment. An attacker gained access to developer account credentials and used them to infiltrate their software supply chain and exfiltrate portions of their proprietary source code.
Update 22.12.2022 Notice:
LastPass disclosed that the threat actor was able to compromise an additional developer account and use its credentials to obtain access to the company's backup storage.
According to LastPass, the following data has been stolen by the attacker:
- Customer's account information:
- Company names
- End-user names
- Billing addresses
- Email addresses
- Telephone numbers
- Login IP addresses
- Vault Data:
- Website URL's
- Encrypted passwords, usernames, secure notes and etc.
The bottom line, the encrypted data is still secured due to LastPass's zero-knowledge architecture. Users of LastPass should (1) validate that their master password follows strong password best practices to reduce the risk of brute force and (2) be aware of phishing attempts.
[This blog is being actively updated as we learn more about the incident.]
Am I impacted by the LastPass Incident?
As a LastPass User:
This incident is worrisome, especially due to the highly sensitive information LastPass holds, which are user passwords for other websites and secure notes. A user's content in LastPass is protected by one master password, and according to the company, Master Passwords weren’t compromised and are not stored by LastPass at all. This means that based on what we know right now, the attacker cannot access to this sensitive information.
However, It is hard to know the full scope of this attack at this moment. A compromised developer account could have access to many privileged assets, and although it appears that Master Passwords are not compromised, the attacker could have access to a wide range of other sensitive information leading to further attacks. LastPass hired two forensics companies for the investigation, and we expect more information to be disclosed including if any sensitive information was compromised.
As a software company:
This is the latest headline-making software supply chain attack in a rapidly growing threat category. Software supply chain attacks are cyber attacks that compromise the development pipelines and systems used to build software. SolarWinds, Codecov, Kaseya, and now LastPass are now some of the most notable cyber attacks of the last few years.
The impact of successful attacks vary widely from the theft of valuable intellectual property, to disrupting business operations, to vulnerabilities and backdoors embedded in the software you ship to your customers. As witnessed with this latest attack and others, there are also steep costs in terms of brand damage, customer reputation and abandonment, and potentially regulatory fines and penalties depending upon your industry.
Software companies need to better protect their own software supply chains to ensure they are protected against attacks like these. For a thorough assessment of your software supply chain risks, you can always reach out to Legit Security for a free rapid risk assessment.
What Can I Do To Protect Against Similar Supply Chain Attacks?
LastPass is now evaluating mitigation techniques to strengthen their developer environments – you should too. The topic of securing a software supply chain is complex and covered extensively in many of our other blogs. However, today we wanted to focus on initial security tips and guidance relative to securing developer environments and what seems likely to have happened with LastPass.
Development environments are very complex. They contain multiple systems:
Source Code Management (SCM): GitHub, Bitbucket, GitLab, etc.
CI/CD: Jenkins, GitHub Actions, GitLab Pipelines, Bitbucket, Bamboo, CircleCI, ArgoCD, etc.
Artifact Registries: JFrog, GitHub, NPM, Harbor, DockerHub, etc.
All of these systems have a different permission model, but are orchestrated together. They are highly privileged since they ultimately enable software to deploy into production. This complex infrastructure has hidden relationships that make it hard to identify what are the true permissions of a developer. Often times, organizations share credentials and/or access tokens across systems and allow them to be accessible to a large portion of the company's development team.
For example, let’s imagine a compromised development account in GitHub with the following setup:
This account has access to a single repository
The repository contains a CI/CD pipeline that uses a PAT (personal access token) to upload an artifact to GitHub Registry
The PAT is created from the DevOps Engineer Account, which is privileged and has access to:
- Upload artifacts
- Many more repositories
In such a case, the (compromised) user can modify the pipeline code to read the DevOps Engineer PAT. Thus, its true permission is the permission of the DevOps Engineer, which is much higher than only access to a single repository.
These kinds of hidden relationships are highly prevalent in development environments, and every DevOps and Information Security Engineer should be aware that they exist.
Best Practices to Secure Development Environments
Have an inventory of your organization's SDLC assets. This includes documenting the relationships between systems in your pipelines.
Identify users or 3rd-parties that have access to data they shouldn’t have access to.
Remove inactive users (especially privileged users) from your organization. They are more likely to be compromised.
Ensure your SDLC asset inventory is always up to date. Continuously monitor for access risks with real-time alerts of issues.
Legit Security helps secure development environments
The Legit Security platform automatically inventories your development environments and the relationship between systems from source to build to artifact, all the way up until production deployment. Our SaaS platform alerts you in real-time when 100s of security policies are violated in your software supply chain – including alerts for over-privileged and/or stale collaborators to your SDLC systems with permissions that need to be revoked.