5 ms·

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)

by 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.
  - freehunter 13y ago
    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.
  - dllthomas 13y ago
    "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 13y ago
      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.
- ogreyonder 13y ago
  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 13y ago
    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.
nraynaud 13y ago
It might simply be that they want to get some bugs first, then others later?
droopybuns 13y ago
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.

by RyanZAG 13y ago

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.
- freehunter 13y ago
  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.
- dllthomas 13y ago
  "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 13y ago
    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.
ogreyonder 13y ago
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 13y ago
  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.

nraynaud 13y ago

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

droopybuns 13y ago

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.