A file called "latestpics.tgz" was posted on a Mac rumors web site http://www.macrumors.com/ , claiming to be pictures of "MacOS X Leopard" (an upcoming version of MacOS X, aka "MacOS X 10.5"). It is actually a Trojan (or arguably, a very non-virulent virus). We'll call it "Oompa-Loompa" (aka "OSX/Oomp-A") for reasons that will become obvious.

Update: Some of the media reports have been inaccurate, stating that I "discovered" this trojan/virus. This is incorrect; it was discovered by a number of readers of http://www.MacRumors.com/ and was passed along to me by the admin of the site, arn. It has also been stated that I analyzed this trojan/virus alone; that's also incorrect. I did some work trudging through it, but primarily was a filter for the yeoman's work done by Ed Wynne and Glenn Anderson.

Unless you work for an anti-virus company, please don't email/message me asking for a copy of this trojan. It's not going to happen.

You cannot be infected by this unless you do all of the following:

1) Are somehow sent (via email, iChat, etc.) or download the "latestpics.tgz" file

2) Double-click on the file to decompress it

3) Double-click on the resulting file to "open" it

...and then for non-Admin users, it fails to infect most applications.

You cannot simply "catch" the virus. Even if someone does send you the "latestpics.tgz" file, you cannot be infected unless you unarchive the file, and then open it.

A few important points

-- This should probably be classified as a Trojan, not a virus, because it doesn't self-propagate externally (though it could arguably be called a very non-virulent virus)

-- It does not exploit any security holes; rather it uses "social engineering" to get the user to launch it on their system

-- If you're not running as an admin user, it will silently fail to infect most applications

-- It doesn't actually do anything other than attempt to propagate itself via iChat, and then only via Bonjour! (aka "Rendezvous) -- it does not sent itself over the Internet, rather just to your local Bonjour user list

-- It has a bug in the code that prevents it from working as intended, which has the side-effect of preventing infected applications from launching

-- It's not particularly sophisticated

--I'd really be tempted to call this thing a non-event; it's poorly written, can't spread beyond your local network, is unlikely to infect anything on most machines, and needs user interaction to do anything at all--

A good rule of thumb is: if your user account allows you to install an application without entering your password, then this trojan/virus can modify (infect) that application without you entering a password. Regardless, it can install the "apphook" InputManager portion of its payload no matter what type of user account you have (admin or non-admin).

To be on the safe side...

DO NOT DOWNLOAD OR RUN THIS FILE

It's come to my attention that this file was actually originally posted to a "hacking" web board under a different name, purporting to be a picture of the MacBook Pro internals. Someone likely renamed it and posted it to MacRumors.com.

When unarchived (it is a gzip-compressed tar file), which can be done by simply double-clicking on the file, it appears to be a JPEG file because someone pasted the image of a JPEG file onto the file.

After it's been unzipped, tar will tell you there are two files in the archive:

._latestpics
latestpics

...the ._latestpics is just the resource fork of the file, which contains the pasted in custom icon meant to fool people into double-clicking on it to (in theory) open the JPEG file for viewing. In actuality, double-clicking on it will launch an executable file.

The file "latestpics" is actually a PowerPC-compiled executable program, with routines such as:

_infect:
_infectApps:
_installHooks:
_copySelf:

Here's what it does if a user double-clicks on the file, or otherwise executes it:

1) It copies itself to /tmp as "latestpics"
2) 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
3) It then tar + gzips itself so a pristine copy of itself in .tgz format is left in /tmp
4) It renames itself from "latestpics.tar.gz" to "latestpics.tgz" then deletes the copied "latestpics" executable from /tmp

--This gives it a pristine copy of itself, for later transmission.--

5) It extracts an Input Manager called "apphook.bundle" that is embedded in the macho executable, and copies it to /tmp
6a) If your uid = 0 (you're root), it creates /Library/InputManagers/ , deletes any existing "apphook" bundle in that folder, and copies "apphook" from /tmp to that folder
6b) If your uid != 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
7) When any application is launched, MacOS X loads the newly installed "apphook" Input Manager automatically into its address space

