[toddmorey]

Why even have a limited scope on bounty programs? (This is not the only time I've seen that.) Is it only to limit payout? Are their legal reasons? For example, their client tablet applications are ineligible. I just don't get the reasoning.

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.

[RyanZAG]

Having these kinds of rules on bug bounty programs is excellent for hackers though.

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.

[dllthomas]

'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.'

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).

[RyanZAG]

I disagree here - you've either lost the data or you haven't. You can make guesses as to the expected resources of the attacker, but if you're wrong and the attacker has more resources, then you might as well have not even bothered.

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.

[freehunter]

I think the idea the parent was trying to express is there is different risk appetites for various things/companies. If it would cost more than your profits to secure something 100%, obviously you need to look at other ways to go about it. Mitigation is a major force in information security. Mitigation isn't solving the risk, it's just making sure that the impact of the risk is low if it does get exploited. Likewise, while PCI data needs to be as locked down as possible, other data doesn't need that level of security because the tradeoffs are too massive to be cost effective or business effective.

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.

[gabemart]

> I disagree here - you've either lost the data or you haven't.

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".

[grannyg00se]

How do you relate this to something like home security? You have valuables at your home. People can come in and take it with varying degrees of force. Are you prepared for the maximum force attack, or do you accept the typical security features which you know to be minimally effective?

[xerophtye]

hahah was just gonna write about this, but you beat me to it.

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

[abstrakraft]

By your logic, there are only two kinds of chess (or any game) players: those who win every game they play, and those that don't.

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.

[dllthomas]

"Because they tried" doesn't get a B. You're not graded on effort. What you're graded on - when it comes to defense as opposed to recovery, though both are a part of this - is how likely a breach is. Unfortunately, you don't always learn your grade (and when you do, it's bad).

"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?

[RyanZAG]

No. But if the site gets hacked, I failed. If I asked users for their credits cards and stored it in a publicly accessible plain text file or in a secure system that still gets hacked the end result is still the same. My users are having unauthorized payments coming off their credit cards. I've failed.

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.

[lifeisstillgood]

This is a fascinating discussion because it betrays two fundamental attitudes of society to risk.

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.

[dasil003]

You're conflating two things, inappropriately in my opinion:

> 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.

[dllthomas]

No, security is about trade-offs. If you throw absurd resources toward protecting against entirely unrealistic threats and your company goes out of business, you've failed. If you have legitimately made the risks small enough, for the resources and threat model (and that threat model sufficiently matches reality), you've succeeded. There are of course some legitimate caveats, including talk of externalities and questions about how one would measure things, but I still assert my basic model is more correct than yours.

Recognition that security is only as strong as the weak link does not imply that all links must be infinitely strong.

[darkarmani]

> So skimping on security is always a terrible idea. If you know of a way to increase security, then you should increase it.

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.

[at-fates-hands]

>>> You can make guesses as to the expected resources of the attacker, but if you're wrong and the attacker has more resources, then you might as well have not even bothered.

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.

[ogreyonder]

Almost by definition, there is only a secure access continuum for known points of attack. Once you breach the access layer--no matter how it's done--the game is 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.

[dllthomas]

Defense in depth is an important principle, and compromise of some but not all layers could be said to form something of a continuum, but I think a stronger case is that odds of a breach forms a continuum.

[droopybuns]

I want to address your edit:

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.

[nraynaud]

It might simply be that they want to get some bugs first, then others later?

[dpeck]

> Why even have a limited scope on bounty programs?

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.

[eli]

Well of course there have to be rules. Does spear phishing employees email accounts and using their password to access control panels count as a bug? I bet I could hack a lot of companies that way. Does being susceptible to a massive DDoS count as a bug? Cutting power to the building?

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.

[davorak]

A simple rule of thumb seems to be is, does it cause a problem if all the bug bounty hunters take the same approach.

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.

[fleitz]

Yes, it does. Customers do not care how the intruder got in only that they got in. Spearfishing is an attack that makes the company look dumb. Leaving the credentials for your source code on the web makes you look even dumber.

To qualify for the bug bounty he should have inserted code into their codebase and then exploited that. Fuck these guys.

[dllthomas]

Flooding communications channels (in particular, mental bandwidth of front-line employees) with attempts to spearfish is an attack that interferes with operations even when unsuccessful. It does not make sense to ask the world at large to persistently try such attacks.

This case is not like that, though.

[tantalor]

> Does spear phishing employees email accounts and using their password to access control panels count as a bug?

Yes, because those control panels should require 2FA, so password-only access is a bug.

[ars_technician]

2FA is susceptible to spear phishing if all the attacker needs is a one time login.

Remember that credentials and tokens can be relayed.

[tantalor]

Not necessarily. FIDO fixes this.

http://www.fidoalliance.org/user-experience.html

[ars_technician]

How? A phishing site can relay any of this information by acting as a client to the real site while prompting the end user for the requested credentials.

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.

[tantalor]

With FIDO, the user doesn't manually enter a 2FA token into a form field. Instead they press a button or something which directly transmits the token over SSL to the authentication server.

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/

[nostrademons]

Large tech companies routinely run pentest exercises against themselves that involve phishing their own employees. Good security has to include educating the human element as well: if you have great technical security but all you have to do to get in is ask an employee their password, you've lost.

Large companies also invest significantly in protection against massive DDoS and power cuts to the building, along with drills for earthquakes and zombie apocalypses.

[eli]

I wasn't trying to say those things aren't really security problems... just that they perhaps aren't things you'd want random people on the internet attempting to exploit.

[danielweber]

They also control the rate at how their own employees get phished, especially if they want the employees to report any suspicious attempts. Constant barrages from outsiders will make the employees stop reporting.

[columbo]

I can see why they would want to set up rules instead of allowing anything to happen.

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.".

[jarrett]

Your point is good. I'd solve the problem like this: Instead of whitelisting certain kinds of attacks and parts of the company for bounty eligibility, I'd create a very limited blacklist. This blacklist would consist of actions which, despite being good-faith security research, would cause unacceptable damage to the company. For example, blacklisted actions might include:

- 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.

[jbverschoor]

Well, this social engineering is what got kevin mitnick in jail

[mpeg]

I think it's ridiculous, I've reported similar "out of scope" bugs and got no bounty for them.

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.

[kitsune_]

Sorry, I have some problems with this attitude of expecting a reward for each and every action that benefits other human beings. Whatever happened to altruism?

[mpeg]

I don't think you understand, it's not about a reward; it's about having a clearly defined process to report security bugs that is inclusive of every kind of bug.

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"

[jablan]

Since when the word "altruism" applies to corporations? I believe that word is intended to relate to people, not businesses.

[azernik]

Often this is to keep from having to pay out for bugs you can't fix (the most common things to be out of scope are third party services). In this case the problem was actually on Prezi, but I imagine the rule was written to exclude bugs in their version control system from the bounty program.

[tlrobinson]

The only reason I see is if you provide immunity in exchange for following the rules you don't want to allow actions that can degrade your service like DDoSing, online brute forcing, vulnerability scanners, etc.

That doesn't really apply in this case though.