Category Archives: 10.12

how to remove “Plugins Button” from Chrome





Update: DetectX v2.75+ now deals correctly with the Plugins Button adware and the instructions below are now redundant.  Just ‘Search’ and ‘Trash All…’ should be sufficient.



 

If you’re having trouble trying to remove the “Plugins Button” from Chrome because its ‘managed and cannot be removed or disabled’, then follow this procedure.

1. Launch DetectX and do a search. You should see at least 5 items. Do NOT click the Trash button yet.

2. Quit Chrome

3. In Terminal, execute this command* (you’ll need admin privileges)

sudo /usr/bin/profiles -P; sudo -K

If you see a single configuration profile installed with the profileIdentifier ‘org.superduper.extension’, then execute

sudo /usr/bin/profiles -D; sudo -K

to remove it.

Type ‘y’ when prompted.

4. Read the caveats below, and then if appropriate, in DetectX, now click the ‘Trash All…’ button.

5. Relaunch Chrome and check that all is well.

Caveats
* If you or the machine’s administrator are using ‘Managed Preferences’ and have profiles other than the one mentioned above installed, then do NOT use the ‘-D’ switch in step 3. You’ll need to identify the correct profiles. Use the -P switch to list the installed profiles and only delete the one with ‘org.superduper.extension’ identifier. Likewise, do NOT use the Trash All… feature in DetectX, which will remove the Managed Preferences folder***. Instead, double-click the items in DetectX’s window to open them in Finder and remove them manually that way.

** You’ll need to authorise the deletions when macOS asks you as DetectX doesn’t have the permissions to do that (a safety feature).

*** Note that the ‘Managed Preferences’ folder is a perfectly legitimate folder for server admins that have knowingly installed managed preferences for their users, or for those using Parental Controls. An application update for DetectX will be released shortly to more accurately target this issue rather than flagging the entire Managed Preferences folder.

how to quickly toggle Swift Compiler warnings





I thought I’d share this little AppleScript for anyone working with Xcode 8.3.3 and using Swift.

One of the things I find intrusive are the constant Swift Compiler warnings while I’m actually in the middle of writing a block of code (e.g, ‘…value was never used consider replacing…’). Well, yeah, it’s not been used *yet* …grrr!

However, turning off compiler warnings isn’t something I want to do either. It’s too easy to go into the build settings, turn them off, do a bit of coding, take a break, do a bit more coding…oh, three thousand lines later and I suddenly realize why Xcode hasn’t been correcting my mistakes all afternoon!

This script allows you to quickly and easily toggle the warnings from a hotkey, and just gives you a gentle reminder as to what you’ve done. Of course that won’t stop you forgetting, but assigning a hotkey for this script makes it painless to just turn warnings off and back on again as soon as you’ve got past whatever bit of code the compiler was complaining about.


Xcode unfortunately doesn’t have its own scripts menu, so in order to assign the script a hotkey, you’ll need to either make it into a Service with Automator or use a script runner like Red Sweater’s FastScripts.

#start
on sendNotification(aVal)

display notification "Suppress Warnings was set to " & aVal with title "Swift Compiler - Warnings Policies"

end sendNotification

