Leap-A Trojan

From MacShadows KB

Introduction

This article's purpose is to stop misinformation about the recent Mac OS X Trojan titled "Leap-A", also known as "Oompa Loompa" or "latestpics". Many news sites, including CNN, have, in my opinion, reported incorrectly on it. In addition a lot of people, especially in the underground community, feel the need to contribute to the article, so if you can provide useful information, I invite you to add to this article.

Origin

The Leap-A Trojan first surfaced on the 10th of February, 2006 on the Macintosh Underground forums by a user named "r3d3pshun". It was later renamed and posted to the MacRumors forums. It has since gained much press attention as the "first Mac virus" and misinformation has been spread on many news sites.

Classification

Many people have speculated that this is a virus, or worm instead of a trojan. While there are no precise definitions for any, it is my opinion and the opinion of many others that this is in fact a trojan. One of the main reasons I classified it this way is because it does masquerade as a JPEG image file, and because of an error in the program it does not "infect" files properly, and destroys them instead. Therefore it does not successfully replicate by injecting itself into other executables, and its only means of replication is copying itself to the /tmp directory on the computer, used for transmitting itself over Apple's iChat to everyone on the Bonjour buddy list. While this propagation may seem to be a characteristic of a worm, it must be kept in mind that worms do not require user intervention, whereas Leap-A requires the recipient to accept the file transfer.

Infection

Since the Leap-A Trojan uses Spotlight, it will only work on 10.4.x. In addition to this, Intel machine users need not worry, as the InputManagers are not loaded on these systems, and the trojan itself is a PPC binary. (No word as of yet if it runs in Rosetta.)

Appearance

Leap-A is usually sent bundled in a gzip compressed tarball ("latestpics.tgz"), with a resource fork of the preview JPEG custom file icon. It usually appears as a JPEG file, without an extension named "latestpics", and is claimed to be pictures of Apple products, previews of Mac OS 10.5 "Leopard", or Britney Spears' child.

The following files are contained within the archive:

._latestpics
latestpics

How it spreads

Originally Leap-A was spread by links on forums to a RapidShare download. The Trojan spreads itself by way of Apple's instant messanger iChat. An infected user will automatically send the file to all the contacts on his Bonjour list, without noticing, but the end receiver will have to accept the file, decompress it, and then open the application.

It cannot send itself over the Internet.

What it does

The trojan relies heavily on "system" calls, using external applications to do most of the work rather than doing it itself. It's supposedly written in the C programming language, and has the following functions:

_copySelf 
_infectApps 
_installHooks 
_receive_samples 
_hook 
_infect

Here is a string dump of the executable ("strings -a -16 latestpics"):

__dyld_mod_term_funcs 
__dyld_make_delayed_module_initializer_calls 
__dyld_image_count 
__dyld_get_image_name 
__dyld_get_image_header 
__dyld_NSLookupSymbolInImage 
__dyld_NSAddressOfSymbol 
The kernel support for the dynamic linker is not present to run this program. 
/..namedfork/rsrc 
/usr/bin/tar -zxf /tmp/hook -C /tmp 
/Library/InputManagers 
/bin/rm -rf /Library/InputManagers/apphook 
/bin/mv -f /tmp/apphook /Library/InputManagers 
~/Library/InputManagers 
/bin/rm -rf ~/Library/InputManagers/apphook 
/bin/mv -f /tmp/apphook ~/Library/InputManagers 
%s/Contents/MacOS/%s 
/bin/cp '%s' '%s/..namedfork/rsrc' 
/bin/cp -f '%s' '%s' 
(kMDItemKind == 'Application') && (kMDItemLastUsedDate >= $time.this_month) 
/usr/bin/ditto %s /tmp/latestpics 
/usr/bin/gzip -f -q /tmp/latestpics

And here is a link to the mirrored decompilation of the executable: latestpics_annotated.txt

The following happens when the file is executed:

