LastPass Says Hackers Had Internal Access For Four Days (bleepingcomputer.com) 27
LastPass says the attacker behind the August security breach had internal access to the company's systems for four days until they were detected and evicted. BleepingComputer reports: In an update to the security incident notification published last month, Lastpass' CEO Karim Toubba also said that the company's investigation (carried out in partnership with cybersecurity firm Mandiant) found no evidence the threat actor accessed customer data or encrypted password vaults. "Although the threat actor was able to access the Development environment, our system design and controls prevented the threat actor from accessing any customer data or encrypted password vaults," Toubba said.
While method through which the attacker was able to compromise a Lastpass developer's endpoint to access the Development environment, the investigation found that the threat actor was able to impersonate the developer after he "had successfully authenticated using multi-factor authentication." After analyzing source code and production builds, the company has also not found evidence that the attacker tried to inject malicious code. This is likely because only the Build Release team can push code from Development into Production, and even then, Toubba said the process involves code review, testing, and validation stages. Additionally, he added that the LastPass Development environment is "physically separated from, and has no direct connectivity to" Lastpass' Production environment. The company says it has since "deployed enhanced security controls including additional endpoint security controls and monitoring," as well as additional threat intelligence capabilities and enhanced detection and prevention technologies in both Development and Production environments.
While method through which the attacker was able to compromise a Lastpass developer's endpoint to access the Development environment, the investigation found that the threat actor was able to impersonate the developer after he "had successfully authenticated using multi-factor authentication." After analyzing source code and production builds, the company has also not found evidence that the attacker tried to inject malicious code. This is likely because only the Build Release team can push code from Development into Production, and even then, Toubba said the process involves code review, testing, and validation stages. Additionally, he added that the LastPass Development environment is "physically separated from, and has no direct connectivity to" Lastpass' Production environment. The company says it has since "deployed enhanced security controls including additional endpoint security controls and monitoring," as well as additional threat intelligence capabilities and enhanced detection and prevention technologies in both Development and Production environments.
Sounds like they did this mostly right (Score:5, Interesting)
These days it is exceptionally hard to keep an attacker completely out. But you can make sure they do not sabotage anything really critical if they get in. Sounds to me like exactly this has happened here. Whether source code theft is a proble, depends on the quality of that source code.
While not stated, the attack was likely compromising the PC of a developer and the smartphone with the 2nd vector in addition. That is why privileged accounts and critical accounts should have a 2nd factor that is not easily identified as belonging to the user. This usually means a 2nd phone with nothing but the authenticator app on it and ideally no SIM card in the first place or a discrete authentication token with no network access. It is inconvenient as it means carrying a 2nd device, but prevents compromise of the 2nd factor pretty reliably. I am currently recommending to my audit customers to do this for all privileged account access.
Re:Sounds like they did this mostly right (Score:5, Interesting)
This is why I like Yubikeys. For access, one needs the physical key, and the PIN code. Three wrong guesses, the key is locked. YubiKeys are also great for GPG code commit signing as well.
Re: (Score:2)
This is why I like Yubikeys. For access, one needs the physical key, and the PIN code. Three wrong guesses, the key is locked. YubiKeys are also great for GPG code commit signing as well.
Definitely a good choice for a token if you need what it can do. In principle, it can be attacked as it gets connected to a computer, so not an offline token. Should not be a concern in most scenarios IMO though.
Re: (Score:2)
Agreed. However, I don't know anything that can help, once an attacker has browser access and get to those tokens. But it does mitigate things a lot. A compromised computer is pretty much game over, no matter how much security is there, but if an app does prompt for access with Yubikeys if the user requests some major task (sign a document, delete some stuff, ask for admin role rights), that can at least help. For example, a button press before the HSM certifies a key, or signs a package can keep rogue
Re: (Score:2)
It depends. If it is user authentication, a token that is not network reachable or identifiable (e.g. an authenticator app not on the personal smartphone) can be used for reliable user authentication even with a compromised browser. It will not tell you whether there is an attacker in the loop, but it will tell you the user on the other end is who they claim. Of course, for many scenarios that compromised browser is basically game over for security, that is why I think a toke that plugs into the computer is
Re: (Score:2)
LastPass just doesn't offer enough benefit to justify the increased attack surface.
KeePass supports cloud storage. There are plug-ins for all major browsers, or you can just copy/paste from KeePass manually. Being a separate app, not written in Javascript and not running in the browser process, gives you an extra layer of defence.
KeePass can handle OTP codes too, although you are better off keeping them on a separate device for even more security. I have both a phone and Yubikey for that.
Re: (Score:2)
Quite possibly. I was commenting on the attack and their defenses though.
Re: (Score:2)
KeePass is fine for s single user, not so much for a business where multiple users need role based access to passwords and other enterprise features like audit trails and integrations with external authentication such as Okta.
Re: Sounds like they did this mostly right (Score:2)
Does it fill Android apps? That's what I like so much about LastPass.
Stop giving them a pass (Score:2)
https://tech.slashdot.org/stor... [slashdot.org]
https://it.slashdot.org/story/... [slashdot.org]
https://yro.slashdot.org/story... [slashdot.org]
https://it.slashdot.org/story/... [slashdot.org]
https://it.slashdot.org/story/... [slashdot.org]
https://it.slashdot.org/story/... [slashdot.org]
https://it.slashdot.org/story/... [slashdot.org]
https://it.slashdot.org/story/... [slashdot.org]
https://it.slashdot.org/story/... [slashdot.org]
Why do people still trust them? I mean, after this latest hack where the source code was apparently stolen I suppose it may soon involuntarily become open source, but you can do better.
Re: (Score:2)
Well, compared to "use one password for everything" they're a lot more secure... so they're a popular attack site for hackers. Most attackers get the dev code, but not passwords. Fair enough.
Re: (Score:2)
Re: Stop giving them a pass (Score:3)
Unless some problem with the vault encryption has been found it shouldn't matter. Even if an attacker gets my vault file they won't be able to do anything with it.
Centralized password repositories (Score:2)
...give hackers a centralized location to try to hack.
Why? (Score:5, Insightful)
Re: Why? (Score:2)
You don't, you trust them to encrypt your passwords. LastPass doesn't have your passwords, they have a blob of ciphertext.
Re: (Score:2)
Dodged a bullet... this time... maybe (Score:2)
"Although the threat actor was able to access the Development environment, our system design and controls prevented the threat actor from accessing any customer data or encrypted password vaults"
If they had access to LastPass's dev environment, it may be a bit premature to declare customer data as "safe". They should really say "to this point in time, the company has also not found evidence that the attacker tried to inject malicious code."
Maybe add a secondary key into the encryption? (Score:2)
One of the things that 1Password does is, upon account creation, give the user a must-write-down account [1password.com] key. This key is used with their master password to gain access.
The advantage of having this secondary key is the fact that even if someone filched 1Password's entire password database, it would be impossible to brute force any info on it, unless the attacker also had access to the user's endpoint, or via some other means, found out their account key.
Other password programs have this as an option. Code
Re: Maybe add a secondary key into the encryption? (Score:2)
What is the benefit of two passwords over one strong one?
Re: (Score:2)
Not everyone has a single strong password. Having a keyfile also deters brute force completely, either now, or in the future where more computing power is available.
Re: Maybe add a secondary key into the encryption (Score:2)
Because it's long and complex? Does it solve anything that requiring a long complex password wouldn't?
Re: (Score:2)
It lets you pick an easy to remember password to use to login each time (because you assume the guy who steals your laptop or your skeevy friend won't create a massive cloud job to bruteforce your password) while still having a very high degree of protection against the hackers who compromise the password manager server who likely will run massive bruteforce attacks against the database (they get to amortize costs of hashing passwords over many many accounts).
Re: (Score:2)
Because there is a cost to remembering very long passphrases. A very nice solution is to have a passphrase that you enter once per device (keep it written down somewhere...or hell even on your devices) as well as a passphrase that you enter each time you are logged out.
This way, even if someone gains full access to the remote servers they can't just brute force your password (if it's short enough to use and remember it's likely to have limited entropy) since they also need the really long and hard to remem
Re: Maybe add a secondary key into the encryption (Score:2)
Ah so the passkey thing lives on the device. So it's kind of a 2fa thing sounds like.