Summary
Basic upload form in Flickr.com was vulnerable to CSRF. Visiting a malicious page while being logged in to Flickr.com (or using Flickr.com 'keep me signed in' feature) allowed attacker to upload images or videos on user's behalf. These files could have all the visibility / privacy settings that user can set in Basic Upload form. Uploading files did not require any user intervention and/or consent.Described vulnerability has been quickly fixed by Flickr.com team.
The exploit is an example of using my HTML5 arbitrary file upload method.
Demo
Vulnerability description
Flickr.com basic upload form displayed on http://www.flickr.com/photos/upload/basic/ submits a POST request with multipart/form-data MIME type (standard HTTP File Upload form).| Basic File Upload Form |
POST /photos/upload/transfer/ HTTP/1.1 Host: up.flickr.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.2.18pre) Gecko/20110419 Ubuntu/10.04 (lucid) Namoroka/3.6.18pre Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pl,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: http://www.flickr.com/photos/upload/basic/ Cookie: BX=somecookies&b=3&s=rv; localization=en-us%3Bus%3Bpl; current_identity_provider_name=yahoo; current_identity_email=removed@example.com; cookie_session=session-id-here Content-Type: multipart/form-data; boundary=---------------------------410405671879807276394827599 Content-Length: 29437 -----------------------------410405671879807276394827599 Content-Disposition: form-data; name="done" 1 -----------------------------410405671879807276394827599 Content-Disposition: form-data; name="complex_perms" 0 -----------------------------410405671879807276394827599 Content-Disposition: form-data; name="magic_cookie" 8b84f6a5d988b5f3a1be31c841042f41 -----------------------------410405671879807276394827599 Content-Disposition: form-data; name="file1"; filename="0011.jpg" Content-Type: image/jpeg [binary-data-here] -----------------------------410405671879807276394827599 Content-Disposition: form-data; name="tags" -----------------------------410405671879807276394827599 Content-Disposition: form-data; name="is_public_0" 1 -----------------------------410405671879807276394827599 Content-Disposition: form-data; name="safety_level" 0 -----------------------------410405671879807276394827599 Content-Disposition: form-data; name="content_type" 0 -----------------------------410405671879807276394827599 Content-Disposition: form-data; name="Submit" UPLOAD -----------------------------410405671879807276394827599--
On line 11 there are some Flickr.com cookies, there is also a magic_cookie form field which looks like an anti-CSRF token. However, it was not verified properly. Changing the value or removing magic_cookie field still resulted in successful file upload.
To make things worse, Flickr.com uses persistent cookie BX for 'keep me signed in' feature. Sending POST request to http://up.flickr.com/photos/upload/transfer/does not require an active session set up beforehand. If BX cookie is present, Flickr.com will silently sign the user in while processing the request. Therefore all accounts using Flickr.com 'keep me signed in' feature were potential targets of described attack.
To make things worse, Flickr.com uses persistent cookie BX for 'keep me signed in' feature. Sending POST request to http://up.flickr.com/photos/upload/transfer/does not require an active session set up beforehand. If BX cookie is present, Flickr.com will silently sign the user in while processing the request. Therefore all accounts using Flickr.com 'keep me signed in' feature were potential targets of described attack.
Attack
Malicious page with this HTML code:<form enctype=multipart/form-data action="http://up.flickr.com/photos/upload/transfer/" method="post"> <input type=hidden name=is_public_0 value=1> <input type=file name=file1> <input type="submit"> <!-- no magic_cookie here, still works --> </form>
was able to submit a file to Flickr.com on logged in user's behalf, because the browser would attach the Flickr cookies to the request, and Flickr had no way of distinguishing it from a legitimate request (a classic CSRF vulnerability).
Above technique required user to manually choose the file from his HDD. However, using my HTML5 arbitrary file upload method a malicious page was able to construct the raw multipart/form-data request in Javascript and send it quietly without user interaction. In the demo video, a button press is required, but this is only for presentational purposes. File upload can be triggered automatically on page load.
As a result, visiting malicious page in browsers supporting CORS requests as per specification (Firefox 4, Chrome) while using Flickr.com 'keep me signed in' feature (or having an active Flickr.com session) resulted in uploading images and videos chosen by attacker to Flickr.com photostream (with visibility settings, tags etc. chosen by the attacker).
Exemplary exploit code is here.
18.05.2011 - vendor responded, fix released
Above technique required user to manually choose the file from his HDD. However, using my HTML5 arbitrary file upload method a malicious page was able to construct the raw multipart/form-data request in Javascript and send it quietly without user interaction. In the demo video, a button press is required, but this is only for presentational purposes. File upload can be triggered automatically on page load.
As a result, visiting malicious page in browsers supporting CORS requests as per specification (Firefox 4, Chrome) while using Flickr.com 'keep me signed in' feature (or having an active Flickr.com session) resulted in uploading images and videos chosen by attacker to Flickr.com photostream (with visibility settings, tags etc. chosen by the attacker).
Exemplary exploit code is here.
Fix
As of today, Flickr.com fixed the issue and contacted me to confirm the fix - all within a few hours since notifying, great work guys! Now magic_cookie value is checked upon processing the upload request.Timeline
17.05.2011 - vulnerability discovered
18.05.2011 - vendor notified18.05.2011 - vendor responded, fix released