Blog Archives

Dropbox hack blocked by Apple in Sierra

tcc-rootless

With the release of the latest version of the Mac operating system, 10.12 macOS Sierra, it’s pleasing to see that Apple have fixed a bug I reported against El Capitan in October of last year, and wrote about on this blog here and here.

The TCC.db is now under SIP, which means hacking the Accessibility preferences is no longer possible.

The bug basically allowed anyone to circumvent the authorisation warning to place an app in the list of Accessibility apps in System Preferences > Security & Privacy. It still required sudo, but an app (Dropbox being the most high profile offender) that got your admin credentials in other ways could insert itself into Accessibility and make it almost impossible for the user to remove.

Users can still alter Accessibility in the normal way (through Sys prefs GUI), but trying to hack the SQL database via Terminal now returns:

Error: attempt to write a readonly database.

Looking at xattr in Terminal for /Library/Application\ Support/com.apple.TCC confirms this with the reply:

com.apple.rootless: TCC

Hopefully, this fix will be ported to EC as well. At the moment, it’s still possible to run this hack in OS X 10.11.6.

🙂

Advertisements

discovering how Dropbox hacks your mac

Screen Shot 2016-08-26 at 23.05.27

Update: Dropbox hack blocked by Apple in Sierra

Following my post revealing Dropbox’s Dirty Little Security Hack a few weeks ago, I thought I’d look deeper into how Dropbox was getting around Apple’s security.

After a little digging around in Apple’s vast documentation, it occurred to me to check the authorization database and see if that had been tampered with. According to the docs:

In a policy-based system, a user requests authorization—the act of granting a right or privilege—to perform a privileged operation. Authorization is performed through an agent so the user doesn’t have to trust the application with a password. The agent is the user interface— operating on behalf of the Security Server—used to obtain the user’s password or other form of identification, which also ensures consistency between applications. The Security Server—a Core Services daemon in OS X that deals with authorization and authentication—determines whether no one, everyone, or only certain users may perform a privileged operation.

The list of authorization “rights” used by the system to manage this “policy based system” is held in /var/db/auth.db database, and a backup or default copy is retained in /System/Library/Security/authorization.plist.

Looking at the default with

defaults read /System/Library/Security/authorization.plist

we can find that there is an authorization right for System Preferences’ Accessibility list, which says:

"system.preferences.accessibility" = {
class = user;
comment = "Checked when making changes to the Accessibility Preferences.";
group = admin;
shared = 0;
timeout = 0;

That file’s comments also state that “The allow-root property specifies whether a right should be allowed automatically if the requesting process is running with uid == 0. This defaults to false if not specified.”

In other words, if allow-root isn’t explicitly set, the default is that even a process with root user privileges does not have the right to perform that operation. Since that’s not specified in the default shown above, then even root couldn’t add Dropbox to the list of apps in Accessibility preferences. Is it possible then, that Dropbox had overriden this setting in the auth.db? Let’s go and check!

To see what the current policies are, you have to actually read the sql database in /var/db/auth.db. There’s various ways of doing that, but the easiest for me was to access auth.db through the command line using the security tool. Issuing the following command in Terminal will return us the currently active policy for Accessibility:

security authorization read system.preferences.accessibility

On my machine, this returned:

Screen Shot 2016-08-26 at 20.57.12

Root wasn’t allowed to override Accessibility, and authenticate was on, so it couldn’t be this way that Dropbox was hacking my mac.

Security on OS X is a complex beast, however, and there are other authorization protocols at work. One that I already knew of is tccutil. If you issue man tccutil in Terminal, you’ll see this:

tccutil(1) BSD General Commands Manual tccutil(1)

NAME
tccutil — manage the privacy database

SYNOPSIS
tccutil command service

DESCRIPTION
The tccutil command manages the privacy database, which stores decisions the user has made about
whether apps may access personal data.

One command is current supported:

reset Reset all decisions for the specified service, causing apps to prompt again the next time
they access the service.

EXAMPLES
To reset all decisions about whether apps may access the address book:

tccutil reset AddressBook

Darwin April 3, 2012 Darwin
(END)

I had heard of a hack of this utility that was related directly to adding apps to Accessibility list over a year ago when I stumbled across this stackexchange page. In short, what that hack suggests is that you modify tcc directly by inserting an entry into the sql database located here /Library/Application Support/com.apple.TCC/TCC.db.

You can read the current list with the command:

sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db 'select * from access'.

To insert an app in the list, you grab it’s bundle identifier (in the case of Dropbox, that’s com.getdropbox.dropbox), and issue:

sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db “REPLACE INTO access VALUES(‘kTCCServiceAccessibility’,’com.getdropbox.dropbox’,0,1,1,NULL, NULL);”

(*note the code given on the stackexchange page isn’t quite correct for the latest builds of the mac operating system, in which the access table now has 7 columns and so requires and extra “NULL” on the end as shown above).

I tested this with several of my own apps and found it worked reliably. It’ll even work while System Preferences is open, which is exactly the behaviour I saw with Dropbox.

It remained to prove, though, that this was indeed the hack that Dropbox was using, and so I started to look at what exactly Dropbox did after being given an admin password on installation or launch. Using DetectX, I was able to see that Dropbox added a new folder to my /Library folder after the password was entered:

Screen Shot 2016-08-26 at 21.36.35

Screen Shot 2016-08-26 at 21.37.09

As can be seen, instead of adding something to the PrivilegedHelperTools folder as is standard behaviour for apps on the mac that need elevated privileges for one or two specialist operations, Dropbox installs its own folder containing these interesting items:

Screen Shot 2016-08-26 at 21.40.45

Not one, but three binaries! I wonder what they do? The first thing I did on each was to run the strings command on them. I still haven’t determined what that 1.5MB DropboxHelperInstaller binary is doing (that’s pretty big for a binary for a helper app), but its jam-packed with strings relating to file compression and encryption. The string output for dbfseventsd binary didn’t reveal anything much interesting, but with the deliciously named dbaccessperm file, we finally hit gold and the exact proof I was looking for that Dropbox was using a sql attack on the tcc database to circumvent Apple’s authorization policy:

Screen Shot 2016-08-26 at 23.05.27

This is all the more telling when we look at what Dropbox themselves say when queried about why their app is in the list of Accessibility apps here. After a great deal of obfuscation, misdirection and irrelevance in which they mention everything about permissions in general and nothing about Accessibility in particular, or that they’re hacking their way into the user’s Accessibility list rather than going through the supported channel of presenting the user with a dialog box and asking for permission, comes this line:

we need to request all the permissions we need or even may need in the future.
(my emphasis)

Ostensibly, that’s in the context of Drobpox on mobile apps, but since the question isn’t related to mobile apps at all, I think interpreting anything said there as being honest is naive at best. What I do suspect, especially in light of the fact that there just doesn’t seem to be any need for Dropbox to have Accessibility permissions, is that it’s in there just in case they want that access in the future. If that’s right, it suggests that Dropbox simply want to have access to anything and everything on your mac, whether it’s needed or not.

The upshot for me was that I learned a few things about how security and authorisation work on the mac that I didn’t know before investigating what Dropbox was up to. But most of all, I learned that I don’t trust Dropbox at all. Unnecessary privileges and backdooring are what I call untrustworthy behaviour and a clear breach of user trust. With Apple’s recent stance against the FBI and their commitment to privacy in general, I feel moving over to iCloud and dropping Dropbox is a far more sensible way to go for me. For those of you who are stuck with Dropbox but don’t want to allow it access to Accessibility features, you can thwart Dropbox’s hack by following my procedure here.

🙂

Further Reading:

Dropbox hack blocked by Apple in Sierra

Revealing Dropbox’s Dirty Little Security Hack

Hackers steal over 60m Dropbox user account passwords

How keyloggers get around OSX Security

 

revealing Dropbox’s dirty little security hack

Screen Shot 2016-07-28 at 14.54.30

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:

AskForPermission

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:

Stop! Choose 'Cancel' !!!

Stop! Choose ‘Cancel’ !!!

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.

 

how to remove Dropbox green blobs

Screen Shot 2014-10-24 at 15.32.36

UPDATE: this method should no longer be necessary. See the Comments below for the latest.

If like me, you’re not impressed with Dropbox drawing huge green blobs all over your Finder windows without even asking, here’s a great tip from Zackary Corbett for getting rid of them. Run the following line in Terminal:

pluginkit -e ignore -i com.getdropbox.dropbox.garcon

And you’ll be blessed with some visual peace and quiet:
Screen Shot 2014-10-24 at 15.33.25
If you want to reverse the effect and enjoy the green blobs again, use this line:

pluginkit -e use -i com.getdropbox.dropbox.garcon

Thanks Zachary 🙂

%d bloggers like this: