I found Prezi's source code(blog.shubh.am) |
I found Prezi's source code(blog.shubh.am) |
None of this happened in the United States at all - it's amazing! Non-Americans also have businesses!
If cracking an internal service is possible, a bug exploiting it should be within scope of any bounty program.
Nice, nice.
Where does it end?!
But I'm also quite upset with the fact that OP is outing the dev. Everybody makes mistakes, no need to out any individual developer because OP is pissed at the company management.
Passive aggressive much?
I think he should have got a bounty -- if not the official one, then a special, bigger one. However, this is an odd way to conclude the post. "Oh, I'm not at all trying to discourage others for participating, oh no no". Of course he's trying to discourage others. With justification. I don't get it.
What’s up with other vulnerabilities? ... we will consider if they are eligible for a bounty or not
What is the bounty? ... we will increase it at our discretion for distinctly creative or severe bugs
Prezi explicitly designed the rules to be flexible, so they could give the award in this case, but decided not to because "intra.prezi.com is out of scope".
The rules about scope appear to exclude vulnerabilities in 3rd-party services such as AWS, not backends, e.g., the backends for our iPad and desktop applications are in scope
By doing this, future employers hopefully will not see the blog post when searching their names.
The Nexus Repositories URL (http://intra.prezi.com:8081/nexus/content/repositories) is still not restricted
Pay him something outside the bug bounty program. Easy and cheap solution that could've avoided all this mess.
By paying nothing for what could have been sold back to them for a huge sum, they may disaffect hackers, who could do them real harm. You become a sucker to volunteer for their 'bounty', and decide to turn to the dark side instead.
I think Prezi are very silly to be splitting hairs about this. They stuck the stick in the hornets' nest, now they are arguing with the hornets.
Does this mean that Prezi do not value their code and don't believe there would have been any significant loss if that code became public?
Are they saying that the next person that discovers serious flaws in their security should just keep quiet - or sell it on to some hacker, where at least they can make some money from it?
Just what message are the Prezi people trying to send by nit-picking over $500?
How much is worth the vulnerability of having access to all your source code. Just ping me if you're interested.
Still a bad move to have denied him the bounty in the first place, but good to see that they're listening to the outrage.
Do you really think that any extremely motivated hacker would just stick to the arbitrary terms you set.
He will do whatever it takes to get in and by limiting security research you're making yourself vulnerable in other areas not defined in that assessment request.
I think Prezi should have done something like this:
* Acknowledge the problem and the seriousness of it
* offer a reward, but not under the bounty, just a "thanks"
* Have him sign an NDA about the source itself, and the specific details of the issue, and the amount of the award
* Allowed him to write up the experience should he choose (good PR for prezi)
* (maybe) offered a contract for the researcher to find more such issues, or announced a different program as a result of it.
The reasoning behind doing it outside the program is that Prezi needs to walk a fine line between saying "just attack everything and we'll pay you!", "we are too process driven for our own good", or they end up getting bad press from people who tried to follow the rules not getting anything, but cheaters are getting paid.
I'm not sure I agree with this particular argument, it essentially reduces the concept of a bug bounty to blackmail. This mindset is not a constructive one.
The tester should get rewarded for their hard work and helpfulness, not the decision to follow the law.
And it seems like he knew it was out of scope when he submitted it too: "I had spent a total of 2 hours sifting and crawling through their services which were in scope, but wanted to see if I could locate any other subdomains..."
Now I think Prezi should probably have paid him anyway because that's a pretty boneheaded error and I'd be very grateful if someone politely pointed it out to me... but they aren't obligated to. You can put your pitchforks down.
The Finder provided tremendous value by discovering this issues and reporting it responsibly. He certainly should be rewarded with something more substantial than swag.
Would Prezi have preferred that the Finder just not report this issues?
And I don't usually go looking for them, but if I come across a security problem (e.g. someone left login credentials unsecured in bitbucket) I would let them know because it's the right thing to do, not because I expect cash.
But Shubham did one additional thing, he unintentionally embarrassed a founder. That's the real reason he's not getting paid, everything else is a technicality...
In their position, I'd pay him the $500 and remove the idea of scope. I'm just curious if there's some counter-argument I'm not thinking about.
Companies could sign on to using this third party and pay a fee and put up escrow for the service. This would motivate researchers to find bugs for those companies that utilize the service, knowing payment will be impartial.
Disclosure: I'm co-founder of CrowdCurity
Ps: the idea is pretty cool. So is the implementation =) though how would you guys have handled if an issue like this occurs on your platform? A submitter submits a bug but the company refuses to pay for it citing "out of scope" ??
The only thing this causes is exceptionally bad PR, or even worse for the company; someone just got access and you don't know. Access to source code is like the gold mine of finding an exploit, because you will know exactly where a vulnerability is, and you won't even have to blindly test it.
This suggests that anything less than perfect security is worthless. Which is better, having pentesters look for vulnerabilities in 50% of your surface area, or having pentesters look for vulnerabilities in 0% of your surface area?
Setting up a bug bounty program has a cost, both in terms of processing the data submitted and in potential disruption of the provision of services. This cost will differ from attack vector to attack vector. Having pentesters dress up as utility workers and attempt to sneak into your company offices to install keyloggers will have an extremely high cost in terms of disruption. This cost may be higher than the potential benefit of learning about the company's vulnerabilities in this area.
There are also some attack vectors that may be problematic to allow pentesters to probe due to third-party contracts, data protection laws, compliance issues, etc.
You may disagree with the particular areas a company chooses to define as out-of-scope, but to claim that having any areas off-limits renders the whole enterprise pointless is reductive and incorrect.
Is this supposed to be rhetorical?
Say you buy a really good front door for your house, and forget to put a back door on your house. I would say that testing the security of the front door is a waste of time.
In the end, everything matters
An out-of-band attack in the datacenter, VPS? Compromise of a developer machine to get inside the network? Social engineering?
in the end, if it caused loss or extraction of service/data, it doesn't matter how it's done.
> I had spent a total of 2 hours sifting and crawling through their services which were in scope, but wanted to see if I could locate any other subdomains, with the assistance of google.
While I agree that he most certainly found a "bug" (perhaps flaw would be a better word), it was out of scope. And using credentials from an employee to log in is nearly always out of scope.
At the time in which I found the bug and was not awarded for it, I was quite upset, evident from my tone in the email in which I decided that I did not want to receive any of their "swag", but rather give them some constructive criticism.
I wasn't expecting the blog post to get as noticed as it did, but as it has, I was able to observe great points on both sides of the argument of whether or not I should be received the bug bounty. These discussions were definitely required as they brought out some important issues with bug bounties today and how security issues should really be dealt with.
Prezi, has now both apologised to me and also have offered to pay me for my findings. I have updated my blog post to show this, as well as the emails exchanged between us. I'm glad that it ended this way - all within the last 12 hours.
Initially, I did not redact the developers names, and after the blog post became I had to rush to make sure that I had removed them from all places which were indexed by Google. My intention was not to negatively affect the careers of the Prezi developers affected from my findings.
I thank everyone here, and generally on the internet, for looking closer into my findings.
Thank you, Shubham
Actually we're continuously thinking on your case and struggling on the right move. On one hand, your finding was very useful for us, and we learnt a lesson from it. On the other hand, intra.prezi.com is out of scope, and by using the credentials to log in you violated the terms and conditions of our bounty program.
...
In the past we turned down the bounty request of people finding issues in out-of-scope services. We had a lot internal discussions about your request: if we were about to pay, we couldn't justify our out-of-scope decisions for anyone else.
What, are we in kindergarten? Does Prezi not have managers entrusted with taking decisions? They can run their bounty program however they want.
That they choose to run it in this fashion sends several messages in addition to the obvious, "we are obnoxious miserly prats". While hackers in white hats might be hearing "concentrate your efforts elsewhere", those in black hear exactly the opposite message. Many people who might previously have admired Prezi for their innovation and paid them money for their services, have now heard a reason to find other means to create presentations. Potential acquirers and potential hires have heard that this company's management finds running a bounty program challenging.
EDIT: Maybe I'm being too harsh. Apparently this is a largely Hungarian company; it's possible there are cultural misunderstandings in play. From a (perhaps cliched?) American perspective, however, following the rules is less important than accomplishing the goals of the program.
The Internet isn't just something happening in the United States.
Think if someone found the source code for Windows / Office / Photoshop, without any bounty program, and responsibly disclosed it to the respective companies. If he didn't walk away with nice amount of money, he could easily just put it in the nearest torrent site* without even feeling guilty (*this is wrong, and illegal, don't do it)
He plugged a huge issue for them, and they screw him over due to "scope"... That's their choice, but it still seems bureaucratic to me.
I think this is (yet another) lesson that participating in these kinds of bounty hunts is very risky and should only be done if the company is reputable (which this one apparently is not).
They also said that they will release a blog post and they will change the bounty program, so mistakes like this will not happen again (hopefully)
https://ilt.eff.org/index.php/Computer_Fraud_and_Abuse_Act_(...
Apparently neither Prezi nor the guy who found the login are American, so this particular law might not apply, but many other countries have similar laws.
[1] Except for the totally illegal aspect, obviously. And the not-telling-them-their-source-is-open-to-the-world bit.
In a legal sense, they aren't obligated to pay. There are a lot of legal loop holes. By not paying for something that they obviously want to know, they are discouraging other security researchers to disclose "out of scope" holes. To what end?
If you succeed, we will give you cash. That’s right; we’ll pay cold hard currency into your bank account. Think of it as a thank you. (Prezi bug bounty site)
I guess the right way to read this is as a (legal, of course) fuck you.
It's no wonder security researchers turn to black hat methods, when they're treated/compensated like shit for their effort. "Swag" in return for your source code? What a joke
Those who "turn to blackhat methods" do so because they want to make money and don't place a premium on the potential moral/legal/ethical issues at play in how they're doing it. They make a choice, irrespective of the shortsightedness on display by Prezi here. Don't conflate the two behaviors.
They absolutely didn't.
I don't get how there seems to be absolutely no human side to these cases.
Guy discovers critical vulnerability and could have completely fucked the company over. Instead he responsibly reports it, and he gets back a big fuck you. How can you possibly think that's fair? The fact that it's out of scope only means they should give him an out of scope reward - much higher!
Saying he could have not checked the credentials is a bit silly, because if the credentials were invalid (quite likely), it goes from CRITICAL to MINOR.
And isn't the entire point in bug bounties to encourage pen testers to explore your system? Sure, you don't really want them poking around your source control, but better that than black hats.
All of the above aside. They really couldn't spare $500 for someone who could have caused $millions of damage?
We all frequently have the opportunity to cause damage, but we don't get rewarded for _not_ doing so. I think Prezi may have given the cash reward if the pentester hadn't logged in and browsed around. They probably don't want to set a precedent (take the data you find, get cash reward).
> ... because if the credentials were invalid (quite likely), it goes from CRITICAL to MINOR.
Agreed, but either way the pentester won't be able to fix it. All he can do is report his findings.
> ... but better that than black hats.
Agreed, but if you stray outside the terms of the bounty then you're no longer guaranteed the rewards. I think the pentester tried his best to report responsibly but I don't think Prezi are obligated to give the reward, based on the terms.
If I wanted to hack Prezi I now have a lot of very useful information.
1) Prezi is not interested in blocking access to people who already have the ID of the presentation. This is good news since it means I can enumerate the IDs and get access to private presentations - some of which could have useful private data.
2) Prezi is not interested in blocking attacks which enumerate user ids, etc. This is great news - I can get a list of likely email addresses to use later.
3) Prezi disallows any forms of attacks that utilize outside services. That means that while Prezi's core systems have now been nicely screened, other systems are going to be wide open because nobody has bothered to test them properly. This works well with the list of email addresses from above and possibly data obtained from the private presentations above.
EDIT: Just want to add that this shows a very large misconception in the corporate security world. Security is not something you can get a "B - good effort" for. Security is all encompassing. You either get an A+ and the hacker does not get in, or you get an F and your data is gone. There is no middle ground. Putting parts of your security off-limit means you shouldn't have even bothered to begin with.
That's not true. There are substantially different levels of security required depending on the expected resources an attacker can devote to attacking you, and you can be better or worse at resiliency and recovery (where dollars and hours very much form a continuum).
I think your post also shows a very large misconception in the disclosure world.
It sounds like you're saying that bug bounties should be a free-for-all.
Are you recognizing that these companies often already have security programs in place? Do you also concede that the companies may already be aware of where their vulnerabilities rest?
Large organizations know things that you don't when you're submitting bugs to a reward program. Constraints on a program help them focus on areas where they know they have unknowns. It also helps them deal with situations where they know fixes are scheduled, but not currently implemented.
How are things going to play out if you took the time to discover a bug and the company told you they're not going to pay for it because they already know about it and already have a fix scheduled?
The average 'researcher' is going to be pissed. You don't know if they're telling the truth, you put in your valuable time into finding the bug, and you're wondering why you should put in your time next time.
Rules on a bug bounty program do not necessarily exist to constrain the reporters to only the "known strong areas". They're there to help avoid situations that might lead them to quite reasonably ask why they bothered to try to do a responsible disclosure in the first place.
Theres a few reasons, most of them having to do with managing day to day operations and keeping the business operating, etc. It'd be great to have everything wide open and and getting hammered until anything resembling a vulnerability is found, but that is sadly not really practical in most businesses.
Most bounty hunters aren't using precision. Without a doubt some are very meticulous, but a great many will throw every possible tool/option at their disposal at an application. This is great if it finds bugs, but it can also cause a lot of problems if their script generates a few hundred thousand help desk tickets that put your support/sales team way behind at a crucial times.
Theres also a lot of politics thats come into play. A lot of times these bounty programs have a split fanbase within company management and anything that interrupts the business, causes "bad" PR, and such will be quickly pointed out as reasons why the program should be discontinued.
Bug bounties != pen tests. Penetration testing takes a lot more for teams to work with and get something out of, and honestly a lot of organizations don't get anything out of a pentest. They either get a vuln assessment that a scanner jockey exported to pdf and showed up in a sports coat to present, or if they get an actual pen test by some of the people really doing it they get their ass handed to them so badly they have no idea what to do.
Bounties are to help a company understand the problems they have and get them fixed. Pen testing is about seeing how well you respond when everything goes to hell around you. Smaller orgs being constantly beat down isn't going to let them get a lot done to do anything except put out fires. (beware, physical world analogy ahead) Learning to defend yourself involves working with an instructor, and constantly getting better, not paying someone to whip your ass daily until you can't stand. Some people can work through the latter and become very well adapted to mitigating the attacks, but most will just get beat down and quit.
Maybe Prezi was trying to take a stand by not paying the guy for being out of scope, and thats fine they're certainly dealing with the consequences of that decision, but its completely understandable as to why they'd want some sort of scope to begin with.
I can't speak for Prezi, but it seems like they want people to test the security of their app, but not of their employees or back office infrastructure. Maybe you disagree, but it's their bounty and I think those are fair rules.
Phishing employees, DDoSing definitely cause problems if a large number, or one, of bug bounty hunters take on the approach.
It seems even if all the bug bounty hunters searched for and found http://intra.prezi.com:8081, preformed google searches and tested found logins by hand, no problem would result for prezi.
So it seems like Phishing employees and DDoSing are inherently different then the approach in the post.
To qualify for the bug bounty he should have inserted code into their codebase and then exploited that. Fuck these guys.
Yes, because those control panels should require 2FA, so password-only access is a bug.
Large companies also invest significantly in protection against massive DDoS and power cuts to the building, along with drills for earthquakes and zombie apocalypses.
For example, if I was to set up a bounty I really wouldn't want people at random contacting current or former clients trying to phish for passwords; I completely understand this is a threat, but I would want to personally manage something like that.
With that said, if something like this was found I'd pay the person. There's a point where you just recognize "Oh shit, that's a big hole, pay the man.".
- Deleting the company's data.
- Stealing from customers.
- DDoSing the site.
If you find a bug by taking any of the blacklisted actions, you get no bounty.
This approach protects the company without unduly limiting the thoroughness of the review.
Even worse are the companies that DON'T state any kind of bug bounty or instructions to report a security bug...
I found a data leak issue in one of the web properties of an S&P 500 company last week and I'm not sure if I should report it, because I feel that if misunderstood it could have negative consequences for me; and not having a security contact means I can't be sure the person I'm talking to understands my motives.
That doesn't really apply in this case though.
I think your point is too extreme. Locking your front door is most definitely NOT a waste of time, because with that move alone, you've automatically protected yourself against the subset of attackers who don't think to try the back door. Are you still vulnerable? Yes, of course. But decidedly less so. As the OP said, 50% is better than 0%.
The real conversation that should be taking place is not whether or not a limited scope should exist (it should), but how far that scope should extend given the costs of extending it.
This seems to be key. Did he just verify the credentials, or did he poke around thereafter? If the latter, Prezi has a better case but they should have stated it more clearly.
This case is not like that, though.
If you don't have that, people don't know if they are breaking the law by sending you a bug report, and they might not report the issues.
Most of the time, the bounty is not going to pay for my time anyway; I just do it for the fun of it, but it definitely says "security issues are welcome"
http://books.google.ca/books?id=ZjBvpN0zZNkC&lpg=PA33&ots=Uq...
Not exactly the same situation, but it suggests that the law is fairly strict.
You did not enter the house you did not explore. You turned the key, the knob, and made sure the door would open a little.
Not something I would recommend, especially since the key had the address and the owner name and address attached to it.
But not as bad as someone entering the home and looking around.
It helps decide weather or not the legal response if any is reasonable.
> whether you think that it ought to be or not.
I was not trying to comment on what I think ought to be.
Remember that credentials and tokens can be relayed.
The only way FIDO could prevent this would be to make the credentials dependent on the URL in the browser, but I don't see where it does this.
I thought the whole point of gray hat is that it's possibly illegal, but not downright "evil".
i.e. Stealing source code to fix bugs = gray, stealing source code to steal credit card info = black
Generally "gray hat" and "corporation/law-friendly" don't mix, even if there are some cases that call for it.
Until he contacted Prezi, how could he be certain beyond any doubt that they weren't already aware of it? Could you explain that to me?
MITM is still possible, but there are other ways to combat that, such as TLS Channel IDs [1] or Bearer Tokens [2].
[1] http://www.google.com/intl/en/chrome/browser/privacy/whitepa... [2] http://www.browserauth.net/
I am trying to make that judgment and help others to do so.
> and the second says that you're not trying to comment on what the law ought to be.
If I am trying to make a judgment, if I am in the process of reasoning through something I do not know what something ought to be.
Good analogies are those that help people reason through a problem and come to the correct conclusion, not a tool to sway people to your opinion.
As an example, you have some fairly non-sensitive private health records. Here are three approaches:
(1) No security at all. You hope nobody is going to bother taking them and using them for anything malicious.
(2) You put in decent security, but a contractor for a new feature left open a vulnerability you didn't know about.
(3) You make sure everything is secure and have security audits over the code that closes the vulnerabilities that a contractor made.
The data for (1) and (2) get hacked and used in a bigger hack on a different service that results in money being stolen.
Now you could say that (1) gets an F, (2) gets a B because at least they tried, and (3) gets an A+ because the data wasn't stolen. This is rubbish - both (1) and (2) resulted in data being stolen and lost customers / lost money / insurance penalties / whatever. The security teams for both (1) and (2) failed utterly and get an F.
If (2) had guessed correctly and nobody had actually devoted those resources then (2) gets a flying colors because the data is safe - but it's just pure gambling. Gambling with security will always be a losing bet in the long run. Rather just make it secure. Going off some strange 'expected resources' is just asking for the time when your data somehow becomes valuable and those resources get brought (or more likely, one of your employees annoys the wrong person with too much free time).
Explaining to your customers that their email addresses weren't valuable enough to do proper security is a great way to lose me as a customer.
What you should realize is that "security teams" are generally not responsible for the level of security at organizations. The information security team will generally present the risk to the business owner of that process, that data, that application, etc and let the business owner decide if they want to accept the risk, mitigate the risk, or avoid the risk. If I went to the CEO of Dropbox and told him the biggest security flaw in Dropbox is that users can share files with each other, he's going to tell me to jump in a lake because that's their entire business.
Nothing is 100% secure, and nothing can be 100% secure. I'm not agreeing or disagreeing with what Prezi is doing, but your notions of all-or-nothing security seem a little out of touch with the reality of business.
You seem to be implying that the fact there are two possible outcomes implies there are only two possible initial states - vulnerable and not vulnerable. If the attacker steals data, the initial state was vulnerable, and if the attacker fails, the initial state was not vulnerable.
This is what poker players call "results-orientated thinking". The initial state is much more like a range of continuous values, where 0 is "having literally no security whatsoever" and 1 is "having security no earthly force can overcome in any scenario".
No private company has perfect security, and perfect security is not desirable, because incremental security has non-zero cost. Does it make sense for a typical firm to spend millions of dollars hardening their office building against the threat of attack by a heavily armed private militia? No, because for most firms the cost of preparing against such an attack outweighs the risk-weighted value of preventing such an attack.
Incrementally improving security narrows the range of successful attacks. Incrementally improving security means fewer attackers will be skilled enough able to successfully infiltrate, and fewer attackers with enough skill will go to the effort to successfully infiltrate. The goal is not to guard against every conceivable attacker, but, in a simplified model, to incrementally improve security until the marginal cost of the last improvement is equal to the marginal value of the reduction of attack scenarios.
> If (2) had guessed correctly and nobody had actually devoted those resources then (2) gets a flying colors because the data is safe - but it's just pure gambling
"Gambling" has no particular meaning in this context, because every decision about security precautions involves weighing known costs against potential risks. The division of security plans is not between "gambling" and "not gambling" but rather between "positive expected value" and "negative expected value".
Either way, the point is, there's a trade off. Kinda like the 80-20 rule. It obviously taken 20% effort to protect against 80% attacks (the casual opportunistic attacks. like preventing sql injections, or locking your front door) and it takes 80% effort to prevent those last 20% attacks (actual Pros). SO "you might as well not have bothered" is somewhat naive in my opinion
Unfortunately, the real world isn't so black and white. The resources someone will put into hacking your site depends on their perceived value of success, and if someone with enough resources values it enough, they will hack your site, no matter what you do.
Anyone who claims to have constructed an unhackable internet service has either constructed a trivial and useless service, or doesn't understand the complexity of software.
"Gambling with security will always be a losing bet in the long run. Rather just make it secure. Going off some strange 'expected resources' is just asking for the time when your data somehow becomes valuable and those resources get brought (or more likely, one of your employees annoys the wrong person with too much free time)."
So, every site you deploy is going to indefinitely withstand armed assault by government forces?
Maybe I can sleep better at night if I didn't go storing them in plain text and I can make up excuses easier, but I still failed. Regardless of how likely any breach was, I failed. My customers have probably jumped ship.
If I store it in plain text and I never get hacked, then I've succeeded. I'm more likely to succeed the more security I add, but if it gets stolen then it doesn't matter anymore. Basically I'm trying to imply that success or failure is a boolean based on real world results and does not depend on the amount of effort placed into the security. The security can influence the result, but once the result occurs the security I used or did not use is irrelevant.
So skimping on security is always a terrible idea. If you know of a way to increase security, then you should increase it. If you offer a bug bounty to improve security, make sure you give a reward for any possible breach that could cause you to get hacked, regardless of whose 'fault' the vulnerability is. If someone can social engineer your developer, then pay out the bounty. Maybe it won't happen next time because now the developer has learned something.
This statement is dead on.
From the Wired article about Max Butler: http://www.wired.com/techbiz/people/magazine/17-01/ff_max_bu...
"Butler spent months plotting to infiltrate and overtake his four competitors, culminating in the two-day hackfest in his overheated safe house high above the Tenderloin. The sites blinked out of existence, their thousands of forum posts later rematerializing on CardersMarket. Iceman now had upwards of 6,000 users on his site, making it by far the biggest carder site on the Internet."
Your security people work 8-5 and go home and leave their work at their office. Most hackers have the ability go days or weeks at a time banging away on your system until they find a crack wide enough to get in and then its game over.
- One copy of your data that is publicly writable is very insecure
- One copy with credentialed access is better
- Redundant copies with credentialed access and PK-signed master-slave synchronization is better still
- Add periodic off-site backups to encrypted media with keys generated using a hash-based one-time password and it's even better
But, oops! Someone left a debug line in the Javascript that runs your restore-from-backup webapp. The auth layer has been silently truncating passwords for the last 10 months to just 3 characters. All that extra security you entered to prevent anyone reading your dataset now means ... absolutely nothing. Anyone could have gotten in, and once they're in the backup app, they've got everything.
Beyond redundant copies to recover after malicious tampering, every single seal must be perfectly tight or you'll leak all your data. I've seen source code for some old Windows 98 malware (analyzed on MSDN, I think) and it's crazy how specific they are. One unchecked array index or untested struct size UINT before a memcpy is all it takes to do a privilege escalation.
Depends where you are. In Germany you are entitled to a finder's fee by law (in the case of the taxi only if the value is > 50€ and only 2.5% instead of the normal 5%)
"Taxi drivers and owners must return property they find in a taxicab." - http://www.nyc.gov/html/tlc/html/passenger/sub_lost_prop_inq...
Further: Money doesn't have any owners. Only spenders.
Double standards.
It's moral when you do it because it's obviously the right thing for everyone involved. When there's money involved, that's something else.
This thread hasn't really been about the article for a while. It's been about someone feeling that people that don't reward for good deeds are greedy assholes, which I think sets a bad precedent. If you want to incentivize fine, but let's not confuse that with what the right thing to do is.
How about a moral obligation? Honestly, it sounds like if a taxi driver returns a bag full of cash to the owner, it is perfectlly alright if they just say "Thank you" and walk him to the road. Legally: nothing wrong, morally: being a greedy asshole.
Edit: Fixed truncated second paragraph.
Why not sell it? People sell URLs all the time, and bitbucket is clear written intent from the company that they wanted their source control systems accessible to the public else they would not have provided written notice to the world of their passwords.
Surely the creators of the software are competent software experts who fully understood the implications of making their repository public. Surely, they are not asserting that they were so negligent in the performance of their duties as to not check whether the repository would be made public.
Also, they've made numerous written affirmations that the issue found is not a bug, and would not qualify as part of their bug bounty for security flaws.
They are morons and deserve to be hacked because they are negligent and make affirmations that leaving their source control system passwords on public computers is not a security issue worthy of payment. They deem the risk to be so insignificant as to not even be worth $500.
RyanZAG is "correct". If someone breaks into my house and steals my TV, then my security was a failure.
This leads to the next problem - its not a catastrophic failure in today's (western) society. I am probably out at work, and I am insured, and the burglar is unlikely to be waiting when I get home to murder me.
However, there have been plenty of societies in the past, and are many now, where the expectation of loss would be almost total - someone breaches your security, they take the tv, kill you and your family and burn the house down on the way out.
So its not a judgement on the resources of the attacker that matters, it is the expected consequences of the breach - the expected value of damage.
Which side of the argument you come down on depends on whether you see the Internet as basically a nice London suburb with a few bad eggs in it, or a violent amalgam of Feudal Middle England and Mogadishu on a bad day.
"So its not a judgement on the resources of the attacker that matters, it is the expected consequences of the breach - the expected value of damage."
I nodded at this when I mentioned resiliency and recovery, but I still think resources of the attacker matters. A determined attacker could doubtless breach your front door with a battering ram or axe and enough time. Part of the reason you don't worry about this, I assert, is that it's not likely because the costs to the attacker (in terms of chances of getting caught and penalties if they are) are too high. Part of it, as you say, is that we have some amount of resiliency against the threats posed. And probably part of it is that most of us are not terribly inclined to do damage to each other without provocation and there are many possible targets for the few who are - I'm not really sure the degree to which we should legitimately consider that bit a part of "security" but it certainly merits weight in calculating risks.
Curiously I am not convinced of the total damage done by these various break-ins. Stealing credit card numbers is not the same as getting the loot into a laundered bank account. Grabbing bitcoin wallets is closer, but the liquidity does not exist to extract much.
The damage is seemingly more reputational, or other internal costs to the hacked company (like paying security consultants). The actual "money the thieves ran off with and could convert into real cash" is pretty thin - would value some pointers at studies here.
> If you offer a bug bounty to improve security, make sure you give a reward for any possible breach that could cause you to get hacked, regardless of whose 'fault' the vulnerability is.
This is true. There's no upside for rejecting this as "out of bounds" except for a relatively tiny sum of cash.
> If you know of a way to increase security, then you should increase it.
This I disagree with completely. If there's anything you can do with negligible cost you should do it, however there are all kinds of costs. There are usability costs, operational costs, training costs, etc, etc.
You can't hand-wave these away by declaring that any breach is failure without recognizing the fact that there is no such thing as perfect security. In fact all security is gambling, and it should be a gamble based on the best odds we can come up with professionally against the cost of failure. If something requires 100% perfect security then that thing should not be done, period.
There can be. If the attack involved something that - done broadly - would itself cause problems even without a vulnerability, then you don't want to reward people for probing those ways without arranging it first. As a sort of extreme example, imagine hundreds of security researchers getting in the way of your paying customers while trying social engineering attacks on your staff.
Recognition that security is only as strong as the weak link does not imply that all links must be infinitely strong.
This is what all of the "security" vendors would like you to believe. It completely ignores the value of the assets you are securing.
How many rounds do you use with PBKDF2 if you want to slow down attackers? You can always add more rounds to slow down brute forcing, so how would you reconcile this with your statement of always increasing security. The same applies to bcrypt.