--This allows it to have the code in the "apphook.bundle" injected into any subsequently launched application via the InputManager mechanism--

8a) 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).

8b) (It looks like the author intended to get it to send the "latestpics.tgz" file out via eMail as well, but never got around to writing that code)

9) It only sends itself to people on your local Bonjour! (aka "Rendezvous") buddy list; it cannot send itself over the Internet

--This lets it send itself to people on your Bonjour! buddy list via iChat; this appears to be the only way it self-propagates externally--

10) It then uses Spotlight to find the 4 most recently used applications on your machine that are not owned by root
11) In an apparent "Charlie and the Chocolate Factory" reference, it then checks to see if the xattr 'oompa' of the application executable is > 0... if so, it bails out, to prevent it from re-infecting an already infected application
12) 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)
13) It then copies the application executable to its own resource fork, and replaces the application executable with the OSX/Oomp-A trojan

nb: If run via double-clicking on the file, and the user doesn't have privileges to modify an application, it silently fails.

--It has thus effectively injected its code in the host application, but it can only do so for applications that the user has write access to--

13) 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
14) 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)
15) Due to a bug in it's code for executing the original app from it's resource fork, it is only allocating a buffer 4 bytes bigger than the path when appending "/..namedfork/rsrc" to the path, it 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.

--In the end, it doesn't appear to actually do anything other than try to propagate itself via iChat over your local Bonjour! buddy list (it cannot send itself over the Internet), and unintentionally prevent infected applications from running--

It seems that this is more of a "proof of concept" implementation that could be utilized to actually do something in the future, depending on how successful it is, or it was simply done to garner attention/press. Which I'm sure it'll get.

.....

The executable itself has a number of interesting things embedded into various macho segments, including an entire Input Manager bundle called "apphook" (stored as "latestpics_hook.tar"); the string data is "protected" with a simple XOR to prevent easy reading of what it's doing. It's definitely trying to mask what it is doing in a number of ways, but is relatively simplistic in nature.

If you are a programmer, attached is the disassembly of the executable (it's just a plain text file) for your reading pleasure. This is just the main executable portion of the code, not the embedded "apphook" InputManager code.

Thanks to Ed Wynne for his crucial help in uncovering the true nature of this trojan, Glenn Anderson for his southern-hemisphere hacking help, and other "smart friends".

Woof, that's interesting. Keep us updated Andrew.

Very Interesting.

Andrew,

If you have the file, could you send it to me for further disassembly? Also, this file should be submitted to entities like Symantec Security Response (e.g., via this method).

My contact information is below.

Andrew,

Please check your private messages.

"177 User(s) are reading this topic (174 Guests and 0 Anonymous Users)
3 Members: artoo-detoo, cpfusion, Steelix"

O.o

Woah.

Well tickle me pink! Our first malware!!!

Still, you'd have to be caught napping to actually launch this thing surely? I would get pretty suspicous if upon opening a jpeg, I got an admin password dialog.

Yeah, but there are some very stupid people out there.

That password dialog won't necessarily appear, if you're an admin already.

hi,

thanks for all the information. is it possibel to get the file for more investigation and make an signature for clamav?

thanks,
hag

Andrew,

why exactly is that? Normally, the admin password is required to write outside user space, so even a logged-in admin would be ask for a pw. What exactly is the Trojan trying to do when the password dialogue only appears with non-admins? (And wouldn't it be time for us to not run stuff as admins?! Though I thought the OS X admin model was secure.)

If the trojan adds an "apphook" file into /Library/InputManagers/ or
~/Library/InputManagers/
(depending upon whether one is logged in as Admin), would I be correct in thinking that if one did the following, the "apphook" would only be able to be installed with the user's knowledge?

1. If you don't have an InputManagers folder, create one
2. Then control click on the folder and select "enable folder actions"
3. Next, control click the InputManagers folder again and select "attach a folder action".
4. A window will open, click on "add - new item alert"
5. Click choose.

The modifications it does to applications.

A non-admin user may not be able to install/delete applications on a MacOS X machine without entering an admin password. An admin user can do it with impunity. Same rule of thumb applies to the trojan.

That would prevent it from attempting to send itself to people on your iChat buddy list, but it would still be able to infect your applications.

Hi,

how about changing permissions to Read only and/or locking the /Library/Input Manager/ (and user equivalent) folder? Would that lead to a password being requested?

I assume that any copy cats would still have to use the Input Manager folder for this (how else would they inject code into all applications?). I haven't looked at APE for a long time so don't recall how it works, but the method it uses is a potentially similar security hole is it not?

Presumably there would be a simple spotlight search to pick up any files that have been oopa loompa'd.

Anybody know what that might be? would 'mdfind oompa' or 'mdfind loompa' at the command line do the job?

Just a thought, but if you change the permissions of your library folder so that it is read only, and therefore requires a password to be entered for items to be changed etc, would that not protect un-infected users in the short term?

Just a thought from a n00b

OK, correct me if I'm wrong on any of this:

1) you have to be logged in as admin
2) you have to use something OTHER than Safari

