5 ms·

Being involved in bug bounties, don't be fooled by what happened here. This is exactly a case of extortion: the hacker had downloaded user data from Uber, and w

by cablej 9y ago

Being involved in bug bounties, don't be fooled by what happened here. This is exactly a case of extortion: the hacker had downloaded user data from Uber, and was paid off in order to delete the files. This differs from an actual bug bounty payout, where a hacker would be disqualified for extracting user information.

SilasX 9y ago
But judging from how they weasel out of paying bug bounties, this may be the only way to get them to pay anything!
- dominotw 9y ago
  Extortion is always wrong.
- julianj 9y ago
  According to Hackerone they've paid out quite a few bounties. I am not sure if this total includes the 100k in question though. Total bounties paid $1,345,845 https://hackerone.com/uber https://hackerone.com/uber
  - fstuff 9y ago
    It's the 100k paid out to this guy included with that number? Just curious
  - r3bl 9y ago
    The minimum payout matches the average payout at $500. Highly doubt 100k is included in there.
BRAlNlAC 9y ago
According to the article "Other emails obtained by The Times show Mr. Fletcher treated the incident as a bounty and encouraged Preacher to provide proof of the vulnerability, including sending a few lines of data from the database he had breached." So no, this was not disqualifying and he was told to do so. This is not extortion, just pay negotiations.
- nyolfen 9y ago
  alternately: your read on it is precisely why he phrased the email this way, understanding the gravity of the situation and hedging if the email conversation ever became public.
charleslmunger 9y ago
Yeah, I'm disappointed that the article didn't focus more on that distinction - "send us a snippet from our production database" is not really how responsible programs operate. Compare this story with a similar severity facebook bug: > That's right, the response contained Facebook's /etc/passwd. Now we were going somewhere. By then I knew I had found the keys to the kingdom. After all, having the ability to read (almost) any file and open arbitrary network connections through the point of view of the Facebook server, and which doesn't go through any kind of proxy was surely something Facebook wanted to avoid at any cost. But I wanted more. I wanted to escalate this to a full Remote Execution. > A lot of bug bounty programs around the web have a rule that I think is very sensible: whenever you find a bug, don't linger on messing around. Report the bug right away and the security team will consider the worst case scenario and pay accordingly. However, I didn't have much experience with the security team at Facebook and didn't know if they would consider my bug as a Remote Code Execution or not. I Since I didn't want to cause the wrong impressions, I decided I would report the bug right away, ask for permission to try to escalate it to a RCE and then work on it while it was being fixed. I figured that would be ok because most bugs take a long time to be processed, and so I had plenty of time to try to escalate to an RCE while still keeping the nice imaginary white hat I have on my head. So after writing the bug report I decided to go out and have lunch, and the plan was to continue working when I came back. https://www.ubercomp.com/posts/2014-01-16_facebook_remote_code_execution https://www.ubercomp.com/posts/2014-01-16_facebook_remote_co... That's the difference between paying a ransom and a bounty.
droopybuns 9y ago
I’ve been involved on the payout side of the equation. I disagree with your position. BB’s are complicated and can be messy. You never know what the behavior of the participant will be after the award. Someone had to fight for approval of this payout at significant career risk for themselves. If we broadly assume bad faith on the reporter or on the recipients, we’ll lose the protection that bb’s can provide and white hats will be more at risk of CFAA prosecution. We need to be more willing to make mistakes when it comes to these situations.
- mannykannot 9y ago
  > Someone had to fight for approval of this payout at significant career risk for themselves. I think that, in this case, it is more likely that someone was told, or felt it to be the case, that their career or options were at risk unless they could come up with some sort of cover so that Uber could claim it did not have to disclose the leak. There is a simple test for whether someone is seeking a bug bonus, or to extort you: if someone says he has a way to get your data and would you care to know how, its a BB case, but if they say they have your data, give us some money to say we deleted all copies of it, that's extortion.
013a 9y ago
To be honest, its very hard to tell from the article. I get the feeling Uber is covering something up. The hacker definitely downloaded files, but Uber also asked him to download production data to confirm the hack (um, what?) Uber escalated the payout; the hack wasn't particularly interesting, but it was substantial, so who knows there. The hacker's communication was dodgy, but he eventually met in person, and the fact he didn't want to leave his house indicates a possible social disorder. Their handling was poor, but this may just be a case of "hating uber because they're uber".
- daveFNbuck 9y ago
  Uber's story doesn't make any sense. In what world does "you published your passwords on GitHub" get a response of "prove it by using them"?
  - monocasa 9y ago
    IDK, it seems to fit the frat bro culture I've come to expect out of Uber. "Oh yeah? Then fucking do it then", seems fairly Uber.
  - whack 9y ago
    In any sufficiently large corporation, there are so many different accounts/credentials floating around, that it's hard for anyone to keep track of them all. It's possible that the engineering team may have already invalidated the credentials that were published on GitHub. It's possible that those credentials were actually a bait, meant specifically to distract potential hackers. Asking for proof is a very quick and easy (and sloppy) way to get around all of the above.
    - daveFNbuck 9y ago
      Private user information isn't proof that valid credentials were published on GitHub. It would be faster and easier to ask for actual proof in the form of a link to a valid credential published on GitHub, and that would actually prove that they were published.
