Skip Navigation
Get a Demo
 
 
 
 
 
 
 
 
 
Resources Blog Threat detection

Detecting CVE-2015-1130 on Mac OS X Endpoints

Cory Bowline
Originally published . Last modified .

Security researcher Emil Kvarnhammar released details related to his discovery of the latest vulnerability in Mac OS X – CVE-2015-1130 – on his blog today. The vulnerability exists in Apple’s Admin.framework and allows unprivileged users to elevate their privileges to root on any vulnerable system. Mac OS X versions 10.7 through 10.10.2 inclusive are vulnerable to this exploit, as Apple has patched this vulnerability in its 10.10.3 release.

The Red Canary platform allows us to detect a variety of threats on Windows and Mac OS X endpoints. We investigated how we could leverage our endpoint sensor of choice, Carbon Black, to detect this threat for our customers when we learned about this vulnerability. This post provides some insight into how you can detect this activity on your network using data from Carbon Black.

In order to understand how to detect this threat, one must first understand how Apple provides applications with low privileges or in a sandbox–for example, applications downloaded from the Mac App Store–to access privileged system services. Apple provides a low level service called the XPC Service API through which Apple and other software developers can create small helper tools that perform privileged work on behalf of other non-privileged applications.

This separation of privileges provides a net security benefit by reducing the attack surface for desktop applications. If an application must perform an action that is usually only available to privileged code – for example, changing system-wide network settings – then traditionally the entire application must be run with the elevated privileges required to perform that action. With XPC services, Apple aims to separate the small amount of code required to perform the privileged work from the much larger set of unprivileged code.

However, this security benefit only comes with very careful access control and carefully designed interfaces for the privileged components. In this case, a component called WriteConfigClient does not perform any access checks or sanitize its input, allowing any process to write files to the Mac’s file system as root.

How do we detect this activity? Now that we know that the flaw exists in the WriteConfigClient XPC service, we can look in Carbon Black for executions related to that specific service:

[gist ce85ccb5f4473456e522]

Once we have matched a process through this query, we can begin analyzing the file modification events from the xpcproxy process in order to determine whether this process successfully overwrote a system file. We can see this activity through the process view of the xpcproxy process in Carbon Black. In this case, the exploit overwrote the /usr/bin/rsh binary with a new binary.

process

process 1

Note: This Carbon Black query only identifies activity exploiting this vulnerability on Mac OS X 10.9.x (older versions use a different XPC service) and may identify activity that is not associated with CVE-2015-1130.  Additionally, while this will detect exploitation of the aforementioned vulnerability, processes matching this query may have been compromised in another manner. In any event, a process matching these criteria should be further investigated.

While we are providing this detection for the benefit of the community, it also highlights a key benefit of our approach: rapid identification of suspicious behaviors without explicit knowledge of the tool(s) an attacker uses. After alerting our client to the occurrence, they or their IR partners can surgically remediate the threat.  This also allows them to determine whether a more expansive investigation is warranted.

 

Apple picking: Bobbing for Atomic Stealer & other macOS malware

 

Keep track of AWS user activity with SourceIdentity attribute

 

Trending cyberthreats and techniques from the first half of 2024

 

Detecting brute-force attacks with a smart watchlist

Subscribe to our blog

 
 
Back to Top