Live data from Hacker News

LastPass autofill exploit

labs.detectify.com

241–250 of 443 posts

Re: LastPass autofill exploit

#241
post #124

Earlier quoted context omitted.

While that might be an "easy way" - it isn't a secure way in this case. Since malicious attackers have complete control over the page you're seeing - they can simply replace document.createElement with their own function. And instead of returning a DOM object, they can return an object that returns whatever they want in .hostname

No, that is not possible. Extensions in Chrome run in a different execution context than the website. The website's document.creatElement is different from the extension's. If the website could override extension functions, attacks would already be possible by overriding Regex functions.

Good point, but that's assuming you're running in the context of the popup and not in the context of a content script. In the popup's script, you are using a new DOM. But in a content script - you're using the same DOM as the client, which can override createElement (and any other function as well).

Re: LastPass autofill exploit

#242

Earlier quoted context omitted.

Disclosure: I work for AgileBits, makers of 1Password. For browser extensions, the URL constructor would be even easier: https://developer.mozilla.org/en-US/docs/Web/API/URL/URL (Yes, I know it says that IE doesn't support it, but IE doesn't have a proper extensions framework, so it's irrelevant to this topic.)

While you are here, can you confirm whether a similar regex vulnerability does not affect 1Password?

Why not take a look at the code injected by 1Password's browser extension and find out for yourself whether it handles URLs safely? That shouldn't be hard to do, and it's a lot healthier for the community than discouraging devs to participate by taking their presence as an opportunity for drive-by pot shots.

Re: LastPass autofill exploit

#243
Only one person mentioned it, so I'll pitch in - Dashlane [1] is a great password manager, and it's communication with their customers is top notch (customer service and security wise [1]). Speaking as a humble premium user which thinks they don't get enough credit.

[1] https://www.dashlane.com/download/Dashlane-Security-Whitepap...

Re: LastPass autofill exploit

#244

Earlier quoted context omitted.

While you are here, can you confirm whether a similar regex vulnerability does not affect 1Password?

What you are really "asking" is logically equivalent to this blaming statement: "I see you are posting about LastPass' vulnerability, but you work for 1Password. Please confirm there exists a regex vulnerability in 1Password which is similar in nature to the one that occurred with LastPass." Put this way, the insanity of the statement is obvious. In questions, it becomes less obvious to the majority of the population…

Here's some context: I am a former LastPass user for many years and current (concerned) 1Password user wondering if I should be changing all of my passwords again.

My goal was to settle concern for myself and other 1Password users. That's why I wrote whether a similar vulnerability "does not affect 1Password" instead of "does". My apologies if this was unclear.

Re: LastPass autofill exploit

#245

I am using PasswordSafe ( pwsafe.org ) and Dropbox to sync to the cloud. I do not use autofill, nor I asked my browser to manage my passwords. There are a mix of opensource and commercial implementation covering all platforms (iOS, Android and what not). PasswordSafe has also been audited. Why isn't PasswordSafe more popular ? What do other password managers have that Password Safe does not ?

I do pretty much the same thing (but I keep pwsafe in version control). Great tool.

Re: LastPass autofill exploit

#246

He deserved a whole lot more than $1000 for discovering and reporting such a huge, idiotic security hole that should have never happened in the first place, and it should come out of the salary of whoever caused it by indulging their own laziness and convenience by abusing regular expressions so carelessly and casually.

> and it should come out of the salary of whoever caused it by indulging their own laziness and convenience by abusing regular expressions so carelessly and casually.

No. People make mistakes. Honest, unintentional, well-meaning mistakes. Don't punish individuals for being human. Help them learn from them.

Don't make individuals afraid to do their job.

Should the _organization_ be punished? Should they pay more than $1000? That's well worth discussing.

Re: LastPass autofill exploit

#247

Earlier quoted context omitted.

While you are here, can you confirm whether a similar regex vulnerability does not affect 1Password?

Why not take a look at the code injected by 1Password's browser extension and find out for yourself whether it handles URLs safely? That shouldn't be hard to do, and it's a lot healthier for the community than discouraging devs to participate by taking their presence as an opportunity for drive-by pot shots.

I'm sorry, but I don't see how asking an employee of the company that makes the product that I use every day is "discouraging devs to participate by taking their presence as an opportunity for drive-by pot shots".

I think an official word holds more clout and is more valuable than any one person confirming for themselves in one version of one browser on one version of one OS.

Re: LastPass autofill exploit

#249
post #72

Earlier quoted context omitted.

The concern with the low payout is that it's supposed to be a way to compensate white hat hackers and dissuaded them from going to the black market with security problems like this. Given the business that LastPass is in wouldn't you agree that it's extremely crucial they make sure white hat hackers are aptly compensated for serious problems they find? In fact I'd think it'd be reasonable for them to pay more than Fa…

No, that is not at all what a bug bounty is meant to do. We are not expected to pay people to avoid them launching criminal conspiracies against us. The purpose of a bug bounty is to incentivize researchers to target specific pieces of software so that vendors can benefit from that attention.

Let's assume that there is a spectrum of honesty (say, from 1-10) and the pool of people capable of discovering vulnerabilities in your product includes people from the entire range.

If you're a 10 you will disclose responsibly regardless of a bounty, and if you're a 1 you will disclose to the highest bidder. The rest will weight profit, ethics, and risk in some ratio depending on where they fall on the scale and decide to act based on that calculation.

The company has to price their bounty on a few factors: how much they can afford to pay, how much a bug is worth to them (eg damage to their reputation, fines in the event of a vulnerability), and how important it is and to have researchers looking at their product instead of another product.

I agree with you that companies should not be required to pay people to prevent them from launching criminal conspiracies. But this is not a perfect world and people are not so black and white in their actions and motivations. There is no point trying to optimize your bounty program for the 1's or the 10's. Therefore, when optimizing for the rest it makes sense to pay as much as possible within the constraints I mentioned (in the previous paragraph) in order to tip the scales in your favor for the largest part of the spectrum possible. Right now the tech community knows about this problem with LastPass. If this exploit had made it to the wild things would've been much worse for them from a PR perspective.

I am hoping that the $1000 cap on the bounty program came from careful consideration of these factors, but my gut tells me it was a number handed down from management.

Re: LastPass autofill exploit

#250
post #124

Earlier quoted context omitted.

While that might be an "easy way" - it isn't a secure way in this case. Since malicious attackers have complete control over the page you're seeing - they can simply replace document.createElement with their own function. And instead of returning a DOM object, they can return an object that returns whatever they want in .hostname

Disclosure: I work for AgileBits, makers of 1Password. For desktop browser extensions that are properly using the frameworks, the extension's Javascript runs in its own execution context so the page cannot redefine variables. This protected 1Password when we discovered that a certain page had redefined the global JSON object, which provides parse and stringify functions among other things, to be the number 3, i.e. a…

Out of curiosity, does this apply only to Chrome's extension framework, or to Firefox's and Safari's as well?

Context: I'm a new 1Password user who is contemplating use of the extensions for those latter two browsers, and while it seems probable their extension frameworks offer the level of security you describe, I'd like to be certain before pulling the trigger. Thanks!

Post reply on HN