A bit of additional material has been added to clarify why “a few hundered KB isn’t much”

There is a pretty serious allegation that Dropbox is stealing all your files making the rounds. The allegation is based on the following observations:

  • An unnamed DLP product noted that the Dropbox application accesses newly-created files outside the Dropbox folder

  • Firewall logs show the Dropbox application accessing Dropbox itself and Dropbox-controlled AWS endpoints around the same time as the above file access.

Seems pretty damning, right? Well… maybe not so much.

The Dropbox application uses a filesystem monitor to detect when changes are made by monitoring filesystem write events. This is, by necessity, a system-wide process. So DLP alerting that Dropbox is “acccessing” a new file shouldn’t be surprising.

Update: it turns out that it’s the Dropbox shell extension that’s most likely triggering these events. Thanks to @razvanh’s Medium explanation that clarifies this important point.

Likewise, the Dropbox application routinely communicates with its sync infrastructure at Dropbox and AWS endpoints, so it’s not surprising to see Dropbox communicating regularly to check whether there is a new sync point or the like.

So the provided evidence doesn’t show that Dropbox is reading or transmitting any files outside your Dropbox folder; but it doesn’t disprove it either. So how can we test?

A simple protocol can give us an idea of whether data is being sent to Dropbox:

  1. Create a large-ish file (1MB) outside of the Dropbox folder
  2. Monitor the network usage of the Dropbox application to see if it sends enough data that it could be that file
  3. Repeat with many different files, etc.

Doing exactly that, Dropbox only sent a few hundred KB after “accessing” the target file. This is the same communications pattern you see when Dropbox is simply doing routine server checks. Seems unlikely that Dropbox is uploading files outside your Dropbox folder.

But are they reading the files, looking for sensitive data to send? Test:

  1. Create target files outside the Dropbox folder, various sizes, mostly text
  2. Use process monitoring to see how many bytes are read

If Dropbox is scanning those files, it should read a large number of bytes from disk after seeing new files outside the Dropbox folder.

Again, it’s in the kilobyte range, which suggests Dropbox isn’t scanning these files beyond a call to stat() as part of its file monitoring service.

Why isn’t “a few hundered KB” very much data?

A few people on Twitter and in private have pointed out that “a few hundred KB” seems like a lot of data, and that bears some further discussion. This section was added in response to those points.

Firstly, it’s a few hundred KB over about 10 minutes. I should have been clearer about that.

Secondly, it’s background noise. this amount of traffic is about the same as when Dropbox isn’t reading new files. It’s hard to do a properly-controlled test of this, but I don’t see anything suspicious based on my comparison.

Also, compression wouldn’t explain it. My original test file was a 1300KB (~1.2MB) file composed of a JPEG embedded in a .docx Word file. If Dropbox can compress that JPEG enough to have it be about half the size… well, they should pivot!

A couple people have mentioned metadata scanning. That’s certainly possible, and it’s a hypothesis that fits the facts. Becasue of Dropbox’s good SSL implementation that resists MiTM (BurpSuite interception doesn’t work), I can’t prove that they aren’t scanning and uploading file metadata. However, I still say “probably not”, because I don’t see any evidence to suggest that’s what they’re doing, and there are reasonable explanations for what I do see that don’t require Dropbox to have a shadow business plan.

This also means I can’t easily see exactly what Dropbox is sending. I have no evidence that they’re sending any unexpected data out of my network, but I admit that I can’t prove they aren’t either.

Since Dropbox’s application is free, lots of people can test, and if someone does a more-rigorous test that sheds light on any of the above I will happily link it here.

For the time being, there’s no reason to believe that Dropbox is doing anything unacceptable. The E-Siber article is interesting, but nothing it shows is at all suprising given Dropbox’s expected function, and so there’s just not enough evidence to conclude more than “Dropbox is probably not malicious, further research is needed.”

Deeper analysis

This section was added after initial publication to attempt to document some deeper analyses. These folks have done great work, and so far it all confirms the hypothesis that Dropbox isn’t behaving maliciously:

If there are additional resources, please mention them to me on Twitter (@DarrenPMeyer)