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

 

Advertisement

About philastokes

Independent Software Developer, Technical Writer and Researcher at SentinelOne. Explaining the unexplainable with images, video and text. Scripting anything imaginable in AppleScript, Bash, Python and Swift.

Posted on August 29, 2016, in 10.11, 10.12, Security and tagged , , , . Bookmark the permalink. 29 Comments.

  1. Thanks for this insight.
    I was already growing wary of Dropbox, but I am now going to cut all ties with db and only trust iCloud. Way to go!

  2. Let me also command you for this very interesting post and for letting me discover DetectX – I wish I had much earlier 🙂

  3. Thank you for this, and the previous, article. It’s Hard to come to any conclusion other than Dropbox is a great big RAT/Trojan horse.

    Long ago I was mesmerized by Dropbox’s shiny lights. Then the Condoleza Rice hire happened…. Then Snowden happened… I still figured storing limited non-sensitive data there was reasonably safe.

    I’m really not a privacy paranoid individual, or I’d have ditched Dropbox a long time ago…

    Now it turns out they’re not just one step away from my Dropbox data, but all my data. 😦

  4. Fabulous post. You didn’t say it outright, but Dropbox’ need for “future use” is nothing but a huge, whopping, ginormous backdoor in macOS.

    No wonder Edward Snowden warned in 2014 to “get rid of Dropbox”. https://techcrunch.com/2014/10/11/edward-snowden-new-yorker-festival/

  5. Very interesting research! I would love to know what other tools like Dropbox do in the same situation!

  6. Hi HN — Ben from Dropbox here on the desktop client team. Wanted to clarify a few things —

    – Clearly we need to do a better job communicating about Dropbox’s OS integration. We ask for permissions once but don’t describe what we’re doing or why. We’ll fix that.

    – We only ask for privileges we actively use — but unfortunately some of the permissions aren’t as granular as we would like.

    – We use accessibility APIs for the Dropbox badge (Office integrations) and other integrations (finding windows & other UI interactions).

    – We use elevated access for where the built-in FS APIs come up short. We’ve been working with Apple to eliminate this dependency and we should have what we need soon.

    – We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).

    – We check and set privileges on startup — the intent was to make sure Dropbox is functioning properly, works across OS updates, etc. The intent was never to frustrate people or override their choices.

    We’re all jumping on this. We’ll do a better job here and we’re sorry for any anger, frustration or confusion we’ve caused.

    • The dialog box you see is a native OS X API (i.e. made by Apple).

      You’re using Apple APIs to create the password request dialog box, but that’s coming from Dropbox.app not from the Finder or any OS X process as it misleadingly appears to be and as you seem to be misleadingly claiming right here.

      You say you only request permissions you “actively use”, and yet Dropbox appears to function normally when these permissions are not granted. Can you clarify exactly WHY Dropbox needs admin privileges (e.g., in what way do “built-in FS APIs come up short”, precisely?), and what are the executables in DropboxHelperTools folder actually doing?

      Why don’t you use the XPC Services methods for PrivilegedHelperTools like all other well-behaved OSX apps?

      Most importantly, why are you hacking the TCC database instead of throwing the correct, and authorised, Accessibility authorisation request?

      Your “clarification” looks like more obfuscation to me, sorry. 👎🏽

      • That password prompt is a SecurityAgent process. You’re really turning a pretty inconsequential discovery of a developer kind of being bad in not following OS X developer guidelines into some wild tinfoil conspiracy. Yikes.

        • You might be right, but I’m not convinced.

          This is what a real one looks like. Note the different wording and paragraphing. AFAIK (and I may be incorrect, granted), the developer doesn’t get to format the message of that dialog in the API. Or if they do, it’s remarkable how every one I’ve ever seen is worded and formatted exactly the same, except the Dropbox one.

          *NB: no, I didn’t let MalwareBytes into my PrivilegedHelperTools either, but at least if I did, I know it’s using the correct XPC Services API to gain elevated privileges.

    • Please let us turn off of that crap off and let us deny the request permission. Thanks!

  7. Don’t run strings with sudo!
    CVE-2014-8485 was a code execution vuln using the strings command.
    Parsing untrusted data can be very harmful!

    https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on-untrusted-files.html

    • Thx for sharing that! 👍🏼

      Isn’t that Linux only, tho?

      • This vuln was in GNU strings (binutils), OSX ships with BSD strings, which was not vulnerable to this particular vector. You can install gnu strings with brew on OSX with a:
        $ brew install binutils

        However this class of vulnerabilities could exist in any binary that parses untrusted data, its not limited to Linux. Its good practise not to elevate permissions for something simple like running strings. Use sudo to cp the file/chmod to a place that your user account can read it if needed.

  8. Hack? Malware? Hardly, this simply uses a standard privileged helper tool to circumvent normal accessibility approval method (where users have to manually go into System Preferences and approve the app).

    This “hack” was likely simply added to streamline the user experience. Approve Dropbox popup once and be done.

    There are tons of legitimate reasons to get accessibility privileges, such as controlling window focus, notifications or other interaction with the OS that doesn’t have other available API’s.

    I don’t see this being dangerous as you are still required to approve this change with your admin password (when you install the helper tool) but sure you can argue that it circumvents policies put in place by Apple and isn’t a clean, future-proof solution for such a mainstream app.

    But enough with the conspiracy theories and sensationalised headlines. This is hardly a reason to uninstall Dropbox.

    • Nobody mentioned malware, but it’s certainly a hack, and deceptive. It also refuses to obey user wishes – try removing it without taking the steps I’ve outlined.

      Nor is it a “standard privileged helper tool” by any stretch. Those use XPC Services and are located in a designated folder. Even XPC Services cannot override Accessibility authorisation.

    • I don’t know if you paid attention to the first article but Dropbox gets your username and password by using a fake permissions window. This is UNACCEPTABLE!
      They should not have access to this information!

  9. Interesting bit of research. Thanks. One thing to mention is that those binaries in DropboxHelperTools are installed setuid root – so they run with root privileges whenever they are invoked. This is generally a Very Bad Idea as it leaves open a path for system attack (depending on how well they are written, how well they sanitise any input, and how much you trust the app developer). I note that there’s nothing else from all the other applications I have installed that leaves setuid root files in /Library on my Mac.

  10. Thanks for bringing this shady practice to light. What are you thoughts on Dropbox alternatives like SpiderOak or syncthing with regards to security vs usability?

    Complete aside: What font is that in your terminal screenshots?

  11. I discovered your posts on this topic after I grabbed a screen shot and a Dropbox dialog popped up to ask if I’d like to share it via Dropbox. I suspect it was getting that information via the accessibility permissions, though I’m too lazy to verify. I certainly never opted into that behavior. So, I deleted Dropbox. Thanks for the information regarding what Dropbox is doing. It is quite sleazy regardless of whether it caused my specific problem.

    • Thanks J.J., I think you might be onto something there.

      It makes sense that Dropbox would need access to NSAccessibilityPostNotification in order to know when the user does something like take a screenshot so that it can then throw that nag window to store images in Dropbox.

      There would be nothing wrong with them doing that IF they had gone through the correct authorisation protocol. It remains a mystery to me why Dropbox chose to hack their users’ macs rather than just ask for permission like every other app that wants in to Accessibility.

      • Dropbox does not need the Accessibility APIs in order to know when a screenshot is taken. A more proper way is to use the FSEvents or kqueue APIs to monitor the screenshots directory (which can be retrieved via NSUserDefaults).

        Then, when a new screenshot is created in that folder, they will know.

        • Thanks for your comment. I haven’t looked into that as yet, to be honest, but I’ll take your word for it; nevertheless, the fact remains that certain notifications are only posted to apps that are listed as Accessibility apps. Presumably, Dropbox wants those notifications for something or other.

          None of which, as I’ve said, warrants backdooring their way into that list.

      • Dropbox does this because it uses the accessibility features of the OS in order to implement the Dropbox Badge [1] / Project Harmony feature.

        [1] https://www.dropbox.com/help/7672

        • Interesting. I had Dropbox Badge set to ‘Never Show’ and yet it still asked for my password on every launch and installed itself in Accessibility if given.

          When all’s said and done, the issue is not the reason, but the deception and the overriding of user preferences.

  12. Very interesting article. Thank you, you’ve given me something to think about.

%d bloggers like this: