Quote:

Researcher Patrick Wardle has demonstrated how a chain of exploits can be successfully used to attack macOS Catalina.

Many macOS computer users are still confident that their machines do not need protection. Worse, system administrators at companies where employees work on Apple hardware often hold the same opinion.

At the Black Hat USA 2020 conference, researcher Patrick Wardle tried to disabuse the audience of this misconception by presenting his analysis of malware for macOS and building an exploit chain to take control of an Apple computer.

Microsoft, macros, and Macs

One of the most common ways of attacking computers running macOS is through documents with malicious macros — that is, through Microsoft Office applications. Indeed, despite the availability of Apple’s own productivity apps, many users prefer to use Microsoft Office. Some do so out of habit; others for the sake of compatibility with the documents their colleagues create.

Of course, everyone has long known about the potential threat posed by documents containing macros. Therefore, both Microsoft and Apple have mechanisms to protect the user.

Microsoft alerts users when they open a document that contains a macro. In addition, if the user decides to launch the macro anyway, then the code is executed in a sandbox, which, according to Microsoft’s developers, prevents the code from accessing the user’s files or causing other damage to the system.

For Apple’s part, the company introduced several new security features in the latest version of its operating system, macOS Catalina. In particular, these include file quarantine and “notarization,” which is a technology that prevents the launch of executables from external sources.

Basically, these technologies, combined, should be sufficient to prevent any harm from malicious macros. In theory, everything seems quite secure.

An exploit chain gets the macro out of the sandbox

In practice, however, many security mechanisms are implemented rather problematically. Therefore, researchers (or attackers) can potentially find methods to bypass them. Wardle illustrated his presentation by demonstrating a chain of exploits.

1. Bypassing the mechanism that disables macros

Take, for example, the system that warns the user when it detects a macro in a document. In most cases, it works as the developers intended. But at the same time, it is possible to create a document in which the macro launches automatically and without any user notification, even if macros have been disabled in the settings.

This can be done using the Sylk (SLK) file format. The format, which uses the XLM macro language, was developed in the 1980s and was last updated in 1986. However, Microsoft applications (e.g., Excel) still support Sylk for reasons of backward compatibility. This vulnerability is not new, and it was described in detail in 2019.

2. Escaping from the sandbox

As we have now established, an attacker can run a macro invisibly. But the code is still executed within MS Office’s isolated sandbox. How can a hacker attack the computer anyway? Well, it turns out it’s not very hard to escape Microsoft’s sandbox on a Mac.

It’s true you cannot modify files already stored on your computer from within the sandbox. You can, however, create them. This exploit has already been used to escape the sandbox before, and it seems Microsoft released an update to close the vulnerability. However, the problem was not really solved, as a more detailed examination of the patch has shown: The fix addressed the symptoms, blocking file creation from within places that some of the developers considered insecure, such as in the LaunchAgents folder, which is the storage location for scripts that are automatically launched after a reboot.

But who decided that Microsoft accounted for every “dangerous location” when creating the patch? As it happened, a script written in Python and launched from an Office document — and therefore executed inside a sandbox — could be used to create an object called “Login Item.” An object with that name launches automatically when the user logs in to the system. The system launches the object, so it will be executed outside the Office sandbox and thus bypass Microsoft’s security restrictions.

3. Bypassing Apple’s security mechanisms

So, now we know how to secretly run a macro and create a Login Item object. Of course, the security mechanisms in macOS still prevent the backdoor, which having been created by a suspicious process from inside the sandbox is untrusted, from being launched — right?

On the one hand, yes: Apple’s security mechanisms indeed block the execution of code obtained in such a way. On the other hand, there is a workaround: If you slip in a ZIP archive as a Login Item, then at the next login the system will automatically unzip the file.

All that remains for the attacker to do is choose the right location to unzip the file. For example, the archive can be placed in the same directory as user libraries, one step above the one where Launch Agent–type objects are supposed to be stored (the ones Microsoft correctly considers dangerous). The archive itself can include a directory called LaunchAgents, containing the Launch Agent script.

Once unzipped, the script is placed in the LaunchAgents folder to execute on reboot. Having been created by a trusted program (the Archiver) and not having quarantine attributes, it can be used to launch something more dangerous. Security mechanisms will not even prevent this file from launching.

As a result, an attacker can launch a mechanism through the Bash command shell to obtain remote access (thereby obtaining a so-called reverse shell). This Bash process can be used to download files, which will also lack the quarantine attribute, letting the attacker download truly malicious code and execute it without any restrictions.
...