Objective by the Sea 3.0

The world’s only Mac and iOS security conference returned home to Maui last week, with some of the best minds in Apple security research coming together for a few days of learning, training, information sharing, and tool demos.

The conference is a truly one-of-a-kind event, and not only strengthens the Mac security community but also allows students and younger researchers to network with some of the top experts in their field. For this reason, SecureMac was proud to help sponsor the conference for yet another year.

The speakers at OBTS 3.0 touched on a wide range of topics, and while many of the talks were deeply technical, there were plenty of excellent takeaways relevant to anyone who uses a Mac or iPhone — or indeed anyone interested in digital security and privacy issues generally.

In what follows, we’ll offer some highlights from the OBTS 3.0 presentations — and tell you what they mean for everyday users of Macs and iPhones. And if you’d like to go a bit deeper into the technical aspects of the presentations, or watch all of the talks in their entirety, we’ll provide some information at the end of this piece on how to do that.

An insecure successor

Scott Knight talked about security issues with system extensions. As you may remember, macOS Catalina marked the end of the kernel extension, or “kext”. A kext is code written by a third-party developer to extend the functionality of the macOS kernel in order to do things that their app needs to do. By deprecating kexts, Apple aimed to restrict outside access to the core of the OS — and thereby make it more secure.

System extensions are the replacement for kexts. In many ways, they are quite similar to kernel extensions — except that they run in user space instead of in the kernel. Different types of system extensions provide functionality for networking, device drivers, and endpoint security. They interact with the kernel through a complex, layered system of OS processes communicating with one another — which ensures that the OS doesn’t launch a system extension unless it’s properly validated. As Scott put it, “there are a lot of moving parts”.

Scott’s talk went deep into how he reverse engineered Apple’s new system extension framework for endpoint security — and how he found a vulnerability in its implementation. It turns out that it was possible to create an app that would send a request to the OS to launch a program (with root privileges), and that the system would do this without first checking that the app actually had the necessary entitlements. The bug was reported to Apple as CVE-2019-8805 and was patched in macOS 10.15.1. 

The Takeaway: Scott made it clear that he thinks of the new system extension framework as a good thing for macOS security. But he also pointed out that the complexity of the system extension architecture — all those “moving parts” — means that it will be more challenging for Apple developers to test and build, which may result in vulnerabilities. For everyday users, this is a reminder that even well-engineered systems that put security front and center will still have occasional bugs that require patches, which is why it’s imperative to take updates seriously and keep your OS current.

If your Mac could talk

Sarah Edwards discussed APOLLO, a tool that she created, and its applications in Mac forensics. APOLLO (an acronym for Apple Pattern Of Life Lazy Outputter) was initially designed as an iOS forensics tool, and was introduced at the very first Objective by the Sea conference. Since that time, it has grown enormously in popularity, and is now used by companies and law enforcement agencies around the world.

The inspiration for APOLLO came from a recurring challenge that Sarah had found in her own forensic investigation work on iOS devices: the difficulty of extracting forensic data from multiple SQLite databases using multiple queries. APOLLO was her solution, offering a way to automate the work of figuring out what had happened on a device and avoid having to manually run dozens of separate queries on dozens of databases. The project has since been expanded to support both Android and macOS forensics, and the tool’s use on Mac devices was the focus of Sarah’s talk.

APOLLO is able to give a forensic investigator access to tremendously detailed information about a user’s activity on a Mac and its synced Apple devices, including:

• What Mac apps were used by which users (and when)
• Activity on iOS devices synced to the Mac
• Safari web browsing activity (across devices)
• User interactions with app notifications
• Network activity and logs
• Details of user interactions with their Contacts
• App update activity and changes to TCC permissions
• Laptop lid open and close states

The data provided can help an investigator figure out what happened on a Mac — and also paint a fuller picture of events by correlating related activity from synced devices. The APOLLO project continues to develop and grow, with Sarah inviting people to try it out and to write their own APOLLO modules for Windows and Android.

