|
|
A little later in June than usual, Apple’s WorldWide Developer Conference (WWDC) 2020 kicked off this week in, of course, more than unusual circumstances. With COVID-19 still very much an issue as we hit the mid-year mark, Apple’s signature event has turned entirely virtual, allowing us all a front-row seat to take in the news, announcements and forthcoming developments across Apple’s platforms. Among those, the beta release of the next version of macOS is of major interest to enterprises and security teams. In this post, we round up the most significant changes we’ve seen announced so far affecting macOS security. Let’s take a look!
1. Will Your Hardware Support macOS 11.0 Big Sur?
In order to take advantage of the changes brought to macOS in Big Sur, you will of course need compatible Apple hardware. There are seven supported product lines for macOS Big Sur, with the earliest supported models going back to 2013:
- Mac Pro, 2013 and later
- MacBook Air, 2013 and later
- MacBook Pro, Late 2013 and later
- Mac Mini, 2014 and later
- iMac, 2014 and later
- MacBook, 2015 and later
- iMac Pro, 2017 and later
What does this mean for enterprise?
Ageing hardware in your Mac fleet is probably already feeling the heat from the resource-intensive Mojave and Catalina. The only real question is how much of your macOS hardware you want to update now before the ARM chip hardware becomes available at the end of 2020 and through 2021.
2. Big Sur Version Number: Is it macOS 10.16 or 11.0?
There were a couple of big shocks with the first release of the macOS Big Sur beta, neither of which were explicitly called out in Apple’s Keynote on Monday. The first of these, spotted by some eagle-eyed watchers, was that macOS 10.15 isn’t being superseded by macOS 10.16! Instead, Apple have finally put the nail in the coffin of the 20-years of Mac OS X, now not just in name but in version number, too: Big Sur is to be the first macOS 11.0!
What does this mean for enterprise?
Such a small change, but it will have consequences for many enterprises, as Apple themselves are finding out. So many enterprise workflows rely on scripts that check for version numbers in the 10.x range that many of these are going to be instantly broken.
if [[ ${osvers_major} -ne 10 ]]; then
Even Apple’s own software update check is probably counting in 10s, and the first beta was delivered as 10.16 (and possibly the rest, too; indeed, there’s plenty of internal documentation referencing “10.16”).
3. Kexts Get a Temporary Stay of Execution
Another big surprise turned out to be that the much-anticipated demise of kernel extensions did not occur, although Apple have certainly put in enough roadblocks to make developers and users want to transition away from kexts as fast as possible and migrate to using System Extensions and DriverKit instead.
Nonetheless, kexts remain an open possibility for organizations that have critical dependencies, and there’s a new tool kmutil to manage loading, unloading and diagnosing kexts and “kext collections” on Big Sur.
What does this mean for enterprise?
Organizations will be able to upgrade to macOS Big Sur without fear of losing functionality from software that depends on kernel extensions. However, it should be noted that kextutil and kextload have now been replaced by kmutil and there are changes and restrictions on how these work (see the man page for details).
Apple have made it clear that there’s no let up in the drive to move developers away from kexts, advising that:
SentinelOne customers can be assured that our forthcoming macOS 4.4 Agent does not use kexts and will be compatible with macOS 10.15 Catalina and macOS Big Sur.
4. Compatibility with Rosetta 2, Apple silicon and Universal Binaries
Of course, one huge change that was mentioned at the end of the Keynote was the one that has been widely anticipated in the media: Apple’s move to an ARM-based chipset for macOS, dubbed “Apple silicon” at WWDC 2020. Although there is no ARM-based hardware available at the moment, a Developer Transition Kit is being made available, and Apple have said they expect to start shipping ARM Macs in late 2020.
To facilitate this transition, Apple have resurrected an old friend familiar to those that remember the PowerPC-to-Intel transition: Rosetta. Reinvented as Rosetta 2, this software-layer technology will allow certain classes of software compiled on Intel architecture to run on ARM-powered devices.
However, there’s a couple of gotchas with Rosetta 2. First, the translation inevitably takes time, and no amount of clever optimization will alter the fact that some applications relying on Rosetta 2 will launch or run slower than they would if run natively on the Intel architecture they were compiled for. To help avoid this problem, Apple have also introduced a new multi-architecture, Universal (aka ‘Fat’) binary format. This allows developers to port existing macOS apps to run natively on Apple silicon. With Xcode 12 or later, developers can build a “fat” binary that contains architectures for both machines: an ARM-based Mac isn’t required to compile these universal binaries.
The second problem with Rosetta 2 is that it won’t translate all software compiled on Intel architecture into something that will run on Apple silicon. In particular, Windows virtualization software and kernel exensions are not supported. Those hoping Rosetta 2 might give them a ‘get out of jail free’ card for their kernel extensions will have to think again. It remains unclear what future there is for Windows Virtual machines on macOS, though VMWare at least seem to still be holding out some hope that all is not lost.
What does this mean for enterprise?
The widely-anticipated transition to ARM, which Apple expect to happen over 2 years, will not have any immediate effects on enterprise, but in the mid-to-long term IT teams will need to inventory which apps can run natively with universal binary, which are labouring under Rosetta 2 translation, and which are just incompatible.
Perhaps the biggest choice affecting organizations here, as mentioned earlier in this post, is deciding on when to upgrade hardware, and whether it’s in your businesses’ best interest to await ARM-powered Macs before further purchases.
5. Keep Out! A Cryptographically Signed System Volume
Aside from the big changes we’ve already covered, there are some important changes that have received less attention. Among these is that macOS 11 brings cryptographic signing to the System volume. In Catalina, Apple already made an architectural change to split the root volume into two: a read-only System volume and a Data volume for everything else.
Now, the System volume receives extra protection by being cryptographically validated to prevent offline attacks and malicious tampering.
What does this mean for enterprise?
As messing with the System has been a “no-no” since Apple introduced System Integrity Protection way back in macOS El Capitan 10.11, this hardening of the System volume shouldn’t present too many challenges to IT and security teams.
There are a couple of upshots, however. One is that FileVault no longer needs to encrypt the System volume at rest on macOS 11. The Data volume will still be protected by FileVault encryption, if it is turned on.
Secondly, attempting to boot a “live” version of the OS (i.e., a writable filesystem) by turning off System Integrity Protection will no longer work. It is possible to disable the protections and make modifications while it is not booted, but “live” modifications are now off the table in macOS 11.
6. Networking Ins and Outs
There’s a number of small changes to networking and internet use that could affect your security or workflows that we will lump together here.
The first, publicly reported by macrumors, is that the long-standing Network Utility app has been “deprecated”, although from what we can tell it’s actually now entirely non-functional.
The Network Utility contains a bunch of useful tools like Netstat, Ping, Traceroute and Port Scanning among others.
Apple have also added a useful Privacy Tracker and blocker to Safari that allows users to see what tracking cookies a site is using and that Safari has blocked. Publicly reported here, the Privacy toolbar button provides detailed insight through a popup with a number of further pop-outs accessed from within.
Given the extensive malicious use of extensions in all popular browsers, security teams will want to take note of the new Web Extensions feature in macOS Big Sur. This allows existing Chrome and Firefox extensions to be easily converted to use with Safari 14 with the xcrun tool. Apple hope to ameliorate security concerns around this by continuing to insist browser extensions must be distributed through its App Store. There are also new user controls for managing extensions in the browser.
Safari 14 will also reportedly have HTTP/3 enabled by default. According to Apple’s release notes, Big Sur enables experimental HTTP/3 support in Safari via Experimental Features in the Developer menu. It can be enabled system-wide using the following Terminal command:
defaults write -g CFNetworkHTTP3Override -int 3
And since we’re discussing the command line, another networking change in macOS 11 pertains to the networksetup utility, /usr/sbin/networksetup. As of Big Sur, this tool will no longer allow standard users to change network settings. Standard users will be able to toggle Wifi on and off and read the network settings, but modifications will require an administrator user name and password.
What does this mean for enterprise?
Overall, these changes should help to enhance network security. The change to the networksetup command line tool is in line with permissions that standard users have in the System Preferences.app, and it’s nice to see Apple get consistent across tools.
We also don’t envisage a significantly greater attack surface arising from an increase in browser extensions so long as Apple’s App Store does the work of monitoring and removing these for malicious or abusive behaviour in a timely and effective manner. The onus there, of course, is on Apple, and enterprise security teams may well feel that locking down the installation of browser extensions through MDM or similar configuration tools is something worth considering given both the history of malicious extensions and how much of our private and sensitive data goes through browser applications. On that, the new privacy reporting tool is a welcome addition to Safari 14 in Big Sur.
Finally, on networking, the removal of the Network Utility app shouldn’t cause much consternation among IT teams. You probably are already using the command line equivalents of the tools it provided a GUI wrapper for, so we don’t expect this to be missed by too many.
7. Certificate Trust: Root Is Not Enough
With macOS Catalina and earlier, the command line security tool can be used to change certificate trust settings if the effective user is running as root via the add-trusted-cert flag, as shown in the tool’s man page on a Catalina install:
In macOS Big Sur, simply running with UID 0 will no longer be sufficient to make this change: confirmation will be required with an administrator password.
In a fortunate nod to managed enterprise environments, Apple will allow the change to take place without confirmation if the certificate payload is deployed with the root certificate using a configuration profile.
What does this mean for enterprise?
This welcome hardening to certificate trust settings may affect your workflow if you use the security command-line tool to change trust settings or a privileged process calling the SecTrustSettingsSetTrustSettings function.
8. Configuration Profiles Get Preferential Treatment
Configuration profiles, managed through the command-line profiles tool or the Profiles System Preferences pane, have been abused by macOS malware for some time now. Chief among the perpertrators are adware infections seeking to manipulate browser home page and search settings, although others have been seen that configure things like malicious DNS settings, too. Profiles started to become a preferred target by adware after Apple took steps to lock down Safari browser preferences in previous OS releases.
In macOS Big Sur, Apple have acknowledged this abusive use of profiles and now raised the bar for their installation. Unless the device is enrolled in an MDM program, installing a profile will now require the user to manually finish the profile installation in the System Preferences app, where a window will also describe the profile’s actual behaviour.
Somewhat oddly, there is an 8 minute timeout on this action: if the user does not complete the installation within that timeframe, macOS Big Sur will remove it from System Preferences.
What does this mean for enterprise?
Your enterprise is likely only using profiles through an MDM solution, and so this change shouldn’t affect most. If for some reason you are manually scripting the installation of profiles, you will need to engage in user education to teach them how to complete the steps (in less than 8 minutes!).
While malicious use of profiles through social engineering will undoubtedly be tried by adware and other macOS malware vendors, this change should have a welcome impact on reducing some of the worst offenders.
9. Surprisingly, No Surprises in App Security
Although WWDC 2020 is far from over, we haven’t seen any announcements or suggestions that Apple will change their approach to App security with macOS 11. With so many under-the-hood changes focused on security, enterprise security teams might have been hoping for some major developments, but as yet that remains to be seen.
In macOS 11, it seems that Apple will continue to rely on the model that’s been slowly evolving through the macOS 10.x years but which is still somewhat behind the rest of the industry in relying on static signatures for blocking and detection. The app security model continues to look something like this:
- Protect: codesigning, notarization, and system policy checks via Gatekeeper
- Detect: malware blocking via static Yara rules in XProtect
- Remove: removal of known malware via static detection signatures in MRT.app
What does this mean for enterprise?
While Apple admirably places lots of focus on security – and some of the changes in Big Sur are more than welcome – it does seem oddly out-of-touch in some respects. Even Windows now has some rudimentary behavioral detection, and Apple’s reliance on its triumvirate of Gatekeeper, XProtect and MRT.app is starting to look and feel dated.
Gatekeeper and Notarization are weakened by simple social engineering ploys that attackers began using with 10.14 and have only got better at. XProtect’s static YARA rules rely on malware already being known to Apple (i.e., some user or organization has to first get infected before Apple can update the signatures), and MRT.app only runs when it is updated, the user logs in or reboots the Mac – meaning it is impotent for most of the time the Mac is actually in use.
Moreover, for enterprise security teams, there’s no visibility as to what any of these tools are doing or have done. Even with Apple’s latest iteration of macOS, with its new name, new version number and many new features, there’s still every need to keep your Macs protected by a behavioral security platform that can detect, protect and report on known and unknown malicious activity.
Conclusion
WWDC 2020 still has a few days to run, and we’ll update this post in light of any new announcements in the rest of the week. From what we’ve seen so far, we like the look of macOS 11 and welcome the changes that have been reported. Most of these should help your security team to improve the security posture of your macOS fleet with only a few changes needed to most workflows.
