BugTraq
InqTana Through the eyes of Dr. Frankenstein. Feb 22 2006 07:30AM
KF (lists) (kf_lists digitalmunition com)
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/Ma
cOS/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/T
asks/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/Dynami
cLibraries/Articles/DynamicLibraryDesignGuidelines.html

k-fs-ibook:~ kf$ /usr/bin/say "All, your bluetooth, and OSX,,, are belong,, to, us"

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus