Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Phishing attack against Lastpass

seancassidy.me

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Phishing attack against Lastpass

#61

Post by DrewHintz »

level3 wrote: post #45
komaromy wrote: post #41

Earlier quoted context omitted.

Sending the notification still seems like a better idea than not doing it. If a page has gotten you to enter the password at all then it's pretty likely that it knows the significance before the notification.

But does the page even need to get you to enter it? Could it be possible to set up a hidden password field for LastPass to monitor, and then run a dictionary attack in the background, waiting for the notification? (I don't use LastPass, so I don't know anything about how this feature is designed.)

This can be protected against by the extension looking at keyboardEvents and verifying the isTrusted attribute. Here are details about how we do this in Password Alert: https://github.com/google/password-alert/blob/master/SECURIT...

Before Chrome implemented isTrusted, it was a bit more tricky and we had to rely on a variety of attributes that did not have as much of a security guarantee.

Re: Phishing attack against Lastpass

#62

Post by DrewHintz »

pwman wrote: post #60
bqe wrote: post #39

Earlier quoted context omitted.

Sean here: the mitigation you speak of (notifying the user that they've typed in their master password) is actually another vulnerability. A malicious page can detect the fact that LastPass put that notification, and then it knows exactly what your master password is without even contacting LastPass. I've told your security team about this but haven't yet received a response.

Yes, we're pushing the notification to a new tab (which can't be blocked or interfered with) once it goes through QA -- likely early next week. Also even multifactor now must be new location verified so the ability to exploit this is now extremely low. Any attempt utilize those credentials will be blocked an email will be generated just like what happened in the non-multifactor case. Hopefully you've gained enough at…

> Yes, we're pushing the notification to a new tab (which can't be blocked or interfered with)

We went through a similar iteration with Password Alert. If you're setting focus on the new tab, an onBlur event could indicate that the current page has lost focus, perhaps due to the warning tab. I think notifying the user is still net-positive for the user's security.

Re: Phishing attack against Lastpass

#63

Post by level3 »

DrewHintz wrote: post #61
level3 wrote: post #45

Earlier quoted context omitted.

But does the page even need to get you to enter it? Could it be possible to set up a hidden password field for LastPass to monitor, and then run a dictionary attack in the background, waiting for the notification? (I don't use LastPass, so I don't know anything about how this feature is designed.)

This can be protected against by the extension looking at keyboardEvents and verifying the isTrusted attribute. Here are details about how we do this in Password Alert: https://github.com/google/password-alert/blob/master/SECURIT... Before Chrome implemented isTrusted, it was a bit more tricky and we had to rely on a variety of attributes that did not have as much of a security guarantee.

Thanks for the helpful explanation! Those seem like fair mitigations.

Reading more on it, though, since isTrusted can apparently be spoofed, it looks like the main obstacles are the (2) rate-limiting and the (3) intentional collisions.

For (2), I suspect typical users would have a memorizable master password that's more susceptible to brute forcing, but of course it depends on the actual rate limit and how long you can keep the script running. Alternatively, I suppose a malicious script could overwhelm the rate limit so that the user wouldn't receive a legitimate warning.

For (3), I wonder whether LastPass has a similar mitigation? From what I understand, they don't store the actual password, so all you would need is a matching hash.

I'd be interested to know more details about LastPass's protections.

Edit: I just saw pwman's response above.

Re: Phishing attack against Lastpass

#64

Post by viraptor »

bikamonki wrote: post #58
viraptor wrote: post #40

Earlier quoted context omitted.

What do you do on pages that require / forbid special characters and require / forbid length >8 characters?

Thats an easy tweak (global replace the forbidden characters after hash) on the hash generator and for the max length I normally just copy paste the required length.

But how do you know which transformation to apply when you log in? Unless you store the rules for each site somewhere, but then it's not really portable system.

Re: Phishing attack against Lastpass

#65

Post by pwman »

DrewHintz wrote: post #62
pwman wrote: post #60

Earlier quoted context omitted.

