Uber explains itself after 'moving the goalposts' on its new bug bounties It has been less than a week since Uber launched its bug bounty program and already security researchers are calling foul. The taxi app biz teamed up with HackerOne to run the scheme, which promises to pay out up to $10,000 for bugs, and 10 per cent loyalty bonus on top of that for those who submit five bugs or more. So …
I'll create a site where everyone can bring their bugs and security vulnerabilities and broker the leasing of them out to companies and individuals that want them, with surge pricing, and take a slice of the pie.
That's what's supposed to excite us these days, isn't it?
"[T]he rules were changed to stop researchers wasting their time on minor bugs".
This is not, in and of itself, unreasonable.
But the right thing to do would be pay for all the bugs already submitted that fall under the old rules. Minor amounts of cash, as the bugs are, but pay *something* to maintain good well.
But the right thing to do would be pay for all the bugs already submitted that fall under the old rules. Minor amounts of cash, as the bugs are, but pay *something* to maintain goodwill
The impression I get from this is that they got buried under bug reports to the point that they realised that paying out as originally indicated would cost them more than spending that amount on decent coding in the first place, which is the exact thing these bug bounty issuers seem to want to avoid.
If I appear to expect the worst from this company, it is simply because that's what their business behaviour so far has made me assume.
As a frequent participant in bug bounties.... I come across this often... and then some.
You either get :
a) This is not a bug - this a FEATURE!
b) We don't regarde this as a security risk
and
c) Oh that's out of scope now...
I remember I was testing a well known sandboxing program that was touting how it could stop cryptolocker dead in its tracks. It has a tick box which says "deny all internet access" for the sandboxed program, but what I found out was it forgot about SMB protocol so your sandboxed program could do bypass these restrictions like this: \\www.yoursite.com\fileyouwanthere$ and it bypassed the restrictions and went to fetch that file (not to mention the DNS queries were also treated so DNS exfiltration was allowed too). Response from vendor -> We know about this, it's supposed to be like that...
So I go back in and keep looking... find that I can keylog from processes that are OUTSIDE the sandbox from within it... ooh nice. Submit it -> Scope is suddenly changed to "Our sandboxing program is not supposed to protect against keyloggers"...
After that I found a way to pivot into a system level process outside the sandbox from within it, and you know what? I just thought "screw these guys" and just didn't submit it......
That's exactly the issue with slippery bug bounty rules.
If, as a company, you run a bug bounty scheme properly and pay for valid submissions (and then go and amend your code), you can improve your code.
If, on the other hand, you keep changing rules to dodge payments, many bounty hunters will think "screw it" - or worse: sell it elsewhere. The result is that security issues get out into the open, and the code of the site remains vulnerable. The company achieves the exact opposite of what bug bounty schemes are intended to achieve: they become more vulnerable, faster than they would if they didn't have any bug bounty scheme to begin with.
Uber, like many others, seem to think a bug bounty is a marketing stunt. Well, wait until it backfires.
"All the members of team running this program are part of the security community and many of us actively submit to other bug bounty programs..."
and they still somehow failed to "better define" the scope of the bounty program from day 0? either they are all incompetent or someone is full of shit.
These kinds of bug bounties are bullshit. There's no way a professional could make a living off what they pay. To use ubers analogy it's like standing on the corner of the street inviting all cabs to come and give you a ride, then telling them how much you will pay them, whilst selectively ignoring a few and then going for the ride that looks like what you wanted really.
There's no way a professional could make a living off what they pay.
Well, duh, that's exactly what such programs suggest to me: a way to AVOID getting a professional involved. Let's not spend any money on doing it right but patch as often as Microsoft afterwards, and we crowdsource the bug detection so we don't have to pay much.
That is, until it emerges that there are really a LOT of bugs, at which point you have two choices as a company:
1 - pay those who have found genuine bugs, admit you screwed up and start again
2 - change the goalposts, don't pay people and leave both the impression that you're both cheap and unreliable (no news here), and that your code has serious problems that you really, really don't want to talk about (which is what I read out of those changes).
Outcome 1 would have gotten my respect and would have been a hint that the company does have some idea of how to keep user details safe (such as person, address, travel routes and payment data), however, it appears outcome 2 is in play, which suggest you shouldn't touch these shyster's code with a 10ft barge pole. But hey, it's Uber. If outcome 2 is a surprise to you you really haven't been paying attention much.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
