Skip to main content

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
but I have been "invited" to try to "request mediation" from Hackerone

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

 

Comments

Popular posts from this blog

Billion Laugh Attack in https://sites.google.com

tl;dr https://sites.google.com suffered from a Billion Laugh Attack vulnerability that made the containerized environment to crash with a single invocation.
Introduction Few months ago I applied for a talk at a security conference titled Soyouwanna be a Bug Bounty Hunter but it was rejected :(. The reason behind it is that I have been on/off in the bug bounty business for a while as you can see here:
Funny. Found in a forgotten drawer from the time I was a bug hunter :p #facebook#bug#bountypic.twitter.com/Tt4saGZVLI — Antonio Sanso (@asanso) November 30, 2018 and I would have liked to share some of the things I have learned during these years (not necessary technical advises only). You can find a couple of these advises here:


Rule #1 of any bug hunter is to have a good RSS feed list
and here


The rule #2 of any bug hunter is to DO NOT be to fussy with 'food' specifically with "left over"
Today's rule is: The rule #3 of any bug hunter is DO LOOK at the old stuff

and…

Slack SAML authentication bypass

tl;dr  I found a severe issue in the Slack's SAML implementation that allowed me to bypass the authentication. This has now been solved by Slack.
Introduction IMHO the rule #1 of any bug hunter (note I do not consider myself one of them since I do this really sporadically) is to have a good RSS feed list.  In the course of the last years I built a pretty decent one and I try to follow other security experts trying to "steal" some useful tricks. There are many experts in different fields of the security panorama and too many to quote them here (maybe another post). But one of the leading expert (that I follow) on SAML is by far Ioannis Kakavas. Indeed he was able in the last years to find serious vulnerability in the SAML implementation of Microsoft and Github. Usually I am more an "OAuth guy" but since both, SAML and OAuth, are nothing else that grandchildren of Kerberos learning SAML has been in my todo list for long time. The Github incident gave me the final…