The Myth of the Missing Mac Malware, part 1

Apple once ran, and caught a reasonable amount of flak for, an ad that implied Macs didn’t get viruses. The PC (John Hodgman) in the ad says there were “114,000 known viruses” for PCs in 2006, to which the Mac (Justin Long) replies, “PCs. Not Macs.” While misleading, it’s technically correct, which may have been sufficient to avoid truth-in-advertising lawsuits.

Any long-time Mac user, and especially anyone who is used to managing Macs professionally will tell you that yes, Macs get malware.

To be pedantic, most malware today, regardless of platform, doesn’t fit the definition of a virus. There are worms, trojans, adware, PUPs, RATs, rootkits, macros—while my personal Mac has never been infected by any of these (knock on wood), I made a significant portion of my income as an IT consultant detecting, removing, and preventing such nasty things from taking root on my customers’ Macs.

That being said, Apple enjoys a significant advantage against Microsoft in the struggle to secure their respective platforms. In order to maintain that security posture, Mac users are subjected to occasional interruptions and other minor inconveniences. As a trade-off though, the momentary diversion of granting access to an application to use your camera or microphone is preferable to an afternoon spent rooting out and removing spyware.

How Apple protects user data

Historically, a contributing factor to Apple’s relative lack of malware was the comparatively small share Macs occupied in the overall personal computer market. Other aspects of Apple’s hardware and software design legacy will be topics for future posts in this series. Before delving into any of those though, I should start by examining what Apple has built into the current macOS to protect its users and their data from harm.

Securing an operating system against threats goes deeper than software; it starts by securing the hardware. The latest generation of Macs run on an Apple-designed chip, based on the same ARM architecture used in phones, tablets, and, well, pretty much everything that’s not a computer in the traditional sense.

Built into that processor, the M1, is what’s called the Secure Enclave—what in previous generation Intel Macs was the T2, a separate system-on-a-chip (SoC). This is where any sensitive data resides while the Mac is running, instead of being loaded into RAM or stored unencrypted on disk. This includes biometrics data, the user’s fingerprint, and face scans in the case of iPhones. When you need to authenticate with TouchID for instance, the scan data is sent into the Secure Enclave, where it’s compared against what is stored there. TouchID gets back either a “yes” or “no” so the stored fingerprint never leaves the enclave. The subsystem also provides encrypted output to the OS and apps without exposing the keys used to encrypt the data.

With processing power dedicated to encryption, the Secure Enclave’s AES Engine enables FileVault—built-in disk encryption—to encrypt everything on the internal drive on the fly. (Removable disks are encrypted in a different manner that doesn’t involve the Secure Enclave). Other encryption schemes require the system’s CPU to perform the encoding and decoding and have to balance securing data on the drive with not slowing down operations.

The actual encryption process combines the user’s authentication information and a unique hardware ID built into the M1, so FileVault volumes can’t easily be removed or cloned to a different machine to decrypt. Even if the user leaves FileVault turned off, the drive data is still encrypted but only with the hardware ID, so the data can only be read by the machine it was originally installed on. Nothing on the drive is readable without unlocking the encryption, including the data necessary to boot the Mac, which causes the “double log-in” situation that can catch new Mac users unawares.

Signed, Sealed, Notarized

Another source of consternation among Mac newbies is what can sometimes seem like an endless barrage of notifications and requests to approve application permissions.

Similar to the process that ensures the website you’re logging into is actually the site you expected, apps are “signed” by their developers with certificates that are confirmed by the OS before an app can launch. If the signature says the app on your drive is different from the app that was signed, it won’t open. If the signature itself has been modified, the app won’t run.

Gatekeeper is the process that checks for signatures and changes to apps as they run and is responsible for those “Are you sure?” dialogs when you open something you’ve downloaded for the first time. It can be set to only allow apps from the App Store to run, only allow signed apps, or turned off entirely.

