A Sign of the Times
Each year Apple brings new features to OS X. Features that aim to secure the system. Features that bring about discussions that suggest OS X is becoming a ‘Walled Garden’ like IOS and question “Why is apple making OS X more like IOS?”.
So, we now have Gatekeeper, Sandboxing and System Integrity Protection (aka rootless).
There’s no question that Apple takes security seriously, though I do sometimes wonder about some of the solutions they provide, such as SIP, which has made developer lives so difficult that some have abandoned development, whilst others use more nefarious methods:
As third-party developers of OS X applications and solutions, we have to take some responsibility to ensure that what we provide is also secure. Not only must we consider attack vectors in our own designs, but we should also be protecting customers via methods of deployment.
Unfortunately, many are falling short. As @patrickwardle has pointed out, popular applications are often distributed via the insecure http protocol, instead of https and are prime targets for MITM attacks
Each of these applications have been downloaded from developers’ sites, rather than Apple’s App Store, as it’s often the case that such applications fall short of Apple’s requirements. Features such as Sandboxing are sometimes just too restrictive, as well as not allowing the installation of kernel extensions.
Once an application has been downloaded, it often comes in the form of a package (pkg) file. Running the package displays the familiar dialog
It is at this point that most users are accustomed to simply selecting ‘Continue’ and why wouldn’t they? They’ve navigated directly to a developer’s site and downloaded the software they intended to install.
Take a look again at the Installer image above and see if you noticed something missing…
Here’s another, but this time, other than the text, what’s the difference?
I’m betting that most readers will have installed packages using similar dialogs to the first one and failed to notice the padlock (or lack of) in the top right corner, as can be seen in the second image.
The reason you may have missed it, is that it’s rarely there. If you see this padlock, it denotes that the package has been signed by the developer. We can click on it to display the certificate and be confident that the package hasn’t been modified since the developer created the package
Strangely, once this dialog is dismissed the padlock is no longer visible!
So, not only have users been downloading applications from insecure http sites, but the packages they download are often not signed.
So, what’s the big deal?
Almost all packages request Administrative Rights to install
As the user has chosen to install the application, they won’t think twice of providing admin credentials at this point.
A package not only has the ability to copy files to locations on the target disk, but they can run pre and post install scripts and the user has just given the package admin rights!
So, if the package isn’t signed, it’s not too difficult for an MITM attack to simply repackage the intended content with their own malware, run scripts and have instant root access, with little effort.
How to sign a package
Most applications developed for OS X are signed. Apple provides developers with their own certificate to do this and it’s simple to setup.
Apple provide a separate installer certificate to be used to sign packages.
There’s more than one way to create a package, but as an example, the command line utility pkgbuild can be used. Once a developer has acquired their installer certificate, it’s simple to ensure that a package is signed by appending the sign option to the call to pkgbuild
In this case, the text in quotes is the name of the developer’s certificate, which resides in their keychain.
That’s all there is to it; simple, right?
So why don’t all developers do this? Perhaps they’re unaware of both the availability of signing the package and the importance of it.
I can’t think of any valid reason for developers distributing packages not to sign them. When you next come across an unsigned package, be wary and shout about it; tell the developer and let them know why it should be signed.
After all, if it’s your application that was exploited, everyone will hear about it; don’t believe in the old adage “There’s no such thing as bad publicity”.
Gatekeeper Protects Users slide by @patrickwardle reproduced, with permission.
Title Icon by [Freepik](http://www.freepik.com/} from Flaticon licensed by Creative Commons 3.0