Malicious Bundles on Mac OS X
One of the cool (but somewhat unknown to non-developers) features in Mac OS X is the ability to load bundle code into arbitrary applications using the InputManagers directory. Basically, any bundle that is loaded into the InputManagers directory in a user’s Library directory (or the root Library directory) will be loaded into every application that user opens.
One of the cool features of the Objective-C runtime environment is the ability to dynamically change functions within an application. I call this Method Swizzling, because that’s what CocoaDev calls it (http://www.cocoadev.com/index.pl?MethodSwizzling), and I like the name. Cocoa applications are extremely easy to reverse-engineer using tools like otool and class-dump, from which one can obtain the entire class listing of the application. Selecting a function to swizzle is as simple as reading the class and selector names.
The combination of the Objective-C runtime swizzling and the InputManagers bundle-loading feature gives the user the ability to easily modify the behavior of any application they have. Some software crackers use this functionality to easily modify the registration-checking code in Objective-C applications. Some legitimate software companies offer such bundles to modify applications to add features. One example (and where I first heard of the InputManagers hack) is SubEthaFari.
The ability to make such modifications without any user notification (and modifying a user’s InputManagers directory is available to any process running as the user), has been previously put forth as a security problem with Mac OS X. I wanted to further investigate the possibility of malicious bundles on Mac OS X, and their effect on the end user.
Although Mac OS X is well known and frequently touted to be free from viruses spreading among the public, the InputManagers interface offers an easy way for virus spread, while avoiding the suspicion of the knowledgable user, that may have a tool like “Little Snitch” active and watching outgoing network connections. For example, I wrote a proof-of-concept malicious bundle called mailHack that loads within the Mail.app application and swizzles the [MessageEditor send:] function. The hacked version of the function calls [self addFileWrappersForPaths:myFilePath], where myFilePath points to its own file path. This adds itself as an attachment to any email sent through the Mail.app application. There is no user notification whatsoever, except the user might notice their email takes slightly longer to send than usual.
Download the source code to mailHack here
I also wrote a second proof-of-concept bundle called iChatHack that patches numerous functions within iChat. By patching the [BuddyList personStatusChanged:] function, I was able to run my code anytime someone’s status changed. The bundle uses the [FileSender _sendFile] function to send itself every person who is already online or later comes online. By patching three FileProgress functions, I was able to perform the operation without notifying the user that the file transfer is taking place.
Download the source code to iChatHack here
Today there was no real response to this information. So, I decided to write a proof-of-concept bundle called safariHack. It patches a couple functions within Safari that send login information to secure webpages. The bundle stores the login information from the pages and saves it out to a SQLite database at ~/Library/Safari.db, as well as outputing what data it has "stolen" to the console log. Requires OS 10.4 because of its dependence on SQLite. Of course the SQLite stuff isn't necessary, I just felt like playing with SQLite.
Download the source code to safariHack here
What’s unique about this method of malicious software spread is that it utilizes the flexibility of Objective-C to use existing software on the user’s machine to spread. Of course, the bundle code could also perform other tasks that the virus-writer wanted. Additionally, no escalated privileges are required in order to install an InputManager bundle.
Disclaimer: Source code to these modules is not in any way a functional virus, but only posted to demonstrate how a virus can utilize Method Swizzling maliciously. However, download, compile, and test at your own risk. I do not condone malware or malicious software. Do not ask me how to write a virus. Only the source code is included, and some knowledge of the input manager plist configuration files is necessary to use these bundles.
If you are aware of any inaccurate information on this page, please notify me immediately.