Uploading image files…

Assembla security exploit: session take over

Why you shouldn’t trust SVG images (hint: it supports <script>)

I reported a security exploit in Assembla, a project management tool similar to Jira, last week. The tool is used by thousands of software development teams, contains development roadmaps, internal ticketing, (private) documentation and (git) code repositories.

Below I’ll share my exploit write-up:

• Assembla allows users to upload files. The uploaded file is then hosted on a separate subdomain (bigfiles.assembla.com), but by replacing the subdomain in the file url with www.assembla.com the file is coincidently accessible from the main app domain. I found something similar with Facebook as well in ‘12.
• Hence somebody could upload a exploit file, serve it from www.assembla.com which would circumvent default cross-domain browser protections, exposing a user’s session (cookie), hence hijacking an complete account.
• I reported this issue a while back using a POC javascript exploit, and was awarded 99 dollars in Assembla credits as thank you. I wasn’t asked any details, beyond my initial report.
• A few days later, they changed a setting in the response header (Content-Disposition: attachment) forcing all uploaded files to trigger a download in the browser, instead of allowing it to execute/run inline. So the attack (e.g. my javascript exploit) would only trigger a file download for a target user, instead of the browser running it within the assembla.com security scope.
• Still the subdomain of uploaded user files was still accessible from any subdomain (including app. or www.).
• Note: It is a minimal security practice to always serve user content away from the main domain name (assembla.com in this case). Think of github.io, facebook.net or googleusercontent.com.

Fast forward to last week:

• I noticed images uploaded by users would still render inline instead a forced download. This might indicate there is a way to trigger inline serving of uploaded files, although possibly restricted to images.
• And that hypothesis was correct, I found images and plaintext files to be not forced as a download.
• Unfortunately, that includes SVG image files, which can contain javascript (!!). And browsers run that javascript in the browser’s window, and within the security scope of of the domain.
• So I created an POC exploit SVG image, which did a XHR request to a interesting endpoint (e.g. /user/edit).
• The uploaded SVG ended up on bigfiles.assembla.com, but I could still replace the domain in the url with app.assembla.com, from there anyone with an active Assembla session that would access the SVG, the javascript would execute, and be able to execute any action using the user’s session. Including even silently passing back any details of the complete workspace to a roque endpoint.

In the POC exploit above, I show the SVG executes my javascript within the app’s domain. If you are logged in, it shows you your username.

What we can learn from this:

• Make sure security issues raised by researchers are dealt with in a proper way (Hackerone?)
• Make sure security issues are completely resolved, and stay resolved. Check with the researcher, his time spend on the exploit makes him an expert.
• Never rely on whitelisting certain file types for security. This will never be fool proof.

7 march: reported exploit.
14 march: confirmed exploit is resolved by forcing download of SVG.