{"id":11973,"date":"2013-03-26T12:36:24","date_gmt":"2013-03-26T19:36:24","guid":{"rendered":"http:\/\/www.intego.com\/mac-security-blog\/?p=11973"},"modified":"2019-05-17T21:50:34","modified_gmt":"2019-05-18T04:50:34","slug":"do-os-xs-built-in-security-features-offer-good-enough-protection","status":"publish","type":"post","link":"https:\/\/www.intego.com\/mac-security-blog\/do-os-xs-built-in-security-features-offer-good-enough-protection\/","title":{"rendered":"Do OS X’s Built-In Security Features Offer Good Enough Protection?"},"content":{"rendered":"

\"\"<\/p>\n

There has been a lot of talk about the malware that hit a number of high profile Mac developers<\/a>\u00a0and the fact that Pintsized got through OS X\u2019s security features. While Apple’s built-in features are definitely helpful and vastly better than being on the Internet totally unprotected, they are not designed to be a full security solution. There are many very simple ways to get around these security features, and there is no functionality to clean up if something does bypass them.<\/p>\n

You may be wondering, “What are these various security functions? How are they helpful? And how can they be circumvented?” Here’s a rundown of Apple’s most high-profile security features.<\/p>\n

XProtect and Gatekeeper<\/h3>\n

\"\"<\/p>\n

XProtect was designed<\/a> as a way to prevent or mitigate some general problems and specific threats that were hitting a large section of their userbase. The general protections are the warnings you see about potentially dangerous file-types. The anti-malware component does help detect malware, but it\u2019s intended to be strictly reactive. The detections are quite specific, and there is no heuristic or generic detection. There is almost no chance it would detect something brand new. <\/strong><\/p>\n

XProtect is not intended to be what one would consider a \u201cmodern AV product\u201d \u2013 it\u2019s only designed to find a very small handful of existing threats. There\u2019s also a big window between the time researchers (from Apple or from other security companies) discover new Mac-related threats and when they\u2019re added to XProtect. Malware that is less prevalent never makes it into XProtect, which isn\u2019t much help if you\u2019re one of those few who are affected. In the case of the watering hole attack, XProtect was not updated to cover this threat \u2013 Apple created a removal tool<\/a> which was originally bundled with a Java update, which makes sense in that the threat relied on Java to infect.<\/p>\n

Gatekeeper<\/a> was designed to help limit the applications that you can intentionally install. It can be helpful when a threat relies solely on social engineering to get you to infect your system \u2013 the dreaded double-click of doom. But if the malware authors manage to get hold of a certificate to sign their creations so that it looks legit, you\u2019re out of luck. Or if the threat uses an exploit (such as the Java 0-day in this instance) to install silently, you\u2019re once again out of luck.<\/p>\n

Both Gatekeeper and XProtect care about where you got a given file \u2013 if you\u2019ve gotten a file from fixed media (from a disk, rather than from the Internet) or from applications that are not ones that it monitors, it won\u2019t warn you. And if it\u2019s one of the file-types OS X considers safe, it also will not warn you. And both features only concern themselves with files coming into your machine. They won\u2019t prevent malware from going out (should you share a file via Dropbox or email, for instance).<\/p>\n

Apple\u2019s Firewall<\/h3>\n

\"\"<\/p>\n

The Application Firewall<\/a> was designed to protect you from attacks coming from outside your machine \u2013 it filters inbound connections, but not outbound<\/strong>. This is great if someone is trying to use common attack tools that try to look for listening ports, but not so great if the threat has somehow managed to get on your machine already, as in the case of malware. If malware or hackers manage to get into your machine, they can send your data out to attackers. Ideally, you should be alerted to strange traffic both coming into and going out of your machine, so if they manage to bypass one defense, they may not get past the next.<\/p>\n

You have three main options when you set up Apple\u2019s firewall:<\/p>\n

    \n
  1. The default option is to let only signed applications connect into your computer.<\/li>\n
  2. Another option is to block all non-essential incoming connections, which will obviously limit many common programs that might need to communicate with your machine.<\/li>\n
  3. The final option is to enable \u201cStealth Mode,\u201d which means it will not acknowledge (or respond to) requests from diagnostic tools that use ICMP<\/a>, like Ping or Traceroute.<\/li>\n<\/ol>\n

    You can use any one option individually or in combination with the others. And you can allow or block specific applications separate from these three options.<\/p>\n

    Sandboxing<\/h3>\n

    \"\"<\/p>\n

    When you’re dealing with something potentially explosive, sometimes the best thing to do is to try and limit the damage. Exploits work by busting their way out of the context of an application so they can get into areas where they\u2019re not really supposed to be in order to run whatever code they like. So, if an app developer creates a sandboxed version of their product<\/a>, they can essentially put themselves in a walled-off enclosure that limits what damage a potential exploit can do. Apple has required this of apps that are sold in their App Store. It\u2019s good for users, in a security context, for developers to take this measure if they can. (Plus, being in the App Store is good exposure for the developer.)<\/p>\n

    As we all know, because iOS only lets you install apps from the App Store (unless you\u2019ve jailbroken your device), this is how all iOS apps operate. This is a big limitation of their functionality versus what you can do with apps on a mobile OS like Android, but also why there has been very little interest by malware authors in creating threats for iOS thus far. It’s simply too much work for too little benefit right now.<\/p>\n

    Because it severely limits what apps can do, for many products sandboxing may simply degrade the user experience too much. Applications that are popular due to 3rd<\/span>\u00a0party plugins, allow you to access files throughout your system or on a network, or interact with non-USB devices can\u2019t be sandboxed. That covers a lot of popular products, including utilities like anti-virus software, among many others. So while it does limit the possibility and power of exploits, it also severely limits the power of the applications themselves, so not all developers can or will sandbox their apps<\/strong>. (Searching for websites pertaining to OS X Sandboxed Apps largely returns articles with words like Sad<\/em>, Frustration<\/em>, Ruin<\/em>, and Killjoy<\/em> in the title;, and these articles are mostly written by app developers. \u2018Nuff said.)<\/p>\n

    Address Space Layout Randomization (ASLR)<\/h3>\n

    \"\"<\/p>\n

    Without going into painful technical detail, the short of ASLR<\/a> is that it tries to make it harder for people to use vulnerabilities in software to create exploits that run arbitrary code. At this point, every major OS has implemented ASLR to some extent, and these versions have been around for many years. Yes, even Windows and Android have ASLR. And, as we\u2019ve not yet heard about the end of exploits, and the jailbreaks or malware that use them, I\u2019m gonna go out on a limb and say this has not really been a sufficient deterrent in the fight against vulnerabilities leading to exploits. Bypassing ASLR has simply become the new cost of entry.<\/strong><\/p>\n

    It’s a Start, But It’s Not Foolproof<\/h3>\n

    \"\"<\/p>\n

    In all these cases, these security features are awesome tools that make you way safer than having no protection at all. They\u2019re meant to help keep you safe from some fairly common types of attacks, but by no means all types. Each feature leaves some pretty large opportunities for malware to get through.<\/strong> And all OS X users have access to this same protection. That means almost all Mac users are protected to at least this degree, and attackers know this. It\u2019s fairly trivial to go beyond that level, which is exactly what happened to the Mac developers that got hit with Pintsized. To be just a little better protected than the next guy, you need to apply additional tools that cover more advanced types of attacks.<\/p>\n

    Apple app sandbox image via Mac Developer Library<\/a><\/em><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

    There has been a lot of talk about the malware that hit a number of high profile Mac developers\u00a0and the fact that Pintsized got through OS X\u2019s security features. While Apple’s built-in features are definitely helpful and vastly better than being on the Internet totally unprotected, they are not designed to be a full security […]<\/p>\n","protected":false},"author":6,"featured_media":12515,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false},"categories":[7,151],"tags":[168,319,303],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\t\n\t\n\t\n