Hacker News Reader

Comment by tptacek | Hacker News Reader

These seem like pretty standard bug bounty terms. "Find bugs, but don't disrupt production systems trying to exploit them to find more".

The last bullet addresses a problem everyone has with bounties and scanners, which is that (a) they don't work and (b) they generate loads of bogus findings that the people who pirate the scanners then demand bounties for.

View on HN

Yeah, I don't understand why the bug bounty programs have you use the live site, and not say, a clone of said site on a sub-domain and isolated servers, with fake customer data and flights populated so you can just have at it.

Because that's expensive and time-consuming to set up, and the ROI is often not there compared to spending those same resources on professional help.

Also, be careful what you wish for. A bug bounty that doesn't come with rules of engagement for a staging site to test is one that gives you permission to test the company's real properties. A bug bounty with staging server rules of engagement is one that doesn't, and you can be sued or even prosecuted for hitting the real servers in that case.

As a rule, big companies with bug bounties are never relying on those bounty programs. When a giant company announces a bug bounty in 2015, they're outing themselves as early adopters (relative to the F500); they'll have been spending buttloads of money on pentesting already.

It's basically an additional QA or acceptance environment, capacity being a fraction of what is running live, that's no more costly and time consuming really then all the effort it takes to setup a bug bounty program, and you can get far more useful take aways from it if they can fully red team it. If someone finds an exploit that takes down the system or compromises account data, no real data or systems are at risk, no more so then they would be to actual malicious users.

The rules of engagement would obviously limit you from testing the real properties and restrict you to said servers that are completely isolated from the working production environment. DDOS attacks would be things that hang the application, or database, not simply flooding it with bot requests. Then they could do code injection, etc.

I spent 10 years negotiating for complete staging environments for professional pentests, on engagements with a median price somewhere in the mid-5-figures, and we rarely got them. Whatever you may think about the simplicity of setting up staging environments on a message board, they are empirically not easy in the real world.

There was no correlation between how savvy the target was and how likely they were to have staging environments for us. The modal organization that gave us a complete staging environment tended to be back-office IT for some huge company. Smart startups virtually never did.

One reason for this is that the environment a pentester needs is different from the one a developer needs. Large portions of the production environment can be stubbed out for a developer, and they can still get testing work done by focusing on their own component. Virtually every part of the environment needs to work, the way it does in prod, for a tester to do their job.

I'm still unclear on why code injection is such a big deal. The company isn't saying you can't test for vulnerabilities that lead to code injection. They're saying you can't actually inject code. There are two reasons you might, as a tester, want to do that: first, to "pivot" through the target to find more vulnerabilities, and second, to confirm a sev:hi flaw.

Neither of those goals are important here, as long as the company is good about acknowledging prospective sev:hi flaws.

Also, it adds ongoing costs to change management, as now you have to modify two environments for each change, test two environments, ensure data is refreshed into your non-prod environment (while ensuring you don't use production data in it), monitor two environments, pay licensing and support costs (hardware and software) for two environments, etc.

Having a secondary 'test' environment isn't as easy as 'oh just clone the VMs'.

To me it reads as a list of vulnerabilities they are guaranteed not to find.

Reminds me of the guy who found the starbucks gift card exploit and decided to test it live. That got him the lawsuit.

Only way to be sure it exists is to test it live.

That is rarely true, and also besides the point: if you report the flaw and they acknowledge it, what does verification matter?

Not only did he test it live, but he used the gift card to purchase items. Could have easily walked in and checked the balance without purchasing anything.

To be fair, his purchase was relatively inexpensive, did not significantly disrupt other customers or otherwise compromise the system, and served to test that the balance was actually available, not just displayed.

Just deduct the price of the sandwiches from the bounty reward?

He never 'got a lawsuit.' Instead, he got some comments from the contact to whom he reported it that criticized his approach. It's not even clear just who this person was. It seems he had trouble locating a contact to report security issues to, so this may as well have just been a low level support rep who was in over his head and saying things he shouldn't have.

"The hardest part - responsible disclosure. Support guy honestly answered there’s absolutely no way to get in touch with technical department and he’s sorry I feel this way. Emailing InformationSecurityServices@starbucks.com on March 23 was futile (and it only was answered on Apr 29). After trying really hard to find anyone who cares, I managed to get this bug fixed in like 10 days.

The unpleasant part is a guy from Starbucks calling me with nothing like “thanks” but mentioning “fraud” and “malicious actions” instead. Sweet!" http://sakurity.com/blog/2015/05/21/starbucks.html

Reply on news.ycombinator.com