Seems like acting nefarious is more profitable than doing the right thing.
I found Prezi's source code
151–160 of 266 posts
Re: I found Prezi's source code
#152[deleted]
Re: I found Prezi's source code
#153Anyone else notice that "Adam "'s full name and contact info are not redacted in the screen print of the email?
I removed the last names from the blog posts and from the PDF, as they could be indexed by Google. I have now also removed them from the screenshots. Thanks. My intention was not to negatively affect these developers careers.
Re: I found Prezi's source code
#154What is the gain in setting up a "Can you hack us?" and then make some parts out of scope?! It's not like a black hat hacker would go "Oh well, this isn't their usual domain, so It's not fair" -.- 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…
> What is the gain in setting up a "Can you hack us?" and then make some parts out of scope?! It's not like a black hat hacker would go "Oh well, this isn't their usual domain, so It's not fair" -.- 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 sur…
[deleted]
Re: I found Prezi's source code
#155Earlier quoted context omitted.
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 int…
'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 resource…
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.
Re: I found Prezi's source code
#156Why 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.
> 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.
Re: I found Prezi's source code
#157Why 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.
[deleted]
To be frank, this isn't some minor display bug, he had access your source.
In other words, this could have ended your company.
He could have sold or leaked it. If naivety is stopping you from grasping the possible consequences, then go ahead and read about Adobe's recent mishap.
You should be on your knees worshipping him.
Re: I found Prezi's source code
#158Earlier quoted context omitted.
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 int…
'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 resource…
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.
Re: I found Prezi's source code
#159What this guy describes doing (using accidentally exposed credentials to log in to somewhere) is quite a bit more than what other people have been successfully prosecuted for violations of the CFAA for. I'd be careful.
You mean that Prezi, a Hungarian company, would prosecute the author, an Australian, under an American law? The Internet isn't just something happening in the United States.
Oh, someone should tell the NSA that.
Re: I found Prezi's source code
#160It was out of scope. The rules are pretty clear: http://prezi.com/bugbounty/ and he broke at least two of them. 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 prett…
So because it was out of scope it means that it could not have harmed the company so he should have just left it there?
Exactly. Because it was out of scope, he should find a competitor and sell the access to the the source code!!!! :-P