9 ms·

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,

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.

eli 13y ago
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.
- fleitz 13y ago
  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 13y ago
    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.
- davorak 13y ago
  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 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.
- tantalor 13y ago
  > 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 13y ago
    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 13y ago
      Not necessarily. FIDO fixes this. http://www.fidoalliance.org/user-experience.html http://www.fidoalliance.org/user-experience.html
      - ars_technician 13y ago
        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 13y ago
        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/whitepaper.html#tls http://www.google.com/intl/en/chrome/browser/privacy/whitepa... [2] http://www.browserauth.net/ http://www.browserauth.net/
- nostrademons 13y ago
  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 13y ago
    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 13y ago
    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.
RyanZAG 13y ago
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 13y ago
  '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 13y ago
    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.
columbo 13y ago
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 13y ago
  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 13y ago
  Well, this social engineering is what got kevin mitnick in jail
deleted 13y ago
[deleted]
- moocowduckquack 13y ago
  This is a no-brainer. Surely the risk of putting off skilled people from your bug bounty program due to the press from this could cost you a lot more than $500.
  - deleted 13y ago
    [deleted]
    - jessaustin 13y ago
      Someone at your company should probably be thinking about Prezi's reputation. That person should probably have a discussion with whomever is running the bounty program.
    - moocowduckquack 13y ago
      Bug bounties have a purpose and it is not to generate press or to be an equality outreach program. It is to find bugs. If the rules are getting in the way of what the organisation is actually trying to use those rules for, then to be a stickler for rules is nuts when the same organisation wrote the rules in the first place and can change them at will. edit - and if it is neccessary due to corporate legal waffle to always be a stickler for rules, then make a rule that details the protocol for exceptions.
- timje1 13y ago
  Someone that hacks your systems won't be limited to a single system or domain, I don't see why your reward system should be. Would you rather that vulnerabilities discovered in out-of-scope systems be sold on forums instead?
- tallanvor 13y ago
  It seems that he pointed out a security vulnerability in your infrastructure - something you do have control over. And if a vulnerability is found in an external service you use, do you feel that you don't have a responsibility to mitigate the risk posed by the service whether or not you have direct control over it?
dpeck 13y ago
> 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.
mpeg 13y ago
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_ 13y ago
  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 13y ago
    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 13y ago
    Since when the word "altruism" applies to corporations? I believe that word is intended to relate to people, not businesses.
azernik 13y ago
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 13y ago
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.

eli 13y ago

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.

fleitz 13y ago
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 13y ago
  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.
davorak 13y ago
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 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.
tantalor 13y ago
> 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 13y ago
  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 13y ago
    Not necessarily. FIDO fixes this. http://www.fidoalliance.org/user-experience.html http://www.fidoalliance.org/user-experience.html
    - ars_technician 13y ago
      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 13y ago
        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/whitepaper.html#tls http://www.google.com/intl/en/chrome/browser/privacy/whitepa... [2] http://www.browserauth.net/ http://www.browserauth.net/
nostrademons 13y ago
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 13y ago
  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 13y ago
  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.

RyanZAG 13y ago

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 13y ago
'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 13y ago
  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.

columbo 13y ago

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 13y ago
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 13y ago
Well, this social engineering is what got kevin mitnick in jail

deleted 13y ago

[deleted]

moocowduckquack 13y ago
This is a no-brainer. Surely the risk of putting off skilled people from your bug bounty program due to the press from this could cost you a lot more than $500.
- deleted 13y ago
  [deleted]
  - jessaustin 13y ago
    Someone at your company should probably be thinking about Prezi's reputation. That person should probably have a discussion with whomever is running the bounty program.
  - moocowduckquack 13y ago
    Bug bounties have a purpose and it is not to generate press or to be an equality outreach program. It is to find bugs. If the rules are getting in the way of what the organisation is actually trying to use those rules for, then to be a stickler for rules is nuts when the same organisation wrote the rules in the first place and can change them at will. edit - and if it is neccessary due to corporate legal waffle to always be a stickler for rules, then make a rule that details the protocol for exceptions.
timje1 13y ago
Someone that hacks your systems won't be limited to a single system or domain, I don't see why your reward system should be. Would you rather that vulnerabilities discovered in out-of-scope systems be sold on forums instead?
tallanvor 13y ago
It seems that he pointed out a security vulnerability in your infrastructure - something you do have control over. And if a vulnerability is found in an external service you use, do you feel that you don't have a responsibility to mitigate the risk posed by the service whether or not you have direct control over it?

dpeck 13y ago

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

mpeg 13y ago

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_ 13y ago
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 13y ago
  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 13y ago
  Since when the word "altruism" applies to corporations? I believe that word is intended to relate to people, not businesses.

azernik 13y ago

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 13y ago

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.