Why Legacy Technologies Won’t Solve Mac Security

A couple of days ago, we learned from Intego that malware on the Mac OS X platform continues to mutate and create problems for Mac users. This new threat is a twist on an older version: OSX/Tibet.C. Tibet.C used an exploit in Microsoft Word for Mac to create a LaunchAgent that starts the next time a user logged in. The malware would then call-out to the attacker’s systems and allow the attacker to use the agent to penetrate the user’s Mac. The new variant, labeled as Tibet.D by Intego, leverages vulnerabilities in Java and can deploy the LaunchAgent from browser-based Java apps.

Despite the use of antivirus with the definition of the old variant, and with tools such application sandboxing and Gatekeeper available, this malware was still able to infect systems and deploy backdoor agents without the user’s knowledge (it is still not clear if this threat could bypass Gatekeeper). I can imagine if the LaunchAgent was a Java app, that yes, it would bypass Gatekeeper as the native executable would be the Java VM, which is allowed to run by Gatekeeper. And if it wasn’t, it demonstrates that the threat is very sophisticated and backed by highly advanced and persistent resources. Bypassing the sandbox security of both the browser and Java apps is already a strong indication of an advanced persistent threat (APT).

Legacy technologies like AV that scan for known patterns simply can’t keep up with the threats that exist today. In the original discussion by Intego, regarding Tibet.C (the previous version), it was noted that the attack exploited Word and could easily be modified and adapted for other malware. It was also noted in the discussion of this latest threat that updating to the latest AV definitions would prevent this. My immediate thought is: “what about zero-day permutations of this?” Stopping threats in today’s world requires an entirely different approach. Such an approach needs three key components:

  1. Requires visibility into the creation of new executables or the modification of existing executables
  2. Treat any new executable as untrusted—unless otherwise approved by some identifiable marker or process (signed, system update, etc.)
  3. Block any untrusted executable from loading

This straightforward and simple approach would have notified an IT organization of the real-time presence of Tibet.D as well as prevented it from executing. Apple has started down this path with Gatekeeper, a very basic default-deny mechanism. However, Gatekeeper lacks the necessary component of visibility—and for whatever reason—this malware was able to bypass it. It could be because the LaunchAgent was a Java app, or it could be a yet unknown vulnerability in Gatekeeper. To be fair, it could also be because the targeted machines had Gatekeeper disabled, but we don’t know that yet.

I know some people will say that this approach to security might get in the way of users running new and valid apps. Others will say that while it sounds simple, it may be too much data to manage. Every simple solution often has devilish details—otherwise everyone would be doing it. But we’ve spent years working out those details and making the management of trust policies within an advanced application control and whitelisting solution extremely low-impact. We’ve also added other core capabilities—outside of just protection—focusing on visibility, detection and responding to these types of incidents.

I can say that Bit9 for Mac, with its real-time endpoint sensor and recorder, would be able to detect the presence of this new threat and report this within the Bit9 Console to alert IT. With minimal effort to establish enforcement policies, it would also be able to prevent this threat and any permutation like it—past, present or future—from executing on any Mac endpoint.

Why Legacy Technologies Won’t Solve Mac Security | Bit9 Blog.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of the author. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided "as-is". The author shall not be liable for any damages whatsoever arising out of the content or use of this blog.
%d bloggers like this: