Skip navigation

Breaking Down the Probable LastPass Breach

If I were a betting man, I'd bet that LastPass has been owned.

In case you haven't heard, LastPass, everyone's favorite browser-based password manager, posted an unsettling blog post yesterday detailing an anomalous event that occurred Tuesday morning on their infrastructure:

Tuesday morning we saw a network traffic anomaly for a few minutes from one of our non-critical machines. ... After delving into the anomaly we found a similar but smaller matching traffic anomaly from one of our databases in the opposite direction (more traffic was sent from the database compared to what was received on the server). Because we can't account for this anomaly either, we're going to be paranoid and assume the worst: that the data we stored in the database was somehow accessed.
Based on the information presented in their blog post, there's a couple potential scenarios here, each with a varying degree of severity and likelihood:
  • Nothing happened. (unlikely)
  • LastPass was compromised and had their master password database exfiltrated. (likely)
  • LastPass was compromised and had both the master password database and encrypted blobs exfiltrated. (possible)
  • LastPass is *still* owned and everyone resetting their master passwords just gave the attackers access to the encrypted blobs that may have been exfiltrated. (scary, but unlikely)
In my personal opinion, I would move forward with the assumption that LastPass was indeed compromised and that the master password database was successfully exfiltrated. As we've previously mentioned, attackers are very keen to going after "infrastructure" services that may be a relatively soft, yet extremely valuable target.

So how was LastPass owned? In most compromises, there is an initial entry point (via weak passwords, vulnerable web apps, etc) followed by lateral movement within the network (via captured employee credentials, weak internal security practices, etc) until the attacker reaches his desired target. In the LastPass blog post, they specifically mention an Asterisk server that was exposed to the Internet, which could be a smoking gun:

We had our asterisk phone server more open to UDP than it needed to be which was an issue our auditing found but we couldn't find any indications on the box itself of tampering
I found this quote particularly disturbing as Asterisk is known for having a no-so-great security track record with a number of remote code execution (RCE) vulnerabilities in its channel drivers (SIP, IAX, SCCP, etc). I interpret the "more open to UDP than it needed to be" as indicating that some of these lesser-used and more-frequently-vulnerable channel drivers may have been mistakenly enabled and exposed. It's unclear why the Asterisk server was specifically mentioned in the blog post, but perhaps more is known about attacker entry point than is being initially disclosed.

Despite the doom and gloom of possibly leaking the master password database, I applaud LastPass for taking the steps to require a master password change for all its users, a decision that probably faced significant internal resistance as it is major annoyance to users who may find themselves unable to access their stored passwords.

However, as in any potential leak of a password database (coughPSNcough), the affected party should disclose what hashing/salting schemes were employed for storing the passwords. A weak hashing scheme would increase the risk of exposure of users' master passwords. While LastPass mentions in the post that they will be moving to PBKDF2 in the future, that provides little assurance of the security of the previous scheme in place when the potential compromise occurred. Hopefully LastPass will follow up with additional information about breach so that users can accurately assess their risk.

Speaking of users, I would recommend users take the following steps to limit the exposure of their credentials from this incident or any potential future incidents:

  • Go through your LastPass keychain and change your passwords for any websites that are important to you. If you want ensure you're safe, you should assume that the master password database and encrypted blobs were exfiltrated and that the attackers will be successful in cracking your master password, thereby recovering all the saved entries in your keychain. Better safe than sorry.
  • Never store sensitive passwords in your LastPass keychain. LastPass is great for all of the random non-critical websites you browse and log in to on a daily basis, but the risk of exposure is too great to trust it for highly sensitive credentials (eg. online banking credentials).
  • Regardless of the outcome of this incident, you should be using a master password that follows strong password guidelines and includes mixed-case alpha, numeric, and special characters.
  • And lastly, encourage the websites you frequent to employ two-factor authentication (I may be a bit biased but I hear those Duo Security folks have a pretty slick two-factor platform ;-)), so that we can kill all of these password management headaches once and for all.
We'll be sure to update this post if and when more information about the potential compromise becomes available from LastPass or other parties. Until then, let's all collectively cross our fingers that the password dump doesn't pop up on PirateBay any time soon!