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.)
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
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:
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
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
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:
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:
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,
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
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.
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.