Digging deeper into the Leap-A malware

To get to the bottom of how serious a threat a piece of malware truly is, sometimes you have to take drastic steps—like deliberately infecting your own Mac to gauge the scope of potential damage. That’s what I did with the Leap-A malware that emerged Thursday, and I’ve learned that the program—while tricky—is not nearly as malicious as it could have been.

First some background: as I reported in the Leap-A FAQ, Leap-A (or Oompa Loompa, as it’s also known) is a potentially malicious program disguised as an image file. Expand the compressed archive and double-click the resulting file, and Leap-A will spring into action, installing itself on your system. The launched malware reportedly does two things: send a version of itself to everyone on your iChat buddy list and infect programs written in the Cocoa development environment. Once infected, those programs won’t be able to launch.

In the course of writing the FAQ, I felt that I needed to have Leap-A on my system, so that I could understand what it did once it was installed, and to understand how to recover from it. I also knew I couldn’t do this alone, as I’d need to have someone to test the iChat portion of the code with. I called on long-time Macworld contributor Kirk McElhearn, who set up a test machine in his office as well. What follows is the result of both of our efforts (so even though you may read “I,” this was really a team effort, as noted by the byline above.)

Setup

The first thing I did was set up my test machine, my handy PowerBook. I installed a fresh version of OS X 10.4 on a partition on a FireWire drive, updated it to 10.4.5, and then put a copy of Leap-A on the FireWire drive. I then booted from the FireWire drive and then unmounted the internal hard drive (for safety’s sake). I also disabled AirPort and unplugged the Ethernet cable. I now had an effectively isolated machine, ready to suffer the wrath of Leap-A.

Pulling the Trigger

With a slightly nervous finger, I double-clicked the .tgz file, watched it expand, then double-clicked the “JPEG image” to launch the malware. For all of you who are curious, here’s exactly what happened. A Terminal window appears, with the results of a script’s execution:

At this point, the malware is now installed on the machine. If you have your InputManagers folder owned by root, however, you’ll instead see a “Permission Denied” error message in that window. (Note that the bit that infects applications will still be installed.) The other thing that’s happened, which you won’t see, is that your /tmp directory now holds a copy of the .tgz archive, ready for distribution via iChat (more on that later).

Examining the impact

So there I was, ready to see the power of Leap-A. Since the machine wasn’t on the Internet as of yet, I thought I’d let it trash a few apps for me. So I launched and quit various Apple-provided Cocoa apps (since that’s what came installed on the machine)—Safari, Mail, Address Book, iCal, Terminal, Console, and so forth. All of them opened fine the first time. And the second. And the third. And the fourth. It seemed this portion of the malware was ineffective, at least on my machine. After a while, I gave up on that front, and decided to test the iChat portion of the program.

Kirk and I both set up new AIM identities to use in our iChat test. I re-enabled AirPort, launched iChat, and signed in with my ID from my now-infected PowerBook. When Kirk logged in, I added his ID to my buddy list, and waited for the fireworks. Nothing happened. We both tried various combinations of quitting and relaunching iChat, and transferring other files to each other, but we couldn’t replicate Leap-A’s reported behavior.

Kirk then infected his test machine as well, but still nothing—no files were being sent in either direction without one of us starting a file transfer in the usual manner. (He also couldn’t make the malware destroy any of his apps). After a good hour or more of this, we gave up on this portion of the malware’s alleged actions as well.

By now, I was several hours into this process, and beginning to think this whole thing was just a bad joke. All I’d managed to do so far was have a few files created on my PowerBook. But I couldn’t get Leap-A to kill any Cocoa apps, nor could Kirk and I get the malware to send itself out via iChat.

Friday morning, I was still bothered by my PowerBook’s apparent invincibility to Leap-A, so I connected with Kirk again via iChat (using our “healthy” systems). But this time, Kirk was in contact with someone from Intego, makers of the VirusBarrier X4 anti-virus software. Through a very lengthy debugging process (yes, we were spending time debugging a piece of malware!), we think we’ve finally figured out exactly how both pieces of Leap-A work, as well as how to best recover from an infection. Credit for most of the following goes to Kirk and the folks at Intego; I was merely a guinea pig and sounding board for much of the process.

Sending via iChat

It turns out that Leap-A will only send itself out via iChat under a very specific set of circumstances:

You must be using Bonjour iChat, not Internet-based iChat. That’s right. If you’re using iChat in the way that probably 99 percent of us do, you’ll never see this file being sent from an infected buddy. Leap-A will only send itself to others on your Bonjour buddy list. This is why Kirk and I were never able to get the malware to do its thing—we were not conversing via Bonjour. It sounds amazingly simple, but we spent quite a bit of time trying to figure this out before someone at Intego pointed out that it was limited to Bonjour networks.

Even on a Bonjour network, you have to work a bit to get the file to send itself. It requires one (or more) status changes on either (or both?) of the Macs involved. In my case, I tested this by activating Bonjour chat on my G5-based desktop. For me, this was the only status change required to activate the file transfer function. But for Kirk, who already had Bonjour running, he had to change his status message on the target machine a couple times before the infected Mac noticed and then tried to send him the file. However, Kirk’s son Perceval, not being warned that this dangerous activity was occurring on the home network, turned on his iBook, logging in to iChat automatically. Since he logs into both AIM and Bonjour, this triggered the “hot” machine to send files to both the iBook and Kirk’s iMac.

