Bug bounty left over (and rant) Part III (Google and Twitter)

tl;dr in this blog post I am going to talk about some bug bounty left over with a little rant.

Here you can find bug bounty left over part I and II
Here you can find bug bounty rant part I and II

Introduction

In one of my previous post I was saying that:   

"The rule #1 of any bug hunter... is to have a good RSS feed list."

 Well well well allow me in this post to state rule #2 (IMHO)

"The rule #2 of any bug hunter is to DO NOT be to fussy with 'food' specifically with left over"

aka even if the most experience bug hunter was there (and it definitely was my case here, given the fact we are talking about no one less than filedescriptor) do not assume that all the vulnerabilities have been found! So if you want some examples here we go. 

Part I - Google

I have the privilege to receive from time to time Google Vulnerability Research Grant. One of the last I received had many target options to choose from, but one in particular caught my attention, namely Google Issue Tracker. The reason why I wanted to give a look at it was due the fact I recently read this blog post: How I hacked Google’s bug tracking system itself for $15,600 in bounties.  I was really impressed by the quality of this research so I thought I would give a look myself and guess what after about 5 minutes I found some little vulnerability in Google Issue Tracker (not of the same caliber as the other report though). This was indeed probably the easier and simpler and tinier vulnerability I ever reported but still :p 
 Basically the Google Issue Tracker has a "Copy comment to..." feature:

"Copy comment to..."

So basically if you are currently on an issue source you can copy comment number X to issue destination clicking the button above. This will generate a link of the form 

https://issuetracker.google.com/issues/destination?template_issue=source&template_comment=X 

and you will have comment X from source copied to destination. But hold on what does it happen if you do not have access to issue source? Well here was a little glitch that made anyone potentially knowing the number of comments existing in an issue without having access to that issue. But how?  Here is the self explanatory example:

• Navigate to https://issuetracker.google.com/issues/destination?template_issue=source&template_comment=4. Observe a read error message saying: "Issue b/source#comment4 does not exist"
• Navigate to https://issuetracker.google.com/issues/destination?template_issue=source&template_comment=1. Observe a read error message saying: "Access denied for: <MAIL_ADDRESS>".
• Navigate to https://issuetracker.google.com/issues/destination?template_issue=source&template_comment=2. Observe a read error message saying: "Access denied for: <MAIL_ADDRESS>".
• Navigate to https://issuetracker.google.com/issues/destination?template_issue=source&template_comment=3. Observe a read error message saying: "Access denied for: <MAIL_ADDRESS>".

Cool. This just told us that the issue  source has 3 comments (without us having reading access to the issue). Right?

Disclosure timeline

23-11-2017 - Awarded Google Vulnerability Research Grant
30-11-2017 - Started giving a look at  Google Issue Tracker
30-11-2017 (5 minutes later) - Reported issue to VRP
05-12-2017 - Google internal issue open
14-12-2017 - Google awarded a 500$ bounty

Part II - Twitter and rant

This issue was highly inspired by me reading this blog post from filedescriptor. In this post filedescriptor found an issue in the new OAuth 2 API in Periscope (little note, while I am a kind of OAuth 2 expert I still am not sure I understood this specific issue). Said  that this blog post made me curious about this new OAuth implementation hence I decided to give a look at it. This was indeed a great decision since I eventually found a sever issue in the implementation. I do not need to spend too much time talking about this issue since it is identical than some other one I previously found on Facebook, and Egor Homakov on Github. This issue is so "popular" that I dedicated a section on the book I co-wrote about OAuth 2:

Providing all those link and references I thought I'd have an easy time collecting a bounty and I opened an issue on Hackerone

As seen in https://hackerone.com/reports/215381 it looks like Periscope.tv implements the OAuth 2 specification.
The redirect_uri validation seems to be vulnerable.
As per https://hackerone.com/reports/215381 there is a OAuth call
https://www.periscope.tv/oauth?client_id=catbzQMNEwPxwfvEMqgMFHbNTcwWevGiDRWUaq3aHERZfgnCuy&redirect_uri=https://getmevo.com/oauth/periscope&error=true
The registered redirect_uri from client catbzQMNEwPxwfvEMqgMFHbNTcwWevGiDRWUaq3aHERZfgnCuy seems to be https://getmevo.com/oauth/periscope.
The Periscope OAuth server seems also to accept https://www.periscope.tv/oauth?client_id=catbzQMNEwPxwfvEMqgMFHbNTcwWevGiDRWUaq3aHERZfgnCuy&redirect_uri=https://getmevo.com/oauth/periscope/../../asanso&error=true.
and is indeed vulnerable to path traversal for the redirect_uri. You can see an example of a vulnerability I reported to Facebook that had the same: http://blog.intothesymmetry.com/2014/04/oauth-2-how-i-have-hacked-facebook.html.
The impact is the hijacking an access token that is indeed delivered to an attacker location

But this is was not the case :(

Disclosure timeline

28-08-2017 - Opened Hackerone report (see above)
29-08-2017 - Response from Twitter: "We're having some trouble following your report, can you elaborate on exactly what behavior you are reporting and how it leaks the access token..."
29-08-2017 - Gave more details
30-08-2017 - Response from Twitter: "Can you please provide an explanation and demonstration of the behavior you are reporting in your own words here, without linking to these other reports or copying from them..."
30-08-2017 - More info from me
31-08-2017 - Provide some pages of the book I co-wrote (see above)  that talk about this specific issue.
31-08-2017 - Response from Twitter: "As we stated previously, in order to take action on a report for Periscope, we require that you demonstrate an attack that is directed at Periscope specifically and can be actively reproduced....." Invalid issue and -5 points
31-08-2017 - Response from me: "Periscope is an OAuth server with a broken validation algorithm.
You do not have control of what is the setup and the domain of your potential OAuth clients...
And with this broken behavior you are putting your 'customers' at risk ."
01-09-2017 - I opened a new Hackerone issue referencing this issue and asking if someone with OAuth 2 knowledge can be assigned to the case
01-09-2017 - Request from Twitter to have more info
01-09-2017 - More info from me
01-09-2017 - Response from Twitter: "Please keep in mind that our HackerOne program does not accept theoretical or potential vulnerabilities, and requires that researchers demonstrate that the behavior they have found can be actively used in an attack against Twitter or its other in-scope services. Since you have not identified any specific attack against Twitter, we are unable to take further action on your report...."  Invalid issue and -5 points

I was a bit frustrated at this point

so I guess for this time I need to experiment with the lost art of full disclosure sighhttps://t.co/ZDlUpe8Wok pic.twitter.com/nAFBQcA4Go

— Antonio Sanso (@asanso) September 7, 2017

but I have been "invited" to try to "request mediation" from Hackerone

For the first time ever I had to use @Hacker0x01's "request mediation" :( sadhttps://t.co/r6F4O3oeWr

— Antonio Sanso (@asanso) September 6, 2017

I must admit it was a bit convoluted, it took a while but it woooooooorkeeeeeeeeeeeed!!!

27-10-2017 - Twitter rewarded asanso with a $5,040 bounty.

At the end of the day also this was an experience. Hence I would like to thank all the security teams involved: Google/Twitter and a big thank to the Hackerone stuff. Request mediation works!

Well that's all folks. For more OAuth and Webby trickery follow me on Twitter.