Nimbox Unauthenticated Direct Object Reference in Download Function – ‘Stealing the pie from the API‘

Nimbox Unauthenticated Direct Object Reference in Download Function – ‘Stealing the pie from the API‘

Introduction

At the end of July, I identified an unreported vulnerability within Nimbox’s secure file sharing product ‘vault’. The vulnerability allowed me to mass download all their customer’s data stored on the platform. The vulnerability was immediately reported to Nimbox as it effected their entire customer base. It was reported on the 26th of June 2016 effecting version 2.5.0 up to the latest version at the time, 2.5.1.936. It was then patched on the 27th of June 2016 with the release of version 2.5.1.937. I would like to credit Nimbox for their swift response to the issue.

Details of our advisory can be found here.

The Nimbox blog and hotfix can be found here and here.

Technical Detail

As detailed in the advisories above, the vulnerability takes advantage of an Unauthenticated Direct Object Reference in the Download Function of the ‘vault’ application.

“Nimbox is a secure file sharing, collaboration, backup and cloud storage service for managing, sharing and syncing files across your environment. Their ‘vault.nimbox’ service, used for secure file sharing was found to have an unauthenticated direct object reference vulnerability. Resulting in the ability to download all previously-shared customer data stored within https://vault.nimbox.co.uk.”

By exploiting known methods, it was possible to download any customer’s folder and its contents as a .zip file, as long as the content had been previously shared.

Proof of Concept

When viewing or accessing a folder and its contents within the vault, each folder has an ID which can be seen in the following URL:

https://vault.nimbox.co.uk/shares/folder/<validation_token>/?folder_id=<id>

Incrementing the folder_id value yielded an error stating the folder does not exist, whereas decrementing the value gives a 403 forbidden. This indicates to us that folders exist within our contained domain, we just can’t access them, yet.

Nimbox’s ‘vault’ application also contains a ‘download as a zip’ function, which allows clients to download the entire contents of their share instead of each file individually. This function makes use of three separate parameters when making its call to the API end point.

https://vault.nimbox.co.uk/1/files/share/<client_id>/<folder_id>/zip/<validation_token>

The first parameter is organisation A’s directory ID (Nimbox Customer) which increments iteratively with each new customer. The second is the sub-directory ID (i.e., Organisation A’s specific client’s or employee’s directory/share etc.) which increments iteratively with each new sub-directory created. The third is a validation token. The validation token is not tied to access control and it only validates the request to the API to authorise the download. Therefore, changing the sub-directory ID starting at 1 and working up incrementally, we can download all sub directories inside Organisation A’s directory. This is exemplified in following intruder attacker:

Set payload position to the folder_id parameter:

screenshot 1 intruder

Set Intruder to iterate through incrementing by 1 each time from 0 to 610:

screenshot 2 intruder 2

Analyze results, the most interesting parameter here is the Length as it indicates the size of the contents within each share:

screenshot 3 results

This can then be taken one step further to include both the directory ID and sub-directory ID. In turn working through every organisation and all the sub-directories owned by that organisation.

https://vault.nimbox.co.uk/1/files/share/1412/2/zip/f90a76b68b226b

These requests can be made without first authenticating to the service. All that is required is for the directory ID and/or sub directory ID to exist along with a valid token. This results in a mass download of all previously-shared customer data stored on https://vault.nimbox.co.uk. A token can be trivially obtained in multiple ways, either from brute forcing, having a link shared with you, capturing a link in transit, being a customer/user, or simply signing up for a free trial.

From this point you can unzip the file and retrieve all documents stored within the downloaded zip file. You can also work out based on the size of the response what folders have a large number of files in them. Otherwise just mass download all the shares. The following quick and dirty wget command will download the first 10 shares from the first 100 organisations and save each share as a .zip in /customer_data:

wget https://vault.nimbox.co.uk/1/files/share/{001..100}/{001..010}/zip/f90a76b68b226b -P customer_data/

Alternatively, you can then submit the following URL in a browser and download the file unauthenticated:

https://vault.nimbox.co.uk/1/files/share/1364/554/zip/f90a76b68b226b

NOTE: This can all be done completely unauthenticated and on mass.

Remediation

Nimbox issued a hotfix for this issue here and details about the steps they took can be found here. Anyone running the below version or previous are urged to upgrade immediately to the latest version:

Product Version Platform
Nimbox 2.5.0 – 2.5.1.936 vault.nimbox.co.uk

Conclusion

This shows how a common attack vector that has been in the OWASP top 10 for a number of years such as Insecure Direct Object Reference can still have a significant impact. The PoC also shows how using commonly available tools and techniques combined with a little bit of ingenuity, you can go from having nothing to gaining full access to all the customer data. User access control also plays a role here and highlights the need for a defence in depth approach.