Yes, we're pushing the notification to a new tab (which can't be blocked or interfered with) once it goes through QA -- likely early next week. Also even multifactor now must be new location verified so the ability to exploit this is now extremely low. Any attempt utilize those credentials will be blocked an email will be generated just like what happened in the non-multifactor case. Hopefully you've gained enough at…

> Yes, we're pushing the notification to a new tab (which can't be blocked or interfered with) We went through a similar iteration with Password Alert. If you're setting focus on the new tab, an onBlur event could indicate that the current page has lost focus, perhaps due to the warning tab. I think notifying the user is still net-positive for the user's security.

Interesting, I hadn't heard of Password Alert -- we should definitely share notes if you're open to it -- I'd love to be able to generalize what we're doing to other domains if we could -- it's unfortunately cpu intense how we're doing it.

Re: Phishing attack against Lastpass

#66

Post by bikamonki »

viraptor wrote: post #64
bikamonki wrote: post #58

Earlier quoted context omitted.

Thats an easy tweak (global replace the forbidden characters after hash) on the hash generator and for the max length I normally just copy paste the required length.

But how do you know which transformation to apply when you log in? Unless you store the rules for each site somewhere, but then it's not really portable system.

Like I said before: rules are stored in my brain. So far reliable and portable :)

Re: Phishing attack against Lastpass

#67

Post by DrewHintz »

level3 wrote: post #63
DrewHintz wrote: post #61

Earlier quoted context omitted.

This can be protected against by the extension looking at keyboardEvents and verifying the isTrusted attribute. Here are details about how we do this in Password Alert: https://github.com/google/password-alert/blob/master/SECURIT... Before Chrome implemented isTrusted, it was a bit more tricky and we had to rely on a variety of attributes that did not have as much of a security guarantee.

Thanks for the helpful explanation! Those seem like fair mitigations. Reading more on it, though, since isTrusted can apparently be spoofed, it looks like the main obstacles are the (2) rate-limiting and the (3) intentional collisions. For (2), I suspect typical users would have a memorizable master password that's more susceptible to brute forcing, but of course it depends on the actual rate limit and how long you c…

> isTrusted can apparently be spoofed

isTrusted cannot be spoofed in this situation, which is its intended use in Chrome. A Chrome extension in the isolated world is receiving events from the main world and checking isTrusted for those events.

Re: Phishing attack against Lastpass

#68

Post by DrewHintz »

pwman wrote: post #65
DrewHintz wrote: post #62

Earlier quoted context omitted.

> Yes, we're pushing the notification to a new tab (which can't be blocked or interfered with) We went through a similar iteration with Password Alert. If you're setting focus on the new tab, an onBlur event could indicate that the current page has lost focus, perhaps due to the warning tab. I think notifying the user is still net-positive for the user's security.

Interesting, I hadn't heard of Password Alert -- we should definitely share notes if you're open to it -- I'd love to be able to generalize what we're doing to other domains if we could -- it's unfortunately cpu intense how we're doing it.

Sure thing, I'm happy to help. Our code is at https://github.com/google/password-alert and feel free to email me any questions at drew@overt.org

However we haven't published a good design document about the client. If you're interested, let me know and I'll try to publish one.

Re: Phishing attack against Lastpass

#69

Post by level3 »

DrewHintz wrote: post #67
level3 wrote: post #63

Earlier quoted context omitted.

Thanks for the helpful explanation! Those seem like fair mitigations. Reading more on it, though, since isTrusted can apparently be spoofed, it looks like the main obstacles are the (2) rate-limiting and the (3) intentional collisions. For (2), I suspect typical users would have a memorizable master password that's more susceptible to brute forcing, but of course it depends on the actual rate limit and how long you c…

> isTrusted can apparently be spoofed isTrusted cannot be spoofed in this situation, which is its intended use in Chrome. A Chrome extension in the isolated world is receiving events from the main world and checking isTrusted for those events.

Thanks for the clarification. I assume the spoofability applies only to JS in the main world then? And extensions can receive the event before a script has a chance to fiddle with it?

Sorry for the questions, just trying to figure out how this all works, and Googling doesn't give me a clear answer.

Post reply on HN