LastPass: Hackers Stole Customer Vault Data In Cloud Storage Breach (bleepingcomputer.com) 38
LastPass revealed today that attackers stole customer vault data after breaching its cloud storage earlier this year using information stolen during an August 2022 incident. BleepingComputer reports: This follows a previous update issued last month when the company's CEO, Karim Toubba, only said that the threat actor gained access to "certain elements" of customer information. Today, Toubba added that the cloud storage service is used by LastPass to store archived backups of production data. The attacker gained access to Lastpass' cloud storage using "cloud storage access key and dual storage container decryption keys" stolen from its developer environment.
"The threat actor copied information from backup that contained basic customer account information and related metadata including company names, end-user names, billing addresses, email addresses, telephone numbers, and the IP addresses from which customers were accessing the LastPass service," Toubba said today. "The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data."
Fortunately, the encrypted data is secured with 256-bit AES encryption and can only be decrypted with a unique encryption key derived from each user's master password. According to Toubba, the master password is never known to LastPass, it is not stored on Lastpass' systems, and LastPass does not maintain it. Customers were also warned that the attackers might try to brute force their master passwords to gain access to the stolen encrypted vault data. However, this would be very difficult and time-consuming if you've been following password best practices recommended by LastPass. If you do, "it would take millions of years to guess your master password using generally-available password-cracking technology," Toubba added. "Your sensitive vault data, such as usernames and passwords, secure notes, attachments, and form-fill fields, remain safely encrypted based on LastPass' Zero Knowledge architecture."
"The threat actor copied information from backup that contained basic customer account information and related metadata including company names, end-user names, billing addresses, email addresses, telephone numbers, and the IP addresses from which customers were accessing the LastPass service," Toubba said today. "The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data."
Fortunately, the encrypted data is secured with 256-bit AES encryption and can only be decrypted with a unique encryption key derived from each user's master password. According to Toubba, the master password is never known to LastPass, it is not stored on Lastpass' systems, and LastPass does not maintain it. Customers were also warned that the attackers might try to brute force their master passwords to gain access to the stolen encrypted vault data. However, this would be very difficult and time-consuming if you've been following password best practices recommended by LastPass. If you do, "it would take millions of years to guess your master password using generally-available password-cracking technology," Toubba added. "Your sensitive vault data, such as usernames and passwords, secure notes, attachments, and form-fill fields, remain safely encrypted based on LastPass' Zero Knowledge architecture."
Re: (Score:3)
You technically don't trust them to secure your passwords. Each user encrypts there own set of passwords with an AES-256 master password.
It's right in the summary.
Re: (Score:2)
You technically don't trust them to secure your passwords. Each user encrypts there own set of passwords with an AES-256 master password. It's right in the summary.
Yes you do, they write the software and the whole stack that manages your password. The fact that encryption is used at one point in the stack doesn't change the fact you are trusting that all the other components from the app, to the storage are done properly and secure.
Re:Crazy Idea (Score:5, Interesting)
This is what FIPS 140-x validation [nist.gov] is for encryption -- validation of the correct behavior of the code itself. It isn't just "we use AES" it is an independent test that validates you did it right and didn't screw up. That's why there's a delay in initializing FIPS-validated crypto -- it requires a test with known values to be performed to ensure it wasn't tampered with. Even if everything else falls down the crypto works.
Re:Crazy Idea (Score:5, Interesting)
I have read about "security" products using "military strength AES". When in reality, they use AES-ECB, store MD5 hash of the user's password, and just use all zeros for the AES key for all encryption. The user won't know, and it looks "encrypted".
Encryption is all about implementation. FIPS validation does help greatly to ensure what is being used actually is cobbled together in a secure manner.
Re:Crazy Idea (Score:4, Interesting)
While FIPS ensures that you haven't just used base64 and called it encryption, FIPS validated code is typically worse, from a security perspective, than non-validated code.
Once a piece of code is FIPS validated it can't be changed, even if it has a potentially exploitable flaw like a buffer overflow. Any change requires recertification before it can be used, certification can take two years... it just doesn't happen in practice.
So you fix the buffer overflow, in the main tree of the code base. But the "secure" products that require and run FIPS, they run the old vulnerable but "validated" code.
And because the validation process is long and expensive, you will aggressively reuse that FIPS validated code for as long as you can, spreading that vulnerability.
A concrete example, openssl 3.0 just got a new FIPS validation a few months ago, which means that a huge number of FIPS certified products are running openssl v1.0.2 (certificate #1747), with all the known and publicly documented vulnerabilities. And they don't have to upgrade or stop, their certification isn't impacted by all the known issues.
Re: (Score:2)
I don't know what requires you to run FIPS, but the things that require me to run FIPS also require me to assess, test, and deploy (certified) updates when they are available. I cannot just live in the past.
Re: (Score:3)
You are mistaken. The portion that is validated is called the "FIPS module" and is a specific subset of OpenSSL that is implemented as a shared library -- fips.so or fips.dll. The rest of OpenSSL can be rebuilt with patches, it is just the module that has to be built in a very specific way as described in the security policy associated with it.
Bugs found w/1.0.2 were patched, and bugs found in later versions that affected 1.0.2 were backported and applied. While 1.0.2 was EOL in December of 2019, there are
Re:Crazy Idea (Score:5, Interesting)
They should at least secure URLs and such, like other password managers do. KeePass, 1Password, and others protect all user data, and even though they may have an index table so URL matching is quick, that is encrypted as well. In articles about the breach, it mentions that URLs are not encrypted.
URLs need just as much protection as a username and password. They can point an attacker to where an internal SAN or NAS is located to try default passwords. They can be used for phishing attempts, or in some cases. blackmail, especially if someone has URLs to sites that would be embarrassing. Even login attempts can be gleaned, like Slashdot's ability to login from a URL.
For a password manager, people need to be confident that -everything- put into it is encrypted. Not just passwords, not just usernames... all data.
I am going out on a limb here, and also mention that URLs unencrypted would be a great thing to harvest and sell off for user's personal profile data. This doesn't imply that LastPass would do this or let a third party do it, and it appears against their privacy policy [lastpass.com]. However the info is there, and a bad guy who (in theory) manages to get a foothold and is able to access the database could get a lot of intelligence by fetching those URLs over a period of time.
The solution? Go with a PW manager that does encrypt URLs. BitWarden comes to mind, as it is open source and has a sterling reputation.
As for compromising the backend database, 1Password's solution of having a 128 bit secondary secret key [1password.com], as well as a password is arguably the best. This way, an attacker has to have both the user's pass phrase and the 128 bit key, which is never stored with anything server side with 1Password, and means an attacker has to guess that key before being able to decrypt user data. Of course, an attacker can glean the key off the endpoint, but if the endpoint is compromised, the PW program is toast anyway. Having the 128 bit secondary key does a lot to mitigate server side compromise.
Of course, one could use a Keepass compatible program, like KeePassXC, Strongbox, or others, keep a keyfile stored on the endpoint (be it a PC or phone), and store the database on one's existing cloud storage. This provides the same protection, and ensures that an attacker accessing the backend cloud storage couldn't brute force the data.
Re: (Score:2)
I could see PW managers becoming a part of routers.
Re: (Score:2)
They should at least secure URLs and such, like other password managers do.
Fully agreed, Also their post is concerning because they Imply URLS are JUST AN EXAMPLE of what is unencrypted. What about our Website passwords' "Name" and "Notes" fields; Are those also Unencrypted?
I am not referring to 'Secure Notes' objects, but the Notes field of ordinary websites, where it is common to enter some additional authentication notes such as Security Questions+Answers.
What about Usernames are those encry
Re: Crazy Idea (Score:3)
Re: (Score:2)
Here is some implied trust I have with a PW manager. I don't just trust them to keep my passwords secure. It is assumed that I trust them to:
* Keep the cloud backend confidential, integrity validated, and available (the CIA trinity approach to security.) Passwords are useless if they were modified or I can't reach the servers.
* Use multiple tiers of encryption. For example, the backend application should encrypt all data on a column basis that is in the database. This is a basic security item, and do
Re: (Score:2)
Except for all the data that wasn't encrypted.
It's just a bad idea to use a service like this, especially a paid one. Giving them your real name, billing details, and more, just means exposing it to this kind of theft.
There's absolutely no reason to do it.
Worse than you thought (Score:2, Interesting)
Hopefully no one saved their DNC login credentials alongside all their furry porn creds. That could be embarrassing and immediately leakable. Sounds like site URLs and user info were clear-text.
Next, they probably got the code to handle that proprietary binary format, so that's one less safeguard that will be removed in short-order.
After that's done, it's a simple matter of throwing dictio
Have I Been Pwned? (Score:2)
well this makes me fee good (Score:2)
Some of the stolen vault data is "safely encrypted"
I feel safe now, this was only a matter of time. I keep my passwords in an encrypted file on my local PC that. I never used these password managers and being in the cloud just increases the risk. You might as well use a postit in a locked draw :)
How often were they hacked and lost customer data? (Score:2)
This must be leak / customer data lost / hack number 2 or 3, at least.
Bad News Released Just Before Xmas (Score:2)
So they post a media release -- containing worse news -- days before Xmas. (?)
Were they hoping the broader media wouldn't pick-up this announcement? Or that no one would be around to read it?
Now *that* I don't like.
Given they have no knowledge of our passwords, I was willing to overlook this breach. ... I'm one of those idiots w
But the timing of this release stinks. I'll be moving to the paid BitWarden in a few months when my LastPass subscription expires.
When I cancel my subscription I hope they ask "Why?"
Re: Bad News Released Just Before Xmas (Score:1)
" let's "
Idiot indeed.
Also, just cancelled the auto-renew on my paid LastPass.
Re: (Score:2)
Production data in a developer environment!! (Score:1)
Re: (Score:2)
Indeed. This is some high-grade incompetence at work. In well-run environments, there is a prohibition against that. The only place where it is outright forbidden is probably regulated industries though, like banking. I know examples of that.
Victim Blaming (Score:2)
dictionary attacks explained (Score:5, Informative)
As an attacker I will look for a block that has a large number of bits that are common to all plain text key stores.. Maybe a block that has a version number and some known formatting like a type and a length field, spaces or even just ascii where I know the high bit is 0. I just need about 40 bits of one block.
Next I get a list of a few hundred billion common passwords. These are combinations of pet names, colours, kids, months, names etc, plus common substitutions @ for a, ! for i, people also commonly pad passwords with 123
I encrypt the counter of my chosen block with all the hundreds of billions of passwords, XOR each result with the known bits for that block and then mask out the unknown bits (set them to zero), I then sort the list.
next I take the target block from my stolen key stores, mask out the bits in the block which I don't know and sort the key stores by the result.
I can now quickly run through both lists in order looking for a match. Each time I fine match I can be reasonably confident that I have the master password for that key store.
Re: (Score:3)
It would be nice if they added three additional columns. A 256 bit salt, a SHA-256 bit hash (encrypted) of all the previous stuff on the row, and a checksum (which doesn't have to be cryptographically secure, but good enough to check damage) as the final item. The outer checksum is something that could be run on the database backend just to tell if there is corruption or damage to rows, as a way to ensure integrity. The inner SHA256 hash ensures that nothing has been tampered with, even if the checksum w
Re: (Score:2)
Assuming you can associate a vault to a user and that user uses the email address they used with lastpass as the email address for logging into most sites. The known plaintext attack could be on the username and not the password. That would speed things up no?
Re: (Score:2)
Since LP is correctly using PBKDF2, assuming the default of 100,100 rounds, each guessed encryption has to be done 100K times. That's 2x10^16 tries. Assuming 1 billion attempts per second, that's 3.2 million years to completion, or 1.6 million years for 50% likelihood of random match. Sufficient to the task.
The URLs should still have been encrypted.
not 1.6 million years closer to already done (Score:2)
"I encrypt the counter of my chosen block with all the hundreds of billions of passwords"
Since LP is correctly using PBKDF2, assuming the default of 100,100 rounds, each guessed encryption has to be done 100K times. That's 2x10^16 tries. Assuming 1 billion attempts per second, that's 3.2 million years to completion, or 1.6 million years for 50% likelihood of random match. Sufficient to the task.
The default for PBKDF2 is 100,000 or 10^5 and 100 billion is 10^11. So 10^16 hashes. At 1 billion hashes a second that's 10^7 seconds or 115 days. But a billion hashes a second isn't that much if I have a lot of money I would just rent the computing power and do it all in a day. If your password store was stolen and your password was in a my dictionary your store is already broken.
One dictionary attack to rule them all (Score:2)
How many of those master passwords are 123456?
Spearphishing in 3..2..1 (Score:2)
So, OK they did not get folks master passwords.. but with enough data to identify/ contact them how long before high value targets start seeing really sophisticated spear phishing attacks to get in so they can access the master passwords?
Probably already started.
I know that done right these cloud based wallets can be really convenient and secure but they still just make me nervous ... Maybe I just don't get the kids these days and what I'm doing is the digital equivalent of my grandma who lived through the
What if attacker knows some of the passwords or us (Score:1)
LastPass will be always the week link (Score:1)
LastPass has to store the full text of your passphrases to other sites. These passphrases are encrypted, but the encrypted blob still contains the full passphrases. As the article says, soon as the thieves brute force and guess your master passphrase, they will be able to see all your passphrases to other sites in clear text and use them for logins.
On the other hand, slashdot and other sites can store only salted peppered has
Unencrypted URL's (Score:2)
> " in a proprietary binary format that contains both unencrypted data, such as website URLs"
I posted about the URL's on the last story.
This metadata leak is what caused me to leave LastPass several years ago, thanks to an intrepid whistleblower on Reddit. FWIW I informed TWiT about this while they were still hawking LastPass because they have influence in the security community (to no avail).
Many people counter-claimed that unencrypted URL's was fixed not long after I left. I didn't see any official c
Keepass (Score:1)