This blog post covers a (now fixed) critical security vulnerability on the Nimbox platform, that was reported to us recently by a researcher.
Setting the scene
It goes without saying that we take immense pride in the security of our applications. But, nobody is infallible—mistakes can and do happen.
Because of this, we launched our vulnerability reporting programme last year, which aims to give security researchers an easy way to report their findings.
Since its launch, our programme has received bug reports from over sixty researchers. Whilst most of these reports detailed expected behaviour, or things that were outside the scope of our programme, fourteen reports resulted in legitimate ‘minor’ vulnerabilities.
The latest report, however, was a little different; it was our first ‘critical’ vulnerability.
What did the report say?
Ross Bingham, of 7 Elements, emailed us on 26 July. He had found an unauthenticated direct object reference bug in our ‘Download as ZIP’ feature, which, in short, meant that anybody could download a file from our platform without the correct permission. You can read more about how Ross discovered this vulnerability on the 7 Elements blog, here.
Has it been fixed?
We fixed the vulnerability in a matter of hours. Ross emailed us on 26 July, and we rolled-out a fix in the wolf-light on 27 July.
What is it, technically?
Our web application is based on the same API that you point to when integrating our service into your networks. The API provides several tools, one of which is the ability to download files and folders as a ZIP archive.
To achieve logical separation of the objects on our platform (such as organisations, accounts, folders, and files), unique numerical IDs are issued for each object. These IDs are generated by an open-source, cryptographically secure, pseudorandom number generator.
When a user performs any one of hundreds of actions on our platform, this unique ID is created and stored in our database.
Subsequently, when a user shares a file or folder, its unique ID is assigned an access token, which is then embedded into the share link. At this point, the user has two options: create a public link, or create a secure link.
If a user chooses to create a secure link, our application sets a tag that will require credentialed access to the object that has been shared.
When a user selects the ‘Download as ZIP’ option on the share page, they see a URL like this:
By executing this link, a call is made to our API, which checks whether you are permitted to see the content, and then either allows you to download the ZIP, or redirects you to a login page.
Ross discovered, however, that by changing the random user ID or random folder ID perimeters in the URL, he could navigate through other users’ objects, and download the ZIP archives at will. The only requirement being that he must have a valid access token.
What was affected?
This bug only affected files that had been shared during our 2.5.0 to 2.5.1 release cycle. Files shared before 2.5.0 were not affected. This release cycle covered a period of approximately 2 months. Files that have never been shared, were not affected.
What caused it?
During our 2.5 release cycle, we made some significant changes to the way our object and sharing mechanisms operate, in preparation for the release of our Collaborative Editing Tool later this summer.
As part of these changes, we accidentally disabled the process which matched the object ID with the respective access token, resulting in open access to files that had previously been shared.
A final note
We’ve learned a lot from this vulnerability report, and we have some things to improve on, but we’re largely pleased with how we handled it. Within a couple of hours, we had verified the bug, performed emergency mitigations, and started to work on a fix. By the next morning, we had rolled-out a fix across our entire platform.
Finally, we’d like to thank Ross and 7 Elements for their professionalism, willingness to communicate, and discretion in the short period it took for us to fix the issue.