It copies itself to /tmp as "latestpics"
It recreates its resource fork in /tmp (with the custom icon in it) from an internally stored gzip'd copy, then sets custom icon bit for the new file in /tmp
It then tar + gzips itself so a pristine copy of itself in .tgz format is left in /tmp
It renames itself from "latestpics.tar.gz" to "latestpics.tgz" then deletes the copied "latestpics" executable from /tmp
It extracts an Input Manager called "apphook.bundle" that is embedded in the mach-o executable, and copies it to /tmp
If your uid is 0 (you're root), it creates /Library/InputManagers/ , deletes any existing "apphook" bundle in that folder, and copies "apphook" from /tmp to that folder, If your uid is not 0 (you're not root), it creates ~/Library/InputManagers/, deletes any existing "apphook" bundle in that folder, and copies "apphook" from /tmp to that folder
When any application is launched, Mac OS X loads the newly installed "apphook" Input Manager automatically into its address space
When an application is subsequently launched, the "apphook.bundle" Input Manager then appears to try to send the pristine "latestpics.tgz" file in /tmp to people on your buddy list via iChat (who will then presumably download the file, double-click on it, and the cycle repeats).
It only sends itself to people on your local Bonjour (aka "Rendezvous") buddy list; It cannot send itself over the Internet.
It then uses Spotlight to find the four (4) most recently used applications on your machine that are not owned by root
In an apparent "Charlie and the Chocolate Factory" reference, it then checks to see if the xattr 'oompa' of the application executable is greater than 0... if so, it bails out, to prevent it from re-infecting an already infected application
If not, it sets the xattr 'oompa' of the application executable to be 'loompa' (this does nothing, it is just a marker that it has infected this app)
It then copies the application executable to its own resource fork, and replaces the application executable with the trojan
When an infected application is launched from then on, the trojan code is executed, and it tries to re-infect and re-propagate itself to other applications
It then does an execv on the resource fork of the executable, which is the original application, so the application launches as it normally would (in theory... see below)
Due to a bug in its code for executing the original app from its resource fork, it is only allocating a buffer 4 bytes bigger than the path when appending "/..namedfork/rsrc" to the path and will stop any app it infects from running. Instead of adding the length of the string, it errantly adds the length of the pointer to the string, which is always 4 bytes.

Life expectancy

The life of this trojan should be short lived at best. The fact it doesn't spread through the Internet, requires direct user interaction, and several other factors (common sense) should contribute to its swift end.

Prevention

Obviously infection can be prevented mainly by common sense. Not opening things you're unsure of, "getting info" on them, and asking people about files they send to you are all things users should make habit to do. While I understand Mac users are used to a kind of "invulnerability" when it comes to malware, this has never really been the case. Many people have written malicious scripts and bundles that performed similar to this, but they were never released into the wild, or intended to harm. Now, this doesn't mean you need to rush out and buy the latest anti-virus software the "security experts" are peddling, and that next week virii and worms are going to be spread throughout the Mac OS X community. It's more of a wake up call to OSX users that things aren't always what they appear, and that you can't always rely on your system for your total security and should have a hand in it yourself.

The exploitation of a feature known as swizzling [1] where InputManager bundles are loaded each time any application is launched, is at the heart of the trojan.

Denying access to InputManagers

One of the easiest ways to prevent infection is to create the InputManagers folders, make them owned by the root user, and then as a safe measure, deny all access to them. This can easily be achieved with the following commands within Mac OS X's Terminal application, or another Terminal emulator:

mkdir ~/Library/InputManagers /Library/InputManagers
chmod 000 ~/Library/InputManagers /Library/InputManagers
sudo chown 0 ~/Library/InputManagers /Library/InputManagers

Note that this cure will only work for copies of Leap-A presently in the wild: systems prior to Tiger and/or using third party products which access the /Library/StartupItems directory may be vulnerable to the exploit used in Leap-A. Further hardening of /Library/StartupItems along the lines of the above is therefore recommended for these systems.

Symlinking InputManagers to the Trash

Another measure that could be taken (but may not work) is to symlink InputManagers to the trash like so

 ln -s ~/.Trash/ ~/Library/InputManagers && ln -s ~/.Trash/ /Library/InputManagers

but this may cause problems for other programs that use InputManagers.

Third party applications

A simple way to stop this Trojan from spreading is to not use iChat, seeing as it will only transfer through that application, also making sure not to accept any file over iChat that the other user did not intend to send to you. You may wish to use a client like Adium X instead.

For those of you that aren't Unix-savvy but want to take direct preventative action, you can use third party applications like Oompa Stompa or the free Mac antivirus software, ClamXav.

Things to keep in mind

It is also very important to remember that some innocent applications require access to InputManagers, and you would need to reverse these procedures, so it is once again suggested that you use common sense above all other methods. Should you decide to take action, Oompa Stompa provides the ability to reverse any changes it makes.

Removal

This is just going by order of looking at what it does and trying to counteract each of those steps. In Terminal, or another terminal emulator, enter the following commands. Removing files that don't exist will not hurt your computer.

rm -fr ~/Library/InputManagers/apphook.bundle
rm -fr /Library/InputManagers/apphook.bundle

The /tmp directory is emptied on startup, so so you can remove the file directly with:

rm -fr /tmp/latestpics.tgz

or just wait for it to be deleted next time you restart.

Depending on when you downloaded latestpics change 60 to however many minutes ago you downloaded latestpics, this should tell you which applications have been modified, it's not great but if you don't remember modifying any applications you should delete anything found by this command and replace it with a fresh copy.

find /Applications -name '*MacOS*' -cmin 60

Contributers

The following people have directly or indirectly contributed to this article (Alphabetical order by first name/psuedonym):

Andrew Welch
Braden Thomas
Ed Wynne
Glenn Anderson
Jinxie
Lambo (Joe Lamb) - Writer of Oompa Stompa
reikon (Thomas Dixon)
Rick
Subterraneus (Alex Karpinski)

References