In Part 2, we explore the pros and cons of Apple’s new architecture and what it means for macOS malware & adware
In Part 1 we looked at the security implications of Safari extensions and examined the case of an adware extension called Pitchofcase. In this post, we’ll explore how Apple have changed extension architecture with the stated aim of improving security. We’ll re-examine the behaviour of Pitchofcase in light of these changes, and conclude with a summary of what all this means for security-conscious users.
As Apple noted at WWDC 2018, “legacy extensions” – those distributed with .safariextz file type both in and out of the Safari Extensions Gallery, are
“incredibly powerful, because they had access to all your browsing data, which made them popular, especially for fraud and malware”.
In 2016 and with an eye to the future, Apple introduced Safari App Extensions. Unlike the legacy Safari extension, which users had to install, update and remove independently of a parent app, Safari App Extensions are included inside an application’s bundle as an appex plugin:
This means they are tied to developer IDs and can be made available through the App Store; in other words, the distribution of extensions is now subject to the same constraints as the distribution of regular macOS applications.
Along with this, in Mojave and Safari 12, legacy .safariextz are now blocked unless they are sourced directly from Apple’s Safari Extensions Gallery. And that’s only a temporary reprieve. Apple intend to abandon the Gallery entirely and are only accepting submissions to it until the end of 2018. Ultimately, only extensions bundled with applications will be allowed for Safari on macOS.
Of course, it hasn’t taken legitimate developers long to realise that empty “shell” apps can easily be created that do nothing other than provide a wrapper for their extension:
We’re sure that malware authors will soon follow suit.
One step forward…
From a security perspective, the App Extension model has both pros and cons for users. Aside from closer integration between the extension and its associated app, another advantage is that in Mojave, Apple have added the ability for developers to use subresource integrity or SRI. This means developers can guard against MITM attacks such as those we mentioned in the previous post by ensuring that any scripts an extension downloads via http or https can be checked against a pre-defined checksum that the developer includes in the App Extension bundle.
Two steps back…
While this is a great security addition to help conscientious developers protect their users, it still requires developer adoption, and consequently it won’t stop unscrupulous devs from turning a seemingly innocuous extension into a malware dropper at a later date if they so choose. The MITM threat can only really be squashed if Apple make SRI a requirement.
Nor will it protect users from developers with no ill-intent but who, for one reason or another, fail to adopt subresource integrity when calling external scripts. It would be nice to think the number of developers that would fail to follow best practice would be reassuringly small, but history suggests otherwise. In 2017, researchers found that up to 40% of extensions in the Safari Extension Gallery contained a security vulnerability that was not the result of a bug in Apple’s APIs, but simply the result of numerous developers allowing a secure token to be leaked through failing to follow best practice.
A second backward step concerns the ability of malware processes to enumerate installed extensions. As we’ve reported elsewhere, one of the big changes in Mojave is the locking down of access to User data. One of these locked areas is the user’s Safari folder. On earlier versions of macOS, a malware process could access this to enumerate the extensions a given user had installed:
It’s a good thing that this command fails to work on Mojave (if User protections have not been bypassed, that is). Being able to list extensions is one way for malware developers to profile users and perform targeted attacks. For example, malware could:
“search for users with shopping management extensions and password managers to narrow down their attack surface to only those users whose credit card information has a higher likelihood to be stolen. Another possibility would be to identify the presence of a major antivirus vendor extension to personalize an exploit kit or to decide whether the malicious payload should be delivered or not to a certain user. “
Unfortunately, the move to App Extensions undermines the effort to block access to the Safari folder’s extensions data. A consequence of the fact that extensions are now .appex plugins in the application bundle is that malware can enumerate installed extensions using the pluginkit utility:
Pitchofcase Revisited
If you recall in Part 1, we noted how Pitchofcase could not be removed without uninstalling the app, and based on what we now know about the Safari App Extension model, we can start to understand why that is.
For while the Pitchofcase installer does in fact include a legacy .safariextz version for good measure, it is the “new” version that requires the application to be removed in order to uninstall it. This is true of all extensions that currently use the new architecture and will be the only method of uninstalling an extension once Apple completely discontinue the Safari Extensions Gallery, presumably sometime in 2019.
Pitchofcase comes from neither the Safari Extensions Gallery, nor the App Store, but still “works as intended” by its developers, Genieo, on Mojave 10.14.
Using Safari 12’s Show All History view, we can easily determine which sites were redirected by the Genieo software:
Although the container architecture of Extensions has changed, the implementation details are largely the same. The “script.js” file is now located in the .appex bundle’s Resources folder:
It’s as capable on Mojave as earlier versions of macOS of inflicting – in what appears to be a tongue-in-cheek pun on the developer’s part – “URL Hell”:
Taming Extensions
As we can see, the new architecture and Mojave’s new security protocols haven’t really been able to stop unwanted and malicious extensions from being installed. At least, not yet.
However, it’s fair to say that Mojave takes some important steps toward taming extensions. We haven’t yet discovered a way for applications to auto-enable their extension, so even though there’s the somewhat worrying fact that any app with an appex plugin will get registered with the plugin architecture, our experiments to enable these on Mojave through the pluginkit utility reassuringly failed.
More importantly, although the risk of users being tricked into running a malicious uninstaller rather than just sending the parent app to the Trash is a very real one that we’ve seen occur in the wild, it should be only a matter of time before users become used to this new workflow and become less likely to fall victim to that particular manoeuvre. We also expect that with the forthcoming requirement for all macOS applications to eventually be notarized, the notarization check will also include a check on any bundled plugins. On top of that, we’d like to see greater strictures on apps that are just shells for extensions, as well as a stricter policy on enforcing SRI.
Are bad extensions a thing of the past? Certainly not yet, but we can see that Apple are on a path that clearly aims to make that possible.
Sample Hashes
5bf86d5860b886bbce146188078a1b406ec30620
ade7e10339acbdf8518a65a802299b5f01e31af2
8b1d4328e32db7f0a079f1f9e208c77ada76b1e1
78084f36435ec4971d96262c04c441dfe5ecbd17
