Hacker News new | ask | show | jobs
by palant 1637 days ago
I am the author of this article. I’ve kept it short, some points made there could have been expanded considerably. So if there are questions, feel free to ask here.
7 comments

What is your opinion of the analysis from LastPass themselves?[0] It seems to have been some internal alerting that went wrong, which does happen from time to time.

> Our initial findings led us to believe that these alerts were triggered in response to attempted “credential stuffing” activity [...] We quickly worked to investigate this activity and, at this time, have no indication that any LastPass accounts were compromised by an unauthorized third-party as a result of these credential stuffing attempts, nor have we found any indication that user’s LastPass credentials were harvested by malware, rogue browser extensions, or phishing campaigns.

> Our investigation has since found that some of these security alerts, which were sent to a limited subset of LastPass users, were likely triggered in error.

[0] https://blog.lastpass.com/2021/12/unusual-attempted-login-ac...

The formulation is vague enough that it could mean anything. Maybe the alerts were sent out by mistake which would be good news. But they don’t quite say that. Their statement might also mean that they rather disabled legitimate alerts so that people don’t get concerned. So they might have “cured” the symptoms without addressing the actual issue.

It certainly isn’t reassuring that they keep talking about credential stuffing, even though it’s quite unlikely to be the culprit here.

>Our investigation has since found that some of these security alerts, which were sent to a limited subset of LastPass users, were likely triggered in error. As a result, we have adjusted our security alert systems and this issue has since been resolved.

This added bit hints that these emails were erroneously sent in response to the wrong password being attempted against the master account (which normally doesn't rate an email). It isn't fully spelled out tho.

LP spends most of the blogpost going on about bad user practices - which feels a lot like gaslighting in this context.

edit: I'm leaning toward accepting LP's incomplete, forced explanation and that hackery isn't in play here.

> erroneously sent in response to the wrong password being attempted against the master account

This seems likely. After the original HN post, I went to delete my LastPass account as I've been using Bitwarden for several years. I initially used the wrong password, but then successfully logged in.

I got the alert email in question, so either it was sent in response to the wrong password (incorrectly) or it was sent in response to the full login, which of course wasn't blocked. The former seems more likely to me.

I agree that it's more likely review misses a change that results in spurious "Correct master password" emails than say, a change that lets people log in as you without the correct password.

It could also happen that there's always been a low frequency bug (e.g. 1 in every 50000 failed login attempts is mistakenly treated as "correct master password" and triggers email) but the nature of it was triggered more recently by some change in attacker behaviour.

e.g. imagine your bug is, if the failed login occurs just after the top of the hour, a variable somewhere has recently changed and this is mistaken as "correct master password" even when it isn't, so the email goes out. Somebody at LastPass finds this bug, it's happening maybe 2-3 times per month, no big deal, P3 give the new engineer trainee something interesting to look at in 2022.

But meanwhile bad guys discover the timeout they've been fighting resets hourly. Instead of one attempt every ten seconds per IP address in the botnet they're using to try phished credentials, they can do 360 attempts in the first 10 seconds of the hour, then do something else with the botnet for the rest of the hour. Now most of these attempts hit that bug, and suddenly dozens of spurious emails per hour are going out to your users. Ouch. Now, who is going to explain to the big boss that this is the same bug you triaged as P3 last month?

> LP spends most of the blogpost going on about bad user practices - which feels a lot like gaslighting in this context.

He spends most of the post dismissing user error. That looks very reasonable to me, as those are the most likely issues by a large margin.

Good write up. They have been in full PR deflection mode rather than to actually engage those users to which it apparently happened in dialogue to try to nail down the root cause and were much too quick with their denial of their own involvement for that to be believable.
Thanks for writing this up! After reading LastPass' very vague response, they did not inspire confidence for me to stick around as a paying customer.

I am unsure if this is too small of a compromise for them to be able to a) care or b) spend resources on investigating or that they just don't know what's happening.

It’s vacation time, they simply don’t have the people on site to investigate the issue quickly. So far not surprising, and certainly intended by the timing of this attack.

