█████████ - Insecure download cookie generation allows bypass of CAC authentication, access to deleted and locked files

How it was found

Summary:

To download a file, ████ directs users to /██████████/Download.aspx and sets a cookie authenticating the download. The cookie looks like this:

pickup=Subject=&PackageID=MTU4NDgzMTU=███

If an attacker can generate this cookie, this allows downloading a file. As it turns out, the generation of the cookie is fairly straightforward and requires no server-side key, only a file ID and its associated password. The components are:

1. The file ID, base 64 encoded, followed by a dash
2. The SHA512 hash of the plaintext file ID, base 64 encoded
3. The secret key of the package (as sent in the email), base 64 encoded, followed by a dash
4. The SHA2512 hash of the secret key, base 64 encoded

By generating a cookie using this format, an attacker can accomplish the following:

1. Bypass CAC-enforced files.
2. Bypass deleted files (tested when a user deletes their package). Untested if this allows accessing historical files.
3. Bypass "locked" files that have already been downloaded.

For instance, after attempting to download a deleted package on █████, █████ displays the following error:

The package Is no longer available For download. The file(s) has been permanently deleted from ███████. You will have To contact the sender And ask them To upload the file(s) again.

However, this is not true. By making a crafted request to /█████████/Download.aspx given the above cookies, a user can still download deleted files. This may also apply to past files, meaning that all previous uploaded files may not be deleted. I will test this when files I have submitted expire.

Impact

Significant bypasses to █████████ security controls, including:

• Bypass CAC protections
• Download files that ███ says have been deleted from the file system
• Download locked files that have already been downloaded

It is unclear at the moment if this also applies to files that have expired after a set period of time. I will retest when files I have uploaded have expired.

Step-by-step Reproduction Instructions

1. Visit https://███████/██████/pickupfiles.aspx?id=15849581, a file I uploaded and deleted.
2. Try the password █████████. Observe that an error is displayed that the file is deleted.
3. As described above, generate the following cookie, based on the file ID and password.

pickup=Subject=&PackageID=MTU4NDk1ODE=█████████

4. Make the following GET request with the cookie:

GET /████████/Download.aspx?PackageID=15849581&FileName=dog.jpg HTTP/1.1
Host: ███████
Connection: close
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: https://█████/██████████/pickupfiles.aspx?id=15849581
Accept-Language: en-US,en;q=0.9
Cookie:  pickup=Subject=&PackageID=MTU4NDk1ODE=████

5. Observe that the file is returned, demonstrating that it has not been deleted.

This also has been tested with CAC-enforced files and files that are "locked" due to already having been downloaded.

Impact

.