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.
To help ameliorate that, I’ve produced a script that will abort a scheduled backup task using Carbon Copy Cloner if a user-defined percentage of changes have occurred in a designated ‘Canary’ folder.
Here’s how it works. In order to be successful, ransomware must change a large percentage, if not all, of your personal files in your Home folder by encrypting them. That means we can determine if a folder has been encrypted by looking for an unusual amount of changes or additions since the last backup.
A Canary folder is a folder that we use to warn us of precisely that. It should be a folder that contains some random dummy files (.doc, .png, .xls files etc), and/or a folder which you don’t make large changes to from one backup to the next. The script itself will change the folder slightly each time it runs, to ensure that the Canary folder does not look like it’s ‘stale’ (which might cause an attacking script to ignore it).
The key to the Canary is that the percentage of files changed or added on each scheduled backup is less than the threshold you set in the script. The default is set to no more than 10%. If the number of files changed or added is higher than that, then the backup aborts. You can of course change the default to a bit higher if you use a ‘real’ folder that you don’t change often, but remember we’re only talking changes between one scheduled backup and another, so it will also depend on how frequently your backups are scheduled.
For example, I have a 2-hour scheduled backup and I use my ‘Documents’ folder as the Canary. Since I only use that folder for long-term archives, it is actually rarely changed, and certainly never as much as 10% within 2 hours, and that makes it a perfect choice as a Canary. You can pick any real, rarely used folder or you can set up a complete dummy folder if you prefer.
If you do pick a real folder, keep in mind its size. The larger the folder, the longer it’s going to take the script to determine the differences between it and the last backup of it. A couple of thousand files is OK, but once you get into the tens of thousands you might find the script takes several minutes to complete. With only a few hundred files in my Documents folder, it takes literally a second or two.
Here’s a sample output from the log file the script produces in the ‘Canary’:
Destination /Volumes/Backup Disk/Users/phil/Documents has 360 files in the folder. There are 3 changes between it and the source /Users/phil/Documents. The threshold for aborting the task is 10 percent, or 30 changes. Result: task will run.
For our strategy to be successful, we need to ensure the attacking script doesn’t ignore the Canary and does try to encrypt the Canary before the next backup is scheduled. For that reason, if you opt for a complete dummy folder, you might like to give it a name so that it’s somewhere near the beginning (alphabetically) of your Home folder. Since the Canary folder will be slightly modified each time the script runs, it should get hit early if the attack is looking either for recently modified files or just starts trawling your home folder in ascending name order (and I know what you’re thinking: what about descending order? Sure, you could add another Canary at the end, and modify the script to check both ;)).
Note that this script is for use only with a regular, scheduled backup task, and only for use with Carbon Copy Cloner (version 4). We’ll be posting about Time Machine strategies later.
Another note of caution is that while this script should stop your scheduled CCC task from infecting a backup drive, it won’t stop an attacking script from attempting to encrypt any mounted drives it finds by itself. That really depends on the sophistication of the attack. To that end, we’ll soon be posting a general strategy for detecting a ransomware attack on your internal drive using multiple Canaries and a bit of Folder Action script magic. Stay tuned for that.
In the meantime, here’s the script. Due to the vagaries of WordPress.com formatting, I’ve hosted it over on my pastebin. Please read the extensive comments, which also explain how to set it up and how to use it. Any questions, drop a comment below. 🙂
Picture Credits: ‘Caged Egg’ by Marije Berting
Yes, two in two days! We’ve added a Preference Pane since yesterday, and improved the performance of the search function. Note that the new Sparkle Vulnerability check we introduced in v2.13 is now off by default. It can be turned on from the Preference Pane (see above).
Other changes are listed in the release notes.
DetectX is still free, fully-functional, and without time-limit for home users. Available for download from here.
We’ve just released DetectX for Snow Leopard v2.1 (DetectXSL), a long-awaited update that fixes, among other things, the bug in the updater mechanism.
If you have problems either downloading or installing the update from within DetectXSL*, please delete the DetectXSL.app (v2.0) from your mac and download and install v2.1 directly from here (direct download).
Now that we’ve got a working install of 10.6.8 again in the Sqwarq office, we’re planning on updating DetectXSL a bit more frequently, though working in Xcode 3 again is proving to be a bit of a memory challenge!
(and for you more up-to-date folks, don’t forget DetectX runs on everything from OSX 10.7 thru 10.11).
*requires 10.6.8, Intel, 64-bit architecture
The quickest way to get out of a persistent popup that won’t go away (unless you do what it demands!) is to quit or force quit* the browser then restart Safari holding down the ‘Shift’ key.
Holding down Shift allows Safari (or any other app) to restart without resuming its last state.
While this is a great, fast way to solve the problem, it can be annoying if you had other tabs open, and you don’t want to loose those too (or any unsaved data they may contain).
1. Go to Terminal and paste this command (it’s all one line):
2. Reopen Safari
You’ll get all your tabs back including the hijacked tab, but the pop up won’t appear, and you can now close the hijacked tab.
(alternatively you can do that in Terminal).
Don’t forget this step, or you’ll think the web is broken!
*You can force quit an app by pressing the following keys in combination on your keyboard <command><option><esc> then choosing the app you want to quit.
Another day, another raft of apps removed from the iOS App Store. Well, actually it’s not quite that bad, but it does seem to be getting a bit more common.
In any case, Apple have just released this statement:
“Apple has removed a few apps from the App Store that install root certificates that could allow monitoring of data. This monitoring could be used to compromise SSL/TLS security solutions. If you have one of these apps installed on your device, delete both the app and its associated configuration profile to make sure your data remains protected.”
The only minor problem being they haven’t actually named which apps have been removed, making it sort-of impossible to follow their advice.
Not to worry. You can tell if you have one of the not-mentioned apps simply by going to
Settings > General and looking for the Profile option.
If you don’t see ‘Profile’ anywhere in the list, then you can rest easy. You don’t have any of those apps.
If you do see ‘Profile’ in the list, look at what’s in it. Anything you don’t recognise should be removed. There shouldn’t be anything in there that you didn’t explicitly approve of and know about.
Anything you do recognise but are not sure if its safe, contact the developer and/or Apple directly.
Keeping an eye on General > Profiles is a good idea. We recently found a website that will download a config profile and install apps to your iOS device without that device being either Jailbroken or requiring you to enter an AppleID for the download.
Fair enough, it does require the user to click-through a few “do you want to trust this…” type dialogue boxes, but that’s hardly child-proof. If you’re a parent who lets your children use your iOS devices without constant surveillance like most of us, that’s a real security issue (and yet another reason why we at Applehelpwriter insist user accounts is a must-have feature Apple need to implement in iOS sooner rather than later).
Back in the days of Mountain Lion when Apple introduced GateKeeper, a lot of talk was heard about the best way to protect your mac being to only download apps from the App Store. With several hundred malware infected apps discovered in the App Store last month alone, what’s clear is that leaving your security up to someone else (even if its Apple) is short-sighted at best, and disastrous at worse, particularly if your reliable source just happens to be of great interest to hackers (especially if its Apple!).
Rather than relying on others for your protection, the solution is to have a system in place that will protect you and allow you to recover completely and quickly regardless of the source of the infection. In this post I’m going to share with you (part of) my security set up. Of course, at least in part, it uses my own s/w (if I can’t trust my own software, who can? And besides, my s/w is free!), but there are other ways to achieve the same thing. What’s important is the process, rather than the particular tools mentioned to implement it.
I’ll break these five essential security tips down into two parts, protection and recovery. However, if this post looks too intimidatingly long, skip to the end where I summarise the essential points in the TL;DR. OK, here we go:
1. Log changes to your system
I achieve this with my app DetectX (my app FastTasks 2 also does this, but DetectX is better at it). I have DetectX (v2 or higher) in my Login Items. This means every time I login, DetectX reports what’s changed on my system. If you’re starting from a clean bill of health as hopefully you are now, this is vital information in tracking down what’s changed when new trouble begins.
If I don’t log out at the end of the day, I run DetectX the next day, and I always run it after downloading and installing any new software. That means I have a record of what that s/w has done and I know exactly how to uninstall it if I need to.
Incidentally, as soon as you’ve launched DetectX and taken a note of any changes (signalled by the yellow alert triangle), you can quit it. It doesn’t need to be running. It just needs to launch and scan (literally, takes a second) and then quit.
2. Do NOT use your AppleID for your admin account password
Use a unique password for your Admin user account and do NOT allow the options for the user to reset the password using AppleID or to administer the computer using your AppleID. This is a massive security flaw (this setting is made in System Preferences > Users & Groups). Your AppleID is hackable and indeed there has been at least one famous case of a Wired journalist who had his entire mac wiped in front of his eyes while sitting at home by a hacker who had ascertained his AppleID.
3. Use a Password manager
I use 1Password myself, but any similar product will do. The point is that i. you’re not using the same credentials on more than one site and ii. that you’re using passwords whose length and structure is uncrackable. No matter how ingenious you think your passwords may be, trust me if you made them up yourself they are not. Do a search on ArsTechnica.com for “password cracking” and weep at the ease with which this is possible. A password manager is the only sensible solution.
If you care at all about your data you need to invest in a structured backup system. Simply plugging in Time Machine isn’t sufficient since, as many have already discovered, TM will back up all the ‘infections’ along with everything else. When you try to recover, you just end up re-infecting your machine.
This is what I do.
4. Use a variety of both clones and Time Machine on a staggered schedule
I have a TM disk always connected. On top of that, I clone my entire internal HD on Wednesday and Saturdays. This clone is NOT connected to the mac except during backup. I also clone my HD onto a separate disk once a month. Again, this disk is never connected to the mac except when I’m backing up. (I use an app called Carbon Copy Cloner to manage these schedules.)
If any one of these disks gets ‘infected’ or just dies out of natural usage, I’m covered. If I were to get some kind of infection, I’ve got known clean backups for at least one month. So long as the problem manifests itself within that period, I can simply boot from a clean clone and diagnose the problem using the tools mentioned above in PROTECTION. I can then clean my TM Disk and any others once I’ve determined the problem, and of course then I haven’t lost any backup data.
5. Consider CrashPlan or similar online recovery service
I don’t use it myself because I consider my user behaviour as very low risk and my precautions adequate, but if I were either less technically inclined or without the time to manage a system like I described above, CrashPlan is a way to insure yourself without the hassle, (albeit at a cost, so you need to weigh that up). In particular, what I like about the CrashPlan idea is that it offers you protection against ransomware threats (not that we’ve had any serious ones on the mac yet, but I wouldn’t bet against these appearing in the not too distant future). Note that services like CrashPlan are not at all the same kind of thing as Dropbox or iCloud, but the best way to find out more is to head on over to the CrashPlan page and read up on what they offer.
Those are the 5 essential things I think you need to do or consider, but let’s just round this off with some things that you probably don’t need to do.
Do you need AV Software?
Some people are adamant about using this kind of software because of its necessity on Windows machines, where there’s decades of reusable malware going around which makes this kind of app necessary.
On a mac, there isn’t that kind deep history of malware in circulation; the really dangerous stuff is perhaps only now just being written, and none of the AV tools will know about that until after the fact. In other words, any decent malware being written for macs now will get past all the AV vendors. Moreover, much of the worst of known malware is already blocked by Apple via OS X’s Xprotect system. That means your AV software isn’t really doing much other than what OS X is already doing for you.
The other problem with AV software is that its always running on your machine and slowing things down.
Finally, most AV software requires you to give it your Admin password and runs its processes in a persistent ‘super user’ or admin mode. That’s a security compromise in at least two ways. First, it means you are at risk from the AV software vendor if they are not trustworthy themselves. Second, it means your system is vulnerable to bugs or exploits existing in the security software. Hackers love nothing better than finding ways to compromise security software, and if a hacker can get into your machine through bugs in an AV program running on your mac with admin privileges, well, then, you are “pwned” as they say.:o
By way of contrast, DetectX doesn’t need to know about threats in advance; it will tell you whether something new has been added to your mac and where, regardless of what it is, so it will also spot even those kinds of “zero day exploits” that try to sneak malicious files onto your mac. DetectX doesn’t run any ‘always on’ processes or use any system resources in the background. Finally, DetectX doesn’t require you to give it an Admin password.
(Technical note: if you use the Trash function in DetectX, then OS X will ask for your password to trash files outside of your user account, but that’s not a request coming from my app, but from the system. Importantly, authorising that request only allows the system to do what you told it to do: delete the given file selected in DetectX. It cannot be hijacked to do anything else and the authorisation is single-use only. If you tried the same operation again it wouldn’t work without being authorised again).
Should I avoid updating my mac?
In short, no – you should always be on the most recently available update
for your release of OS X as updates almost always address security flaws that have come to light since the last update.
However, update doesn’t mean upgrade. Generally, if you’re going to upgrade (such as from Yosemite to El Capitan), do the upgrade on a spare external disk first and test that everything works OK. Whatever you do, do not just install an upgrade directly over your one-and-only copy of your HD. If you don’t follow the advice above about testing the new OS on an external drive, then at least make an external bootable clone (not Time Machine, too unreliable) of your internal HD first. Anything less is asking for trouble.
Pretty much the same advice can be applied to updates, certainly the early ones. It’s not unknown for a .1 or .2 update to break something serious. These kind of bugs get less likely as you get nearer .4 and .5 updates when everything is fairly stable, but it’s still never a bad idea to make a complete bootable back up of your system just before doing either an update or upgrade. That way, you’re covered whatever happens and can easily roll back to the previous version if necessary.
OK, if I wanted to sum up all of this into two simple golden rules for security and protection it wouldn’t be ‘use this app or that app’ or ‘only trust this source or that source’ it would be: educate yourself about how your mac works, where malicious files hide and keep an eye on those places on a regular basis. That’s what I wrote DetectX to do, but you can do it in other ways without using my app. Secondly, backup regularly and backup onto different disks on a staggered schedule so that you always have a clean, uninfected backup to turn to in case you need it.
Enjoy and share! 🙂