The Takeaway: Sarah’s talk was a great reminder of just how much information our Macs are storing behind the scenes — oftentimes in databases that we’re not even aware of — and how this information is not only limited to the Mac in question, but also to iOS devices that are synced with it. Many of us think of our iPhones as completely locked down and secure, but it’s important to remember that our synced Macs or iCloud accounts can provide others with a means of access to data stored on those devices. This may be a good reason to take a closer look at stronger Mac security measures like disk encryption and firmware passwords.

Vladimir Metnew spoke about a weakness in macOS’s File Quarantine feature — and the design of many messaging apps — that could allow code execution on an unwary user’s device.

File Quarantine is meant to prevent content from being launched without the user’s permission, and to help Gatekeeper enforce code signing requirements. This is important, because it helps prevent files with harmful payloads from being launched. Examples of such files are complex files like disk images and package installers, or standalone macOS files like automators and configuration profiles.

Vladimir focused on a unique feature of the .terminal macOS file, the file that stores the Terminal app’s configuration preferences. The .terminal file is an unsigned and unsignable XML file that has an interesting ability: It can execute code. But because it can’t be signed, it also can’t be checked for notarization — which is a fact that an attacker could take advantage of by using a messaging application to deliver a maliciously crafted .terminal file.

Messenger apps themselves are problematic from a security standpoint. They tend to lack proper safety checks for opening files, and they often don’t offer a preview of non-image files. In addition, some messenger apps will simply download files automatically without first obtaining the user’s consent.

Vladimir showed how an attacker could use a messaging app like Slack to send a malicious .terminal file as an attachment without a file preview. If an overly trusting recipient opened the file, malicious code would immediately execute on the target machine. The vulnerability was reported to Slack and fixed 265 days later. He also offered examples of similar potential attacks on WhatsApp,Telegram, and Skype.

The Takeaway: Vladimir’s talk was a great demonstration of why you should always be careful about what you’re clicking on — not just when you’re using email, but when you’re using messaging apps as well. If something isn’t coming from a trusted sender, don’t click on it. In general, avoid clicking on icons that don’t give you a preview of what you’re going to be opening. His talk was also a healthy reminder that bug fix timelines vary wildly — sometimes taking a day or two, other times the better part of a year. So while you should always be updating your system and your apps regularly, you also need to be proactive about your security, which means paying attention to safe file handling, being aware of phishing tactics, and running anti-malware tools on your machine. 

Malware research and the law

Thomas Reed focused on an aspect of security research that many people may not be aware of: the legal issues associated with disclosing malware.

Reed talked about his experience researching and writing about Fruitfly, a macOS backdoor that had existed in the wild for years when it was finally discovered. The malware was able to communicate with a remote server, execute commands on the infected system, and steal data — and seemed especially interested in stealing camera or webcam data.

In early 2017, Case Western Reserve University in Cleveland, Ohio learned of the existence of the malware on its network. The university immediately contacted the FBI, and a chief suspect was identified the following day: The malware was communicating with an IP address which had also been used to access a specific alumni email account. 

Around the same time, Reed was told of the existence of a new form of malware by an acquaintance, who sent him a sample which he began to analyze and write about for his company’s blog. But after communicating with Apple, he was asked to hold off on publication for a few days — which he did — although he was unaware, at the time, of law enforcement’s involvement. He published his research a week later, per his agreement with Apple. Within hours, the FBI raided a house linked to the malware’s author. They found a laptop which belonged to the suspect — one which was being controlled remotely when they discovered it — along with several hard drives. Interestingly, they didn’t have a warrant to search the house, which was owned by the suspect’s family: His parents had allowed the federal agents to enter without one. After obtaining a warrant, the authorities searched the seized computer and storage devices, and found millions of stolen files, along with child pornography. The suspect was arrested and charged with many serious crimes, including production of child pornography, illegal wiretapping, wire fraud, and identity theft.

The court case is ongoing and, as Thomas told the conference, the circumstances of his initial malware disclosure are still affecting the proceedings. In 2018, the defense filed a motion to suppress the computer evidence based on improper seizure (since the agents didn’t have a warrant to search the house). Part of the prosecution’s reply to this motion was that they had acted quickly — and without a warrant — because they feared that the suspect would see Reed’s blog post and delete the evidence. It remains to be seen whether or not the timing of the blog post’s publication will have any impact on the ultimate outcome of the case.

The Takeaway: Thomas’s story demonstrates the fine line that malware researchers walk: They want to disclose malware in a timely fashion out of concern for victims who may not even know that they have been affected, but they also need to consider the impact of their actions on the legal process. Thomas urged his fellow researchers to get in contact with law enforcement early on, or to make use of professional organizations which facilitate communication between security researchers and the authorities. 

The story of Fruitfly is also an important reminder to practice good password security. Investigations revealed that the criminal behind Fruitfly took advantage of weak passwords and passwords compromised in third-party data breaches to access and infect thousands of machines. That’s why it’s so crucial to create strong, unique passwords for each and every site that you use, and to add extra layers of security like two-factor authentication whenever possible.

A truer tree

Jaron Bradley talked about TrueTree, a tool he created to help incident responders get a better understanding of operating system activity by building a more useful process tree. 

A process tree is simply a diagram of the active programs on a system, arranged as a “tree” to help show the relationships between them. It allows a user to see how processes were launched; what led to the execution of a given process; and what processes are the “children” of other “parent” processes — all of which is essential information to have when doing incident response and threat hunting work. But unfortunately, macOS doesn’t make it easy to view this data in a useful format. 

Because of the way that the operating system’s processes communicate with one another, most of them simply show up as having been created by the OS’s service management framework: launchd. In fact, if you ran the original (now deprecated) “pstree” command for Mac, you’d see a process tree in which launchd would be listed as the parent process for most of the other processes on the system, regardless of how they were actually opened (from the dock, from the Applications folder, from Safari, etc). So while it would be technically true that launchd was the parent process of all of those other processes, this would conceal the actual activity on the system — and wouldn’t be very helpful if you were attempting to determine what had happened during a cyber incident or how a threat worked.

Fortunately, the information required to build a more useful process tree — a “true” tree — is already stored by the OS. Jaron’s tool extracts this information and displays it in a number of intuitive and data-rich formats, offering various options depending on what the user needs to know. TrueTree is thus designed to offer incident responders a snapshot of the processes running on an OS, displayed as a process tree that actually shows what led to each process’s execution. This can allow responders to determine what caused an action on a system, and give helpful contextual insights like whether or not a user intentionally clicked on something in order to launch it.  

The Takeaway: Jaron’s talk was a great demonstration of just how essential the third-party research and development community is to Mac security. The macOS operating system is engineered for performance and safety, but it is largely built with end users in mind. This orientation, however, can sometimes be less than ideal for other stakeholders such as incident responders, forensic analysts, and security researchers, who can’t always rely on Apple to provide them with the tools or information they need. Third-party researchers help to fill these gaps — and make a substantial contribution to the security of macOS in the “real world”, where cyber incidents happen every day, and the security professionals called in to respond need accurate intelligence in order to do their work.

Macs in the enterprise

Calum Hall and Luke Roberts talked about the challenges of securing Apple devices in the enterprise. Large deployments of iOS and macOS devices often rely on device management solutions such as Jamf, which was the subject of Luke and Calum’s presentation.

Jamf allows enterprise IT departments to manage Apple devices at scale, giving them the ability to deploy and enroll new devices, set standard device configurations, decide which software can and can’t be used, gain visibility into what devices are on the  network, provide a centralized location for users to obtain additional apps, and ensure that security protocols are followed.

Jamf is a powerful solution used by thousands of organizations around the world. But as Calum and Luke pointed out, whenever a company makes use of a software as a service product, there are going to be security implications. The two researchers took a closer look at some vulnerabilities that could potentially be exploited to attack businesses which use Jamf.

They noted that with certain Jamf configurations, users can self-enroll their devices, making it theoretically possible for a hacker to get their own machine into a target’s Jamf environment. At first glance, this might seem somewhat strange — after all, by enrolling their device, a threat actor would be putting their computer under the target’s control. But Luke and Calum explained why an attacker might want to do this: They could learn what other, potentially vulnerable applications were being used by the organization; they might be able to obtain company files and templates to use in phishing and social engineering attacks; and they could conceivably uncover useful information about the company’s VPN. They also demonstrated how an attacker with presence on a Jamf estate could use various techniques to gain access to administrator passwords or to take advantage of poor security practices within the organization. The sorts of exploitable vulnerabilities discussed in the talk are surprisingly widespread: Luke said that he’d found them on the majority of tests he’d run in the course of his work.

The Takeaway: Calum and Luke’s presentation was a useful reminder that anything that faces the web is a possible attack surface — and that attackers will often find surprising and even counterintuitive ways to exploit software vulnerabilities. Their talk is also further evidence that Apple has established its place in the enterprise, and that Macs and iOS devices will become even more common in business in the future. While this is great news for Apple (and for anyone who wants to use Apple products at work), it also means that hackers will come to see macOS as a valuable target, and will develop new macOS malware accordingly — a fact that even non-enterprise Mac users will have to contend with.

Attacking with macros on macOS

The final presentation of the conference was given by Patrick Wardle, who talked about a technique he’d developed to attack macOS using macros. 

A macro is, essentially, code which has been embedded in a Microsoft Office document. Macros can lead to security issues: If a user opens an innocent-looking Office document that contains malicious executable code, and they then allow that code to run, their computer could be compromised.

Typically, people think of macro-based attacks as being limited to Windows systems, and this has traditionally been the case. However, with the increase in enterprise use of Macs, hackers are starting to use macros to attack macOS as well.

Patrick produced several examples of this type of attack, and then demonstrated a macro-based attack that he’d developed from an older vulnerability. The original vulnerability was based on an exception to the sandboxing rules for Microsoft Office on macOS: The exception had allowed Office to write to any location on the filesystem as long as the filename ended with the characters “~$”. Microsoft patched this sandbox escape, but Patrick used it as a starting point for his own exploit, and developed a clickless, macro-based attack capable of evading macOS’s notarization requirements and achieving persistence on a target system. His talk provided a great demonstration of exploit development and reverse engineering, and was also a fascinating look at the problem-solving process of a researcher attempting to find a way to bypass Apple’s various security features.

The Takeaway: Patrick’s talk underscored two important points. First, echoing what a number of other speakers said, Macs are becoming much more common in the enterprise, and this has security implications for all Mac users. Hackers who had previously not seen much of a point in building Mac malware, or in designing macro-based attacks aimed at macOS, now have a clear financial incentive to develop these threats — and this affects everyone. 

Secondly, the presentation drove home the point that Mac security is going to have to be a community effort going forward. Apple security enhancements like Quarantine and Notarization are great steps in the right direction, but as Patrick demonstrated, they’re not necessarily enough to stop a motivated and capable attacker. This is why the work of third-party researchers, bug hunters, and software developers is crucial to securing Apple’s platforms. It’s also why conferences like Objective by the Sea are important, since they foster the independent security community that is so essential to keeping Mac users safe.

Watching the full conference and OBTS 4.0

The conference included other great speakers (more than we can cover here), so if you’d like to see all of the presentations, follow Objective-See on Twitter — they’ll let you know when the conference talks are uploaded to YouTube, and will provide links to the speakers’ slides as and when they become available. 

Objective by the Sea 4.0 is tentatively scheduled for the end of 2020, and will most likely be held in Europe, so stay tuned — we’ll be sure to let you know how you can watch the next installment of the world’s best Mac security conference!