That their first reaction is to downplay rather than to admit that they don’t know much yet – that’s rather typical of LastPass unfortunately. Sadly, with this approach they aren’t exactly an outlier in the industry.

There might be a cluster of old accounts in play and perhaps a smaller cluster of newly created or newly changed accounts. This hints at the possibility of more than one bad actor.

It's possible the old accounts could be some old stock sold on a darknet forum and are being bundled in with the newer hashes/pwds. It's also possible that the entity harvesting the newer hashes/pwds isn't the same one who is amateurishly attempting to access the accounts.

Note: Lastpass's geolocation may be off (even more than usual for geolocation) as some of the IPs are in ownership dispute and all of them may be for VPNs.

Yes, the sample is rather small to draw conclusions from. The biggest concern however are the people who got the notification again after changing their master password. It just doesn’t make sense if credential stuffing is what we are talking about.
They claim to have 30,000,000 users but we've only seen a handful of reports about this, why such a small percentage? Wouldn't someone with a full list of passwords want to exfiltrate as much data as possible before it became obvious they had the creds?
First of all: I don’t think that all accounts are affected. For example, my own account didn’t receive this message. Assuming that indeed a logging server was compromised, we don’t know under which conditions the password hash is logged. Maybe it’s only people who used the web interface to log in, or only people who changed their master password, or people who hit a particular error condition.

Second: People only notice the failed login attempts. I don’t know what exactly this attack looks like, but I doubt that the point is triggering these alerts for as many people as possible. They rather want to log in successfully, meaning without any alerts being produced. Who knows how often this happened without anybody noticing?

Finally: We only know about people who were concerned enough about these alerts to write about it on Hacker News (or in some cases Twitter). That’s a tiny fraction of all LastPass users.

There are ways this scenario could manifest. The person submitting the passwords could have purchased them on the darkweb and may be figuring out how to use them. We'd be seeing the trial+error part of their learning curve.
Whoever first gets a hold of the password hashes would need to bruteforce individual entries or cross-check them against known leaks for reuse, which takes time. It's natural that they would only go after high value targets like famous people, cryptocurrency users, etc, then resell the database after they got as much value out of it as possible.
You say that the LastPass protocol is subject to hash replay attacks (my description). I'd be surprised if there wasn't some time dependent pepper (e.g. challenge/response) in the hash, since this seems like a huge vulnerability, and storage of the hash allows for off-line attacks. Normally, I'd think diffie-hellman for this.
No, there is nothing. The complication with challenge/response schemes is that the server doesn’t know the master password – it only has that one hash, so it’s always comparing against it. There are PAKE protocols which work around this issue, but LastPass didn’t implement any of them (probably for historical reasons already, I think LastPass is older than most of these approaches).

Normally, it isn’t such a huge vulnerability. TLS encryption is there, so nobody should be able to catch that hash in transition. And even if they did, the most sensitive data is encrypted so that you still need the master password. Still, this is rather suboptimal.

Can you explain how PAKE would help here? Going just off Wikipedia, it is a key-establishment protocol "based only on their knowledge of a shared password". So I would expect that the shared password is the master password or its hash and the parties are the user and the LP server. So wouldn't using PAKE require the server to know your master password or its hash? That sounds the same as before. Is the idea that they both know the hash only transiently (instead of the server knowing it persistently as it does today) and then establish some other key which they use after that?
No, modern PAKE protocols work without the server actually knowing the password. The server has a “verifier” that lets them tell whether the client’s response to a given challenge is correct. I’m no expert on this topic but https://blog.cryptographyengineering.com/2018/10/19/lets-tal... is a good start.
I haven't seen any mentions discussing HTTP request smuggling try. This could cause LP's internal or external load balancers to misdirect requests/responses.

Thoughts on this as a possible root cause?

I’ve given this some thought, but I think that this scenario still requires someone to attempt a login with correct credentials. It cannot be the legitimate owner however if the account hasn’t been touched for a year.