You still have to manually accept the file (then expand it and then double-click it) to infect your machine. Clearly, this thing is not going to spread like wildfire via iChat.

So it seems the “iChat transmission” aspect of the Leap-A malware has been greatly overstated—unless you use Bonjour iChat, you’ll never see it arriving on your machine in this manner.

Infecting (and Breaking) Cocoa Applications

This was the area where both Kirk and I were really confused. Everything we’d read indicated that our Cocoa applications should be quickly infected by Leap-A, and at that point, they would then stop working. Yet as we kept testing, everything continued to work. I even tried something radical (which I would never recommend on any production machine), and made the entire Applications folder read and write accessible to all. Even then, I could launch, quit, and relaunch Cocoa apps at will. The only sign of Leap-A was a one-line entry in the console.log file each time I launched a Cocoa app:

Safari: Can’t open input server /Users/robg/Library/InputManagers/apphook.bundle

For whatever reason, the InputManager was failing to load when I opened a Cocoa app. Kirk was seeing the same thing on his machine, and after a lot of brainstorming (and a fair bit of cussing), we found out why it wasn’t working. It turns out that Leap-A will only modify Cocoa applications that are owned by your user, and not the system. Since both Kirk and I were testing with Apple-provided apps, all of which are system-owned, we couldn’t corrupt any of those apps. Safari, iChat, Mail, and the like are all seemingly safe from the effects of Leap-A.

After this discovery, we started experimenting, and figured out how this thing works with a new infestation. Say it’s a typical workday, and you’ve launched OmniWeb, surfed the Web, and found some cool pictures of OS X 10.5. You download the archive, expand it, then double-click the JPEG. You’re a bit surprised when the Terminal window opens, and no pictures show up. But it’s a busy day, so you don’t think much of it. You have, of course, now installed the malware on your machine. You quit OmniWeb, go about some other work, then launch OmniWeb a bit later in the day. At this point, Leap-A strikes, and OmniWeb is now infected. The reason OmniWeb becomes infected, and not Safari, is that OmniWeb is installed via a drag-and-drop. When you install in this manner, your user is the owner of the program, not the system. Hence, it was susceptible to Leap-A.

As Andrew Welch noted Thursday, when you try to launch the newly-infected application, an apparent bug (or is it a feature?) in the code prevents it from launching. But, behind the scenes, a lot just happened:

A new copy of latestpictures.tgz was copied to /tmp, if required. This brings the malware back to life after a reboot.

A new version of the input manager was installed, if required. So even if you manually erase this folder, it will come back if you run an infected application again.

A Spotlight search for the most-recently-used user-owned applications is run, and assuming that those apps are Cocoa apps, then up to four of those programs at a time are infected and will also break.

Now, the good news in all of this is the bug (feature?) that breaks the infected application. Since, in this example, OmniWeb is no longer working, you’ll be very unlikely to launch it again after that first “dead” double-click. Instead, you’ll probably just go download a clean version, which won’t be infected. If the bug (feature?) didn’t exist, then you’d never know that each launch of OmniWeb was also searching for other clean apps to infect, and your machine would become much more badly infected over time. That’s why I think this is a bug, not a feature. (It’s only a feature if the author’s intent is to only break all your installed applications.)

The above process will repeat each time you try to launch an infected application. Eventually, if you let this go on long enough, you’d find that all of the Cocoa applications that are owned by your user will no longer work. Hopefully, though, the non-functional applications would indicate to you that there was a problem. What do you do then?

Recovering from Leap-A

For this particular piece of malware, I think the simplest solution is to remove the virus and replace any damaged applications. You could choose to reinstall OS X, but since the malware doesn’t affect any system-owned applications, and your data files are safe, this seems like overkill to me. So here’s a step-by-step guide to removing Leap-A from your system:

Delete latestpics.tgz from /tmp.

Delete the InputManagers folder in your user’s Library folder.

Delete the latestpics.tgz file if you still have it living anywhere on your Mac.

Identify broken applications and replace them with fresh originals.

This last step is where things get a bit tricky. If you try to open a broken application, you’ll reinstall the malware, and possibly infect a few more applications. Hopefully you can simply remember which programs don’t work. But if you’re not sure, you could try these commands in Terminal:

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

The first command moves into the Applications directory; the second command checks the modification times on executables within application packages in that folder. (If you store other programs elsewhere, cd to that directory, too, and then repeat the second command.) Typically, the modification time on an executable will not usually change after you install it (unless you run an updater for it, which you would hopefully remember).

Since Leap-A does make changes to the executable, we can look for changes to the executable’s timestamp to identify affected applications. The last bit of the command, -cmin 60, tells find to show applications modified in the last 60 minutes. Modify that time period as necessary for your system; hopefully if you were to get infected, you would notice very quickly, so you could use 5 or 10, not 60. If you don’t recall running an update to something in the returned list, delete the program and reinstall it from source.

Conclusion

Leap-A is certainly a tricky piece of code. Due to a combination of bugs in its code and decisions made by the author, however, it’s not nearly as malicious as it could have been. It really does seem like a “proof of concept,” designed to show that such things are possible, without doing a great amount of damage. It should, however, serve as a good wake-up call for all of us to closely examine those things we download prior to making the double-click decision.