Great catch and everyone should know there is an easy way to parse URLs in JS. Just create an anchor element and let the browser parse it for you. Like so:
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 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.
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 numeric constant called JSON. :'D
I think the point is that this would run in a document belonging to the LastPass extension -- not that it would run in javascript injected into the target site.
The same attack you describe could be applied to basically any javascript you cared to write (say, String.prototype.length). The safest approach is to treat the output of injected javascript as untrusted third-party input to your extension code and work from there.
At least in Chrome, I'm imagining the raw url would be sent to a background process that is sandboxed from the webpage and would then do the createElement stuff.
But that shouldn't be necessary here, if I understand the problem correctly. The code Lastpass was looking for was simply `document.location.hostname`.
Please correct me if I am mistaken, but couldn't this have been implemented into an iframe that when ran could send the passwords to another remote server?
If so, I am a little taken back by LastPass only offering $1,000 to the researcher that found and reported it for fixing. He or she could have taken a different path and resulted in this being used in some complex targeted attack against tech corporations via short-url redirect interstitial pages, or an ad network's javascript, etc. Given the potential damage, I'd say there is a missing zero or two on that reward amount, in my opinion.
Normally I like bike shedding about bug bounty payouts just about as much as complaints about paywalls. If you are going to go poking around someone's code for fun or profit, the terms of the bounty program are readily available [1] so you can't complain after the fact for earning the maximum payout. LastPass isn't Facebook, and they never claimed they would pay more than $1,000 even for a full compromise or RCE.
On the other hand, using regexp to parse the URL when it's such an obviously security critical code path... just, why?!
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 Facebook for certain classes of bugs(like this one). After all all your passwords are more valuable than your Facebook account.
"On the other hand, using regexp to parse the URL when it's such an obviously security critical code path... just, why?!"
Why not? URIs are at least able to be tokenized perfectly well by a regular expression. You have to do it right, but there's little guarantee that your non-regexp code will do it right either. I glanced at that regexp and immediately recognized several potential problems with it... will I be able to do that with your non-regexp code?
To concretize the "several potential problems": 1. You generally don't want to parse arbitrary protocols, you should do something like (http|https|file) or whatever set of protocols you are ready to receive. Usually you're better off treating anything else as "not a URL", but consult your local security context for details. 2. Failing that, you want at the very least .⁎? to stop matching at the first :, or if your engine doesn't have that, the protocol ought to be matched with something much tighter like [a-z]+. And I do mean + and not ⁎, because you probably don't mean to support an empty protocol before the colon. (You may mean to permit URLs with no protocol, but that's (.⁎?:)? .) 3. Domains should be parsed more tightly than "not a slash". 4. Also, I have no idea what the @ was doing there. Perhaps it was trying to be $; URL parsing should always end with the "end of string" matcher to avoid problems similar to this. It should also start with the start-of-string matcher, which this one doesn't, for similar reasons. 5. Bonus critique, anything using regular expressions to URL-encode or decode is very suspicious; strongly prefer built-in functions that do this.
I literally saw all this faster than I could type it; does your non-regular-expression based code have this property?
Regular expressions aren't bad. They're hard to write properly, but still probably easier to write properly than anything else. It turns out the underlying problem is fundamentally hard.
(Had to use an alternate asterisk to get the RE expressions correct with HN trying to format it.)
I think paying only $1000 for a potentially company-imploding bug like that is incredibly short sighted.
It's far too low to motivate a lot of people to look for bugs, and to me suggests they're not serious about protecting their reputation if someone does find such a company-destroying bug.
The fact that LastPass consider that a flaw in their system that could have put them on their knees is only worth 1K is quite frightening if you are relying on them for your security.
I was surprised by them giving such a tiny amount too. The potential damage to their users here is staggering. If this was used to grab someone's twitter,facebook,email,linkedin an attacker could take full control of their online presence :S
Let's do a little calculation to see if the payout is worthwhile.
Using something illegally means you run the risk of going to prison. Let's say there's a 1% chance you get caught, the prison sentence is 10 years, and the evil hackers will pay you $20,000 for your bug. Let's also say that you're a mid-career software engineer in the US, and over the next 10 years you expect to make $2M (after taxes).
This means your expected outcome over 10 years is $20,000 + (0.99 * $2M) = $1.98M. With Lastpass's bounty you end up with $2.001M.
With these assumptions, you should be paying Lastpass to find bugs in their software! Of course, if you're not in the US, you probably make a more reasonable salary (read: less), taxes are higher, and the risk of getting caught is lower.
Now let's bring that salary estimate back down from outer space. $200,000 per year TAKE HOME, is not realistic, except for the very top percent of developers. And I'm talking the very top.
There is also the reputation boost that the researcher receives for discovering this exploit and disclosing it in a responsible manner. The value of that is incalculable.
>If so, I am a little taken back by LastPass only offering $1,000 to the researcher that found and reported it for fixing.
I am a lot taken back by it. This wasn't a minor bug. I don't care if $1,000 was the published maximum payout under their bug bounty program - for something like this, the payout needs to be representative of the damage that would have been done to their reputation had this bug been discovered and exploited by bad actors. Given that reputation is everything in this space, any well-publicized incident using this would have effectively rendered the company dead within days.
Here's hoping they reconsider the award amount (though I'm certain they won't).
Yes, my thoughts exactly. He could had made 100x that money on the black market, so no wonder we still have problems with 0days traded there.
How long would you work for $1,000? Some days, a week, two? If you spend more than a week on this problem it seems not worth to report it... On the other hand, if you set the incentive for bug bounty too high I imagine all sorts of cranks pop up, that want to show off bugs that are not there, and resources will be bound to this task -- they have to be verified, and analyzed even if its a bogus report (and in the worst case it will not accomplish anything).
> How long would you work for $1,000? Some days, a week, two?
You might not work for long on a $1,000 problem, but other people sure will. College or high school students, people in a country with low salaries such as Ukraine...
He could have basically killed LastPass, the company, if he didn't go white-hat. And caused all sorts of other mayhem that would also have been far more profitable for him.
It does seem like an extremely low bounty for a security bug that severe.
I mean, in a 100% libertarian world, this hole would have been put up for auction to the highest bidder and LastPass would have had to ensure they were the highest bidder in order to close up the hole and basically save their business.
Hi, newbie sec researcher here. Just wanna ask, how do we actually ask for a bounty considering that sometimes the severity of the breach is BIG (this, Shell Access, etc).
I really don't wanna ask the companies for money but it just seem so... underwhelming for me. (3 out of 3 rather big companies just gave some thanks)
No matter what it is, you don't just give someone something they didn't ask for, and then expect money in return.
It would be like someone walking up to you on the street, handing you something they think is valuable, and then hoping that you'll want it and pay them for it.
The first thing you should do is check and see if they have an official bug bounty, if they don't then contact them and ask them if they had one.. say something like "because you saw some things on their site that concerned you, but wanted to know if it was worth the time exploring further" .. this is assuming you already found something. The goal of this is to get them to try and offer a bounty.
If they don't offer a bounty, then if you want to be responsible, you can just disclose their vulnerabilities to them, and accept whatever thanks you get.
If you're explicitly doing what you're doing to try and get some money out of it, then your time would be better spent focusing on companies that have well published bug bounties.
Something to consider is a mis-alignment of incentives.
When LastPass gets breached, they're not directly responsible for what an attacker does with the passwords.
When another site/service gets breached, they have to spend a lot of time making it right to the customer again (e.g. rolling back transactions, compensating for lost or stolen funds, etc.)
I don't think of the bounty as a reward for choosing not to break the law. Staying out of jail is the reward for not breaking the law; the $1000 is just a token of appreciation for someone that could have otherwise not bothered to report the bug.
I've been using LastPass for about 3 years, and now I'm seriously thinking about all the times people told me about how storing passwords in someone else's cloud is bad.
I've been defending LastPass and recommending it to everyone till today. Now I'm thinking about how I might have to 'pay' for a software vulnerability in some private (read:unauditable by me) code. All the comments about offline, local backups make sense to me.
But the points I usually make are still valid, like:
1. I can go to any computer with chrome and get access to all my passwords, so don't have to carry my passwords with me everywhere.
2. Don't have to worry about storing passwords properly since lastpass is a good company and they know their stuff about protecting the customers' data.
3. Password capture. It might seem like a tiny feature, but I'm too lazy to remember opening an app and entering my credentials whenever I create an account or login into an old account.
4. Mobile login, although a paid feature, this really changes my life. If I don't trust a computer enough to login via chrome or something else, or want my secret notes, I just open up my phone.
But all the above features meaning nothing when it comes to the chance of compromising all my passwords (except bank info, of course)
I'd like to hear the thoughts of anyone else who uses lastpass and what they think.
I think you could do a lot worse than lastpass. You could also do better, by sacrificing some usability. On the extreme side, you could use a separate, offline device, just for password storage.
But I don't think it's worth getting excited about a single lastpass bug. Everything is vulnerable. There will be more of them. Chrome itself had 105 security issues, just this year (https://www.cvedetails.com/product/15031/Google-Chrome.html?...) - a few of them potentially leading to your passwords being exposed without any extensions.
Upgrade often, don't do stupid stuff, keep backups, and you'll be more secure than 99% of people. Evaluate your choices from there.
Well, that put it in perspective for me. I just googled the vulnerabilities in offline password managers like Keepass/X and 1Password. And oh man, I was pretty shocked to see even the offline ones could be broken into.
I think I just had a crisis of faith.
>you'll be more secure than 99% of people
Thanks. I guess since I don't store very sensitive info (financial, etc.), and the important services - Google, Github, Atlassian, AWS use 2FA. I guess I don't have to be paranoid.
I do not use LastPass exactly because of what you describe. I use a KeePass Password safe without autofill. I use other software to sync the file. It used to be Dropbox, later I was using BitTorrent Sync, but what tool sync shouldn't really matter. As I see it: the tool only gets to see and sync an encrypted file. You could even use a USB stick and not sync at all. Or only sync on LANs.
I love it how I get to decide who or what gets to see the encrypted file.
Now hopefully the Keepass audit will not reveal any issues in the encryption.
I'd say some of the points could be easily covered by something like KeePass which, unlike cloud, doesn't have to depend on questionable security of third-party services.
For example. I use KeePass to store all my password. I keep my KeePass database in Google Drive, so any change to the file will be updated. because of that I can use KeePass on any machine that has access to Google Drive (I also keep executables for various systems in drive). Furthermore, there are number of free mobile applications for KeePass which can hook into GDrive and you can use KeePass on the phone too. And lastly - browser extensions which let you use your KeePass to automatically fill & save passwords (I don't use it, though).
Sure, KeePass requires a bit more of an effort compared to all-in-one solutions such as LastPass. That is the price you pay for not thinking about possible security breaches in the cloud.
It's not really very much more effort. I use KeeFox (Firefox) and Keepass2Android (you can guess). I love both tools, they've made password management trivial, and I used to be a die-hard "one password for everything is just so much more convenient" fan.
> 1. I can go to any computer with chrome and get access to all my passwords, so don't have to carry my passwords with me everywhere.
Maybe a computer you can trust but I wouldn't say any computer. I consider the shared PC you'd find in a hotel business center to be the digital equivalent of a diseased hooker. I'd be impressed if it didn't have a key logger installed.
> 2. Don't have to worry about storing passwords properly since lastpass is a good company and they know their stuff about protecting the customers' data.
Not being OSS I don't think that can be proven. It boils down to "Trust us, we're smart".
> I'd like to hear the thoughts of anyone else who uses lastpass and what they think.
Trust noone and put your faith in OSS (KeepassX, pass, etc).
> Maybe a computer you can trust but I wouldn't say any computer. I consider the shared PC you'd find in a hotel business center to be the digital equivalent of a diseased hooker. I'd be impressed if it didn't have a key logger installed.
I think you'll be impressed in a lot of cases than. I would be surprised if more than 15% of shared PCs have keyloggers active on them.
Still doesn't mean i'm going to login to anything on them though.
I use Lastpass for work and can't stand it. I use 1Password for personal stuff (and some private work stuff now that I think of it) and highly recommend it. It's got a Chrome browser extension, mobile app, and like someone else mentioned below you can sync the encrypted db to a cloud service (iCloud, Dropbox, etc) so you can access it from all of your devices.
I don't mean to be the advice bird, but maybe you can point all the points you made to your superiors and make them re-evaluate their choice. If they're a huge enterprise, then I understand
> I've been using LastPass for about 3 years, and now I'm seriously thinking about all the times people told me about how storing passwords in someone else's cloud is bad.
This bug doesn't seem to have anything to do with the cloud.
FTA:
> The bug that allowed me to extract passwords was found in the autofill functionality.
I have never understood the password manager market honestly. To me it's very obvious that the CONCEPT of a "single point of failure" is a terrible idea. Putting faith in one or the other is just like humans backing politicians, they think they are backing something when really they just got manipulated into an opinion which they slowly defend more and more.
Don't use a password manager, remember your passwords, or reset them all the time. It's a conceptual vulnerability, and if you read hacker news you are better than this.
Are you saying that you remember a unique and sufficiently random password for every website/app/etc you use? If so, you've got a far better memory that me.
The post does point out that this would not work if multifactor authentication is on. I would never dream of using my LastPass account without that anyway.
Like with all decisions this is balancing risk/reward. The reward are all the points you have already expressed that I also love about LastPass. Currently I believe the risk is fairly minimal assuming you use 2 factor-authentication. Though I might turn off autofill now as an extra precaution.
(to save a click: Tavis Ormandy: "Are people really using this lastpass thing? I took a quick look and can see a bunch of obvious critical problems. I'll send a report asap.")
I'm generally very sympathetic to regex bugs (especially in a language like JavaScript where you don't get nice expanded multiline regexes with comments), but I am wondering why they went with a regex in the first place. Did they decide `document.location.host` was too brittle for some reason?
Not using `document.location.host` stood out to me too. I think the takeaway here is don't use regex unless you absolutely have to and don't use it to parse things that have rigorous standards describing them. Emails, phone numbers, URLs come to mind.
I'm not sympathetic to regex bugs where they're being used to parse untrusted user input which is then later used to do something important (like, say, pick which URL to submit credentials to). They're way too easy to cock up for anything security-related.
You could have just linked to http://verbalexpressions.github.io instead of spamming all the repositories. Also, about half of them are out of date by 3 or more years.
I don't see how this would have prevented this problem. The issue was not that regular expressions were "too hard" for the lastpass team, but that URLs are hard to parse correctly. To put it another way, if you don't know how to parse a URL correctly, you'll probably write an incorrect parser no matter what parsing tool you use. That's why you generally shouldn't write parsers for URLs.
$1000 for the bug bounty? This is incredibly stupid! How can you make a living off that? You could make hundreds of thousands of US$ from exploiting this. You could sell it on the black market. I am surprised that most of the corporations, even respectable ones, are awarding peanuts for something that is so important to their business process. This makes my blood boil. I operate a small business website and I awarded $3k just because someone found a way to brute force passwords without getting rate limited. This is quite simply unacceptable.
> You could make hundreds of thousands of US$ from exploiting this
Oh no, not this type of comment again. Infosec people always make fun of HN for this exact type of comment. The total lack of understanding of the economics of bug hunting doesn't stop people from commenting here.
Noone is paying $100k in some imaginary black market for web exploits. I mean have you even considered who buys exploits and what type of attacks they conduct? There isn't an active market looking to noisily grab passwords from a low-grade consumer password manager that no enterprise or governments uses. Your XSS/SQLi are only worth a marginal amount of money to the corporation you're pen testing.
And supply/demand is always what drives prices, not the potential damage (or benefit) you can imagine a particular exploit doing. This is as true for vulnerabilities as it is for some business software or mobile app your create. Just because in a perfect situation it could generate x value for a customer doesn't mean there is either demand or an untapped market for it.
A browser-based iPhone zero-day on the other hand can fetch some money. But even then your grey market for this is tiny and most likely not going to be some criminal overlord paying out $100k in bitcoin to kids on a darknet forum.
Ok, you are right, it was naive for me to pull out this "black market" number from the ass, especially because I should know better, coming from Russia where there are many of these forums.
However, I still stand behind that this corporation should have paid $100,000. There are so many opportunities to exploit this vulnerability. LastPass is seen as something "advanced" users use, so it's highly probable that you could PM link to this page to some computer celebrity, and you would have access to his inbox in no-time, because most people don't use annoying second-factor authorization. This could result in a huge amount of new leaks, etc, etc. $1000 basically screams - "fuck you, we don't care about our security, and we are not going to encourage future white hat future bug reporting".
>Noone is paying $100k in some imaginary black market for web exploits.
You're right, it's usually in low-mid $10ks for this sort of thing.
>low-grade consumer password manager that no enterprise or governments uses
Can't speak to government, but multiple large companies I have worked for have mandated LastPass as the password manager.
> But even then your grey market for this is tiny and most likely not going to be some criminal overlord paying out $100k in bitcoin to kids on a darknet forum.
In fact that's almost exactly what it is, except you've underestimated the price. A really juicy iOS RCE or Privesc can fetch almost half a million.
These transactions aren't usually done on forums, though. Not enough trust. There are middlemen who buy exploits from researchers and sell to the big customers.
Someone always makes a comment like this. Honestly, the black market value (if any) has nothing to do with the whitehat bounty amount. Why should it? The person who's going to do legitimate whitehat work isn't the same person who's going to sell on the black market.
I think of it like drugs. $50k street value of cocaine is not going to do me a lot of good because 1) I'd have no idea where to sell it, 2) if I did know where, I wouldn't have the relationships built and would probably get ripped off/killed/what-have-you, and 3) selling drugs isn't something I'd like to do. So, if there were an option of turning in the drugs to the police for $500, I would take that instead.
I think the point is 1) it encourages more people to go the black hat way and 2) $1000 just isn't worth all the time people spend not finding bugs before finding one. So no one is encouraged to look in the first place except maybe the few who find it fun to do in their free time.
Side-note: isn't there a grey market that buys exploits (for sums of ~$100k depending on the exploit) and sells them to government agencies or larger corporations? I think I remember one company charged $500k / year to companies and government agencies who wanted access to their "exploit database". Seems like this is the best route to go with these kinds of exploits since it is completely legal.
But if the police want to incentivize you to find cocaine, how hard are you going to look for only $500?
In the sense that "Oh yeah, I just casually stumbled on an enormous exploit of security software" the bounty is a good deal. In the sense that "Should I look for holes in this thing? Is it worth my time?" it's absolutely not unless the person is interested in it academically or for reputation.
Finding $50K worth of drugs is one thing, converting that to cash would involve a lot of effort on your part.
This is more akin to finding the accounting records of a drug kingpin that could be used as evidence to bring them down. This could have destroyed Lastpass.
I tend to agree. LastPass is literally in the business of securing passwords, and was giving them away.
I think the bounty should be: 10000 < bounty <= 100,000
This bug would have been exploited, sooner or later, and would have had massively disastrous results. Those results are now avoided, and that's worth a lot more than 1k.
It's confusing that the LastPass site is claiming only Firefox is impacted. [1] Whereas the security researcher's site (detectify.com) shows the vulnerability running in Chrome. [2]
Furthermore, the current live version on Firefox addons repository is 3.x [3], which the LastPass team claims is not vulnerable. [1]
The Firefox reference is in the second vulnerability discussed in your link 1, and is unrelated to your link 2 and parent submission. That second vulnerability apparently only affected the version 4 line of the Firefox plugin, which is marked beta in the Mozilla repository.
The end of this article mentions that "Also, this would not work if multi factor authentication was on, so you should probably enable that as well."
Does anyone know why that is the case? It seems like this exploit is just taking advantage of the js that autofills forms on the page based on domain. You can still use autofill if you have multifactor enabled.
Likely in the sense that the attacker cannot login into your account using the stolen credentials, as the second factor would not be in their possession.
The article links to lastpass multifactor [0] though. I agree that having multifactor enabled on the site the credentials were stolen for would block this attack.
I assume it's because LastPass sends you the multi factor auth request before accessing your passwords (and therefore before allowing the autofill js stuff to use your password).
I don't actually use LastPass so I'm not 100% sure, but this would be the most likely case imo
They only send the multi factor auth request when you first login to your account in the browser (and then every 30 days). Once you are logged in, autofilling works exactly the same.
> I assume it's because LastPass sends you the multi factor auth request before accessing your passwords
This would seem like a logical assumption, but I have found that it works differently (at least on the firefox plugin). If I have auto-fill enabled, the password for a site I am looking at is filled in before the MFA prompt pops up. I can even ignore the MFA pop-up and click login and get into the website.
Readit News
var parser = document.createElement('a');
parser.href = "http://example.com:3000/pathname/?search=test#hash";
parser.protocol; // => "http:"
parser.hostname; // => "example.com"
parser.port; // => "3000"
parser.pathname; // => "/pathname/"
parser.search; // => "?search=test"
parser.hash; // => "#hash"
parser.host; // => "example.com:3000"
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.)
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
If the website could override extension functions, attacks would already be possible by overriding Regex functions.
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 numeric constant called JSON. :'D
The same attack you describe could be applied to basically any javascript you cared to write (say, String.prototype.length). The safest approach is to treat the output of injected javascript as untrusted third-party input to your extension code and work from there.
Deleted Comment
If so, I am a little taken back by LastPass only offering $1,000 to the researcher that found and reported it for fixing. He or she could have taken a different path and resulted in this being used in some complex targeted attack against tech corporations via short-url redirect interstitial pages, or an ad network's javascript, etc. Given the potential damage, I'd say there is a missing zero or two on that reward amount, in my opinion.
On the other hand, using regexp to parse the URL when it's such an obviously security critical code path... just, why?!
[1] - https://bugcrowd.com/lastpass
Why not? URIs are at least able to be tokenized perfectly well by a regular expression. You have to do it right, but there's little guarantee that your non-regexp code will do it right either. I glanced at that regexp and immediately recognized several potential problems with it... will I be able to do that with your non-regexp code?
To concretize the "several potential problems": 1. You generally don't want to parse arbitrary protocols, you should do something like (http|https|file) or whatever set of protocols you are ready to receive. Usually you're better off treating anything else as "not a URL", but consult your local security context for details. 2. Failing that, you want at the very least .⁎? to stop matching at the first :, or if your engine doesn't have that, the protocol ought to be matched with something much tighter like [a-z]+. And I do mean + and not ⁎, because you probably don't mean to support an empty protocol before the colon. (You may mean to permit URLs with no protocol, but that's (.⁎?:)? .) 3. Domains should be parsed more tightly than "not a slash". 4. Also, I have no idea what the @ was doing there. Perhaps it was trying to be $; URL parsing should always end with the "end of string" matcher to avoid problems similar to this. It should also start with the start-of-string matcher, which this one doesn't, for similar reasons. 5. Bonus critique, anything using regular expressions to URL-encode or decode is very suspicious; strongly prefer built-in functions that do this.
I literally saw all this faster than I could type it; does your non-regular-expression based code have this property?
Regular expressions aren't bad. They're hard to write properly, but still probably easier to write properly than anything else. It turns out the underlying problem is fundamentally hard.
(Had to use an alternate asterisk to get the RE expressions correct with HN trying to format it.)
Why not? Sure, you can't accuse them of being dishonest, but why would simply announcing an action make it beyond reproach?
It's far too low to motivate a lot of people to look for bugs, and to me suggests they're not serious about protecting their reputation if someone does find such a company-destroying bug.
Have you got a mechanism you could post here for them to do so?
Using something illegally means you run the risk of going to prison. Let's say there's a 1% chance you get caught, the prison sentence is 10 years, and the evil hackers will pay you $20,000 for your bug. Let's also say that you're a mid-career software engineer in the US, and over the next 10 years you expect to make $2M (after taxes).
This means your expected outcome over 10 years is $20,000 + (0.99 * $2M) = $1.98M. With Lastpass's bounty you end up with $2.001M.
With these assumptions, you should be paying Lastpass to find bugs in their software! Of course, if you're not in the US, you probably make a more reasonable salary (read: less), taxes are higher, and the risk of getting caught is lower.
That would be $300K per year pre-tax (assuming current 2016 tax rate of 33% for the 200-400K bracket). Is that really a normal mid-career salary?
I need to change jobs if that's the case...
https://en.wikipedia.org/wiki/List_of_computer_criminals paints a picture that prison time is mostly a US-only thing.
Some people want to watch the burn. An attacker could make it known anonymously and LastPass will never recover from that onslaught.
I am a lot taken back by it. This wasn't a minor bug. I don't care if $1,000 was the published maximum payout under their bug bounty program - for something like this, the payout needs to be representative of the damage that would have been done to their reputation had this bug been discovered and exploited by bad actors. Given that reputation is everything in this space, any well-publicized incident using this would have effectively rendered the company dead within days.
Here's hoping they reconsider the award amount (though I'm certain they won't).
How long would you work for $1,000? Some days, a week, two? If you spend more than a week on this problem it seems not worth to report it... On the other hand, if you set the incentive for bug bounty too high I imagine all sorts of cranks pop up, that want to show off bugs that are not there, and resources will be bound to this task -- they have to be verified, and analyzed even if its a bogus report (and in the worst case it will not accomplish anything).
Where is the middle ground?
Deleted Comment
You might not work for long on a $1,000 problem, but other people sure will. College or high school students, people in a country with low salaries such as Ukraine...
It does seem like an extremely low bounty for a security bug that severe.
I mean, in a 100% libertarian world, this hole would have been put up for auction to the highest bidder and LastPass would have had to ensure they were the highest bidder in order to close up the hole and basically save their business.
https://bugcrowd.com/lastpass
I really don't wanna ask the companies for money but it just seem so... underwhelming for me. (3 out of 3 rather big companies just gave some thanks)
It would be like someone walking up to you on the street, handing you something they think is valuable, and then hoping that you'll want it and pay them for it.
The first thing you should do is check and see if they have an official bug bounty, if they don't then contact them and ask them if they had one.. say something like "because you saw some things on their site that concerned you, but wanted to know if it was worth the time exploring further" .. this is assuming you already found something. The goal of this is to get them to try and offer a bounty.
If they don't offer a bounty, then if you want to be responsible, you can just disclose their vulnerabilities to them, and accept whatever thanks you get.
If you're explicitly doing what you're doing to try and get some money out of it, then your time would be better spent focusing on companies that have well published bug bounties.
When LastPass gets breached, they're not directly responsible for what an attacker does with the passwords.
When another site/service gets breached, they have to spend a lot of time making it right to the customer again (e.g. rolling back transactions, compensating for lost or stolen funds, etc.)
I think it works the other way around.
Dead Comment
I've been defending LastPass and recommending it to everyone till today. Now I'm thinking about how I might have to 'pay' for a software vulnerability in some private (read:unauditable by me) code. All the comments about offline, local backups make sense to me.
But the points I usually make are still valid, like:
1. I can go to any computer with chrome and get access to all my passwords, so don't have to carry my passwords with me everywhere.
2. Don't have to worry about storing passwords properly since lastpass is a good company and they know their stuff about protecting the customers' data.
3. Password capture. It might seem like a tiny feature, but I'm too lazy to remember opening an app and entering my credentials whenever I create an account or login into an old account.
4. Mobile login, although a paid feature, this really changes my life. If I don't trust a computer enough to login via chrome or something else, or want my secret notes, I just open up my phone.
But all the above features meaning nothing when it comes to the chance of compromising all my passwords (except bank info, of course)
I'd like to hear the thoughts of anyone else who uses lastpass and what they think.
But I don't think it's worth getting excited about a single lastpass bug. Everything is vulnerable. There will be more of them. Chrome itself had 105 security issues, just this year (https://www.cvedetails.com/product/15031/Google-Chrome.html?...) - a few of them potentially leading to your passwords being exposed without any extensions.
Upgrade often, don't do stupid stuff, keep backups, and you'll be more secure than 99% of people. Evaluate your choices from there.
Well, that put it in perspective for me. I just googled the vulnerabilities in offline password managers like Keepass/X and 1Password. And oh man, I was pretty shocked to see even the offline ones could be broken into.
I think I just had a crisis of faith.
>you'll be more secure than 99% of people
Thanks. I guess since I don't store very sensitive info (financial, etc.), and the important services - Google, Github, Atlassian, AWS use 2FA. I guess I don't have to be paranoid.
I love it how I get to decide who or what gets to see the encrypted file.
Now hopefully the Keepass audit will not reveal any issues in the encryption.
For example. I use KeePass to store all my password. I keep my KeePass database in Google Drive, so any change to the file will be updated. because of that I can use KeePass on any machine that has access to Google Drive (I also keep executables for various systems in drive). Furthermore, there are number of free mobile applications for KeePass which can hook into GDrive and you can use KeePass on the phone too. And lastly - browser extensions which let you use your KeePass to automatically fill & save passwords (I don't use it, though).
Sure, KeePass requires a bit more of an effort compared to all-in-one solutions such as LastPass. That is the price you pay for not thinking about possible security breaches in the cloud.
Maybe a computer you can trust but I wouldn't say any computer. I consider the shared PC you'd find in a hotel business center to be the digital equivalent of a diseased hooker. I'd be impressed if it didn't have a key logger installed.
> 2. Don't have to worry about storing passwords properly since lastpass is a good company and they know their stuff about protecting the customers' data.
Not being OSS I don't think that can be proven. It boils down to "Trust us, we're smart".
> I'd like to hear the thoughts of anyone else who uses lastpass and what they think.
Trust noone and put your faith in OSS (KeepassX, pass, etc).
I think you'll be impressed in a lot of cases than. I would be surprised if more than 15% of shared PCs have keyloggers active on them.
Still doesn't mean i'm going to login to anything on them though.
I don't mean to be the advice bird, but maybe you can point all the points you made to your superiors and make them re-evaluate their choice. If they're a huge enterprise, then I understand
This bug doesn't seem to have anything to do with the cloud.
FTA:
> The bug that allowed me to extract passwords was found in the autofill functionality.
Don't use a password manager, remember your passwords, or reset them all the time. It's a conceptual vulnerability, and if you read hacker news you are better than this.
Like with all decisions this is balancing risk/reward. The reward are all the points you have already expressed that I also love about LastPass. Currently I believe the risk is fairly minimal assuming you use 2 factor-authentication. Though I might turn off autofill now as an extra precaution.
This was a client-side bug and so surely doesn't depend on the fact that your passwords are 'stored in someone else's cloud'?
i.e. If there was only local storage of passwords this vulnerability would still be there.
(Also worth noting that lastpass encrypts your remote and local store with a key which is presumably only stored hashed and salted on their side)
The idea is good, just not sure about SHA-256...
(to save a click: Tavis Ormandy: "Are people really using this lastpass thing? I took a quick look and can see a bunch of obvious critical problems. I'll send a report asap.")
> @taviso Are you looking at their binary? (I'm a former lastpass engineer)
> @ejcx_ Yes.
> @taviso Ahhh. I never touched it. Very neglected. There's a lot of stuff between message passing between extension and binary that is scary
https://twitter.com/ejcx_/status/758080992724738048
Where a regex must be used, there is a reference regex for parsing URL: https://tools.ietf.org/html/rfc3986#appendix-B
Edit: a permalink to demonstrate the above reference regex: https://regex101.com/r/yJ5nU4/1 -- would have prevented the LastPass bug.
Verbal Expressions - It's an extremely good higher level interface to the underlying regular expressions tools, in MANY languages.
Including:
JavaScript - https://github.com/VerbalExpressions/JSVerbalExpressions
ActionScript 3 - https://github.com/VerbalExpressions/AS3VerbalExpressions
Clojure - https://github.com/VerbalExpressions/ClojureVerbalExpression...
C++ - https://github.com/VerbalExpressions/CppVerbalExpressions
C# - https://github.com/VerbalExpressions/CSharpVerbalExpressions
Dart - https://github.com/VerbalExpressions/DartVerbalExpressions
Elixir - https://github.com/VerbalExpressions/ElixirVerbalExpressions
Elm - https://github.com/VerbalExpressions/elm-verbal-expressions
Erlang - https://github.com/VerbalExpressions/ErlangVerbalExpressions
FreeBasic - https://github.com/VerbalExpressions/FreeBasicVerbalExpressi...
F# - https://github.com/VerbalExpressions/FSharpVerbalExpressions
Go - https://github.com/VerbalExpressions/GoVerbalExpressions
Groovy - https://github.com/VerbalExpressions/GroovyVerbalExpressions
Haskell - https://github.com/VerbalExpressions/HaskellVerbalExpression...
Haxe - https://github.com/VerbalExpressions/HaxeVerbalExpressions
Java - https://github.com/VerbalExpressions/JavaVerbalExpressions
Lua - https://github.com/VerbalExpressions/LuaVerbalExpressions
Objective C - https://github.com/VerbalExpressions/ObjectiveCVerbalExpress...
Perl - https://github.com/VerbalExpressions/PerlVerbalExpressions
PHP - https://github.com/VerbalExpressions/PHPVerbalExpressions
PowerShell - https://github.com/VerbalExpressions/PowerShellVerbalExpress...
PureScript - https://github.com/VerbalExpressions/purescript-verbal-expre...
Python - https://github.com/VerbalExpressions/PythonVerbalExpressions
Racket - https://github.com/VerbalExpressions/RacketVerbalExpressions
Ruby - https://github.com/VerbalExpressions/RubyVerbalExpressions
Rust - https://github.com/VerbalExpressions/RustVerbalExpressions
Scala - https://github.com/VerbalExpressions/ScalaVerbalExpressions
Swift - https://github.com/VerbalExpressions/SwiftVerbalExpressions
Vala - https://github.com/VerbalExpressions/ValaVerbalExpressions
And probably more, but that's just the "official" implementations.
I think the company should have paid $100,000.
Oh no, not this type of comment again. Infosec people always make fun of HN for this exact type of comment. The total lack of understanding of the economics of bug hunting doesn't stop people from commenting here.
Noone is paying $100k in some imaginary black market for web exploits. I mean have you even considered who buys exploits and what type of attacks they conduct? There isn't an active market looking to noisily grab passwords from a low-grade consumer password manager that no enterprise or governments uses. Your XSS/SQLi are only worth a marginal amount of money to the corporation you're pen testing.
And supply/demand is always what drives prices, not the potential damage (or benefit) you can imagine a particular exploit doing. This is as true for vulnerabilities as it is for some business software or mobile app your create. Just because in a perfect situation it could generate x value for a customer doesn't mean there is either demand or an untapped market for it.
A browser-based iPhone zero-day on the other hand can fetch some money. But even then your grey market for this is tiny and most likely not going to be some criminal overlord paying out $100k in bitcoin to kids on a darknet forum.
However, I still stand behind that this corporation should have paid $100,000. There are so many opportunities to exploit this vulnerability. LastPass is seen as something "advanced" users use, so it's highly probable that you could PM link to this page to some computer celebrity, and you would have access to his inbox in no-time, because most people don't use annoying second-factor authorization. This could result in a huge amount of new leaks, etc, etc. $1000 basically screams - "fuck you, we don't care about our security, and we are not going to encourage future white hat future bug reporting".
You're right, it's usually in low-mid $10ks for this sort of thing.
>low-grade consumer password manager that no enterprise or governments uses
Can't speak to government, but multiple large companies I have worked for have mandated LastPass as the password manager.
> But even then your grey market for this is tiny and most likely not going to be some criminal overlord paying out $100k in bitcoin to kids on a darknet forum.
In fact that's almost exactly what it is, except you've underestimated the price. A really juicy iOS RCE or Privesc can fetch almost half a million.
These transactions aren't usually done on forums, though. Not enough trust. There are middlemen who buy exploits from researchers and sell to the big customers.
I think of it like drugs. $50k street value of cocaine is not going to do me a lot of good because 1) I'd have no idea where to sell it, 2) if I did know where, I wouldn't have the relationships built and would probably get ripped off/killed/what-have-you, and 3) selling drugs isn't something I'd like to do. So, if there were an option of turning in the drugs to the police for $500, I would take that instead.
Side-note: isn't there a grey market that buys exploits (for sums of ~$100k depending on the exploit) and sells them to government agencies or larger corporations? I think I remember one company charged $500k / year to companies and government agencies who wanted access to their "exploit database". Seems like this is the best route to go with these kinds of exploits since it is completely legal.
In the sense that "Oh yeah, I just casually stumbled on an enormous exploit of security software" the bounty is a good deal. In the sense that "Should I look for holes in this thing? Is it worth my time?" it's absolutely not unless the person is interested in it academically or for reputation.
Fixing this bug before an exploit is worth a LOT to the company. I think they have a moral obligation to pay more than 1k to fix it.
I also think it makes sense to award good-sized bounties, as at this point I would have no interest in their bounty program, were I hunting bounties.
This is more akin to finding the accounting records of a drug kingpin that could be used as evidence to bring them down. This could have destroyed Lastpass.
I think the bounty should be: 10000 < bounty <= 100,000
This bug would have been exploited, sooner or later, and would have had massively disastrous results. Those results are now avoided, and that's worth a lot more than 1k.
And all you have to do is risk your freedom.
Furthermore, the current live version on Firefox addons repository is 3.x [3], which the LastPass team claims is not vulnerable. [1]
[1] https://blog.lastpass.com/2016/07/lastpass-security-updates.... [2] https://labs.detectify.com/2016/07/27/how-i-made-lastpass-gi... [3] https://addons.mozilla.org/en-US/firefox/addon/lastpass-pass...
Does anyone know why that is the case? It seems like this exploit is just taking advantage of the js that autofills forms on the page based on domain. You can still use autofill if you have multifactor enabled.
[0] https://helpdesk.lastpass.com/multifactor-authentication-opt...
I don't actually use LastPass so I'm not 100% sure, but this would be the most likely case imo
This would seem like a logical assumption, but I have found that it works differently (at least on the firefox plugin). If I have auto-fill enabled, the password for a site I am looking at is filled in before the MFA prompt pops up. I can even ignore the MFA pop-up and click login and get into the website.