On January 9, 2024, researchers from Cornell University contacted LastPass using our vulnerability disclosure and bug bounty partner, Bugcrowd.
We very much appreciate the work done by security researchers to identify and responsibly disclose potential vulnerabilities as it ultimately plays an important role in helping to keep our customers safe.
In this case, the researchers had identified two potential vulnerabilities which the LastPass Product Engineering and Trust, Safety and Security teams quickly investigated. Our teams applied the OWASP threat modeling and risk rating methodologies (https://owasp-risk-rating.com/) to assess the likelihood and impact of these reported vulnerabilities, in addition to thoroughly reviewing the threat model and associated compensating controls.
Based on our analysis, the LastPass team ultimately rated both vulnerabilities as “low risk,” based on likelihood scores related to threat actor and technical impact factors as defined by the threat model/attack scenario and the researchers’ own stated assumptions included in their Bugcrowd submission.
Additional information regarding our assessment of the reported vulnerabilities and our remediation and mitigation activities can be found below.
Vulnerability Summary and Impact
At a high level, the resultant impact across both vulnerabilities, assuming all assumptions in the threat model are met as established by the researchers, theorize that an adversary could be “…able to perform a dictionary attack on a user’s passwords” or glean specific information logged on a backend server component which is related to the name of a Secure Note once the encrypted note is opened on the end user’s local client.
Vulnerability 1 relies upon on the assumption that the attacker (see the mitigation section below) has compromised backend LastPass server components and installs and uses a passive man-in-the-middle (MITM) attack of communications between the end user client and LastPass’ server to derive observable signal and metrics from direct user activity such as updates/modifications of passwords, an individually-shared password or password within a shared folder in a vault.
The researchers also explicitly state that “…we do not assume that the adversary controls any other aspects of the environment (malicious websites, rogue applications in the victim's device, etc.).” Note that it is possible, but not included in the researcher’s assumptions, that any client-side passive MITM mechanism is used to eavesdrop on client to server communications.
This researcher’s assumptions leverage the assumptive successful installation and use of a server-side passive MITM attack in addition to the use of shared credentials or folders containing such, which could be leveraged to indirectly brute force passwords using a classical dictionary attack as the adversary is assumed to be able to inject password entries into a successfully authenticated user's vault using a victim-accepted set of shared credentials. The attacker would then use an internal LastPass mechanism used to detect when duplicates of credentials are found.
Specifically, a brute-forced duplicate password that is injected into the vault via a shared credential/folder would indicate a “match” with an existing password already stored in the broader vault. This is accomplished by leveraging a metric communicated between the client and server which is used to provide administrative reporting and generate a security score to ensure users are aware they are using duplicated passwords for different accounts, which is in contrast to good security and password hygiene best practices.
It is important to note that server-side zero knowledge remains preserved as the password is never unencrypted server side as all cryptographic activities are performed client-side only; the actual passwords are never exposed to LastPass servers.
There are two known ways for an attacker to “inject” password entries into a victim vault. Note that use of the word inject is in reference to adding/modifying shared credentials or credentials in shared folders that are sent to, and accepted by the victim and not the user’s broader vault.
Thus, these two instances leverage credential sharing as a critical step used to exploit the vulnerability:
- If the attacker sends an authenticated victim an individual credential share and the victim accepts the share, then the client synchronizes any changed security score metadata between the client and the server as the researchers note: “…LastPass' clients automatically sync updates to shared entries, and thus the victim need not even have their vault open.” However, the speed and practicality of the attack is significantly lower than what is possible for shared folders (below) due to a delay in synchronization using this method.
- If the attacker sends an authenticated victim with an open vault a shared folder which is accepted/opened, the same process can be followed which allows for a relatively faster brute forcing process without additional victim interaction. This synchronization takes place over minutes given the iterative update frequency of the synchronization process.
While these attack patterns are possible within the context of the established threat model and their assumptions, the probability/likelihood of this being successful is low as it would require (per the researchers’ submission) that “...(1) the adversary and the victim have established a shared folder at the start of the attack, which the adversary will use to "inject" content into the victim's vault; and (2) that the adversary has a persistent foothold on LastPass’s servers, and can thus observe all incoming traffic from clients routed through them.
Given those assumptions, the configuration, compliance and security controls LastPass has in place in our infrastructure and application stacks would otherwise detect and prevent the compromise of backend infrastructure to facilitate the installation and use of a MITM proxy capability. Further, given the privilege necessary to do so, direct server access at that level would present a much greater risk and a completely different threat model reducing the practicality of these attacks. Also, the sequenced requirement for an end-user to also accept a shared credential or folder on their LastPass client led to the assessment of the low likelihood of this happening.
Vulnerability 2 relates to a metadata leakage event that leverages the same required persistent foothold on LastPass servers to perform a MITM attack and suggests that a certain logging event that suggests there is a break in our “zero knowledge” posture. To be clear, this is a logging artifact related to the name of a Secure Note and not a leak in the vault itself, but this metadata should not be visible in any form as the researchers suggest.
Specifically, when a victim opens and decrypts a secure note in their vault, the client sends the cleartext (unencrypted) name of the secure note item to a LastPass backend endpoint which is logged for end user and business administrator customer administrative and audit reporting. This technically leaks information if the attacker were able to access this logging data directly by viewing log files on the servers which would require privileged access or using a server-side passive MITM which we address below.
Resolution and Mitigation
Regardless of the likelihood of the required assumptions in the researcher’s threat model, we confirmed that should those assumptions be met, exploitation of the vulnerabilities is possible, however unlikely.
LastPass has identified a resolution for both vulnerabilities and our mitigation activities are almost complete.
The first vulnerability (vulnerability 1) has been mostly mitigated; the security scores sent from the client to the backend no longer reflect duplicated passwords between shared folder items and owned items and the individual shared item component is targeted for completion later this year as part of an on-going set of security enhancements to our product.
The second (vulnerability 2) has also been mitigated fully as the specific unencrypted metadata related to Secure Note names is no longer sent to the backend servers.
It should be again noted that the successful exploitation of these vulnerabilities is dependent on the assumption of the compromise and persistent footprint of LastPass backend servers to utilize a passive man-in-the-middle attack.
Acknowledgements
We are thankful to Andrés Fábrega, Armin Navamari, Ben Nassi, Prof. Rachit Agarwal, and Prof. Thomas Ristenpart of Cornell University for the efforts and have rewarded them accordingly per the terms of our Bug Bounty program.We encourage the security community to submit potential future vulnerabilities to LastPass via securitydisclosure@lastpass.com or https://bugcrowd.com/lastpass.
