Whether it’s Box, ShareFile, Drive, or any other cloud hosted file sharing services, there are best practices to follow that, unfortunately, are not always followed. During a recent Open Source Intelligence engagement that we were performing, I got a little curious during my searching and wondered how severe something like sending a file without an expiring link could be. After all, the link is randomly generated and can only be accessed by the recipient, right? right?. For the purpose of this article, we’re going to focus on ShareFile, though the same holds true for almost all cloud hosted file sharing applications.
When you share a file with a cloud hosted file platform, you have a couple options. With ShareFile, the options are to either;
- Prompt the user for a some information (in sharefile, the URI for this is /getinfo/). Typically, you can enter any name or email and access the file (not very secure)
- Do not require any information. When this is in use, the URI looks like /share/view/.
- Require a username and password and a valid ShareFile account.
When the file is shared and one of the above is used, ShareFile will create a link that the user will use to access the files. The sender has an option to expire the link at various options of time intervals, or never. NEVER USE NEVER.
Hunting for Data
Using some trusty tooling that we’ve wrote other posts about (see Zoom Bombing), we’re able to query AlienVaults Open Threat Exchange to see if any ShareFile links have been cached by it. If a link has been cached, and, if the link is set to never expire, we may be able to grab some files from these ShareFile accounts and view them. To do this, we are focused on /share/view/ URI as this means that it does not require any information on the recipients end, and we’re relying solely on the link expiration to protect the files after they were in use.
To do this, we ran the following command using GAU (https://github.com/lc/gau)
echo sharefile.com | gau --subs > sharefilelinks.txt
We then grep’d this searches for anything that contained /share/view/. As we can see, a nice amount of links were returned!
Now, one could simply navigate to each URL and see which one is live, but there are tools for that, notably httpx. However, going through mass httpx output is not nearly as fun as seeing actual screenshots, which is where we will use another tool; gowitness. Gowitness can be installed easily with
apt-get install golang-go
go install github.com/sensepost/gowitness@latest
apt-get install chromium
cp /root/go/bin/gowitness /usr/bin
Gowitness is a golang based screenshotting tool that can screenshot from numerous file formats including nessus output, nmap, and from a raw text file. It saves this output into a nice HTML report that is easy to navigate through and gives you a great overview of what is running on each web service. I tend to prefer gowitness over tools such as eyewitness, goverview, etc. as it’s fast and very easy to use.
gowitness file -f sharefilelinx.txt --threads 100
Note that this runs at a default of 20 threads, but because we have some serious computing power at our disposal, I’m not shy about upping those threads. When this finishes, you can create a report from the .zip output which will be in a .HTML format. This will create sceenshots of whatever may be on the other side of that link, whether that’s an error page or someones tax return.
Note that these results are just for ShareFile and only the results using gau. Think of the endless possibilities of anything that may use a single use link, such as:
- Other file sharing services (Drive, Box, Dropbox, etc.)
- Password reset links (assuming they don’t expire after time/first use)
- Meetings links and invites
- Anything else that thinks having a unique link is considered security
