Earlier this year, Apple introduced a new security measure called ‘Notarization’ to complement their existing strategies like Gatekeeper, XProtect, and the Malware Removal Tool. It would be fair to say that there’s been a bit of confusion and not a little pushback from developers about this new security measure. In this post, we’ll look at what Notarization is, why Apple have introduced it, and why it’s proving controversial among developers. We’ll also address the most important question for macOS users: will Apple’s Notarization requirement make your Mac more secure from malware? Let’s find out.
What is Notarization?
That should be a simple question to answer, but as we’ll see, Apple have been shifting the ground on this and a lack of clarity over what Notarization is and what it requires has caused some upset among the developer community.
According to Apple, Notarization is a process whereby all 3rd party software distributed outside of the Mac App Store must be uploaded to Apple’s servers and checked for malware. If the software passes Apple’s malware scan check, its details are added to Apple’s database of “safe” or at least “allowed” software. Developers in return receive an electronic “ticket” which can be attached to the software by the developer when they distribute it. Where Notarization is not yet compulsory (i.e., macOS Mojave), Notarized apps present a slightly different warning from Gatekeeper than unnotarized apps, which supposedly tells users that the software they are about to launch has passed Apple’s checks.
Put like that, Notarization sounds good for both users and developers. Users get extra confidence that apps they download are malware-free, and developers get a way to show users that their apps are safe. Sounds great, but there’s been a few wrinkles not only in implementation but also in design that have, shall we say, upset the Apple cart.
Enter The Hardened Runtime…Or Not
When Apple first introduced Notarization as an optional requirement in Mojave 10.14.5, it laid out very clear rules about what developers would have to do. One of the requirements was that developers build their software using something called the Hardened Runtime. This requires developers to jump through a few hoops to ensure they won’t lose necessary functionality and is signified by a flag in the codesigning certificate which tells the OS to treat the executable somewhat like Apple’s own SIP-protected executables. The existence of the flag will prevent other processes (like a debugger or decompiler) from attaching to it, prevent code injection, DLL hijacking and several other things.
As explained in Howard Oakley’s post “Notarization devalued?“, Apple later decided to encourage developers to have all their software uploaded and scanned by their Notary service, even software that would never be used on newer versions of macOS or which could not, for various reasons, be built with the new hardened runtime.
More recently, in yet a third change, Apple have temporarily dropped the stricter requirements that they originally insisted on.
In short, the only thing it now turns out that is required for Notarization is the malware check itself. There will be a fourth change in January 2020. At that time, Apple’s current intention is to revert back to the strict requirements initially announced.
Who’s Got A Ticket To Ride?
As mentioned above, when an application is successfully notarized, Apple also issues the developer with a “ticket” which they can then attach to their software prior to distribution. The ticket is basically there to take care of the situation when a user tries to launch a Notarized app but has no connection to the internet or Apple’s Notarization servers are down. However, many developers have balked at the clumsy tooling and inevitable delay between building, notarizing and receiving the ticket. The delay is currently only around a few minutes when everything is working properly, but if it’s not, it’s possible that developers may be stuck in limbo waiting for Apple’s servers to respond.
If you’re running Mojave 10.14.5 or later and you have the Xcode Command Line tools installed, you can easily do a quick check of which apps are notarized and stapled with a ticket in your /Applications folder like this:
for i in /Applications/* ; do stapler validate "${i}"|grep -B 1 worked;done
Tickets are, technically, optional. Developers don’t have to staple them to their software when they distribute their app, and doing so is cumbersome for automated workflows as indicated above. However, by not stapling the ticket, developers run the real risk that their app might fail to run on launch if the user’s device cannot connect to Apple’s servers at that time. Given that possibility, very few developers would consider that an “option” and feel forced into adjusting their workflow to accommodate Apple’s changes.
Why Did Apple Introduce Notarization?
Given the extra burden on developers, it’s worth stopping to reflect on why Apple are keen on the Notarization technology. The company recognizes the need for a ‘defense in depth’ strategy, and Notarization is ostensibly another layer of added security for end users. One might hope that Notarization is an attempt to stem the flood of adware, PUP (potentially unwanted programs) and PPI (pay-per-install) “badware” that has been afflicting macOS users for some time now. Apple have been struggling to keep up with revoking developer signatures, and XProtect and MRT tool are simply not built to recognize the simple, automated changes that rogue developers can use to make their software invisible to Apple’s tools. Since Notarization on the forthcoming Catalina and beyond will prevent the launch of any software that Apple has not already received a copy of, presumably Apple will be able to add to their Notarization malware scan more fine-grained signatures over time. In effect, Notarization should serve as a kind of ‘XProtect in the Cloud’ service, allowing Apple to refine their detections and knock out larger classes of unwanted software globally simply by refusing or revoking Notarization status.
Will Notarization Defeat Malware?
That sounds plausible, and worthy, but Apple have been historically unwilling to revoke the signatures of a number of developers who distribute PUPs and who manage to stay within the letter of the law while infuriating users. As far as out-and-out malware goes, the real test of whether Notarization will make any difference will depend on what exactly the “malware scan” involves. As ever with the Cupertino outfit, that remains opaque.
Interestingly, we’ve already seen malware authors adopting the hardened runtime themselves, although to what end it’s not clear.
It fails as an anti-analysis strategy since it’s a simple matter for researchers to bypass the hardened runtime flag. More likely, I suspect, is that malware authors have been testing Apple’s Notarization service to see where and how their creations are caught. Apple helpfully provides a full error log on failed Notarization requests which may be useful to that end, so it’s at least possible if not likely that bad actors will figure out through trial -and-error what they can get away with.
Moreover, while bundles, packages and disk images require Notarization, it remains the case that not all file formats can be notarized or stapled with a ticket. In particular, this new technology is not going to affect any malware that simply runs a script or stand-alone executable. Scripts are increasingly common in adware and malware installers like Shlayer. Although these face the usual Gatekeeper checks, they are not subject to Notarization.
New Technology Bypassed By Old Tricks
A large part of why some developers feel that Notarization is more security theater rather than true security hardening is that while it requires the good guys to adapt to these new requirements, bad actors already have the tools and techniques they need to bypass Notarization checks.
As mentioned above, scripts and standalone binaries are not subject to Notarization, since Apple’s “stapling” technology cannot be applied to these. Notarization checks also only apply to quarantined and “gatekeepered” apps. As we’ve discussed before, the very simple bypass for all of Apple’s security technologies is simply to remove the quarantine bit.
Here’s a simple demonstration. In this example, I’ve chosen a free 3rd party application called “Slimjet.app”. I must stress I have absolutely no knowledge of this application and I am not suggesting there is anything wrong with it. I chose it because it was the first unnotarized application I came across on a 3rd party distribution site. If we download and try to install this application on a system where Notarization is enforced, Gatekeeper will block it because, although it is correctly codesigned, it is not notarized. So far so good.
But there are (at least) two simple ways around this, both of which are old tricks. First, we can simply remove the quarantine bit with xattr. It is still the case that this can be done by a process – such as a malicious installer script – without elevating privileges. The app will now run without complaint from Gatekeeper.
Second, we can build the app into an installer package with pkgbuild and use that to install the app without setting the quarantine bit.
pkgbuild --component /Volumes/FlashPeak Slimjet/FlashPeak Slimjet.app --install-location /Applications ~/Desktop/slimejet.pkg
Apple have said that installer packages signed with Developer IDs must also be notarized, but that does not stop us from creating an unsigned installer package with something like the code above and then using simple social engineering tricks to convince the user to right-click ‘open’ it.
If that strikes you as unlikely, reflect on the fact that we see infections on a daily basis for unsigned code that use this exact trick. Here, for example, is a malicious application on a disk image that helpfully provides the victim with simple images showing exactly what they should do to launch it:
The proof that this is a tried-and-trusted technique lies in the simple fact that these kind of installers are rampant in the wild, and attackers don’t stick with unsuccessful strategies.
Notarization doesn’t raise the bar here for unsigned packages like the one we created above because the unsigned installer isn’t subject to a Notarization check. The app the package drops, as we mentioned, is free of the quarantine bit and so it too will not have to pass Notarization or any other Gatekeeper checks.
Conclusion
It’s hard to knock Apple for effort. They are clearly paying a lot of attention to security issues on macOS, but the Notarization requirements suffer the same flaw as other built-in technologies; namely, relying on the easily-removed and not always respected com.apple.quarantine bit. Meanwhile, developers and end users alike are being forced through a succession of hoops and dialogs. Given the simplicity of bypassing all this extra effort, don’t be surprised if Notarization makes very little impact on the current state of adware, PUPs and malware on macOS.
