Dropbox accesses all the files in your PC?
e-siber.com
e-siber.com
These actions will show up as at least 4 or 5 entries in Process Monitor (and maybe more, I'm not sure off the top of my head). This also means that applications monitoring for file access will catch each time this happens.
Unfortunately, whoever wrote that article does not seem to understand Window's internals, or how to determine what consists of bad or dangerous activity.
It should also be noted that Dropbox runs in the context of your own user account. It does not run as a service or elevated user, so it will only have access to the files you have access to (and that you have access to without requiring elevation).
I'm not going to claim to be a security expert, but I don't see anything that would suggest a security risk on Dropbox's part. Further, if a company has data important enough that they need to run DLP software on individual computers, they should not be allowing software such as Dropbox anyway.
You're right of course, periodic data needs to be sent even if just to keep the TCP connection open, but it's not much and it's not often.
> In Windows, even with a filter limiting which directories to process, a FileSystemWatcher object has to examine each event and decide whether or not to call the event handler or let it pass without action.
Sounds like the very act of checking whether the file falls within the "agreed location" is what caught the author's attention. I can't say whether that's true, but it doesn't seem unreasonable.
You can see three calls for each file in the ProcMon logs:
1. CreateFile
2. QueryBasicInformationFile
3. CloseFile
Let's go through these in order:
1. Opens a handle to the file, allowing the application to query meta information, read, and write
2. Queries meta information about the file.
3. Closes the handle to the file before doing anything else, including reading data.
There's no scanning of files, because no data is read. Its common for applications to traverse directories like this, and the behavior could even be a consequence of a file system library or API that dropbox is using. If you think of your file system as a filing cabinet, what DropBox is doing might be equivalent to opening every drawer looking for a single file.
ProcMon detects CreateFile and QueryInformationFile using these function codes:
https://msdn.microsoft.com/en-us/library/ff548630(v=vs.85).a...
https://msdn.microsoft.com/en-us/library/ff549283.aspx
As you can see, neither of these indicates a file being read. It also monitors a number of other codes (I'm not sure how specifically it detects CloseFile), including this one, which is triggered when data is read from a file:
https://msdn.microsoft.com/en-us/library/ff549327(v=vs.85).a...
If that was being called, ProcMon would show it, but it doesn't
That's a .Net contraption over one of two Win32 APIs that provide file system monitoring services. Neither of these requires opening files in response to file system notifications. That's 100%, guaranteed.
Correct me if I wrong but Dropbox is not written in .Net, so what you said is irrelevant.
--
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
Either way, I'm fairly certain that checking file properties (as would be done to check whether or not a filter applies) would be registered as opening the file.
> I'm fairly certain that checking file properties (as would be done to check whether or not a filter applies) would be registered as opening the file.
Bzzt, nope. Wrong again. You should really try and not comment on things that you are not well-versed at. This part in particular - "as would be done to check whether or not a filter applies" - makes no sense. Dropbox has the file path readily available from the notification itself [1], and that's the only thing they need to look at to determine if the file is in their managed directory or not.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
Point being that the app does not need to open files when processing file system notifications, which is what you stated in the top comment.
The reason Dropbox accesses files all over the drive may be that FS events driver generates events for every file accessed by every program, and Dropbox has to read their metadata for some reason (e.g. to check if their full path is under one of synced folders). He should elaborate by checking if Dropbox is actually scanning and reading all drives, which is hardly unnoticeable, or is it something else.
Having network activity at the same time does not mean this file has been transferred. It is incredibly hard for me to believe that Dropbox has sneakily transferred >1TB from my various computers without me and my ISP noticing. The author should monitor Dropbox traffic volumes over a week and check if it actually exceeds synced folders size before spreading panic.
"It is incredibly hard for me to believe that Dropbox has sneakily transferred >1TB"
Did they transfer hashes? name+type+size for fingerprinting? Searching for credit numbers or SSNs? Who knows. I don't. And don't do evil is no longer the basic assumption.
Collecting "metadata" such as Address X stored on Computer Y on ip address Z could be worth quite alot to likes of NSA who I am sure have plenty of incentive to monitor crypto-currencies and would either pay Dropbox to do it or alternatively bang them over the head with a hammer and make them their bitches in order to collect all sorts of juicy "metadata" on millions of people world wide.
Hell access to so much information could make for quite a political tool, remember that general in washington who was kicked out because he was having an affair and somehow his private communications via gmail drafts became public. What would prevent an opportunistic dictator from gaining absolute control over political landscape of a country if this dictator has access/control to an organization such as NSA?
Americans get up in arms over their right to be armed all the time, but they ignore (or do not realize?) that without privacy and secure communications they would never be able to organize a resistance to a totalitarian government which is better armed and could potentially (already does?) monitor everything and everyone on a scale that would make Orwell blush and spin in his grave.
Also, theoretically, it could be a single (or a few) developers going rogue, rather than an approved company policy. It wouldn't be the first time.[0]
[0] http://www.tomsguide.com/us/David-Barksdale-Google-Engineer-...
Dropbox has already closed hundreds of millions of venture capital money at a valuation of $10 billion. I think it's safe to say Dropbox has found some wallets that are much easier to open than bitcoin wallet files. :)
How does a security researcher not know about procmon? another user here did a test and found no problems.
He has shown - and others here in the comments have verified (https://news.ycombinator.com/item?id=9136740 ) - the file access. It's not a "read contents" though, but only reading metadata.
He has shown there is network activity.
He has NOT shown what exactly that network activity consists of. Without that, the "steals everything" claim is just jumping to conclusions.
As others here have mentioned, setup a proxy and look at the actual data being transferred. Replace the certificate in the client if you have to, to get around cert pinning. The most important part is to get the data. This should be pretty easy to do for someone who claims to have those qualifications.
Shallow work indeed. This reminds me of the Samsung keylogger story a few years ago where a "security professional" ran one AV software, which falsely identified the presence of a single folder's path as a keylogger, and then based on this one data point and blind faith in his AV, claimed there was a keylogger preinstalled on some Samsung laptops. This made the news and was spread widely... yet he had not even taken the most basic step of looking at the contents of that folder, which would've instantly disproved the theory.
This is an example of the right way to investigate and substiantiate your claims:
http://doctorbeet.blogspot.ca/2013/11/lg-smart-tvs-logging-u...
Sadly, we'll probably see a round of "Dropbox steals your data!" going through the media before someone steps up with the truth. I personally don't use Dropbox and don't have the time to verify these claims --- but the onus should be on the one making them in the first place.
"Extraordinary claims require extraordinary evidence."
I'm not saying it is, but your assertion that it uploads all file contents is wrong.
1) when I created a new text file on my desktop, it was not read by Dropbox
2) when I created a new text file in my dropbox folder, it was immideately read by Dropbox
3) I have to find some sync tool that doesn't feel the need to enumerate my network interfaces 3 times every second, when nothing is actually changing.I'm guessing this has to do with the explorer extension.
The Dropbox file status symbols are a -big hack-. Up until OS X 10.10, for instance, the file browsing interface didn't provide per-file badging at the OS API level. So they literally had to patch the running Finder process to do this.
I wouldn't be surprised to learn something similar is going on with Windows Explorer.
Bittorrent Sync works pretty good. Somebody should reverse engineer the protocol and make an open source client.
Edit: why the heck is the grandparent downvoted? He/she offers a good suggestion.
Why? Well, I mostly don't care about all the new features (mobile, Carousel, etc.). What I care the most is that i) it syncs files and ii) acts as a quasi-backup. However, I see the same old bugs from years ago and nothing gets done. To name just a few:
- If I copy a file to the Dropbox folder in Windows, it will convert it to small caps, even if the file is in Camel Case. Yes, I get that for windows caps are just "optional", but do not change it just for the sake of it!
- Many people sometimes have temporary files. Photoshop, Matlab, Word, Latex, etc. leave crumbles of temp files and folders. Can't I just set a quick rule to avoid "tmp" folders and e.g. ".tmp" files?
- A few months ago their forums went down and stayed down for around a month? Why? Technical problems. But the real reason is that they don't really care.
There is no way DB can justify their valuation with just the syncing part, and I'm fine with that. But just stopping altogether to improve in that area is a huge turn-off, and on top of that they do not care to fix bugs (there were hundreds of bug requests about the lowercase bug in the forums, before they deleted it).
Now that my rant is over, I ask you: are there any useful alternatives? I've heard that GDrive is very slow and the MSFT alternative seems a bit risky to me (will it work on Linux in the future? will it be customizable?).
Add in encfs with a cheap storage VPS for off-site redundancy. It should run on android too if you have a normal-looking chroot installed.
A few months ago I switched to csync[1], which looks better so far.
I haven't tried to use it seriously, but seeing that it doesn't do this right discourages me a bit from testing it further.
No way I am sharing private documents over the "cloud".
Maybe it's better now.
Are you sure this is still the case? How exactly do you reproduce this with Dropbox for Windows?
I tried copying and pasting a file, as well as creating a new file, and the case is preserved.
(You could also just collect an ETW trace and analyze it in xperf (err, WPA, of course) yourself.)
[1] https://technet.microsoft.com/en-us/library/bb896645.aspx
But if the information is correct, it does transfer some kind of information to the Dropbox servers directly after accessing files outside the sync folder. I would have liked an examination of the tranferred data, or at least a comparison of the amount of data transferred compared to the size of the accessed file.
1) metadata such as a timestamp when all files in the synced folder were found up to date. 2) metadata about the non-synced file changes, such as timestamps, checksums or etc.
While 2 isn't an upload of the file contents, it's still bad enough. I wouldn't expect Dropbox to upload any data OR metadata related to my unsynced files at all.
I'd be shocked if it's actually uploading a comparably sized payload.
No, Dropbox is not stealing your stuff. Apparently people have never heard of Windows Shell Extensions, the approved non-hacky way to overlay icons over files.
https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...
The tortoise apps do the same thing to overlay Git/Hg/Svn icons.
Dropbox's call to inotify_add_watch [1] is properly scoped so this is either a platform problem (but it looks like Windows' analogous API [3] allows only one directory to be monitored), sloppy development on Windows, or something else. I ran Dropbox under a Docker container under strace and grepped strace's logs for inotify and got this [2]. At least on Linux, it's impossible for Dropbox to receive any notifications about new files outside the Dropbox folder.
[1]: http://man7.org/linux/man-pages/man2/inotify_add_watch.2.htm...
[2]: http://pastie.org/9995412
[3]: https://msdn.microsoft.com/en-us/library/aa364417(VS.85).asp...
Another piece of evidence I'd like to see is a mitmproxy checking out what's under that TLS session. Improper local reads are one thing, it's another thing entirely if they are communicating back file names, hashes and/or the file data actual.
I agree that it's important to find out if they are phoning this information back home, because if they don't this is still very bad but a lot less harmfull.
(But I really don't know enough to day for sure. Still, if the shell extension mechanism is such that you get a file or list of files, it'd need to figure out whether they're in a Dropbox folder or not and play with the icons.)
I'm not saying this as cause for alarm. Obviously if they were sending the files you could measure the volume of traffic if nothing else.
Make a completely random non-compressible file that's of an arbitrarily significant size (say 1M+) and see if that amount of traffic goes out to them.
I do think Dropbox is watching for filesystem events outside of the locations users specify, but I see zero evidence they're uploading information about the files / the files themselves so far.
sed -i 's/old certificate/new certificate/g' /usr/bin/dropbox
EDIT: Matasano has a nice guide for bypassing OpenSSL cert pinning (for iOS apps, but the techniques should be more broadly applicable): http://chargen.matasano.com/chargen/2015/1/6/bypassing-opens...
I think kweinber was kidding, though.
If this is indeed something nefarious, I would much rather assume it would transmit file hashes rather than the files itself. Although I can't possibly imagine this is actually true, the implications would be devastating for dropbox and it should be easy to verify by an independent third party.
Fingerprint popular torrent movie/tv/games etc files and then monitor (via dropbox) their spread and how many computers around the world they end up on, I bet movie studios would love to measure exactly how much piracy affects them
shiiiittt
What's actually going on here? What sort of false positives might we expect from such a program?
It's not a stretch of the imagination that dropbox could still be making a profit spending bandwidth and storage space this way. I can think of a government agency or two that would re-imburse the costs.
I agree with what another commented brought up - it's probably just unfortunately overaggressive 'filesystem-watch' code - IE when you change a file it checks to see if it needs to be synced and re-uploaded. It shouldn't be able to affect other files, though. Makes me wish we had more nuanced security controls, like per-app permissions a la Android/IOS.
Security aside, it is really annoying for scripts which modify a lot of files.
And about that connections to dropbox servers, it needs them to sync files if they were uploaded from another computer/smartphone.
833/0x1c7d: read_nocancel(0x6, "/Users/daniel/foobarbaz\0", 0x17) = 23 0
833/0x1c7d: access("/Users/daniel/foobarbaz\0", 0x4, 0x17) = 0 0
Maybe that's even necessary, though:
https://developer.apple.com/library/mac/documentation/Darwin...
seems to suggest it's not.
I don't want Dropbox to be able to see the contents of my file system at their end.
[0] https://wiki.archlinux.org/index.php/Dropbox#Setup_EncFS_wit...
But I wonder why we don't have application isolation as a basic design principle. Imagine an OS where applications/serices each get their own mini-filesystem, without ability to access each other's data. Would that work?
Edit: And the modern sandbox modes in Windows and OSX.
At least in the case of Android, there is no permission that will give you access to the root filesystem or other apps' sandboxes. Categorically not allowed.
App data is restricted to /data/data/$PACKAGE_NAME. The rest of internal storage is either read-only or completely off-limits (especially in the case of other apps' data). The only way to access data that belongs to other apps is to share the same developer signing key, or explicitly share the data using a content provider.
The only exception is external storage (the SD card, if present). But that's because SD cards use FAT and therefore can't support per-application permissions.
OS X does this for sandboxed apps:
https://developer.apple.com/library/mac/documentation/Securi...
All apps from the App Store are sandboxed.
Red Hat Linux tried a variation of this with the SELinux policy that preceded the 'targeted' policy (I forgot its name). Processes that did not have a policy adding permissions would be allowed to virtually read/write nothing.
The net result was that nearly everyone switched off SELinux.
Afterwards, Red Hat worked in the opposite direction. In the so-called 'targeted' policy processes are allowed to do what a normal UNIX process is allowed to do, unless there is a policy defined for them. Since they provide policies for commonly used daemons it adds security, while not making life too hard for sysadmins. Net result: most people keep SELinux enabled and have safer systems.
Android does this for all apps, as does iOS. MacOS is also doing it for apps downloaded from the App Store.
On the server side, that's also one of the things that Docker gives you.
The idea is not sandboxing, it's "multiverse". Each process, even an OS one, gets its own little filesystem, and connects to a limited set of interfaces explicitly permitted by the user (and that can be audited by the user).
You could make the same argument about a vulnerability in the OS itself. There's nothing magic about kernel code that gives it extra protection here. :)
In fact, I'd argue that the most probable attack against Docker would already be via a vulnerability in the OS. Docker uses a lot of kernel-level technologies, like cgroups. Beyond that, the most likely way to escape a Docker sandbox would be by finding a buggy syscall, since these weren't always designed with containers in mind.
This presentation is a good overview of Docker's attack surface: http://www.slideshare.net/jpetazzo/linux-containers-lxc-dock...
> Each process, even an OS one, gets its own little filesystem, and connects to a limited set of interfaces explicitly permitted by the user (and that can be audited by the user).
That would be an interesting research project, at the very least. You'd probably have to rewrite much of userspace, since it breaks many of the assumptions the current generation of system tools rely on.
Applications only get the data handle for specific files, after being authorized to do so.
Sandboxing is a good idea. An old idea, actually; chroot was added to unix in 1979. But shared filesystems evolved and are the norm, and even if many apps could be sandboxed, Dropbox exists outside the sandbox for a reason.
Getting a list of files from the good old /Torrents directory that everyone has, but pretends they dont can be incriminating enough to raise some very serious privacy issues. They can explain this any way they want, but Dropbox certainly has no business accessing any files outside of its config and its sync folders.
Which is not cool either
I'm going to stop using Dropbox now.
Very interesting wording. I don't want to play conspiracy theory, but it only says what will sync to the computer. It doesn't say anything about what will sync (or upload) to the cloud.
But you don't know. The lesson to be learned here is that proprietary software cannot be trusted.