Patrick Wardle, principle security researcher at Jamf, presented at BlackHat on an interesting approach to escaping the App Sandbox in macOS with a little help from Microsoft Office. For those of you who didn't have access to the talk or would rather read than listen, let’s learn a bit more about his research.
What is a sandbox?
In the world of software security, the concept of a “sandbox” has been commonly used to allow applications that may not be completely trustworthy to run on trusted devices. The “sandbox” is simply a concept that when the operating system (OS) launches an application, the OS limits what the application is allowed to do that may affect the device at large. Some applications such as Google’s Chrome browser have even gone so far as to build a separate sandbox into themselves so that any content they load (such as when visiting a webpage) cannot affect the application in any negative way. Such a sandbox is a core part of the macOS security stack.
It is no wonder that security researches are always looking at ways that an application may escape these sandbox. This is a story of escaping the macOS App Sandbox using malicious Microsoft Office files…
Office and the macOS sandbox
Just like all applications running on macOS, Microsoft Office (Word, Excel, etc) runs within the macOS App Sandbox. Office apps make an attractive attack vector for a malicious attacker because:
- Microsoft Office is very commonly found on Macs
- Users don’t generally think of Office files as a way to attack their device and therefore tend to trust them
- Office files can contain scripts (macros) that can do much more than just manipulate data or text within the office file
Even more interesting, since Microsoft Office has such a long history and is a critical part of many organizations' data processing, Office files support a massive variety of functionality that was once normal, but seems almost out of place today.
Identified sandbox escape
Patrick spent some time looking at various interesting ways to combine and extend known weaknesses in these various mechanisms and identified a novel way to escape from the App Sandbox using a simple Office file.
The sandbox escape basically came down to the following steps:
- Get a user to open a specialized “Sylk” file
- Sylk files are an old Office file format that was intended to link spreadsheet files together.
- Sylk files are not affected by the Microsoft Office setting “Disable all macros without notification,” which would usually prevent any embedded macros from having any effect unless the user allows them to run. Instead, embedded macros are run without user interaction (Sylk and the macro behavior was first discussed by Pieter Ceelen & Stan Hegt and codified by CERT VU#125336).
- Within the Sylk file, include a XLM macro (a pre-VBA scripting language for Office) that downloads a special zip file to the device in the user’s Library folder.
- Name the zip file so that it starts with “~$” such as “~$payload.zip.” Files named this way are allowed to be written outside of the App Sandbox due to the configuration of the App Sandbox for Microsoft Office (discovered by security researcher Adam Chester).
- Within the XLM macro, register the zip file as a “login item.” The next time the user logs in, macOS will execute the default handler for the file type, which extracts the file to the user’s Library folder.
- The unzipped file creates a Launch Agent for that user which launches a built-in macOS utility, such as /bin/bash (which is notarized), and can then launch an arbitrary attack (backdoor, ransomware, etc).
- The device, user, and data are now potentially compromised.
You can read all the technical details on Patrick’s blog at https://objective-see.com/blog/blog_0x4B.html
One nice thing here is that there are several behaviors in this exploit chain that can easily be detected. Since Office macros are a well-trodden subject, we’ll skip that topic in this blog.
A simple logic set to detect the behaviors in this chain would be to alert the security team when the following is observed:
- A Microsoft Office application is the parent process of curl, python, or a similar tool — and this process performs one or more of the following:
- persists files on disk
- modifies applications/scripts on disk
- creates a login item
- creates a launch agent
- Creation of Login Items, especially if they are not applications or scripts (zip files, etc)
This is behavior that can be manually identified with buil-tin tools, but endpoint security tools, such as Jamf Protect, that monitor for this kind of behavior are a much better way to catch these. Check with your vendor if they cover attack vectors such as these.
We’ll save you from sending one of those messages: yes, Jamf Protect helps with these kinds of attacks.
Patches are available
Of course, Patrick reported these findings to Microsoft and Apple.
Microsoft patched the macro issue with Sylk files that Patrick leveraged with CVE-2019-1457. Apple also released a patch to address this exploit chain in macOS 10.15.3.