![Helping Non-Security Stakeholders Understand ATT&CK in 10 Minutes or Less [VIDEO]](https://assets.crowdstrike.com/is/image/crowdstrikeinc/video-ATTCK2-1)
![Qatar’s Commercial Bank Chooses CrowdStrike Falcon®: A Partnership Based on Trust [VIDEO]](https://assets.crowdstrike.com/is/image/crowdstrikeinc/Edward-Gonam-Qatar-Blog2-1)
![Endpoint Protection and Threat Intelligence: The Way Forward [VIDEO]](https://assets.crowdstrike.com/is/image/crowdstrikeinc/GK-Blog_Images-1)
A comprehensive Next-Generation Endpoint Protection strategy shouldn’t just be about reacting and responding to threats, but also be complemented by the ability to prevent such threats from successfully operating to begin with. Such preventative measures are usually implemented by preventing the execution (or other operations) of malicious applications, or sometimes by hardening processes by using mitigations against common exploit techniques. However, there is a third, even more powerful solution which can be generalized: system-wide/platform security improvements that prohibit entire classes of attacks from successfully running.
In the Windows world, such platform-wide mitigations are typically implemented by Microsoft themselves, as 3rd parties don’t usually have the same tools that would allow them to operate in the kernel at a level that would allow such mitigations to be implemented. For example, while Windows filter drivers often have the ability to monitor system operations, very rarely can they deny system operations from occurring, or the granularity offered by such mechanisms is not fine enough to prevent simple bypass mechanisms. That being said, Microsoft does, on their own, implement what are probably the strictest set of platform mitigations across all other major operating systems, exemplified by the latest Virtualization-Based Security framework in Windows 10, which you can read more about here or watch my Black Hat 2015 presentation here.
On Linux, the playing field is changed significantly. The ability to implement an LSM (Linux Security Module) provides capabilities even beyond what Mandatory Access Control (MAC) can offer. In fact, MAC on Linux is actually implemented with an LSM itself, such as the popular SeLinux implementation. Going down from implementing a full-fledged LSM, one can integrate with many of the existing LSM solutions that already exist, and write policies that sit directly on top of these engines. These policies can be successfully used to mitigate against a number of possible attacks.
And finally, on Mac, the subject of this post, a blend of the Windows and Linux world is present. For starters, Apple discourages 3rd party kernel extensions, especially in the security space. On the other hand, they provide an implementation of a MAC (Mandatory Access Control) framework that exists on OS X, which is based off TrustedBSD. Similarly to Microsoft, however, it is Apple itself which provides security solutions that leverage this framework, such as GateKeeper, SeatBelt, and the new “Rootless” or System Integrity Protection (SIP) mechanism in El Capitan. Contrasting with Windows systems however, this framework can be used by 3rd parties and the header files are fully documented for such use. Using the MAC framework allows for the creation of custom policies, which can co-exist with existing system integrity solutions. By allowing multiple MAC policies to be active, the Mac platform actually surpasses Linux, which still only allows a single LSM in the vast majority of distributions (nested LSM capability is not yet in mainline kernel).
By leveraging this MAC framework, SektionEins, the company founded by the infamous iOS and OS X Hacker known as i0n1c or Stefan Esser, created a tool called SUIDGuard, which prevents a specific attack vector that was patched in OS X 10.10.5, as well as two general system security failings which can be misused by various classes of attacks.
The first attack leverages the use of a special environment variable parsed by the dynamic linker (DYLD) which ultimately allowed the execution of binaries running with root-level privileges. SUIDGuard prevents the use of this environment variable in certain contexts where its use could be abused. For the attack to succeed however, an attack technique must be used, which leverages the ability of a non-privileged user with append rights to a file owned by root, to upgrade the append rights to full write permissions, and thus overwrite the file with attacker-controlled content — including executable files with the SUID bit set. SUIDGuard prohibits this technique from functioning, which degrades the ability of other similar exploits from having a higher control of the file system than they should.
Finally, SUIDGuard provides a third protection, which removes the ability to create executable files that force the operating system to map the NULL page. By having the NULL page controllable by an attacker, kernel NULL-pointer dereferences can lead to information leaks, or worse, kernel code execution at system privileges. While this attack was not needed for the aforementioned DYLD exploit, it is often used in other exploits, and this mitigation kills this technique. It should be noted that Windows 8 already offers this mitigation, as does Windows 7 on 64-bit platforms, or Windows 7 combined with EMET, freely downloadable from Microsoft.
SUIDGuard provides an excellent example of what can be implemented on the Mac platform by leveraging the system’s security framework. However, it suffers from a few problems if applied to an enterprise environment:
- It must be manually deployed to each system on the enterprise, and manually upgraded and uninstalled. There is no way to see which versions are installed on which machines, and if an upgrade is available.
- It provides no alerting mechanism — it protects against the attacks, but does not have a way to show that an attack attempt occurred (which could indicate the attacker may try another technique)
- It provides no ability to manage policy around which applications should be allowed to perform one of the banned operations. For example, compatibility concerns may warrant certain applications from continuing to be allowed to remove the append flag — or perhaps on a honeypot machine, we may want the attack to succeed in one instance.
- It is a separate MAC policy implementation, which has to co-exist with other endpoint products, as well as Apple’s own policies. There is a limited set (8) of MAC policies that are allowed on OS X — these will eventually be exhausted with one-off solutions being deployed across an environment.
- It is supported by a single developer, which can result in increased response times, and difficulty dealing with enterprise-level support issues that can arise during 10000-node-plus deployments.
As the implementation is open-sourced, we contacted SektionEins to request permission to integrate the functionality into CrowdStrike Falcon® for Mac. As of the latest release that our customers received two months ago, the full suite of protection capabilities offered by SUIDGuard is now also implemented in our product, which removes the need to install the separate kernel extension. Additionally, by being fully integrated with Falcon, the management of SUIDGuard is handled by customers in the same way they manage other existing platform and exploit mitigations, as well as with visibility into the full event data in their UI and events
workflows, showing which processes attempted the attack, which files were being replaced, and more. Whitelisting requests can be filed with our Support team just like with other types of mitigations. We hope our customers will enjoy this increased level of protection on their Mac platforms. CrowdStrike will continue to integrate future SUIDGuard enhancements, as well as independently provide additional prevention features in the future.
