Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
A lot of folks have been asking for a follow-up to the initial story I had published last month about my experience with the Uber /HackerOne Bug Bounty, so here it is.
To recap, Uber / HackerOne guarantees a $500 minimum payout for any in-scope security flaw or vulnerability discovered on their Internet-facing web and mobile applications. There are loopholes to this though, as Uber can classify a disclosed vulnerability as “informative”, meaning that the impact of the security flaw or vulnerability is not significant enough to merit remediation; or, they can claim that a security flaw or vulnerability had already been discovered prior to disclosure, which gets them out of making any payment. As of the date of this article, that initial post has garnered over 287K views and with 2.2K+ fans, which isn’t too shabby given the 30 minutes or so it took to pen the article.
“OAuth recommends that access token lifetime is very short, only as long as necessary depending on the risk associated with the token leaking. Examples given are minutes to hours.”
In November 2017 I had submitted a first round of security issues to the Uber team that were within scope of their publicly-stated bug bounty rewards program, such as a lack of certificate pinning in the Uber Microsoft Surface / Windows Phone app as the Uber Bug Bounty Treasure Map specifically advises security researchers to “look for” issues related to endpoint cn.uber.com which “is a RESTful API performed over certificate-pinned HTTPS requests”.
Seems simple. Uber says all requests are certificate pinned, the Uber Surface app doesn’t perform certificate pinning, this is a violation of Uber’s own publicly-stated security policy, at least the minimum guaranteed $500 bounty should be awarded. However, some 14 days after the initial submission, the report was closed out as “informative” by Rob Fletcher @ Uber with his statement that “[t]his limitation is already known to us and as such we’ll be closing this duplicate per our program guidelines”, followed by Uber updating the initial authentication process for the Uber Surface app to perform certificate pinning.
Or put another way, it took Uber’s engineering team two weeks to discover that they already knew one of their mobile apps wasn’t within their publicly stated security requirements, resulting in a denial of a guaranteed bug bounty award due to the issue having been “already known”, followed by remedial changes being made to the Uber Surface app shortly thereafter.
Then the issue of no bearer token expiration [1 2], which is a big one. On December 26, 2017, author of OAuth 2.0 Simplified and consultant on the protocol Aaron Parecki publicly chimed in on this issue, stating “OAuth recommends that access token lifetime is very short, only as long as necessary depending on the risk associated with the token leaking. Examples given are minutes to hours.” Within this context bearer tokens are used as a replacement for your account and password combination, and anyone who can get access to your issued Uber bearer token can then compromise all of your account particulars including payment details, trip history etc. Never mind OAuth’s recommended “minutes to hours” token expiration guidance, Uber isn’t expiring bearer tokens at all throughout their entire web and mobile application framework, which means that there are tens of millions of already-issued bearer tokens just hanging out waiting to be discovered by the bad guys; and oh-by-the-way, per Uber’s own engineering department, those tokens can’t be expired without a manual user-initiated password change due to a fundamental design flaw within Uber’s entire authentication framework.
“HackerOne is not able to view the contents of reports, as it’s meant to be kept private between yourself and the program. This is done so the report’s information is kept between the team and you for an additional layer of security.”
In the event of a dispute about bug bounty awards, security researchers can request a mediation from HackerOne, which I did on these subjects.
HackerOne’s first response:
Shay (HackerOne)
Hello Greg,
Thank you for reaching out to us with this concern. I am sorry to hear that you do not agree with the way this report was closed. When you have a signal of 1 or above you will have access to the feature we call Hacker Mediation. This will allow for HackerOne to reach out to the team on your behalf regarding reports that you have not been able to reach an agreement with the program on. At this time we do encourage you to contact the team with your concerns about this report and let them know why you feel it is a valid bug.
Cheers and Happy Hacking,Shay
I respond that HackerOne’s mediation page says nothing about a “signal” requirement, whatever that means, followed by:
Kevin Rosenbaum (krosenbaum) (HackerOne)
Hey Greg,
I am sorry you are having a negative experience with this issue, but we have contacted the Uber App Sec team and they have confirmed with us that these are not security issues that are in scope on their program. I understand that this can be a disappointment but I can assure you that they looked at this report and gave it the proper attention it deserved. I hope you can continue to work on our site and I wish you the best of luck.
Cheers,Kevin
I then submit a series of additional reports [1 2 3] to Uber / HackerOne which are in-the-OWASP-Top-10 and Content Security Policy 2 critical severity findings, such as the ability to render arbitrary web pages and secure forms from the m.uber.com mobile endpoint, all protected by Uber’s signed SSL certificate, and the ability to execute arbitrary JavaScript from any *.cloudfront.net host that I could easily provision from my Amazon Web Services console.
In response, on December 22, 2017 Lindsey Glovin states that “Hey @gregperry, we were able to verify that by hosting javascript at a domain in our CSP whitelist that you would indeed be able to execute Javascript, making this reflected XSS in m.uber.com. Unfortunately, we also found this to be a duplicate of report #276134. Either way, thanks for the reports and good luck bug hunting in the future!” So Uber didn’t actually verify the second critical security flaw as valid until December 22, 2017, but somehow there is an undisclosed duplicate report that covers the issue? And, I had to provide Rob Fletcher with a working proof-of-concept exploit in order to prove a vulnerability that they steadfastly alleged was not a vulnerability, until I send them a WAF-evaded POC that effectively compromises their entire mobile endpoint? Followed by Uber then fixing the issues literally on Christmas Day, but not in response to the reports I had filed? Huh?
Back to HackerOne mediation. Conference call with their staff.
Them: Yes Uber definitely knew about this issue prior to you reporting it, and it was a mere coincidence that they fixed the issues in question shortly after you filed those reports, as those fixes had already been scheduled by Uber for remediation due to the previous report that we have not yet disclosed.Me: No that’s not possible because this testing was not the result of some canned vulnerability scanner, but rather several days-worth of manual traffic analysis and interception proxy testing of the m.uber.com mobile endpoint. And what about Lindsey Glovin’s statement in Report #296701 that their staff didn’t even verify arbitrary JavaScript execution until December 22, 2017? Did Uber invent a self-driving time machine?Them: Ok, we will get back with you next week with our findings.
On a side note, I also mention during this call the facts that 1) after the second round of reports had been submitted to Uber, someone at HackerOne then disabled (as to my account only) the ability to submit any further reports to the Uber Bug Bounty; and 2) at no point during the second round of report submissions did I request or agree to disclose those reports (not that I wouldn’t have, I just didn’t feel like bothering with any of Rob Fletcher’s report disclosure requests on Christmas Eve), but HackerOne went ahead anyway and allowed Uber to make those reports public two days later without my consent, in contravention to their report disclosure guidelines which require mutual consent for any disclosure with a 30 day wait period.
The following week, some correspondence with Kevin Rosenbaum:
Gregory Perry (gregoryperry)
Hello Jon,
Requesting a final disposition and decision from HackerOne on these three critical security vulnerabilities disclosed to Uber. I haven't received any type of supporting documentation from HackerOne or Uber related to Report #276134 that was purportedly discovered prior to our submissions, which is pretty unreasonable given the amount of time and resources we dedicated to Uber over the last month on this bug bounty project.
Thanks in advance,
Gregory Perry
-----
Kevin Rosenbaum (krosenbaum) (HackerOne)
Hey Greg,
Just to give you an update on this, I am waiting for Jon and I to get access to this report and then we will be reviewing this case and we will take some time to reach a decision. Jon is also off until friday so we would be contacting you on Monday at the earliest. If you need any more help with this please feel free to talk to me at any time.
Thanks Again for your Patience and Understanding,Kevin
-----
Gregory Perry (gregoryperry)
Hey there Kevin,
How do you guys not have access to your own HackerOne report?
Am I missing something in this process?
Greg
-----
Kevin Rosenbaum (krosenbaum) (HackerOne)
Hello Greg,
HackerOne is not able to view the contents of reports, as it's meant to be kept private between yourself and the program. This is done so the report's information is kept between the team and you for an additional layer of security.
Kind regards,Kevin
And, the final mediation decision from Jon Bottarini:
Jon Bottarini (jon_3kf8n) (HackerOne)
Hi Gregory,
Hope you had a nice new year! I’m back from vacation and am just getting caught up here with the updates to your case, apologies for the delay. In regards to the Uber report #276134, Uber granted us access to the report and I’ve reviewed it to determine if there is any overlap with your reports #300080, #300101, #300102, and #300103.
Based on the information you provided as well as the information contained within the original report, I can say with complete certainty that Uber was already aware of the issues you presented within your reports prior to you reporting them. We wanted to make sure that the original report was in the process of being investigated before you reported your issues to the team. The team was able to confirm this with us by providing us screenshots showing us code commits that were directly related to the original report.
I know this was not the desired outcome, however we would love to talk through any other concerns you may have about this process if you so desire. We are available to talk with you at your convenience if you wish to discuss this further. In regards to your questions regarding the Spotify reports, I will need some time to review them and determine why they were closed.
Thanks again for your patience,
Jon BottariniTechnical Program ManagerHackerOne
That report and all its findings are still locked and can’t be viewed by me and the public.
“HackerOne on the other hand was supposed to be the nonpartisan, objective intermediary in this situation, but provably did the exact opposite.”
Uber is Uber, and no changing of the guards short of firing their entire staff is going to make one bit of a difference with their corporate culture, business operations, and overt willingness to be deceitful when it benefits their bottom line to do so. Why a $50 billion dollar corporation would publicly degrade itself with these kind of nickel and dime shenanigans is beyond me, but ultimately speaking it’s fairly obvious that Uber’s security group has made significant errors during growing their enterprise architecture, but are reticent about implementing any corrective remedies beyond their boom/bust cycle of product engineering coupled with free security consulting services provided by HackerOne’s bug bounty program. A well-respected fellow in the security community that I worked with in the past but have since fallen out of touch with probably said it best during a similar series of events many years ago, when a penetration testing report that I delivered to a client had everybody in the room fuming by the end of the presentation: security auditing is 90% the subtle art of calling someone’s baby ugly and only 10% the technical details, so don’t ever expect your report and findings to be accepted with accolades and open arms.
HackerOne on the other hand was supposed to be the nonpartisan, objective intermediary in this situation, but provably did the exact opposite. They knowingly violated the terms and conditions of at least two of their own program guidelines, followed by some mumbo jumbo about how they couldn’t see or review their own report, and then issued a nonsensical determination of the facts as the result of having read and analyzed a report that is not, nor will it probably ever be, publicly disclosed.
The final straw was two subsequent reports that I had submitted on January 7, 2018 to a completely different program, this time for the Spotify Bug Bounty, and related to the ability to completely bypass Spotify’s entire CSRF token issuance process thus resulting in any Spotify user account being able to be accessed and/or modified after a user had logged out, using nothing more than a single cookie and mobile user agent:
Using a Galaxy S5 mobile client, a user login was performed to the https://accounts.spotify.com mobile web interface, followed by viewing the account information page for the logged in account via https://www.spotify.com/us/account/overview/.
The user was then logged out of the account.
Using the previously issued cookie authentication credentials, all user account information was still able to be accessed at https://www.spotify.com/us/account/overview/ by asserting a mobile user agent with https://accounts.spotify.com referer:
User-Agent: Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Mobile Safari/537.36
Multiple successive GET requests were then sent to https://www.spotify.com/us/account/overview/ using the previously issued authentication credentials listed above, with each successive request reducing the cookie parameters to determine which parameter was being used for user authentication.
Ultimately all information related to the logged out user account was able to be accessed using only the authentication credentials associated with the sp_dc cookie variable; the spsess, spot, sp_t, spAnalytics_id, _ga, _gid, sc.ASP.NET_SESSIONID, _gat_UA-5784146-31, sp_bon. __bon, sp_t, sp_bon, spsess. and spot cookie variables are not required for accessing the https://www.spotify.com/us/account/overview/ endpoint post-logout, apparently as the result of asserting a mobile user agent (using the same expired authentication credentials for the logged-out user with a Chrome desktop browser, the user is redirected to https://accounts.spotify.com/en-US/login).
For example:
curl -i -s -k -X 'GET' \ -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Mobile Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8' -H 'Referer: https://accounts.spotify.com/en-US/login?continue=https:%2F%2Fwww.spotify.com%2Fus%2Faccount%2Foverview%2F' -H 'Accept-Language: en-US,en;q=0.9' -H 'Cookie: domain.viq=spotify; sp_dc=<INSERT COOKIE HERE>' -H '' \'https://www.spotify.com/us/account/overview/'
This time, HackerOne first sandboxed both reports so that they would not be submitted to Spotify, while dispatching completely with any real names or contact particulars for the responding HackerOne individuals that were tasked with review of the sandboxed reports.
The first response by HackerOne was from chocolatechipmuffin, who expressed difficulty understanding the impact of a CSRF token bypass, followed by closing out the report without providing it to Spotify. Despite the curl POC, chocolatechipmuffin then requested a more detailed exploit to be provided, while apparently not paying attention to the Spotify Bug Bounty program guideline that:
“This does not mean you need to fully exploit issues, just provide the information you have, and we will analyze your report and draw conclusions on the impact.”
Second response was from chessmast3r, who “…would like to see POC with any authenticated state changing action with impact.” Again, no submission to Spotify even after the curl POC which demonstrates the entire CSRF bypass, and without paying attention to the no “need to fully exploit issues” requirement of their program guidelines.
Third response is from HackerOne staff joystick, who requests for me to “provide a working exploit”, followed by then closing out the second report without providing any of the details to Spotify, and then penalizing my “signal” so that I would not be able to submit further reports.
“In the background, every keystroke typed — even if you backspace or erase content in the form — is being silently relayed back to HackerOne.”
HackerOne is an intelligence gathering operation, used to profile persons of interest that are involved with offensive penetration testing and vulnerability analysis pursuits, plain and simple. HackerOne’s bug bounty reporting platform contains extremely valuable information related to the most recent offensive exploitation techniques that are being used to compromise networks and systems — paired with repeated requests from anonymized staff members for exploits to be provided with report submissions, even when individual company program guidelines dictate otherwise— and that information is without question being aggregated across the entire HackerOne reporting platform and then brokered to whatever organizations HackerOne is partnered with on the backend. Weaponized exploits are in some instances priceless, depending on the category and vector of attack, and HackerOne’s goal likely has little if anything to do with revenue generated from these bug bounty programs.
To whit: the HackerOne reporting platform utilizes surreptitious keystroke logging capabilities whenever a security researcher interacts with the various forms used for reporting. Go ahead, see it for yourself: create an account at HackerOne, fire up an interception proxy, and then watch the traffic back and forth whenever you are filling out their reporting forms. Behind the scenes, every keystroke you type — even when you backspace or erase content in the form — is silently being transmitted to HackerOne in the background. So if, for example, you are in the habit (as I frequently am) of pasting a full page of text into a form for editing and proofreading, the entire contents of that pasted clipboard are encrypted and immediately sent to HackerOne for analysis before you hit the submit button, irrespective of any information that you may have modified or deleted from the form prior to submission.
Truth be told, these bug bounty awards are just occasional lottery payouts to select members of the HackerOne publicity team, which in turn attracts free security testing talent in a similar vein to chaos engineering disciplines of distributed systems fault testing. Throw enough attacks at an enterprise network and eventually something is going to break; remediate, lather, rinse, repeat. No doubt Uber benefits from the HackerOne bug bounty program, as they likely receive hundreds of thousands of dollars worth of free security consulting services on a monthly basis as the result. HackerOne is crowdfunded charity smoke testing, and the only thing their clients have to do is write the occasional check for an unpublished report to a member of HackerOne’s PR team in order to keep their bait-and-switch bug bounty carrot dangling.
Like Aesop’s fable of the farmer and the snake, I knew or should have known better than to get involved with anything Uber, but did so anyway based upon the supposed credibility of HackerOne paired with their advertised minimum payout bug bounty guarantees. As the astute reader can easily discern from the facts and circumstances above, things are not as they appear with either character in this sequence of events, and life is short so I won’t be doing any future business with #DeleteUber or HackerOne as the result.
https://medium.com/bread-and-circuses
Uber / HackerOne Bug Bounty Post Mortem was originally published in Bread and Circuses on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.