Introduction

"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:

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

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 details30-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 me31-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 points31-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 case01-09-2017 - Request from Twitter to have more info01-09-2017 - More info from me01-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

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…

then after that the resource owner has authorized the client the authorization server redirects the resource owner back to the client with an authorization code:
Then the OAuth dance continues....
Facebook/Dropbox i…