{"id":21268,"date":"2020-08-27T18:03:09","date_gmt":"2020-08-27T17:03:09","guid":{"rendered":"https:\/\/www.kaspersky.co.uk\/blog\/black-hat-macos-macros-attack\/21268\/"},"modified":"2020-09-03T15:52:40","modified_gmt":"2020-09-03T14:52:40","slug":"black-hat-macos-macros-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.co.uk\/blog\/black-hat-macos-macros-attack\/21268\/","title":{"rendered":"How to launch malicious macros unnoticed on macOS"},"content":{"rendered":"

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.<\/p>\n

At the Black Hat USA 2020<\/a> 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.<\/p>\n

Microsoft, macros, and Macs<\/h2>\n

One of the most common ways of attacking computers running macOS is through documents with malicious macros \u2014 that is, through Microsoft Office applications. Indeed, despite the availability of Apple\u2019s 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.<\/p>\n

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.<\/p>\n

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\u2019s developers, prevents the code from accessing the user\u2019s files or causing other damage to the system.<\/p>\n

For Apple\u2019s 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 \u201cnotarization,\u201d which is a technology that prevents the launch of executables from external sources.<\/p>\n

Basically, these technologies, combined, should be sufficient to prevent any harm from malicious macros. In theory, everything seems quite secure. <\/p>\n\n

An exploit chain gets the macro out of the sandbox<\/h2>\n

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.<\/p>\n

1. Bypassing the mechanism that disables macros<\/h3>\n

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.<\/p>\n

This can be done using the Sylk <\/a>(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<\/a>.<\/p>\n

2. Escaping from the sandbox<\/h3>\n

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

It\u2019s true you cannot modify files already stored on your computer from within the sandbox. You can, however, create<\/em> 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.<\/p>\n

But who decided that Microsoft accounted for every \u201cdangerous location\u201d when creating the patch? As it happened, a script written in Python and launched from an Office document \u2014 and therefore executed inside a sandbox \u2014 could be used to create an object called \u201cLogin Item.\u201d 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<\/em> the Office sandbox and thus bypass Microsoft\u2019s security restrictions.<\/p>\n

3. Bypassing Apple\u2019s security mechanisms<\/h3>\n

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 \u2014 right?<\/p>\n

On the one hand, yes: Apple\u2019s 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.<\/p>\n

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\u2013type 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

In summary:<\/h2>\n