asabjorn 9y ago
Although it is in your right to keep holding the same opinion when new evidence shows that it is probably wrong, that is not a virtue. Sadly this is a core part of discourse in the Bay Area and American society at this point, which I believe contributes to people’s inability to connect well and develop shared empathy.

by cablej 9y ago

SilasX 9y ago

But judging from how they weasel out of paying bug bounties, this may be the only way to get them to pay anything!

dominotw 9y ago
Extortion is always wrong.
julianj 9y ago
According to Hackerone they've paid out quite a few bounties. I am not sure if this total includes the 100k in question though. Total bounties paid $1,345,845 https://hackerone.com/uber https://hackerone.com/uber
- fstuff 9y ago
  It's the 100k paid out to this guy included with that number? Just curious
- r3bl 9y ago
  The minimum payout matches the average payout at $500. Highly doubt 100k is included in there.

BRAlNlAC 9y ago

According to the article "Other emails obtained by The Times show Mr. Fletcher treated the incident as a bounty and encouraged Preacher to provide proof of the vulnerability, including sending a few lines of data from the database he had breached." So no, this was not disqualifying and he was told to do so. This is not extortion, just pay negotiations.

nyolfen 9y ago
alternately: your read on it is precisely why he phrased the email this way, understanding the gravity of the situation and hedging if the email conversation ever became public.

charleslmunger 9y ago

Yeah, I'm disappointed that the article didn't focus more on that distinction - "send us a snippet from our production database" is not really how responsible programs operate. Compare this story with a similar severity facebook bug: > That's right, the response contained Facebook's /etc/passwd. Now we were going somewhere. By then I knew I had found the keys to the kingdom. After all, having the ability to read (almost) any file and open arbitrary network connections through the point of view of the Facebook server, and which doesn't go through any kind of proxy was surely something Facebook wanted to avoid at any cost. But I wanted more. I wanted to escalate this to a full Remote Execution. > A lot of bug bounty programs around the web have a rule that I think is very sensible: whenever you find a bug, don't linger on messing around. Report the bug right away and the security team will consider the worst case scenario and pay accordingly. However, I didn't have much experience with the security team at Facebook and didn't know if they would consider my bug as a Remote Code Execution or not. I Since I didn't want to cause the wrong impressions, I decided I would report the bug right away, ask for permission to try to escalate it to a RCE and then work on it while it was being fixed. I figured that would be ok because most bugs take a long time to be processed, and so I had plenty of time to try to escalate to an RCE while still keeping the nice imaginary white hat I have on my head. So after writing the bug report I decided to go out and have lunch, and the plan was to continue working when I came back. https://www.ubercomp.com/posts/2014-01-16_facebook_remote_code_execution https://www.ubercomp.com/posts/2014-01-16_facebook_remote_co... That's the difference between paying a ransom and a bounty.

droopybuns 9y ago

I’ve been involved on the payout side of the equation. I disagree with your position. BB’s are complicated and can be messy. You never know what the behavior of the participant will be after the award. Someone had to fight for approval of this payout at significant career risk for themselves. If we broadly assume bad faith on the reporter or on the recipients, we’ll lose the protection that bb’s can provide and white hats will be more at risk of CFAA prosecution. We need to be more willing to make mistakes when it comes to these situations.

mannykannot 9y ago
> Someone had to fight for approval of this payout at significant career risk for themselves. I think that, in this case, it is more likely that someone was told, or felt it to be the case, that their career or options were at risk unless they could come up with some sort of cover so that Uber could claim it did not have to disclose the leak. There is a simple test for whether someone is seeking a bug bonus, or to extort you: if someone says he has a way to get your data and would you care to know how, its a BB case, but if they say they have your data, give us some money to say we deleted all copies of it, that's extortion.

013a 9y ago

To be honest, its very hard to tell from the article. I get the feeling Uber is covering something up. The hacker definitely downloaded files, but Uber also asked him to download production data to confirm the hack (um, what?) Uber escalated the payout; the hack wasn't particularly interesting, but it was substantial, so who knows there. The hacker's communication was dodgy, but he eventually met in person, and the fact he didn't want to leave his house indicates a possible social disorder. Their handling was poor, but this may just be a case of "hating uber because they're uber".

daveFNbuck 9y ago
Uber's story doesn't make any sense. In what world does "you published your passwords on GitHub" get a response of "prove it by using them"?
- monocasa 9y ago
  IDK, it seems to fit the frat bro culture I've come to expect out of Uber. "Oh yeah? Then fucking do it then", seems fairly Uber.
- whack 9y ago
  In any sufficiently large corporation, there are so many different accounts/credentials floating around, that it's hard for anyone to keep track of them all. It's possible that the engineering team may have already invalidated the credentials that were published on GitHub. It's possible that those credentials were actually a bait, meant specifically to distract potential hackers. Asking for proof is a very quick and easy (and sloppy) way to get around all of the above.
  - daveFNbuck 9y ago
    Private user information isn't proof that valid credentials were published on GitHub. It would be faster and easier to ask for actual proof in the form of a link to a valid credential published on GitHub, and that would actually prove that they were published.

asabjorn 9y ago

Although it is in your right to keep holding the same opinion when new evidence shows that it is probably wrong, that is not a virtue. Sadly this is a core part of discourse in the Bay Area and American society at this point, which I believe contributes to people’s inability to connect well and develop shared empathy.