To be notarized, an app is submitted to Apple, which scans and confirms it doesn’t do anything malicious. Apple keeps a database of applications that have been notarized and can revoke the notarization “ticket” later if something sneaks past. Gatekeeper checks in with Apple periodically to update an internal database of revoked tickets so it can prevent a bad app from launching, even when you’re offline.

This same paradigm extends to the system’s application firewall, which can be set to only allow network connections to be made by signed and notarized apps.

In addition to Gatekeeper checking signatures, another process, XProtect, scans each app when it first launches. XProtect is Apple’s built-in signature-based malware scanner, comparing an app against signatures defined by security researchers in the form of “YARA signatures” (https://virustotal.github.io/yara/). In addition to that first-access scan, an app is inspected again if it’s been modified or if the XProtect signatures have been updated since the last scan.

Just what do you think you’re doing, Dave?

Providing both fine-grained control of permissions and an endless supply of dialog boxes to click through is the Transparency, Consent, and Control (TCC) system introduced in 2016. TCC is the umbrella under which several subsystems reside that control what the individual apps can and can’t access on the Mac. This includes reading and/or writing to the user’s desktop or contacts database, among others. The one that causes the most trouble tends to be “Screen Capture”, the ability for an app to record what’s on the user’s screen, typically tripping up using remote screen sharing software. Most TCC settings can be deployed by an admin via Mobile Device Management (MDM), except for screen capture and access to the microphone and camera—for privacy reasons which should be obvious.

You might think that the database where the TCC preferences are stored would be a primary target for malware authors. And you would be right. Since so much else relies on the TCC database being resistant to tinkering, it’s protected by the cornerstone of macOS’s security: System Integrity Protection (SIP).

SIP is part of what makes macOS “rootless”, meaning that even an admin user can’t modify certain protected files on the system. Only specific apps are entitled to modify system files and that permission is built into the signature of the app—and recall that if the signature is modified, it won’t run. But malware doesn’t need to crack the SIP protections to wreak havoc, which is why Apple has a nuclear option—the pragmatically named Malware Removal Tool (MRT).

A security update from Apple has the ability to trigger a process to automatically remove an exploit in the wild, even if the malware has made its way past the notarizing scan and XProtect. When the Mac checks for updates—by default, this happens at startup and when the user logs in, and daily while the system is running—if a silent update has been issued, the MRT will take over and do the needful.

MRT updates don’t involve downloading new signatures or definitions but replace the MRT app itself with a new version capable of detecting a specific set of threats, then nuking them from orbit. This capability was most recently invoked for a widespread and embarrassing Zoom vulnerability in 2019. People who had installed Zoom (even if they had then uninstalled it) were left with a vulnerable web server lurking on their Macs. Zoom issued updates and removal instructions and Mac admins pushed out a fix to their fleets, but even that could only cover devices that were actively managed. Ultimately, Apple was able to quietly ensure the vulnerability was purged from every Mac via an MRT update.

Beware The Nut Behind the Wheel

As thorough as all these protections are, they share a single point of failure: the user. Normally, a typical user would never need to adjust or disable the defaults as configured by Apple. But then, when have you ever worked with a “typical” user? Or one that didn’t tinker with a perfectly good operating system until something broke? And that’s why, even with the Mac’s modern security posture, there is still the need for remote management software and MDM. An RMM platform like N‑able RMM will alert the Mac’s admins when security is out of compliance and automatically remedy the situation. In addition, managing the various profiles and permissions on the Macs in your network with an MDM platform—we call ours Apple Device Management (ADM)—will prevent curious users from making those changes in the first place.

So, when you click on a file and that annoying popup appears on your screen asking if you’re sure you want to open it, go ahead and roll your eyes. Your Mac is doing what it can to protect you from miscreants and malware, but no security solution can protect you from yourself. That’s why MSPs exist.

Resources and further reading

• apple.com/security
• objective-see.com
• eclecticlight.co