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


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 

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 Observe a read error message saying: "Issue b/source#comment4 does not exist"
  • Navigate to Observe a read error message saying: "Access denied for: <MAIL_ADDRESS>".
  • Navigate to Observe a read error message saying: "Access denied for: <MAIL_ADDRESS>".
  • Navigate to 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 it looks like implements the OAuth 2 specification.
The redirect_uri validation seems to be vulnerable.
As per there is a OAuth call
The registered redirect_uri from client catbzQMNEwPxwfvEMqgMFHbNTcwWevGiDRWUaq3aHERZfgnCuy seems to be
The Periscope OAuth server seems also to accept
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:
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



Popular posts from this blog

OpenSSL Key Recovery Attack on DH small subgroups (CVE-2016-0701)

Usual Mandatory Disclaimer: IANAC (I am not a cryptographer) so I might likely end up writing a bunch of mistakes in this blog post... tl;dr The OpenSSL 1.0.2 releases suffer from a Key Recovery Attack on DH small subgroups . This issue got assigned CVE-2016-0701 with a severity of High and OpenSSL 1.0.2 users should upgrade to 1.0.2f. If an application is using DH configured with parameters based on primes that are not "safe" or not Lim-Lee (as the one in RFC 5114 ) and either Static DH ciphersuites are used or DHE ciphersuites with the default OpenSSL configuration (in particular SSL_OP_SINGLE_DH_USE is not set) then is vulnerable to this attack.  It is believed that many popular applications (e.g. Apache mod_ssl) do set the  SSL_OP_SINGLE_DH_USE option and would therefore not be at risk (for DHE ciphersuites), they still might be for Static DH ciphersuites. Introduction So if you are still here it means you wanna know more. And here is the thing. In my last bl

Critical vulnerability in JSON Web Encryption (JWE) - RFC 7516

tl;dr if you are using go-jose , node-jose , jose2go , Nimbus JOSE+JWT or jose4j with ECDH-ES please update to the latest version. RFC 7516 aka JSON Web Encryption (JWE) hence many software libraries implementing this specification used to suffer from a classic Invalid Curve Attack . This would allow an attacker to completely recover the secret key of a party using JWE with Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES) , where the sender could extract receiver’s private key. Premise In this blog post I assume you are already knowledgeable about elliptic curves and their use in cryptography. If not Nick Sullivan 's A (Relatively Easy To Understand) Primer on Elliptic Curve Cryptography or Andrea Corbellini's series Elliptic Curve Cryptography: finite fields and discrete logarithms are great starting points. Then if you further want to climb the elliptic learning curve including the related attacks you might also want to visit https://s

The Curious Case of WebCrypto Diffie-Hellman on Firefox - Small Subgroups Key Recovery Attack on DH

tl;dr Mozilla Firefox prior to version 72 suffers from Small Subgroups Key Recovery Attack on DH in the WebCrypto 's API. The Firefox's team fixed the issue r emoving completely support for DH over finite fields (that is not in the WebCrypto standard). If you find this interesting read further below. Premise In this blog post I assume you are already knowledgeable about Diffie-Hellman over finite fields and related attacks. If not I recommend to read any cryptography book that covers public key cryptography. Here is a really cool simple explanation by David Wong : I found a cooler way to explain Diffie-Hellman :D — David Wong (@cryptodavidw) January 4, 2020 If you want more details about Small Subgroups Key Recovery Attack on DH I covered some background in one of my previous post ( OpenSSL Key Recovery Attack on DH small subgroups (CVE-2016-0701) ). There is also an academic pape r where we examine the issue with some more rigors.