So, for the vast majority of users, (like the prototypical grandma) they will get at least one warning, right?

I mean, if I downloaded something that claimed to be pictures I'd be suspicious of 1) a .tgz archive 2) one that Safari told me contain an application.

This seems a bit more like an IQ test than a proper worm, or am I not being charitable again?

I'd agree with 1) but Safari will not warn you that it is an application unless Safari decompresses it for you automatically. I don't use Safari, so I don't know if it auto-decompresses tarred files... I'm guessing not. In which case it won't give you any warning at all.

Honestly, I think the odds of anyone being affected by this are very, very small. You have to get the file somehow (and there seem to be very few people who have it), then you have to explicitly decompress it and double-click on it, then if you're not an admin user, you have to enter your password for it to infect applications (it can still install the InputManager portion without needing a password, though).

Remember, the InputManager portion of this little nasty is what tries to send itself via iChat... so if people you know start trying to send you "latestpics.tgz" via iChat, graciously decline to accept the file.

Regardless of anything, explicit user actions are needed for anyone to become infected by OSX/Oomp-A -- if you don't download, decompress, and then double click on the file, you can't become infected by it. It tries to fool the user into doing this, because it is at its core a rather simplistically written program.

We got dugg Davey...we got dugg.

Even so, that is the default setting for Safari, IIRC, so my point still stands that the prototypical Grandma is going to get at least one warning.

I don't use Safari much... <looks up in surprise> though I'm using it just now ... but I also don't run my machine as an admin.

Here's a stupid idea:

What if you were to create files with the names the program uses in /tmp, and make them non-changeable by anyone (owned and grouped to actual root, rather than just admins, and make 'em have no permissions access...)

That would make you need to have a password box too? Or maybe just give the program an error, because its something it can't deal with?

No, that would work. For this specific version. However, it would be trivial to have it use a random directory name in /tmp, or even a not so random name, perhaps your user name, for example?

I know, I thought of that too.


But, for this particular nasty, that would work.


EDIT: The "program" uses spotlight, what is its effect on machines running Panther?

It's interesting that the input manager as a vector was written about at length in a recent daringfireball.net article - I wonder if that was someone's inspiration?

So to clarify if you are logged in as an admin user then it will not ask for your password? Wow, at first I was under the impression that this would ask for a root password and then thinking why on earth would anyone be logged in full-time with a root account.

Just the vast majority of the Linux community.

Well, this is the first mainstream media report I've seen. The name they've given it (Leap-A) is no where near as good as yours Andrew.

Yeah, I emailed the sophos.com guys last night, provided them with a specimen, and some info... sadly "Oompa-Loompa" was too long for them, and by the time I suggested "OSX/Oomp-A" instead (which is just too perfect for words ), they'd already "gone to press" with their name, so to speak.

Looks like Slashdot has picked it up:

http://it.slashdot.org/it/06/02/16/1322209.shtml

...surprised the "Mac press" has been so slow to follow suit.

You might also try this command:

/usr/bin/find '/' -mmin -'60' -ls 2>/dev/null | grep -v -e"sec_qip" -e"proc"

This will locate all changed files at the root level of your harddrive in the last 60 minutes. If you have been recently infected you can run this and catch anything it has changed.

Oomp-A should have totally been the name.

Werd.

Thanks for the update. I've been running my account as admin, but it looks like I'll have to downgrade it just to be on the safe side.

That said... one trojan in the 5+ years that OSX has been around? I'm sure that Mac-bashers may try to grill us over this malware, but we've got a record they can only dream of.

I'm curious to see Apple's response to this.

I hope you're ready for the Digg effect, cause here it comes!

This was found by our digital crayonboy Marcus (who is having difficulties posting). So, I will pass this on to everyone here:

http://macdailynews.com/index.php/weblog/c...n_to_circulate/

We weathered a much larger Digg effect a couple of months back and these servers just kept right on ticking. I'd be slightly more concerned about the Slashdotting which is happening at the same time, but they built these babies tough.

ASW got linked to in a Slashdot article about this very thing. I think that might explain the 170+ guests appearing.

Oops, read the first page only.

I noticed a poll off a link from there where the question was whether Windoze or Mac were more secure.

I was shocked to find that 3% of people believe windoze is more secure.

Yay! Moki and the real name of the virus get mentioned on Mac Observer

Uh oh... we are on the front page of MacRumors. My poor forum!

(Nice work moki.)

Yeah, but that's certainly not common. Just a small minority of *nix techies and developers. Then again most people that use *nix are techies and I don't know too many consumers or average joe's that use it.

Digg + Slashdot + MacRumors = The perfect bandwidth storm

The forums are more then up for the task. Now if this happened a few months ago we would have problems.

Very nice test I must say.

So it seems. Color me impressed.

Can you guys PLEASE stop calling this thing a virus? Also stop calling it the first piece of malware. It is neither.

First off, the "virus" designation is *highly* inaccurate. A virus spreads by itself without any human interaction, whereas a trojan tricks the user into executing it (hence the name "trojan", from "trojan horse"). This is obviously a trojan. Calling it a virus simply feeds the FUD machine.

And as for the first piece of malware, its' also hardly that. It's probably the most-hyped Mac malware ever since OS X was released, but it's far from the first. Trojans are really nothing special at all - I could write a trojan extremely easily. There's no trick to it - the only "trick" to a trojan is figuring out how to socially-engineer people into opening it, and that has nothing to do with security on a platform. One trojan I can remember specifically was a few years ago when a new version of Office was about to be released a Mac trojan popped up on the P2P networks disguising itself as a bootleg Office installer. And there have been others too.

So please, stop calling this a virus, and stop pretending it's the first piece of malware to hit the Mac. No no no, it's just everybody overreacting and spewing FUD.

Where was anyone really doing that in this thread? andrew only gave the topic title such because when he began examining they weren't sure what it was yet. I think most people are pretty clear on what it is and is not by this point. Histrionics really aren't necessary.

Alright, I guess you're right, looking back you guys are discussing the mechanics of how this works and ignoring the naming. But I'm seeing plenty of people linking to these forums calling it a "virus", based on the topic of this board. Is it not possible to modify the title, or at the least modify the original post so it no longer says "virus"?

This is really very fascinating. I am very curious to learn more about it, to the degree that I'm tempted to find it and run it myself, but maybe some of you guys can just answer a couple of questions for me.

Firstly, I was under the impression that all executables must aquire root privledges before they can be installed on the computer. While this seems to need admin privledges to run properly, it would seem it does not need any sort of root user privledges. How is it that it bypasses this security feature? I would assume it does it through some sort of loop hole as oppossed to actually being clever coding.

Another thing I am curious about, when downloaded in Safari, does it successfully bypass Safari's "you are downloading an application" dialogue? If it does not, then getting that message when you think you are downloading a jpeg should be a dead give away. If it bypasses, I am also curious as to how. Does safari just depend on file extensions (.wdgt, .app, .exe) or is there something more sophisticated that was somehow tricked. It can tell when there is a compressed executable can't it? I mean, widgets are usually sent zipped up, and it detects those.

Thanks for all the info you have already given Andrew. I am a Computer Science major just getting into assembly level programming, and this really is fascinating stuff.