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.
- 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.
- So I created an POC exploit SVG image, which did a XHR request to a interesting endpoint (e.g. /user/edit).
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.