The rules of the bug bounty program disallowed many of the usual red team approaches to finding possible exploits.
Attempting any of the following will result in permanent disqualification from the bug bounty program and possible criminal and/or legal investigation. We do not allow any actions that could negatively impact the experience on our websites, apps or online portals for other United customers.
.. Brute-force attacks
.. Code injection on live systems
.. Disruption or denial-of-service attacks
.. The compromise or testing of MileagePlus accounts that are not your own
.. Any testing on aircraft or aircraft systems such as inflight entertainment or inflight Wi-Fi
.. Any threats, attempts at coercion or extortion of United employees, Star Alliance member airline employees, other partner airline employees, or customers
.. Physical attacks against United employees, Star Alliance member airline employees, other partner airline employees, or customers
.. Vulnerability scans or automated scans on United servers (including scans using tools such as Acunetix, Core Impact or Nessus)
One can hope that the bad guys are similarly polite. And, as you would expect, the United security folks did not see the irony of their restrictions when it was pointed out to them.
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.
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'.
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.
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?
1. Don't do attacks all systems are vulnerable to. (DDOS, Brute force)
2. Don't fuck with our customers.
3. Don't fuck with our employees.
Sounds very fair for a company with hundreds of people hanging in the middle of the air at any given point in time.
It is not an audit or internal code review. This is bug bounty program. If you get to a position from where you can directly or indirectly affect live systems, you should stop there and report.
Any testing on aircraft or aircraft systems such as inflight entertainment or inflight Wi-Fi
I think this one and the "live system" one is due to legal regulations - they obviously do not want you to attempt to actually take control of a plane.
I think the "hack the plane through IFE" thing is nonsense but it still seems negligent to encourage people to try to break the electronics on a plane in the air, which is exactly what a bug bounty that qualifies findings in the IFE does.
Something to remember about every company that offers a bounty: they aren't just offering to pay for findings, but also implicitly granting permission to attack them, waiving many of their rights in the process. It makes sense that an airline would do that carefully.
Hack the inflight entertainment to display a scary action-movie ransom notice on every monitor in the cabin and see if you can't get the plane to go where you want.
Give me a million dollars and a Get Out of Jail Free card and I'll show you it's perfectly possible. If anything security teaches us, it's that everything is vulnerable if the attacker is determined enough.
I just plugged in my raspberry pi. It is air gapped and has no internet connection. Connect to it via SSH and I will be your personal servant for the rest of my life.
Yeah. And they have a huge surface area of non-customer-facing and/or abandoned servers which are off limits. They should be more concerned with that than someone gaming their mileage program.
I guess it's a way to dip their toes into the waters, because for good safe pen testing they would need to mirror their infrastructure and make a system for testers to create accounts on demands, which necessitate work.
Attempting any of the following will result in permanent disqualification from the bug bounty program and possible criminal and/or legal investigation. We do not allow any actions that could negatively impact the experience on our websites, apps or online portals for other United customers.
One can hope that the bad guys are similarly polite. And, as you would expect, the United security folks did not see the irony of their restrictions when it was pointed out to them.