revealing Dropbox’s dirty little security hack
Update: also see Discovering how Dropbox hacks your mac
If you have Dropbox installed, take a look at
System Preferences > Security & Privacy > Accessibility tab (see screenshot above). Notice something? Ever wondered how it got in there? Do you think you might have put that in there yourself after Dropbox asked you for permission to control the computer?
No, I can assure you that your memory isn’t faulty. You don’t remember doing that because Dropbox never presented this dialog to you, as it should have:
That’s the only officially supported way that apps are allowed to appear in that list, but Dropbox never asked you for that permission. I’ll get to why that’s important in a moment, but if you have the time, try this fascinating experiment: try and remove it.
Ok, you say, no problem. We all know how to do that – open the padlock, un-click the checkbox. Click the ‘-‘ button to remove it from the list. Simple, right? Look there it goes, no more Dropbox in the the Preferences panel, right?
Wrong…like a bad penny it’ll be back again before you know it. Either log out and log back in again or quit Dropbox and restart it. Dropbox will surreptitiously insert itself back in to that list AND the checkbox will be checked. That’s the magic of Dropbox for you. If you don’t want to try it for yourself, watch me do it:
That leaves a couple of questions. First, why does it matter, and second, is there any way to keep using Dropbox but stop it having access to control your computer?
There’s at least three reasons why it matters. It matters first and foremost because Dropbox didn’t ask for permission to take control of your computer. What does ‘take control’ mean here? It means to literally do what you can do in the desktop: click buttons, menus, launch apps, delete files… . There’s a reason why apps in that list have to ask for permission and why it takes a password and explicit user permission to get in there: it’s a security risk.
Interlude: Contrary to Dropbox’s completely spurious “explanation”/obfuscation here, Accessibility has nothing at all to do with granting permissions to files. Accessibility frameworks were first introduced in Mac OS X 10.2 and expanded in 10.3 to allow control of user interface items via System Events and the Processes suite. As anyone can readily see, what that allows is GUI control just as if the program or script was clicking buttons and menu items.
But perhaps you implicitly trust Dropbox to not do anything untoward. After all, they’re a big name company who wouldn’t want to upset their customers, right?
There’s two flaws in reasoning that way. One: the bigger the name, the less effect customer dissatisfaction has. Let’s face it. If a 1000 people read this post and stop using Dropbox because of it, it’s not going to make much difference to Dropbox. So assuming you can trust a “big name” company not to “feck you off’ because they might lose your business is not “smart computing”, even less smart if they figure that you’re a customer on a free plan anyway… :p (See this for more reasons why big companies in general don’t pay much attention to ethical values). Two, and more importantly, you already have hard proof that Dropbox can’t be trusted. It just overrode your and Apple’s security preferences without asking you, and – as you’ve seen if you tried to remove it and noticed its magic reappearance act – it disregards your choices and re-inserts itself even after you’ve explicitly removed it (we’ll sort this naughty behaviour out in a minute).
It matters for another reason, too. Let’s assume for the sake of argument that Dropbox never does any evil on your computer. It remains the fact that the Dropbox process has that ability. And that means, if Dropbox itself has a bug in it, it’s possible an attacker could take control of your computer by hijacking flaws in Dropbox’s code. Of course, that’s entirely theoretical, but all security risks are until someone exploits them. The essence of good computer security and indeed the very reason why OSX has these kinds of safeguards in place to begin with is that apps should not have permissions greater than those that they need to do their job.
Which is the third reason why it matters: Dropbox doesn’t appear to need to have access to Accessibility features in order to work properly (update). I figured out what Dropbox was up to in October 2015. Why has it taken me this long to write about it? First, because after having reported it to Apple Product Security at that time, I wanted to see if they would force Dropbox to change this behaviour (they haven’t…yet ;)). Second, because the only way I could be sure that DB didn’t need to be in the list of apps with Accessibility privileges was to test it over a period of time. I use Dropbox across 3 different macs and an iPhone. I haven’t experienced any issues using it whatsoever while denying it access to Accessibility. Caveat: I haven’t tested Dropbox against all of OSX’s Accessibility features, but certainly for a ‘standard’ set up of OS X, it is not needed – and, let me repeat, even if it were needed for some particular feature to work, Dropbox should have explicitly asked for this permission, like every other app, and obeyed the user’s decision to revoke that permission when removing it from the list of allowed apps.
There really isn’t any excuse for Dropbox to ride roughshod over users’ security and preference choices. So that leaves us with just one last question: how to get Dropbox out of there? The short answer is that you first quit Dropbox, then remove it from the Accessibility pane, then delete the DropboxHelperTools folder (see my procedure here). Relaunch Dropbox, but now you hit ‘Cancel’ when it asks you for an admin password:
The dialog box apparently lies (again, still trusting this big name firm?) when it says Dropbox won’t work properly and clearly deceives because this is NOT the dialog box that Dropbox should be showing you to get access into Accessibility. Indeed, even with your admin password, it still shouldn’t be able to get into Accessibility. Clearly Dropbox’s coders have been doing some OS X hacking on company time.
Now, there’s a slight catch. So long as you never give Dropbox your admin password, it won’t be able to install itself in Accessibility and you can keep on using Dropbox just as you have done before. However, it will throw up this dialog box on every restart of the machine or relaunch of Dropbox. So the catch is that you have to actually notice what’s asking you for your password and not just blindly throw your password into the box without looking. :O
But you shouldn’t be doing that anyway, of course, cos that’s not good security practice… 😉 , but given that the dialog box looks just like*** an authentic password request from the OS itself, that may be a habit you have to train yourself into.
Slightly annoying, but not as annoying as having an app hack your mac (of course, if you forget, you’ll have to go uninstall Dropbox again, remove it from Accessibility, then reinstall it).
***But not “like” enough – note the ‘Type your password…’ sentence is both misaligned and is spaced into a separate paragraph, unlike genuine authentication requests from OS X. The phrasing of the first sentence “your computer password” is also very “un-OS X”.
Further Reading: Discovering How Dropbox Hack’s Your Mac
Last edit: 21 Sept, 21:35 ICT.
Posted on July 28, 2016, in El Capitan, Security and tagged Dropbox, security. Bookmark the permalink. 36 Comments.
Never knew this!!!! Thank for exposing it…
Moreover, why is OS X/macOS granting an app accessibility privileges without requiring the proper dialog box?
If Dropbox can do this, then any app can. What’s the point of having a built in dialog box to protect against this sort of thing if any app developer – including bad actors – can just short cut around it?
This has highlighted a poor ethical decision on Dropbox’s part, and a security issue on Apple’s part. Let’s hope both get fixed.
Really interesting series of articles. I note that v2.01 of SQLite Database Browser, found via http://sqlitebrowser.org also added itself to the accessibility enabled app list (though not checked). The latest version does not appear to do this though. Thanks for highlighting this. Time to move on from Dropbox.
Skype has a “Share Desktop”-feature. I suppose Accessability is needed for this
So this happened to me recently. I was part of a Dropbox business account in my company and when I switched teams, the admin of the business account removed me from the account. And instantly, my Dropbox folder from my Mac was deleted, no prompts or anything. It was scary how An application could simply do that; your article explains HOW it’s possible. The business use case makes sense and that’s how they’re making it happen.
Thanks for the info..ill save it to Dropbox…not really!
The macOS security dialog need to be more than a regular UIWindow, it should display some extra infos to prove it’s authenticity.
I guess I now know the answer to the question “what if an app put up a admin password dialog that looks just like the system one?” which has occurred me several times in the past. Annoyingly, probably even as I was looking at Dropbox’s fake dialog.
One more thing you can do to thwart Dropbox. After removing DropboxHelperTools, make sure that it won’t get recreated again, by putting something in its place and making it immutable:
$ sudo touch /Library/DropboxHelperTools
$ sudo chflags schg /Library/DropboxHelperTools
It’ll still prompt you to enter your password, but even if you forget and reenter your password, Dropbox won’t be able to remove that file and recreate its directory.
And if that unsightly zero-length file bothers you in the GUI, you can always hide it:
$ sudo chflags hidden /Library/DropboxHelperTools
Can anyone suggest better mannered alternatives to Dropbox? Other than iCloud that is?
Skype.app is also shows up in the Accessibility prefs on my Mac. I can’t see why Skype needs this either …
With Skype, it might be a trick they use for sharing screens—I’m not sure, though.
This article needs more exposure. Apple or DropBox need to take responsibility before this causes a huge problem.
Isn’t another possible solution to change your admin/root pw?
How long, though, until they find a way to block that from working?
Who? Apple? Oh, not long, I think…
I’ve long wished that the dialog prompts for your password would more clearly state what permissions the app was asking for – and have the OS enforce them.
Good catch. Well thats Dropbox gone from my system for good, shame. Totally agree with Beatrix too. Surprised that anti virus apps like the Mac Avast have not added some kind of shield to alert against this “known” hack / spoof.
If an app can do this without the system throwing up a dialog warning you about it, then I’d say macOS (née OS X) is partially at fault.
There’s a hack that attackers can exploit using SQL injection to place their own apps or processes in Accessibility. I’ve known of it for at least a year, so Apple must be aware of it. They haven’t done anything to stop it. I’m not sure if that’s the way Dropbox are doing it or if they’re using an undocumented API, but either way, I’d say its bad behaviour for a responsible developer.
Yeah, looks like DB uses this to get in Accessibility. Check out the /Library/DropboxHelperTools/dbaccessperm sigh.
So as long as we are on the subject of Accessibility, why does FastTasks 2 appear there?
If you use the Firewall function in FT2’s menu, it will ask you for permission to be added to Accessibility. This is clearly stated in the Support page. If you don’t use that function, you don’t need to add FT2 to Accessibility and it won’t ask. It doesn’t have the power to do anything once it is in there either, except click the on or off button in the Firewall pane (and it still requires a further password authorisation even to do that).
Unfortunately, it seems just plain reinstalling isn’t enough. I tried it and Dropbox just picked up my old preferences and assumed permission, and it’s back in the Accessibility box. Next attempt: a clean install.
The trick is to remove
/Library/DropboxHelperTools, which includes the ‘dbaccessperm’ binary.
It still doesn’t work. First, there is no /Library/DropboxHelperTools in my computer (Mac OS 10.11.6). Second, even if I use an app like AppCleaner to remove the vestiges of Dropbox, the installer still asks for my admin password to begin the download. (I’m not downloading it for the admin user.) If I quit, the download and install stop.
I think you’re confusing different requests for authorisation. The only one you have to avoid is the one that is worded exactly like the one in the post above. You may have to provide your password to OS X to put the Dropbox.app into /Applications and possibly to download it at all, depending on your permissions.
There’s also a link the post above which will take you to an Apple discussions page where uninstalling Dropbox is discussed. Scroll down to read the entire thread.
Having said all that, I’ll update my post with a complete procedure for uninstalling Dropbox over the weekend. Don’t quite have the time to do that right this minute (there’s a quick & dirty guide below, though).
Update: Sorry, was looking for the DropboxHelperTools in the wrong Library! Deleting it also has no effect. I can’t figure out where it’s picking my username/password from. And it’s back in Accessibility!
How to remove Dropbox from Accessibility prefs:
Since writing this post and the follow up to it showing how Dropbox hacks your mac, I’ve discovered a simpler way to thwart Dropbox’s insistence on being in Accessibility:
1. Quit the Dropbox app in the status bar.
3. Remove Dropbox from Accessibility in Sys Prefs Security & Privacy
4. Log out and log back in to your mac user account.
5. After that, you should see this (screenshot below); press ‘Cancel’ – and you’re done*.
*Note: Dropbox will continue to throw this dialog at you on each launch.
Thanks for the work and the explanation.
I guess I’ll neuter Dropbox and will rewrite my own startup script to get rid of that dialogue. Should be start Dropbox via shell command and dismiss the dialogue with tailored apple script commands.
I have better solution:
1. Remove executable and suid bits and lock dbaccessperm file.
sudo chmod -sx dbaccessperm
sudo chflags uchg dbaccessperm
2. Remove (just uncheck) accessibility permission for Dropbox via System Settings.
Thanks for the persistent research and thorough documentation. After performing these steps and verifying that Dropbox was removed from the Accessibility prefs, I noticed that there is still an entry related to Dropbox in the TCC database.
Should we consider also deleting the related rows from TCC.db?
I’ve never looked at TCC.db before so I’m curious about apps which have long been uninstalled but still appear in this db. Is it good security practice to remove unused apps from this DB?
No, I wouldn’t consider that necessary. And although you could do it now, I have a feeling we may soon see changes to TCC.db that won’t make that possible, in any case.
Even worse than Dropbox’ shenanigans is Apple’s reaction. They should enforce that changes like this aren’t possible. If Dropbox can do this any other app can do this, too.
Apple can’t really avoid stuff like this on the Mac – it’s not as easy as on iOS – if the user is giving admin privileges to an app – it can do pretty much anything it wants. Unless you want to turn macOS into iOS, this isn’t going to change.
Apple can, and in many places already do: