5 ms·

The wiki (https://github.com/cfbao/lastpass-vault-parser/blob/master/lastpass-vault-format.md https://github.com/cfbao/lastpass-vault-parser/blob/master/l...) c

by r0uv3n 4y ago

The wiki (https://github.com/cfbao/lastpass-vault-parser/blob/master/lastpass-vault-format.md https://github.com/cfbao/lastpass-vault-parser/blob/master/l...) contains a list of all unencrypted fields in an `acct` data block. It is trivial to decode the custom format of LastPass (e.g. using exactly this tool, but figuring out the format manually doesn't seem much harder). If anyone is interested, although this is originally from 2018, all of these fields still exist and still only the same 6 fields are encrypted. I checked this by creating a LastPass account with a temporary E-mail and looking at the `getaccts.php` network request made upon login to the website. There also seem to be 3 new fields unknown to the tool (in the resulting csv these are just "?", "??", and "???"). "??" appears to be a timestamp of recent settings or password changes. Of particular interest are the following fields - "url": Probably the biggest deal. Attackers know exactly for which sites a specific user used LastPass. - "sharedfromaid": "aid of the sharer's Site/Secure Note". Might be used to correlate different LastPass users. - various timestamps (creation, last access, modification), bools "autologin" and "never-autofill", "fav" (added to favorites): Might be used to infer usage of websites. - "genpw": "Is an auto-saved generated password". Really useful for deciding whether brute-forcing is worth it. - "breached": I couldn't check whether this key is actually being used. If it is, this seems like an incredibly useful shortcut for attackers (directly telling them where passwords from existing breaches might be tried).

mdaniel 4y ago
I've been trying to reason through the threat model for this and 1Password's newfound cloud storage. This write-up, and any reversing efforts for 1P, only speak to what goes over the network and how the client stores locally (1P uses b64 in sqlite on the client, for example) but I don't know how anyone could speak to what the breach had access to unless those dumps are made public. One scenario I can imagine is that the API routes merely add authentication over s3:PutObject and the wire serialization is the storage format. But surely if that were true then 1P wouldn't have thrown such a hissy fit over giving up local vaults since their clients already supported multiple cloud backends anyway. Coming back to the linked repo, the files are 4 years old: did LP not change their format at all over 4 years?
- r0uv3n 4y ago
  You're entirely right of course, the vault data as accessed in the breach need not necessarily be in the same format as what is transmitted to the client. And yes, the whole repository is from 2018, but I checked again today and it seems only 3 additional fields were added. In particular the same fields are unencrypted as before.
  - mdaniel 4y ago
    That's stunning to hear, and also speaks to "then they must not have been adding many features" or that file format must be absolutely rockstar. I'll try to make time to study it in order to learn which this is (BTW, you also have duplicate comments: https://news.ycombinator.com/item?id=34110529 https://news.ycombinator.com/item?id=34110529)
    - deleted 4y ago
      [deleted]
    - r0uv3n 4y ago
      The three additional data fields might fulfill some functions related to new features. Additionally, there is a full history of all former passwords which is transmitted in its own request, so in particular this vault format doesn't seem to contain all data LastPass has concerning a particular account (though what is unencrypted within this format is surely also unencrypted on the LastPass servers). I think I'd see no problem if LastPass had a great product and kept it as is for extended periods of time, I don't need new features every few months for a security product. But this should have all been encrypted from the start, and there were discussions about this 4 years ago already https://www.reddit.com/r/AskNetsec/comments/8v7bcc/just_a_reminder_that_lastpass_is_sending_the_url/ https://www.reddit.com/r/AskNetsec/comments/8v7bcc/just_a_re.... This could have been fixed for years, but it's the same even now.
- deleted 4y ago
  [deleted]
- tailspin2019 4y ago
rkagerer 4y ago
Any idea where the history information is saved? (previous passwords and their dates)
- r0uv3n 4y ago
  I don't know where that information is saved, but it isn't transmitted with the normal vault format on login (at least on the website). When opening the history dialog for a given password/account, a new request is made specifically for the password history. The response contains the edit times in plaintext and the encrypted passwords.

by r0uv3n 4y ago

mdaniel 4y ago

I've been trying to reason through the threat model for this and 1Password's newfound cloud storage. This write-up, and any reversing efforts for 1P, only speak to what goes over the network and how the client stores locally (1P uses b64 in sqlite on the client, for example) but I don't know how anyone could speak to what the breach had access to unless those dumps are made public. One scenario I can imagine is that the API routes merely add authentication over s3:PutObject and the wire serialization is the storage format. But surely if that were true then 1P wouldn't have thrown such a hissy fit over giving up local vaults since their clients already supported multiple cloud backends anyway. Coming back to the linked repo, the files are 4 years old: did LP not change their format at all over 4 years?

r0uv3n 4y ago
You're entirely right of course, the vault data as accessed in the breach need not necessarily be in the same format as what is transmitted to the client. And yes, the whole repository is from 2018, but I checked again today and it seems only 3 additional fields were added. In particular the same fields are unencrypted as before.
- mdaniel 4y ago
  That's stunning to hear, and also speaks to "then they must not have been adding many features" or that file format must be absolutely rockstar. I'll try to make time to study it in order to learn which this is (BTW, you also have duplicate comments: https://news.ycombinator.com/item?id=34110529 https://news.ycombinator.com/item?id=34110529)
  - deleted 4y ago
    [deleted]
  - r0uv3n 4y ago
    The three additional data fields might fulfill some functions related to new features. Additionally, there is a full history of all former passwords which is transmitted in its own request, so in particular this vault format doesn't seem to contain all data LastPass has concerning a particular account (though what is unencrypted within this format is surely also unencrypted on the LastPass servers). I think I'd see no problem if LastPass had a great product and kept it as is for extended periods of time, I don't need new features every few months for a security product. But this should have all been encrypted from the start, and there were discussions about this 4 years ago already https://www.reddit.com/r/AskNetsec/comments/8v7bcc/just_a_reminder_that_lastpass_is_sending_the_url/ https://www.reddit.com/r/AskNetsec/comments/8v7bcc/just_a_re.... This could have been fixed for years, but it's the same even now.
deleted 4y ago
[deleted]
tailspin2019 4y ago

rkagerer 4y ago

Any idea where the history information is saved? (previous passwords and their dates)

r0uv3n 4y ago
I don't know where that information is saved, but it isn't transmitted with the normal vault format on login (at least on the website). When opening the history dialog for a given password/account, a new request is made specifically for the password history. The response contains the edit times in plaintext and the encrypted passwords.