tell application id "com.apple.dt.Xcode"
tell its front document
tell its front project
tell its front target
tell its build configuration "Debug"
set b to build setting "SWIFT_SUPPRESS_WARNINGS"
if b's value is "NO" then
set b's value to "YES"
else
set b's value to "NO"
end if
my sendNotification(b's value)
end tell
end tell
end tell
end tell
end tell
#EOF

If copying the code above doesn’t build, get the raw source from my pastebin here. Here’s how it looks in Script Debugger 6:

Enjoy! 🙂


how to create a bootable macOS installer

If you are preparing to install macOS on multiple computers, one of the things that can make your life simpler (and the waiting shorter) is a bootable USB installer.

The idea of the installer is that you only need to download the macOS Installer.app from the App Store once. Usually, when you run the installer after downloading it, it’ll delete itself and you have to go through the whole download process again on each machine or disk that you want to install macOS onto. By making a bootable USB drive, you simply plug the drive in to your mac, launch the installer app and tell it where to install the OS. You can repeat this as many times as you like as the installer will remain safe on your USB.

There are various ways to make a bootable USB installer, but they all involve the same process:

1. Download the macOS Installer from the App Store.
2. Run the createinstallmedia command from the Terminal, an AppleScript or a helper app.
3. Reboot your mac, choosing the newly created USB as the startup disk.
4. Run the installer.app from the USB.

Step 2 is where the fun is. The createinstallmedia command can be tricky to get right, particularly if you’re not familiar with working on the command line. For those of you that are, follow Apple’s instructions here.

For a little more convenience, I wrapped all that inside an AppleScript which will first ask you for the location of the installer, then ask you to choose the USB target.

For maximum convenience, I also wrote a free little Swift app I’ve dubbed ‘Boot Buddy‘ (cos “Create bootable macOS Installer Drive.app” just didn’t quite have the right ring to it..!) that will present the whole thing in a neat little user interface. Three clicks, more or less, and you’re done.

Boot Buddy doesn’t require an admin password to install, but you do need to provide an admin password to actually create the bootable installer as the createinstallmedia process has to be run as root. Boot Buddy doesn’t see or use this in any way whatsoever other than to start the createinstallmedia process or to cancel it (if you choose to do so); authorisation is handed off to macOS to take care of.

Boot Buddy requires macOS 10.11 or higher and can create bootable USBs from Mavericks, Yosemite, El Capitan, Sierra and High Sierra installer apps.











Share and enjoy! 🙂


BackupCam – a dash cam for your mac





The initial release of BackupCam has just gone live over on sqwarq.com.

The idea behind BackupCam is to keep a continuous, rolling video of the last few minutes of activity on your mac, in just the same way as dash cams in cars work.

There’s a couple of scenarios where this might be useful. If you’re working on a project where ‘undo’ doesn’t always work reliably or when you most need it to – Xcode, for example, can often let you get your project in a mess without offering you a clear path as to how you got there or how to get back, short of discarding all changes in a particular file – with BackupCam you’ll be able to see exactly how you got to where you are.

Similarly, BackupCam can also help you to review changes that you may not have noticed at the time – perhaps if you were distracted by something else happening, either on screen or off. This can help both as a security and a troubleshooting tool

BackupCam can record up to the previous 30 minutes activity, so may help you recover something that is missed even by Time Machine or other traditional file backup mechanism.

More details are over on the BackupCam webpage, but I’ll just note here that BackupCam can also be controlled by AppleScript, with all the flexibility that that offers. Here’s a sample script that checks whether the last recording was longer ago than the time interval set in BackupCam. If it is, it kicks off a new recording session:






BackupCam is still in the early stages of development (we’re calling v1 a beta), so please feel free to report any bugs or enhancments you’d like to see. At the moment, it requires 10.11.6 or higher and only records the main display. I plan to add support for multiple displays in a future update.

how to make Spotlight fast again

I’ve been wondering ever since Yosemite what Apple had done to mess up Spotlight. It used to be my go-to way to launch apps. Faster than LaunchPad, the Dock or, of course, trawling through the Finder.

But something happened after Mavericks, and things have only being getting worse with Spotlight, right up to and including into Sierra.

Not only has Spotlight been slowed down with ads and ‘suggestions’, but we’ve also even lost the choice of re-ordering search results priority in Spotlight preferences.

I find Spotlight is not only slower than before, but it doesn’t always return the hit I want even when I know what I’m looking for. For a while, I got into the habit of searching using mdfind and locate in the Terminal. Like Spotlight, these use an index based search so can return results very fast. Eventually, I got fed up of that, and wrote my own search tool and added it to FastTasks 2

All this is not good, and if you are seeing the same degradation in Spotlight’s usefulness as I have been, try unchecking the following Preferences and see if it works to get Spotlight back up to a useful speed. With these disabled, I’ve seen a remarkable improvement in Spotlight in macOS 10.11.6.

how to tell if iCloud Drive is up-to-date

icloud daemon status script
I tend to work on the iMac at home, then take an MBP to work. Several times I’ve thought iCloud had uploaded what I had been working on at home before I left, only to find that when I got to work, the old version was still the latest one on iCloud. Of course, I checked for the spinning little progress indicator, but apparently I either missed it or it didn’t appear.

To mitigate this problem, I came up with this script to tell me what iCloud daemon is doing. If files are pending update or being updated, it will indicate which ones. It will also tell me if the iCloud daemon is either idle or busy / not responding.

Get the iCloud Daemon Script from my pastebin

Enjoy! 🙂

how to keep track of XProtect & friends


Over on Sqwarq, we’ve just released a new security and troubleshooting utility, the Critical Updates.app.

This little tool will help you keep track of when Apple make changes to system config data like XProtect, Gatekeeper and the Malware Removal Tool. It will also alert you if there is a Security update in the App Store that needs to be manually applied.

Critical Updates is free for home use. Organisations wishing to license it for commercial-scale use should contact me through Sqwarq support.

how to stop Sierra sneakily downloading to your mac

screen-shot-2016-10-06-at-15-07-35

I’ve not been very happy with Apple this week. Not only are they mistreating developers, but they’re also mistreating their customers.

If you have chosen not to upgrade to Sierra for some reason, but your mac is both compatible and has enough disk space for the Sierra download, Apple’s servers may download the entire 5GB Sierra installer to your machine without asking you for permission first.

If you have data caps, or are on a plan that offers differential pricing depending on time of use, this could totally ruin your month.

If you want to ensure that Sierra does not silently download to your mac, you’ll need to uncheck the ‘Download newly available updates in the background’ option in App Store’s Preferences pane in System Preferences (see image above).

Who knew by ‘updates’ that Apple were going to include upgrades of 5GB when they ticked that box? Well, now you do!

Unfortunately, your decision not to upgrade to Sierra won’t stop Apple infecting your machine with it’s own little adware notification, and you’re likely to see this at some point or another:

 

Screen Shot 2016-10-04 at 22.06.30.png

Note that there is no option to say “Don’t remind me again”, so there’s no telling how often you’ll be irritated with this unwanted pop-up.

Hmm, whatever happened to old-fashioned good manners, aye Apple?  😉

 

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.

🙂

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

 

%d bloggers like this: