LastPass autofill exploit
labs.detectify.com
labs.detectify.com
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.)
See this pastebin[1] for the function I believe is determining the url of the active tab and if it has a valid hostname.
There's also this one[2] that seems to be extracting the hostname of a given url also using the URL API.
Both these pastebins contain minimized code that I've cleaned up.
0: https://developer.mozilla.org/en-US/docs/Web/API/URL
LastPass (on Chrome) will auto-fill information on a detected site, which a malicious site can read immediately.
1Password (on Chromium nightly) requires me to hit the 1Password Mini button and select a site/account to log in with. If 1Password had a similar vulnerability, a malicious site as described would merely wind up showing me accounts for the wrong site in the dropdown. Clicking one could wind up submitting/leaking my credentials to the attacker, though.
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.
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.
The untrusted script can override its own view of createElement, but not the extension's view.
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
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!
Hi there!
Yes, all 3 of the major browsers (and derivatives of them) offer the same support for a sandboxed execution environment. You can safely use any of them if that's a requirement you have :)
Kyle
AgileBits
We really try not to call it "Classic" or anything like that. It's standalone, you're in charge of upgrades, syncing and backups and stuff like that. It's also not designed for sharing (at least to the degree of the Family and Team solutions).
That said, we don't have any immediate plans to remove the standalone products. However, if a vast majority of our users switch to 1Password Family or 1Password Teams (and as of today, an Individual plan!) then it doesn't make a ton of sense to keep the standalone product around. So, it's probably one of those speak with your wallet kind of scenarios.
I'll certainly pass your feedback along, it sounds like you'd like to keep it around.
I hope that helps answer your question :)
Kyle
AgileBits
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.
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?!
The purpose of a bug bounty is to incentivize researchers to target specific pieces of software so that vendors can benefit from that attention.
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.
Your rationale would be a valid rebuttal in your world no matter what the amounts in question were. $500? Incentive! $50? Incentive!
As we can see from avlidienbrunn2's response [1] sometimes it's not about the money. It's just fulfilling a natural curiosity about a product, maybe getting your killer write-up of a shocking bug to hit the top of the HN frontpage, etc. So in this case perhaps the bounty program is as much about establishing a legal structure for a whitehat to operate under than to fairly compensate ad hoc pen-testers. I wish they paid 10x or more for this bug. But I'm glad at least pen-testers can report these bugs without [as much] fear of reprisal.
Personally I lost a lot of confidence in them when they got acquired and switched to 1Password, paying very low bounties for critical security flaws further hurts my confidence in them.
So the end effect is more bugs found by "white hats" rather than "black hats" because the bounty has focused the "white hat" efforts on your program. (Or encouraged them to look at all.)
I'm likely to poke around a site with a bug bounty even with small sums just because it hints at a more formal process and also likely means they have a sensible policy about not going after testers.
Bug bounties are as much about signalling than encouraging "black hats" to suddenly turn to the light side.
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.)
https://mathiasbynens.be/demo/url-regex
https://lostechies.com/chadmyers/2010/11/20/parsing-a-url-wi...
https://stackoverflow.com/questions/27745/getting-parts-of-a...
What do all these have in common? They all demonstrate that it is hard to write a regex that parses URLs.
Regex's hide programming mistakes because they not only become harder for humans to parse as they get more complicated, but also there isn't simple programming code to handle potential security vulnerabilities in-line with the code. It also hides the [at least] two considerations of secure programming: designing a secure function, and handling the function securely.
You can't look at regexs in isolation, see that a task is hard, then declare them unfit. You have to consider them as one of the many choices and analyze the cost/benefits of the whole suite of options.
I guarantee you that anyone who has said "Oh, gosh, this is hard, I'll just start using indexOf and substring operations" has written code that is just as broken, only in ways much harder to tell.
Which is probably why everyone here thinks it's better to not use regex. You didn't write better code... you wrote code that hid its brokenness better. That's not a good thing!
Again, my real point here is not "regexes are awesome in every way"... my point is that I literally glanced at that code and saw several ways in which it was wrong. Does your alternative have that property?
Also, some of the difficulties of regexes are accidental, not essential. Take something like the recent Perl 6 efforts for parsing and you're far better off in every way using that stuff than trying to bash together string-manipulation-based parsing, or whatever other alternatives you may be thinking of. The Perl 6 constructs will be more readable and more maintainable. (Perl 6 is crazy in a lot of ways but the parsing support is best-of-breed.)
A while back I whipped this up: https://gist.github.com/pmarreck/2956396
which seemed to work well (although it was a bit slower, I probably didn't know about exponential backtracking at the time and that could probably be revisited). It won't gather multiple name/value pairs though, but it will cut out and name basically every other part of the URL.
"Why not? URIs are at least able to be tokenized perfectly well by a regular expression."
"5. Bonus critique, anything using regular expressions to URL-encode or decode is very suspicious; strongly prefer built-in functions that do this."
And the problem is probably more accurately stated as "be suspicious of any function implementing encoding or decoding" rather than focusing on the regex part. Use the correct standard function. Don't bash something together yourself. They're actually pretty easy functions to write if you know what you're doing, but it's even easier to use some tested already-existing function. In fact, it's so easy that the fact that you see someone bashing together a URL encoding or decoding function almost certainly proves that they don't know what they are doing, which in turn means the URL encoding or decoding function was written by someone who doesn't know what they are doing. Unsurprisingly, these are, well, to quote myself, "suspicious".
Yes, that logic applies to URL parsing as well! Unfortunately, browsers make URL parsing extra hard, which is really stupid, so you end up with more crap in Javascript than anywhere else. Even then you ought to prefer someone else's tested solution over just smashing out a regular expression; however, it is not a knock on the tested solution if it is a regular expression-based solution.
This article is a perfect example of why not.
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.
That was an actual argument on a thread about Facebook underpaying bounties.
Further to that though, we now know that this problem is fixed in LastPass. We don't know about other password managers. To that end, LastPass is now a better option than it's rivals.
Only when you believe that all password managers are equally secure from the start.
There are many reasons to believe that this is not the case. Storing passwords in a cloud service is quite a red flag. Then there is a former employee stating on Twitter that part of the codebase is very neglected:
I put more/less secure in scare quotes, because my point is really that fixing one particular bug certainly closes that one particular attack vector, but security is not a progress bar that goes from 0 to 100.
What this write-up does in my mind is really highlight the risks that come along with using a complex piece of software to manage your passwords. We tell users they can use password managers to safeguard their passwords and increase their security. We talk a lot about the usability trade-offs which password managers entail, but perhaps not as much about the security trade-offs!
Um...it was a really stupid mistake. Writing your own bug-prone regex here instead of using an existing, trustworthy function is just really bad. Especially when the consequences of a bug mean a hacker can steal someone's passwords.
You should really hope that any company that prides itself (and bases itself) on security would never release this bug. It absolutely lowers the reputation of lastpass.
Have you got a mechanism you could post here for them to do so?
I use keepassx, which requires manual search, copy, paste but it can store its vault on a cloud drive, mobile etc. and can have a key file or password.
Here is their security white paper : https://www.dashlane.com/download/Dashlane-Security-Whitepap...
I found this alternative when LastPass was acquired by log me once. I was not happy with this. This app doesn't have hacking or vulnerability history like LastPass.
They also have a dedicated import for LastPass. https://www.enpass.io/docs/desktop-mac/import_lastpass.html
*every few major releases
(Apart from "don't use services that require you to share passwords for a single account". Alas.)
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?
Probably doesn't work out, but it's what came to mind as a way to deal with the balancing act.
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.
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.
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.
This matters because even if it's client-side encryption, the encryption code just got downloaded when you opened the site so if the server or the network was compromised, you got compromised. [0]
With Keepass, the only time you run that risk is when you download Keepass.
[0] As far as I can tell, this is the core argument of tptacek's "javascript crypto considered harmful" rant (https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...). I'm not sure, because it's written worse than his most drunken HN comment, but I believe it is.
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.
Integrating with the browser is probably a bad idea, it shortens the exploit path from a webpage to your password store.
Using a standalone application and using the clipboard would require a malicious website to break out of the browser and then break into the password store process, which could in principle run under a different user and interact with the clipboard through some broker process.
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.
1. "Salt" my email usernames with the name of the service (johndoe+reddit@example.com)
2. Use multiple (long) password bases depending on the type of service (eg website vs app)
3. Combine the password bases with a cipher/salt based on the service name and my username
I'm guilty of not rotating passwords on a regular basis, however.
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...
Or there could be several modes and a database of websites that automatically picks a mode based on the website. Which leaves you remembering modes in the worst case scenario, or trying a few of them out.
I think an acceptable solution can be made by analysing the password requirements of the top N websites, then coming up with a good scheme that works on most, and an alternate scheme that works on the rest. One mistake is usually allowed everywhere.
(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.")
Full report sent to LastPass, they're working on it now. Yes,
it's a complete remote compromise. Yes, I promise I'll look at
1Password.> @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
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.
The string "foo" correctly gets parsed as a path (group 5). However the string "foo;key:value" gets parsed as a "foo;key" scheme (group 1,2) and a "bar" path (group 5) by the regular expression, but as a path if you follow the grammar.
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
vs.
^(([^:\/?#]+):)?
:; are reserved characters, but they do not need to be encoded when they are a part of the path.
So yeah, don't use regular expressions for parsing.
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.
How many times have people had to pay you not to commit felonies that are a) immoral, and b) could land you in jail?
I think most people don't need monetary encouragement not to turn black hat.
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.
In other words, I don't believe bug bounties incentivize people who would otherwise not already be looking, but it gives them a safe outlet and official validation that they can put on their resume/website/whatever.
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.
It's just a tiny overhead to my workflow.
You can also likely mitigate some of this by setting a fairly low autologoff timeout, though how well that will work may vary widely depending on how different people use the Web.
An example is Vault [0].
Encryptr [1] is another alternative: it claims that "all of your data will be saved in encrypted format in our Zero Knowledge [2] cloud".
[0] https://github.com/hashicorp/vault
Zero knowledge is merely the fact that spider oak only holds encrypted backups of your files and it has no way of seeing them. LastPass tells us the same thing.
There are fair number of open source alternatives that allow you to store secrets in the cloud:
vault: https://github.com/hashicorp/vault
blackbox: https://github.com/StackExchange/blackbox
git-crypt: https://www.agwa.name/projects/git-crypt/
Pass: http://www.zx2c4.com/projects/password-store/
Transcrypt: https://github.com/elasticdog/transcrypt
Keyringer: https://keyringer.pw/
git-secret: https://github.com/sobolevn/git-secretIt's probably not worth attempting to convince certain people. Not only Encryptr, but even other ones [0].
Oh, and I'm not even remotely affiliated with SpiderOak.
It targets the local autofill functionality in the browser, so it could conceivably have occurred in any password manager with browser/autofill integration. Including those that use a local password store.
What's happening is that this extension auto filling the password in unintended sites. Where it is getting passwords from (offline or from cloud) is immaterial for this case.
This bug could easily occur in Chrome/Firefox's built-in password manager autofill, though I must admit I have slightly more implicit trust of the developers behind Chrome/Firefox than of Lastpass (instinctively; this may well be unwarranted).
password reuse < own memory/manual storage < synced unencrypted 3rd party storage < synced encrypted 3rd party storage < custom encrypted storage < some custom crazy HSM which doesn't allow you to get more than X passwords per minute and notifies you on each get()
There's another dimension for cross-platform support somewhere in there. At the moment if you want your passwords saved and shared between desktops and mobiles, the best solution I'm aware of is 1password with separate sync (dropbox/icloud) - and you're still trusting the 1password app. You can go further, but you're starting to destroy usability on the way. Lastpass / 1password is still a valid choice that's better than many alternatives.
It works pretty well. Different password for each site, I only have to remember a few things, and it would take several compromises (and a weirdly dedicated attacker) to work out my algorithm.
For example, my 'insecure' fixed part might be 'Tenk5$' (I recommend including uppercase, lowercase, a number and a symbol in that part to get around idiotic password requirements). Then my algorithm could be 'the last 5 letters backwards, skip the first vowel'. In which case my password for HN would be 'Tenk5$rtani'.
Some need Lower-/Uppercase, some with numbers, some with special Chars, some restrict to minimum of x chars, some use a maximum.
Your system works not for all things, i use a similar system, but store a bunch of passwords with last pass. Only really important passwords are in my head.
Use that algorithm widely enough and several compromises are guaranteed. The only thing protecting your password is that url manipulation.
It stores your data locally, is suprisingly easy to use and relies on battle tested GPG.
From the website: "The community has even produced a cross-platform GUI client, an Android app, an iOS app, a Firefox plugin, a Windows client, a pretty Python QML app, a nice Go GUI app, an interactive console UI, Alfred integration (1) (2) (3), a dmenu script, OS X integration, git credential integration, and even an emacs package."
The lack of integration then with the rest of the OS is actually a security benefit.
var fixedURL = URL.match(/^(.*:\/\/[^\/]+\/.*)@/);
fixedURL && (url = url.substring(0, fixedURL[1].length) + url.substring(fixedURL[1].length).replace(/@/g, "%40"));
* fidexURL is whatever is after :// and up until the very last @ (greediness)
* the second line fixedURL && is going to complete if fixedURL is not undefined
* url = this fixedURL, then the rest of it where @ was replaced by %40
so basically, entering http://avlidienbrunn.se/@twitter.com/@hehe.php will give
url = avlidienbrunn.se/@twitter.com/%40hehe.php
if I understand correctly. What happens after?
EDIT: it must be that the last [^/.]* before @ is taken as the domain name. But why splitting the URL before a @ sign? I'm confused
[1] https://www.dashlane.com/download/Dashlane-Security-Whitepap...
Why isn't PasswordSafe more popular ? What do other password managers have that Password Safe does not ?
The open questions are a) how long the flaw existed prior to being fixed and b) whether attackers were able to exploit the flaw.
Update: Looks like LastPass has made a blog regarding the exploit and have stated v3 of the addon is not affected [1]. Would be nice to have further clarification of the differences between v3 and v4 with regard to this.
[1] https://blog.lastpass.com/2016/07/lastpass-security-updates....
http://www.zdnet.com/article/lastpass-zero-day-vulnerability...
Anyway, I'm glad that LastPass has resolved this; last thing I want in the news is another big password breach.
http://ronnie.me/store-encrypted-passwords-in-an-encrypted-f...
The issue I had with 'pass' was that it leaked info via the file names, but I found a nice way around that.
Update: after a few answers to my badly thought through comment, I now feel enlightened. The attack scenario is a malicious web site which can gobble up my passwords. Thanks
1. Writes up that post.
2. Inserts an iframe in the post, which enumerates known sites. (hidden out of view with css tricks)
3. Instead of alerting on screen, sends the results back to their server.
4. Submits to HN.
So no, I don't think it will only give you your own passwords.
Running as a separate application outside the browser is 95% as easy thanks to auto-type.
"Also, this would not work if multi factor authentication was on, so you should probably enable that as well."
If you have something as important as a password manager (ie something that holds the keys to ... everything), then MFA is a must. If you use LastPass without MFA, then you're probably asking for trouble.
https://twitter.com/taviso/status/758143119409885185
Tavis has made quite a name for himself lately by going after AV vendors with no mercy. So when he tweeted, the community sat up and took notice. (Our own Slack was busy with discussion about this today)
Mathias, author of this post replied to Tavis with this:
https://twitter.com/avlidienbrunn/status/758232557829914624
The fix for the detectify exploit has already been pushed to users, so I'm guessing they were holding onto this public disclosure but Tavis putting his sights on lastpass too caused them to move the schedule up a little.
And the exploit from Tavis from 4 hours ago:
https://bugs.chromium.org/p/project-zero/issues/detail?id=88...
It does erase the fields and promoted 2fa, but passwords are available briefly.
I Sent a ticket to their supportthey, they acknowledged the issue and just asked me to disable local cache... (Chrome extension)
You could even use replaceState to change it back immediately.
In fact, I'd go further and say that you can do this with your login name. So for example:
myemail+by@gmail.com for eBaY
This also helps mitigate those attacks where the attacker actually contacts support and socially engineers them into giving all your info and even stealing your account:
https://medium.com/@espringe/amazon-s-customer-service-backd...
If you are hosting with AWS you should really consider doing that
People who enable it might not understand the repercussions.
I use 1Password and always invoke a shortcut to fill in my credentials.
Try this: Cars are dangerous. Why do they even exist? People who drive might not understand the repercussions.
If 1password has the same functionality, it may contain a similar vulnerability, whether you're expected to use a keyboard shortcut or not.
First I decided 1Password to replace LastPass, but it puts a lot of weight on my pockets as it's very expensive. Then I encounter Enpass. It's a really good password manager. What I like about Enpass is that it saves database locally on my device not on their server and gives the desktop app for free.
It's worth to try and it hardly takes a few minutes to move all your LastPass database into into Enpass. https://www.youtube.com/watch?v=Fn69hHur3Jo
Thanks! :-)
Essentially, LastPass made the mistake of writing code which said "If you see `example.com` anywhere in the URL - assume that you're on the right site.
LastPass will allow you to automatically fill in the username and password as soon as you visit a site (I think this is an optional feature).
An attacker convinces you to visit "badsite.wtf/@example.com/". LastPass sees the "example.com" and autofills the password field. The site has some JavaScript to detect the filled in details - and steals them.
Also, what's the return value of the funcion?, and why are there 2 variable named URL?
[1]: https://blog.lastpass.com/2016/07/lastpass-security-updates....
[2]: https://bugs.chromium.org/p/project-zero/issues/detail?id=88...
It's easy to forget that sandboxed extensions don't exist yet in iOS (as of 9.3.3), and sometimes we still have to use bookmarklets.
As far as I know, bookmarklets aren't afforded any level of sandboxing type protection. I wonder if a malicious page could intervene like that.
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.
Some people work in fields where there's an extremely high cost to making mistakes, and whose customers trust them to be careful and meticulous. Those people are paid to be more careful than your average code monkey who churns out regular expressions to save time instead of carefully researching the problem, performing code reviews, and using standard well tested libraries to parse complex but precisely documented standards like html and urls. Developing a browser plug-in to manage passwords is one of them.
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. -JWZ
If they don't have those types of checks in place, that's the fault of the company.
If someone want's to sue over this, then sure, sue the individual (and the company). But as a manager in company, I would not not punish the individual. I would have them conduct a thorough post mortem and look for ways to avoid problems like this in the future. People do learn from their mistakes and that is valuable.
How (and how often) are updates pushed to the client?
They're pushed via Chrome's extension store. Definitely at browser startup, but otherwise periodically every 5 hours (by default)
They have a good product, nice blog articles explaining various technical decisions they made, and a fast customer support in terms of listening feedback.
Beware though..their Android app does not support multiple vaults. And their Windows client is really ugly. Their iOS and Mac apps are very refined though..and I know the founder is trying to close this feature gap across platforms.
They seem to be moving towards subscription licenses with Teams and Family though...which do not require separate licenses for different platforms.
What's the difference with simply going to "http://twitter.com"?
This looks more like a bug than a vulnerability, what am I missing?
Remote JavaScript could trigger the export all passwords feature...
I'm not sure if it is, bugs like that are a serious threat. Personally I use the same (long) password for every website, except one of the characters which I replace by the website's first letter. One could think of similar, more sophisticated schemes of password reuse that yield a slightly different password for each website.
It would be even better if websites started using a public key authentication system, though.