Checklist 209: Apple Flouts the Firewall
You trust Apple. You trust the firewall you’ve set up on your Mac. But … do you trust Apple to decide what your firewall should stop and what it shouldn’t? Patrick Wardle joins us to discuss:
Breaching the wall
It’s come to light that Apple has exempted a number of its own apps and processes from firewall rules in macOS Big Sur — a move that strikes many security researchers as a serious risk.
As a quick refresher, when we talk about a “firewall” in a cybersecurity context, we’re referring to a type of system tool that controls incoming and outgoing network traffic. Firewalls do this by analyzing inbound and outbound traffic, and either allowing or blocking it according to a ruleset created by the user.
While people often think of firewalls in the context of enterprise security, they’re excellent security tools for home users as well. Firewalls let you block traffic to undesirable destinations, and they can also be a good way to defend against new, never-before-seen malware variants, as they may be able to detect and block an unknown program’s attempts to contact its command and control (C&C) server.
So what’s going on with Big Sur and firewalls? Security researchers have discovered that Apple is now allowing some of its own apps and processes to bypass user-defined firewall rules, posing a threat to the security and privacy of those users.
On this week’s Checklist, Patrick Wardle joined us to discuss the issue. Wardle is Principal Security Researcher at Jamf, an Apple device management company that serves businesses and large organizations. He authors a popular macOS technical blog at objective-see.com, and is currently writing a book that will offer a comprehensive introduction to Mac malware analysis (more on how to read sample chapters below). Wardle is considered a leader in the Mac security research community, and is the founder of the world’s foremost Mac and iOS security conference, Objective by the Sea. He was one of the first researchers to investigate the security implications of Apple’s changes to firewalls in macOS Big Sur, and recently demonstrated how a malicious actor might be able to weaponize them against Mac users.
In order to understand what’s going on in Big Sur, it’s important to know a bit of the history behind the change. Third-party firewall developers had previously used something called Network Kernel Extensions (NKEs) to build their tools. In general terms, kernel extensions (KEXTs) are specialized chunks of code used by app developers and device manufacturers to extend the core functionality of the macOS kernel, and give their products the capabilities that they require. However, Apple has long viewed all types of KEXTs as a risk, from both a stability and a security standpoint. Programming for the kernel is difficult, and doesn’t leave a lot of room for error: allowing a third-party developer to access the kernel thus increases the chances of someone inadvertently destabilizing the system for end users. In addition, because the kernel is the core of the OS, anything that affects it can have serious security repercussions — and for this reason, Apple was never all that enthusiastic about allowing third parties into the inner sanctum!
Apple’s answer to these issues, first rolled out in macOS Catalina and continued in macOS Big Sur, was to gradually deprecate KEXTS (including NKEs) and replace them with safer, less-privileged alternatives. NKEs, specifically, were to be replaced by the Network Extension Framework, which was supposed to allow developers to do everything that they used to do with NKEs, but in a more secure way. At first, it seemed that firewall developers would be able to use the Network Extension Framework to build their tools just as effectively as they had with NKEs, but as Wardle explains, the issues with the new solution soon became apparent:
“Closer examination revealed that a large number of Apple’s applications and system daemons would be exempt from routing traffic through any Network Extension client — any firewall”.
The whole point of a firewall is to be able to monitor all network traffic, and so this change significantly weakened the ability of third-party firewalls to perform their basic function. In effect, it’s now impossible for developers to create a truly comprehensive macOS firewall, since by definition at least some processes and apps on the system will be out of its control.
The question, of course, is: Why did Apple do this? No one is completely sure, but Wardle thinks the motivation was most likely well-intentioned, and speculates that the change was largely driven by usability concerns, since there really are times when Mac apps and processes need to be able to send and receive network traffic without interference in order to function properly. If a third-party firewall were to block any of this traffic, then certain important features of macOS might not work as intended. As Wardle puts it:
“They just chose usability over security — which is, unfortunately, a common decision”.
But while usability is an understandable concern, there are three areas in which this change has the potential to impact end users adversely:
Most Mac users probably trust Apple with their data, but some more privacy-conscious folks just don’t want their computer sending network traffic to Apple’s servers — in violation of their stated firewall preferences — just because they opened up the App Store or Maps. While this might not concern most people, it would be nice if Apple let the individual users decide for themselves.
Some people travel with their laptop tethered to a mobile hotspot, and use firewalls to stop system services from using cellular data (e.g. to download updates and other content) when they’re out and about. Under Apple’s new framework, this probably isn’t going to work anymore, meaning that some people may inadvertently exceed their data caps, and will be forced to forgo connectivity if they want to avoid spending extra money.
As a general principle, any time you have an “allow” list on a system, malware may be able to abuse this list of permissioned processes to bypass the system’s security features. In the case of Apple’s new firewall exceptions, this is more than just theoretical: Wardle demonstrated that it was possible for a malicious program to use a trusted process to exfiltrate a file — even with a firewall enabled on the system!
Watch for trouble
Finally, if you’ve installed a new shopping extension, keep an eye out for any signs that it may be adware in disguise. If you install an extension and you suddenly start to notice weird redirects, ads popping up in random web pages that you visit, or a proliferation of low-quality (read: spammy) search results, then it’s time to remove that extension! If this happens, you should also run a systemwide malware scan just to be on the safe side: malicious toolbars and adware are often intentionally difficult to uninstall, but a good malware detection and removal tool can help you completely eliminate an infection.
This last point, interestingly enough, has parallels to the debate over encryption backdoors — the very issue that has caused so many clashes between Apple and the U.S. government. As we’ve said on the Checklist before, there can never be a “good guys only” backdoor, because once such a backdoor exists, the bad guys can exploit it too! Apple’s list of firewall exceptions isn’t a “backdoor” in the same sense, but they pose a similar problem, and in this way highlight an important principle of secure development: if you make a special capability available to a trustworthy actor (even Apple), then that capability may one day be turned against you by malicious actors.
The future of firewalls
So does this mean the end of firewalls on macOS?
Wardle doesn’t think so, and remains optimistic that Apple will eventually take steps to remedy the situation, and make comprehensive firewalls possible on macOS once more. In fact, he says that he’s already been in touch with Apple about the issue, and that their initial response has been very encouraging:
“Apple’s security teams seemed very receptive to my points…they definitely recognize the points I’m making and the issues that other users are bringing up.”
In the meantime, concerned users may want to look into packet-filtering (PF) firewalls, which operate at a lower level on the system than modern firewalls, and don’t rely on Apple’s Network Extension Framework (and thus its built-in list of exceptions) in order to control network traffic. The trade-off is that PF firewalls are significantly less user-friendly, but for people who need comprehensive firewall protection, they’re a reasonable option for the time being.
In addition, the fact that malware might be able to abuse Apple’s firewall exceptions underscores the importance of following best practices and remaining vigilant at all times. On macOS, regardless of whether or not it can contact a C&C server after infection, most malware still requires some user interaction to make it onto the system in the first place. For this reason, it’s important to remember that you are the first line of defense against malware, and act accordingly: learn how to spot phishing emails; don’t click on random links or download files from unknown senders; only use software from the Mac App Store or a known and trusted developer; and update your software regularly.
The Big Sur firewall affair also contains an important takeaway that goes beyond individual users: It’s yet another reminder of the crucial role played by the third-party research community in making macOS and iOS safer. Their work on the behavior of firewalls on macOS Big Sur, as well as their subsequent public discussion of the security and privacy ramifications that this entailed, were both essential to bringing the issue to the public’s attention — and to Apple’s.
The Checklist would like to thank Patrick Wardle for taking the time to join us on the show. To keep up with Patrick’s work online, follow him on Twitter or check out his technical blog at Objective-See. To read excerpts from Patrick’s forthcoming book, The Art of Mac Malware: Analysis, visit the book’s website at www.taomm.org.