Today, I want to share a vulnerability I found on Flickr two months ago. Flickr, one of the most famous photo-sharing services in 2014, piqued my interest, so I thought, why not try to find a bug there and report it to Yahoo?
I began by examining the website and discovered that it is written in PHP and has over 87 million users.
I have always enjoyed attacking websites for the purposes they were designed for. In Flickr’s case, that is photo sharing. Read along to see where the vulnerability lies!
I tried various methods like XSS, XSRF, and permission bypass, but ultimately, I focused on XSRF. I noticed that Flickr used the parameter “magic_cookie” to protect the site from XSRF vulnerabilities. This parameter is included in every request, so the idea was to find a way to bypass this protection method. I tested the most critical requests (Delete, Add, Edit). After uploading a photo in the basic version of Flickr, you are redirected to a page where you can add information to the uploaded photo, such as tags, description, and title. The first request was:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
POST /somewhere HTTP/1.1
Host: www.flickr.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: Long one !!!
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 208
edit_done=1&upload_ids=14401638983&just_photo_ids=&set_id=
&magic_cookie=32e285e98bbef3aa6afd8c879891c01b&title_14401638983=XSRF+bug+POC1
&description_14401638983=XSRF+bug+POC1&tags_14401638983=XSRF+POC1
&tags_14401638983=XSRF+POC2&Submit=SAVE
The hash 32e285e98bbef3aa6afd8c879891c01b is likely an MD5 hash set in the session. MD5 hashes are typically represented as a 32-character hexadecimal string, matching the format of the given hash.
My investigation involved trying various values for the magic_cookie, including those of the same length and expired ones. Despite these efforts, none of the values worked, leading me to delete the magic_cookie parameter. These actions triggered a 302 redirect with no change in the content. I then proceeded to delete the value of the magic_cookie. The first attempt was unsuccessful, but the second attempt proved fruitful, highlighting the intricacy of the vulnerability.
All values, like title, description, and tags were changed and redirected to my photos.
I then checked for additional protections, such as a referrer or another cookie or HTTP header value. It was time to prepare the HTML script for the proof of concept (PoC).
I needed to change the photo ID in the HTML script
upload_ids & tags_{id here} & title_{id here} & description_{id here}
An attacker can obtain the photo ID from the photo URL.
Upon discovering the vulnerability, I promptly reported it to Yahoo. I was initially concerned it might be another duplicate, but I used the “HackerOne” website to report it. To my satisfaction, they responded within two days. The vulnerability was then swiftly fixed in less than 12 hours, demonstrating the efficiency the resolution process.
I received a reply from Yahoo more than a month after the report date, and the bounty still needed to be set.
I sent them a direct message on Twitter, and they kindly allowed me to publish the write-up.
Here is the video for the PoC:
And that’s how it’s done!
Abdullah