OS X: The Trojans Are Here

While I do my best not to be the grip reaper of IT security, I believe that the recent release of OS X trojans is a bit more significant than others. Here is a brief rundown of the recently discovered malware:

CME-4 (OS X Leap.A) – Disguised as screenshots of OS X 10.5 “Lepord”, this malware travels through iChat and presents itself as a compressed file. In order to get infected a user would have to download this file, uncompress it, click on the JPG impage inside, then enter the administrator username and password. Whew, that’s a lot of work to get infected. However, keep in mind that viruses on the PC side travel as compressed email attachments with the password contained in the email. These viruses have been known to be successful. Once CME-4 infects a system, it runs through the standard malware behavior which includes embedding itself into existing binaries on the system, attempts to propigate itself, and in true malware fashion, contains bugs that prevent it from performing certain tasks (maybe its a good thing malware writers don’t unit test or QA their code :).
OSX/Inqtana.A – This worms uses a bluetooth vulnerability from May 2005 to spread from computer to computer. The worm, quite frankly, is pretty lame. It shuts itself off after February 24, 2006. Users must accept the data transfer over bluetooth (Which means bluetooth must be enabled). It has mechanisms to spread to other computers. There are no reports of this worm in the wild and it does not appear to do anything other than spread, hence it is being dubbed a “proof of concept”.

When you look at the above malware you probably come to the same conclusion as most, “No big deal, the malware doesn’t really do anything bad, nor does it spread very well”. And, your right, the risk that the malware poses by itself does not warrant classification as a critical security threat. However, it is very likely that its a testament of things to come. I’d like to jump in the time machine and take us back to the times of Code Red. It spread fast, but was pretty lame too. It was memory resident. It merely defaced the web page. It had no backdoor. It was pretty easy to detect. Remember what happened after? We got hit with Code Red, NIMDA, and a slew of other worms that plagued our networks for years to come. Was Code Red a test? I think so (think about how hard it is to come up with a worm test lab that emulates the Internet and people’s behavior). Wait, people’s behavior? Yes, not only do I believe that malware writers release worms to test code and see how a worm propagates on the network, but they release them to test our reaction. How do users respond? How do anti-virus companies respond? How well does current anti-virus software pick up on the new malware? OS X and its user base has been largely untested when it comes to malware, and in my opinion is very unprepared.
The canary is dead. OS X users need to start running out of the mines they have been so deeply buried in all this time.
So what do we do? Here are some tips, that will come as no surprise to those who are familiar with locking down a UNIX or Windows host:

Patch – You not only need to patch your operating system, but all of your applications as well. Applications such as Version Tracker can help you do this.
Firewall – The built-in firewall in its default configuration is very weak. It should definitely be enabled, but some work must be done to overcome its shortcomings (ever try to Nmap an OS X host? Try fragmenting the packets or setting your source port to 20). Also consider a 3rd party add-on, such as Brickhouse to ease the configuration pain, unless you are really good with ipfw.
Disable unnecessary services – Bluetooth would fall into this category, in addition to other services you may have enabled on your OS X system that you do not use.
Proper user permissions – If it can be helped, do not run with a user that has administrative privileges. I run as a normal user in OS X, then use fast user switching to logon as administrator. I know that in previous articles I have warned against fast user switching as it does create some physical security concerns, but in this case I think its more important to be able to logon with regular user privileges.

.com